- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a client that is setup in our EMA server under a tenant. We have a valid certificate with the 2.16.840.1.113741.1.2.3 extension from Godaddy. But when we try to provision, we always see this:
Provisioning Record State: Pending Activation
I'm attaching screenshots of everything I can think of. I've redacted everything.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Find,
Thank you for sharing the screenshots and ECT logs with us.
Based on our review, we would like to share the following observations and recommendations:
Current Status
- From the screenshot provided (General tab), we can see that CIRA status is “Not Connected” and the system is in a Pending Activation state.
- The OID value you shared appears to be correct, and the certificate is valid.
ME Driver Recommendation
- From the ECT logs, we noticed that the Intel® Management Engine (ME) drivers on the endpoint are outdated.
- We recommend updating the endpoint to the latest Intel Management Engine drivers, as this can impact AMT provisioning and connectivity.
You can download the latest ME drivers for Windows 10 and Windows 11 from the link below:
AMT Provisioning over WLAN – PKI DNS Suffix Configuration
Provisioning over WLAN requires physical access to each system in order to configure the PKI DNS Suffix in the Intel® AMT MEBx. This is similar to ensuring that the LAN DNS suffix matches the provisioning certificate.
When the PKI DNS Suffix configured in MEBx matches the provisioning certificate, the network DNS suffix is ignored. This method applies to both:
- AMT LAN systems (with Ethernet)
- LAN‑less systems (wireless‑only)
Please follow the steps below:
- Log in to the Intel® AMT MEBx
- Default password: admin
- For MEBx access instructions, please refer to your system OEM documentation
- If this is the first login, you will be prompted to change the password
- Navigate to:
- Intel® AMT Configuration → Remote Setup and Configuration → TLS PKI → PKI DNS Suffix
- If the PKI DNS Suffix option is not visible, AMT is currently provisioned. In that case:
- Go to Intel® AMT Configuration → Unconfigure Network Access → Full Unprovision
- Complete the unprovisioning process
- Enter the PKI DNS Suffix so that it matches the provisioning certificate
- Example: intel.com (without quotes)
- Exit MEBx and save the changes
- Proceed with provisioning the client again
- Follow the steps outlined in the Intel® EMA Administration and Usage Guide, under
- Intel® AMT Provisioning / Setup Flow in Intel® EMA
Please let us know once the above steps are completed or if you encounter any issues along the way. We will be happy to continue assisting you.
Best regards,
Vijay N.
Intel Customer Support
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We updated the drivers, the DNS Suffix, and moved to Ethernet instead of WLAN. I enabled network, and now we're in the "POST_PROVISIONING_STATE" and is now showing the following in EMA:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Reperio,
Thank you for your response. As per the ECT logs, we can see that the ME drivers are up to date and the PKI DNS suffix has been added.
Could you please confirm where the GoDaddy certificate was converted to a PFX file? Specifically:
- Was it converted on a local system and then pushed to the EMA server machine, or
- Was the certificate converted directly to a PFX file on the EMA server machine?
Additionally, could you please confirm whether the endpoint was previously provisioned in CCM mode?
Environmental Details Required
To assist further, kindly provide the following details:
- OS version of the EMA Server
- SQL version
- Installation type (Physical or Virtual)
- Will EMA and SQL be hosted on the same server?
- Authentication mode (Local, Azure AD, or Windows AD)
- Intel® EMA version
- Location of endpoints (Local or Remote)
Best regards,
Vijay N.
Intel Customer Support Technician
intel.com/vPro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The PFX was created/converted on a local system and then pushed to the DMA server machine.
We do not believe the endpoint was previously provisoined in CCM mode.
- OS version of the EMA Server - Windows 2019 Standard
- SQL version - SQL Server 2022
- Installation type (Physical or Virtual) - Virtual
- Will EMA and SQL be hosted on the same server? - Same
- Authentication mode (Local, Azure AD, or Windows AD) - Windows AD
- Intel® EMA version - 1.14.5.0
- Location of endpoints (Local or Remote) - Remote
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Reperio,
Thank you for your response. As you mentioned, the PFX file was created/converted on a local system and then pushed to the DMA server machine. This indicates that the certificate was installed in an incorrect location.
To resolve this, please install the .pfx certificate directly on the Intel® EMA server, ensuring it is imported with the new name into the EMA console.
Required Actions:
Once the PFX file has been successfully installed on the Intel® EMA server, please complete the following steps:
- Update the certificate directly within the Intel® EMA console and ensure it is properly associated with the relevant endpoint groups.
- Intel® EMA provides an option (which must be enabled) to automatically push configuration changes to endpoints. Enabling this option will help streamline the update process and reduce manual effort. Please refer to the screenshot below for guidance.
- After updating the certificate in the Intel® EMA console, confirm that it is correctly assigned to the appropriate endpoint groups. Additionally, in the Intel® AMT Auto Setup settings, select the newly updated certificate so it is used for provisioning the endpoints.
- Restarting the endpoints will help accelerate the application of the updated configuration.
Please proceed with the above steps and let us know once they are completed, or if you require any assistance enabling the automatic synchronization option.
Best regards,
Vijay N.
Intel Customer Support Technician
intel.com/vPro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To resolve this, please install the .pfx certificate directly on the Intel® EMA server, ensuring it is imported with the new name into the EMA console.I don't really understand what you mean by this. Are you suggesting that we copy the .PFX file to the VM that's hosting the EMA server; and then using the web-browser locally on that VM, upload the certificate to the tenant in the EMA web portal (please see the screenshot for the location)?
Separately, the "Agent Auto Update" was already set for the Swarm Server Settings (please see the screenshot).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Reperio,
Thank you for your message. I understand the confusion, so I’d like to clarify the expected process and answer your question directly.
To confirm first: No, we are not suggesting that you create the PFX on a different system and later upload it from the EMA server via the browser. The key issue is where the PFX file is created, not where the browser is used.
Correct and Supported Process
The .PFX file must be created on the same machine where the Intel® EMA server is installed. The reason for this is that the private key must be generated and stored locally on the EMA server to ensure proper certificate binding during AMT certificate‑based provisioning.
Please follow these steps:
- On the EMA Server machine itself
- Import/install the GoDaddy certificate (CRT + private key) locally
- Convert the certificate into a .PFX file on the EMA server
- Do not create the PFX on another system and copy it over
- Upload the PFX into the EMA console
- Log in to the EMA Web Console as Tenant Administrator
- Go to Settings → Certificates
- Upload the newly created .PFX file and assign a new, clear name
- Assign the new certificate to Endpoint Group
- Open the relevant Endpoint Group
- Select Intel® AMT Auto Setup
- Set Activation Method to Certificate‑Based Provisioning
- From the certificate drop‑down list, select the newly uploaded certificate
- Save the configuration
- Restart the endpoints
- To expedite provisioning, reboot the endpoints so they pick up the updated configuration
Key Point
Creating the PFX on a separate system and copying it to the EMA server is not supported and can lead to provisioning failures due to private key and certificate trust issues.
Best regards,
Vijay N.
Intel Customer Support Technician
intel.com/vPro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did the requested steps, it's all still in the same state as before.
I even tried doing a full unprovision from the bios and starting over, and still ended up in the same state.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Reperio,
Thank you for your response.
We have reviewed the ECT logs, and the following entries were observed:
- CIRA Server: Not Found
- CIRA Connection Status: NOT_CONNECTED
- CIRA Connection Trigger: USER_INITIATED
Additionally, the CIRA server name is not being reflected in the logs. This indicates that the EMA server FQDN is not being resolved or reached, which suggests that there may be a network restriction or firewall blocking the communication.
To further diagnose this, could you please run the following command on the affected endpoint and share the output with us?
PowerShell command:
PowerShell
Test-NetConnection -ComputerName <EMA-FQDN> -Port 8080
Please also ensure the following:
- Port 8080 is not blocked by any local or network firewall.
- Confirm whether the endpoint is connected through a VPN, as this may impact CIRA connectivity.
We look forward to your findings so we can continue troubleshooting accordingly.
Best regards,
Vijay N.
Intel Customer Support Technician
intel.com/vPro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
PS C:\windows\system32> Test-NetConnection -ComputerName e---.-----.---- -Port 8080
ComputerName : e---.-----.----
RemoteAddress : ---.---.---.---
RemotePort : 8080
InterfaceAlias : Ethernet
SourceAddress : 172.22.200.156
TcpTestSucceeded : True
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, no, there's no VPN. But how do we know that the DNS I'm doing the test with is the DNS that the client has been provisioned with? How does this interact with the CIRA suffix (which is supposed to not resolve)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Reperio,
This is regarding the ongoing issue. We have sent an email to you. We request you to kindly review the details and revert back to us in email.
We thank you for your co-operation.
Regards,
Vijay N
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Reprior,
Thank you for your continued cooperation.
Based on the log analysis, we observed that most Intel® EMA components are running on version 1.14.5.0; however, the Manageability Server component is still referencing version 1.14.4.0. This indicates a potential version mismatch or incomplete upgrade, which may be contributing to the provisioning and CIRA connectivity issues you are experiencing.
Manageability log entry:
2026-04-09 23:07:40.1114|ERROR||8984|12|UnhandledExceptionEventSink - MeshManageabilityServer.Program, EMAManageabilityServer, Version=1.14.4.0, Culture=neutral, PublicKeyToken=57d11e903ea1ca2c - EVENT: Exception, System.IO.FileLoadException: Could not load file or assembly 'Manageability Stack, Version=1.14.4.0, Culture=neutral, PublicKeyToken=57d11e903ea1ca2c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Regards,
Vijay n
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page