CIRA not connecting after removing duplicate with script "Remove-DuplicateEndpoints"

[LucasOIZ]

Hello

I'm currently experimenting in our test lab with using the Remove-DuplicateEndpoints.ps1 provided in the Intel EMA API Scripts because our enterprise contact told me that the SQL manipulation we were told to do to get rid of duplicates is no longer supported.

The issue I'm having is with this following scenario:

1. Client X is fully provisioned, CIRA connected, and Hardware Manageability is working correctly
2. OS Re-Imaging occurs
3. Client is now duplicated in EMA
4. I use the Remove-DuplicateEndpoints.ps1
5. The old endpoint gets removed, and record is being migrated to the new endpoint
6. New endpoint is stuck on "Pending Configuration"
7. EMALog-ManageabilityServer-Log shows error: "The realm value was used already" (See below)
8. CIRA never gets connected, but the Hardware Manageability works with no issue

About our Infrastructure:

• EMA-Server: 1.12.2.0 running on Server 2019 / Virtual-Server OnPrem
• EMA-Agent : 1.12.04
• AMT Configuration: ACM, CIRA / FQDN Source: Primary DNS / IP Address: From the DHCP Server
• Using own PKI-Certificates since we run on a ".loc" domain (Cert gets loaded into the system by Thumb drive)
• Clients are connected by Ethernet-Wire or WLAN without adapters an such.

The in Point 7 noted logs (also in the attachments):

2024-10-28 15:08:52.2753|INFO||740|63|PerformAction - MeshManageabilityServer.CentralManageabilityServer, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Message: Attempting Non-TLS Mesh phase 2 connection : (XXZN0083,D043C0F9). 
2024-10-28 15:08:52.2753|INFO||740|63|PerformRound2Provisioning - MeshManageabilityServer.CentralManageabilityServer, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Message:AMT Profile detected : (XXZN0083,D043C0F9). 
2024-10-28 15:08:54.8540|INFO||740|63|CleanupAmtConfigurations - MeshManageabilityServer.code.AmtSetup.CleanupManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Start cleaning up AMT configurations : (XXZN0083,D043C0F9). 
2024-10-28 15:08:54.8540|INFO||740|63|CleanupAmtConfigurations - MeshManageabilityServer.code.AmtSetup.CleanupNetworkConfigManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Disable wired 802.1X settings : (XXZN0083,D043C0F9). 
2024-10-28 15:08:55.1197|INFO||740|63|CleanupExistingWirelessProfiles - MeshManageabilityServer.code.AmtSetup.WirelessManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Remove WiFi profiles : (XXZN0083,D043C0F9). 
2024-10-28 15:08:55.3163|INFO||740|63|CleanEnvironmentDetection - MeshManageabilityServer.code.AmtSetup.CiraManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Disable environment detection : (XXZN0083,D043C0F9). 
2024-10-28 15:08:55.3788|INFO||740|63|RemoveRemoteAccessPolicies - MeshManageabilityServer.code.AmtSetup.CiraManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Removing remote access policies : (XXZN0083,D043C0F9). 
2024-10-28 15:08:55.5976|INFO||740|63|RemoveRemoteAccessServers - MeshManageabilityServer.code.AmtSetup.CiraManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Removing remote access servers : (XXZN0083,D043C0F9). 
2024-10-28 15:08:55.8319|INFO||740|63|RemoveAllUserAclEntries - MeshManageabilityServer.code.AmtSetup.UserAclManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Remove all user ACL entries : (XXZN0083,D043C0F9). 
2024-10-28 15:08:56.2852|INFO||740|63|RemoveAllCertificatesAndKeys - MeshManageabilityServer.code.AmtSetup.TlsManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Remove certificates and keys : (XXZN0083,D043C0F9). 
2024-10-28 15:09:06.7130|INFO||740|63|SetDigestRealm - MeshManageabilityServer.code.AmtSetup.CleanupManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - Set current digest realm : (XXZN0083,D043C0F9). 
2024-10-28 15:09:06.8537|ERROR||740|63|SetDigestRealm - MeshManageabilityServer.code.AmtSetup.CleanupManager, EMAManageabilityServer, Version=1.12.2.0, Culture=neutral, PublicKeyToken=Removed - [1] - The realm value was used already : (XXZN0083,D043C0F9). 

The system status:

Although CIRA is not connected HW-Manageability still works:

CSME Discovery looks OK:

Attached is a XML from the EMA Config Tool which in my eyes also looks ok.

Thanks in advance.

Lucas

[Suneesh]

Hello Lucas,

Good day.

Thank you for sharing the details.

Could you please also share the Swarm server logs and ECT logs from the endpoints.

Please run this on the Command line and share the output.

   Open a command line as Administrator in the endpoint.

   Go to the default path \c:\Program Files\Intel\Ema Agent\

   Run the command: EmaAgent.exe -swarmserver

Intel® EMA Configuration Tool (ECT) Logs:

Download the tool from the following link: Intel® EMA Configuration Tool

Installation:

Download and unzip the tool.

Double-click the .msi file and follow the installation prompts.

Run the Tool:

a. Open a command prompt as an administrator (or use Windows PowerShell*).

b. Navigate to the installation folder (default: C:\Program Files (x86)\Intel\EMAConfigTool).

c. Run the following command:

EMAConfigTool.exe --verbose

Also please share below details- 

SQL version 

Location of both; (physical, virtual) 

Will they be on the same server machine? 

Authentication mode: Local, Azure AD, or Windows AD 

Number of endpoints to be provisioned. 

Location of endpoints: local or remote. 

FQDN: 

Additionally, let us know if the endpoint with the issue is within the company domain, using VPN and out of domain, or out of domain without VPN.

Looking forward to your response.

Regards,

Suneesh

[LucasOIZ]

Hello, thanks for getting back to me.

Sure, please check below for the requested information:

Could you please also share the Swarm server logs and ECT logs from the endpoints.
-Attached

Run the command: EmaAgent.exe -swarmserver

Intel® EMA Configuration Tool (ECT) Logs:
XML Attached in original post, added it again here (XXZN0083_System_Summary_Clean.xml).

Also, please share below details-
SQL version:

- SQL 2019 Standard (64bit) v15.0.4395.2

Location of both; (physical, virtual)
- EMA: Virtual On-Prem
- SQL Virtual On-Prem

Will they be on the same server machine?
- No, EMA/SQL are on different virtual machines

Authentication mode:
- Windows AD

Number of endpoints to be provisioned.
- In the test lab, ~20
- In Production, ~13K

Location of endpoints: local or remote.
- Remote site(s) but within same network

FQDN:
-I guess from the EMA server?: kcm9152.tsh.tstkfk.loc

Additionally, let us know if the endpoint with the issue is within the company domain, using VPN and out of domain, or out of domain without VPN.
- Within company domain, we don't use OOB management/VPN

[Suneesh]

Hello Lucas,

Good day.

Client Control Mode works both into the company domain and out of band with user consent. If out-of-band is not a requirement and you require User-Consent, the Client Control Mode is the best option, it is not necessary to create and add the self-Cert domain in MEBx. CCM works with endpoints into the domain and outside, the user gives the approval.

The self-Cert provisioning has disadvantages, every time we do changes to the configuration, we need to reprovision each endpoint from scratch. Please refer to the logs mentioned below:

<ProvisioningTLSMode>PKI</ProvisioningTLSMode>

<ProvisioningRootCert>REMOVED</ProvisioningRootCert>

<ProvisioningCertHashType>SHA256</ProvisioningCertHashType>

<ProvisioningServerFQDN>REMOVED.tsh.tstkfk.loc</ProvisioningServerFQDN>

<ProvisioningServerIP>Not Set</ProvisioningServerIP>

Best Regards,

Suneesh_Intel

[LucasOIZ]

Hello,

CCM is not an option since we need the KVM function of AMT, to wake up and PXE boot clients sometimes while they are inside our network.

"every time we do changes to the configuration, we need to reprovision each endpoint from scratch"

So why was I able to adopt 13K endpoints from SCS to EMA, but can't "adopt" them inside the same EMA instance to remove it's duplicate?

Rgds,

Lucas

[Arun_Intel1]

Hi LucasOIZ,

Greetings!

 Intel is doing an SQL script to fix the duplicate endpoint issues. Please give us 3 to 4 business days.

Best Regards

Arun_intel

[Suneesh · Accepted solution]

Hello Lucas,

Good day.

Please find the SQL script below. You won’t need the API to merge duplicate endpoint IDs.

Please don’t hesitate to contact us for any further assistance.

Regards,

Suneesh

[LucasOIZ]

Hello Suneesh

Thanks for the SQL!

I was just curious because Mr. vPro, Darek told us that SQL duplication removal is no longer supported.

I see that this SQL is for version >=1.14 which comes in handy since we are updating our integration environment next week.

Regards,

Lucas

[Suneesh]

Hello Lucas,

Good day.

Thank you for the update.

Please run the provided script and let us know the outcome. If further assistance is needed, feel free to reach out.

Regards,

Suneesh

[LucasOIZ]

Hello @Suneesh 

Thanks again for the SQL.

In the meantime we have updated our lab-env to EMA version 1.14.1.0 and replaced our existing duplicate-removal-script with the one you provided.

So far the script works perfect!

Regards,

Lucas