CIRA not connecting after re-imaging (EMA 1.9.1)

[JRüeg]

We have the same issue described in https://community.intel.com/t5/Intel-vPro-Platform/Rebuilding-machines-with-EMA-not-reconnecting-to-CIRA/m-p/1425442?search-action-id=99648598471&search-result-uid=1425442.

After we re-image a device, a new additional endpoint object is created in EMA that does not have the provisioning information and cannot connect CIRA. When we use the script provided in https://www.intel.com/content/www/us/en/support/articles/000087537/technologies/intel-active-management-technology-intel-amt.html the objects are merged but CIRA still does not connect. So we loose the ability to wake up the device or use KVM to view the boot process.

The only solution provided in the original thread is to unprovision the device.

We reinstall devices because windows is not working correctly, so unprovisioning before each reinstall is no option. 

Re-Imaging is a standard process that we use often when a computer has any kind of problem. It is fully automated and provides an easy solution for our support staff.

Intel EMA should be able to handle this without any manual interventions.

After reinstalling we have two endpoints in EMA. The new one shows "Admin Control Mode" in red because "EMA does not have the record" for this provisioning. This endpoints gets "Connected" when the device is on and the agent runs.

The other endpoint shows the old "Last Connect Start Time" and the agent in Windows will not connect this. But "Admin Control Mode" is black and when the device is turned off, CIRA will connect and I can wake up the endpoint over this object.

Since the old endpoint object is able to connect CIRA, it should be possible to merge the objects without loosing this capability.

I can reproduce the issue and have a database backup in our lab with the two endpoint objects where one does connect cira and the other connects the agent. So I could test different merge scripts or check additional stuff in the tables to help troubleshoot this. 

Which tablets / infromation in the database is relevant for the CIRA connection to work?

Environment Information:

We use EMA 1.91

The AMT profile is configured with "Always Use Intel AMT CIRA"

AMT Autosetup is configured to do Certificate Provisioning

The administrator password is randomized, mebx password does not get set in this lab environment

Initial provisioning works and CIRA connects. The problem only occurs with reinstalled computers.

[Victor_G_Intel]

Hello JRüeg,

Thank you so much for contacting Intel customer support,

In order to investigate this further on our end, please provide the information below:

1. AMT version(s) used:
2. Is the EMA server installed on a physical server or a virtual machine?
3. How many endpoints do you have in your deployment?
4. Please share the OS being used on the EMA server.

Best regards,

Victor G.

Intel Technical Support Technician  

[JRüeg]

1. AMT version(s) used:
   I have tested this with a version 14.1.60 on a Lenovo T14 Gen 1 directly connected over ethernet. If this was resolved in a newer version, kindly tell me the version required
2. Is the EMA server installed on a physical server or a virtual machine?
   On a virtual machine
3. How many endpoints do you have in your deployment?
   We are still in testing mode but it will be around 10k endpoints when productive
4. Please share the OS being used on the EMA server.
   EMA is installed on Windows Server 2019 and Database is Microsoft SQL Server 2014.

[MIGUEL_C_Intel]

Hello, JRüeg,

We reviewed your request with the engineering department, and the troubleshooting for duplicate endpoints is erasing them manually from the database with the article mentioned before. Intel® EMA works together with hardware and operating system, and not possible to skip the validation.

Why are Intel® Endpoint Management Assistant (Intel® EMA) Endpoints Showing Duplicated After Re-imaging?

https://www.intel.com/content/www/us/en/support/articles/000087537/technologies/intel-active-management-technology-intel-amt.html

We will take into consideration your request, and hopefully, in future Intel® EMA releases, we will include a different workaround for duplicate endpoints.

Regards,

Miguel C.

Intel Customer Support Technician

[JRüeg]

Dear Miguel

Thank you for your reply. Having to use a manual way to erase duplicate endpoints is unpleasent but the real problem is, that it does not result in a working endpint object. 

When we use the documente script to merge the duplicates in the database, CIRA will not connect and I cannot wake up such a computer anymore.

[SergioS_Intel]

Hello JRüeg,

Can you please send us a screenshot of the error that you are getting?

Best regards,

Sergio S.

Intel Customer Support Technician

[JRüeg]

Dear Sergio

I am unsure of what you would like to see a screenshot of. The error shows like this:

CIRA will not connect and stays yellow. When the computer is on, the first two dots get green. But in both states CIRA will stay yellow. Before reinstalling the client CIRA would be green and I could wake up the client using the method under "Manage this endpoint". After the reinstall there are two objects. With one of them CIRA works and I can wake up the computer, but under Windows the agent wont connect. With the other Admin Control Mode is red because the record does not know the admin password. After applying the merge script, CIRA does not work, only the agent will connect in a booted windows. I would like this newly created object not only to have the AMT admin credentials and provisioning info but also to retain CIRA connectivty.

We regularly reinstall some of our 10k computers, this is fully automated and can be initiated by the user herself. Having to apply the merge script is unpleasent but doable. But when it does not allow us to manage the computers afterwards, this is no solution. 

This was not necessary with Intel SCS. A provisioned computer would neither create a new object in SCS, nor did we loose the ability to wake up the client. 

[MIGUEL_C_Intel]

Hello JRüeg,

We are investigating your case, an update will be provided soon.

Regards,

Miguel C.

Intel Customer Support Technician

[JRüeg]

Thank you Miguel

I will be out-of-office for a few days but reply to any new posts/questions by 19. May.

best regards

Jasmin

[Jools86]

Hi JRueg,

I had the exact same issue. I had to add domain suffix to MEBx (within BIOS). It was really messy.

Solved: Intel EMA Agent - Rebuild - Intel Communities.

As it stands, I ran that SQL job every night and for the most part it works.

Have you also tried the following (as a test):

• De-Provision PC (Via EMA Console)
• Re-Provision PC (Via EMA Console)
• Restart EMAAgent on Client

[JRüeg]

De- and Re-Provisioning after reimaging works but has a grave downside: During the initial staging we can ensure computers are connected over a supported network adapter. For pki provisioning to succeed this must be an integrated network card or TBT 4 dock with AMT capability for notebooks without an integrated network card.

During reimaging this cannot be ensured. The user might only have an usb-c dock or use an usb-c adapter for the reinstall. So after unprovisioning this device will not be manageable anymore.

Reinstalling a computer should not require us to unprovision a correctly provisioned device. Reimaging worked flawlessly with Intel SCS and unprovisioning will mean we loose the ability to manage and the functionality to start computers in a maintenance windows over amt alarm clocks. 

Manually changing or correcting computers might be a solution for small businesses but is not feasible for companies with several thousands of computers. And I would guess it is those companies that explicitly buy the more expensive vPro computers for their manageability options.

[XCEL]

Was this ever resolved? I was hopeful that EMA was going to provide great benefits for remote management but the more I work with it, the more issues I find.

Losing the ability to manage an endpoint after remote imaging is a major problem, did you find a solution?