- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am developing a utility using the Intel EMA API. For operations requiring user consent I am having the following problem:
If I start and cancel a user consent session more than once, usually the endpoint gets into a locked state where subsequent requests to start a user consent session fail with the error `"{\"ExtendedCode\":2022,\"ExtendedMessage\":\"Endpoint is not ready to execute this operation yet, please wait and retry\"}"`.
The endpoint stays locked for a while and then it responds again.
Sometimes many tries are allowed and sometimes at the second call the endpoint gets already locked. The wait time seems to be variable as well. Other operations, like turning the endpoint off, work.
It looks like there is some kind of throttling going on, but I've been checking the documentation and looking around for answers and I have not been able to determine its logic, and how can I avoid it.
Could you please help me with this issue? Is there really some kind of throttling logic? How does it work or where can I read about it? Is there a way to avoid or relax it?
Thanks in advance,
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JMLooper,
Please refer to Section 3.0 – Troubleshooting (Page 13) of the Intel® EMA API Guide for detailed guidance.
Additionally, you can find more information in the article linked below for further reference:
Regards,
Suneesh S
Intel Customer Support Technician
intel.com/vPro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JMLooper,
We are following up on this case.
If further assistance is necessary, please do not hesitate to reply.
Regards,
Suneesh
Intel Customer Support Technician
intel.com/vpro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Suneesh,
Thank you for your quick replies.
I have been given the logs of the day I did most of the testing (08-05-2025). What I've found are the following errors related to the endpoint I did my testing on:
- `The endpoint with ID: **bleep** is not reachable.`
- `Unexpected failure getting AMT platform capabilities of an endpoint **bleep**, Exception:System.NullReferenceException Object reference not set to an instance of an object. at MeshWebCore.WebApi.Models.Repositories.EndpointRepository.<GetEndpointAmtPlatformCapabilitiesAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MeshWebCore.WebApi.Controllers.EndpointsController.<GetAmtPlatformCapabilitiesById>d__14.MoveNext()`
They appear many times during the day. Unfortunately I have not been given direct access to the server yet, so I have not been able to do testing where I see the errors as they appear. I may be able to get this access in some weeks. In any case, there is no other type of error related to the endpoint I've been using to test.
In any case, I can't extract much more information from `The endpoint with ID: **bleep** is not reachable.` than from `Endpoint is not ready to execute this operation yet, please wait and retry`. Do you know what could be happening or where else could I have a look at?
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JMLooper,
Thank you for your response.
To assist you further, could you please share the script or API you're using to develop the utility? Additionally, we’d appreciate it if you could provide the following details:
- Intel AMT version of the endpoint
- Intel EMA version
- Whether you're using a wired or wireless connection
Also, it would be helpful to understand the purpose of the utility you're developing — could you please elaborate on the use case.
Lastly, please let us know where you're seeing the error (which logs), and kindly share the specific log file where the error appears.
Looking forward to your response.
Regards,
Suneesh S
Intel Customer Support Technician
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Suneesh, thanks for your reply.
The utilities I am developing are part of a bigger application. This application lets our customer manage part of their IT infrastructure. Some of the machines are Intel vPro enabled machines. There is no single "script" to do the Intel vPro related operations, there are many classes. At the moment I can not share it's contents, but I can describe what the code does. The code does call the Intel EMA API for each Intel vPro operation we want to do on each enabled computer. For each call to the Intel EMA API we first log in (calling the `/token` endpoint).
The flows that require user consent work this way:
- We do a call to an endpoint that may require user consent.
- If the call return an Intel EMA extended code 2030 (which indicates that the action requires user consent), we perform the user consent flow:
- We call the start user consent session endpoint (https://www.intel.com/content/dam/support/us/en/documents/software/manageability-products/Latestswagger.html#operation/UserConsent_StartUserConsent).
- We prompt the user to enter the six digit code and call the send user consent code endpoint (https://www.intel.com/content/dam/support/us/en/documents/software/manageability-products/Latestswagger.html#operation/UserConsent_SendUserConsentCode).
- If the code is correct, we call the original endpoint again.
- If there are any errors, we allow to Retry. Retrying calls the cancel user consent session endpoint (https://www.intel.com/content/dam/support/us/en/documents/software/manageability-products/Latestswagger.html#operation/UserConsent_CancelUserConsent) followed by the start user consent code endpoint (and prompts the user for the code again).
- We also allow cancelling the operation altogether, which calls the cancel user consent session endpoint.
Regarding the rest of the information requested:
- Intel AMT version of the endpoint: 1.12.0.4.
- Intel EMA version: Intel® EMA v1.12.2.0 (I can see this in the Intel EMA portal).
- Whether you're using a wired or wireless connection: wired.
The logs I am looking at are in `<base-directory>/EmaWebApiLogs/<tenant-name>/2025-08-05.log`.
I cannot attach the file but I can show part of its contents (the ones related to the Endpoint I am using for testing) with the Endpoint ID redacted:
```
2025-08-05 13:04:29.5503 [ERROR], Message: Unexpected failure getting AMT platform capabilities of an endpoint **bleep**, Exception:System.NullReferenceException Object reference not set to an instance of an object. at MeshWebCore.WebApi.Models.Repositories.EndpointRepository.<GetEndpointAmtPlatformCapabilitiesAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MeshWebCore.WebApi.Controllers.EndpointsController.<GetAmtPlatformCapabilitiesById>d__14.MoveNext()
2025-08-05 13:04:29.5503 [ERROR], Message: Unexpected failure getting AMT platform capabilities of an endpoint **bleep**, Exception:System.NullReferenceException Object reference not set to an instance of an object. at MeshWebCore.WebApi.Models.Repositories.EndpointRepository.<GetEndpointAmtPlatformCapabilitiesAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MeshWebCore.WebApi.Controllers.EndpointsController.<GetAmtPlatformCapabilitiesById>d__14.MoveNext()
2025-08-05 13:04:29.5503 [ERROR], Message: Unexpected failure getting AMT platform capabilities of an endpoint **bleep**, Exception:System.NullReferenceException Object reference not set to an instance of an object. at MeshWebCore.WebApi.Models.Repositories.EndpointRepository.<GetEndpointAmtPlatformCapabilitiesAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MeshWebCore.WebApi.Controllers.EndpointsController.<GetAmtPlatformCapabilitiesById>d__14.MoveNext()
2025-08-05 13:04:50.6913 [ERROR], Message: The endpoint with ID: **bleep** is not reachable.
2025-08-05 13:04:54.0975 [ERROR], Message: The endpoint with ID: **bleep** is not reachable.
```
Thanks again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JMLooper,
Thank you for the response.
Intel® AMT runs on its dedicated chipset, which has limited processing power and network throughput. I have seen AMT get overwhelmed when a large number of remote requests come in a short time. There are multiple requests involved in starting/cancelling user consent sessions, so doing that repeatedly could cause this kind of behavior.
I understand the API requests you are using work correctly sometimes, but sometimes, they are getting the “Endpoint is not ready…” response from AMT and the API. This suggests you are coding the API calls correctly; there is just some intermittent issue affecting AMT or EMA.
My suggestions are below:
- Make sure you have all the latest updates at the endpoint from its OEM, to ensure the most recent and updated version of AMT firmware is on the endpoint. Update the BIOS and the Management Engine driver.
You can use our generic Intel® Management Engine Drivers for Windows 10* and Windows 11 2514.7.16.0
Intel® Management Engine Drivers for Windows 10* and Windows 11*
(We could try to reproduce if you update the endpoint firmware and then share the version number (ECT log.)
- In the flows you describe, when you are going between cancelling a user consent session and starting another user consent session – and in general, between AMT API requests -- try inserting a delay of a few seconds to give Intel® AMT time to be ready for another request.
- I see you are using Intel® EMA 1.12.2. Intel® EMA 1.14.3.0 has some significant performance improvements associated with Intel® AMT and loading the Hardware Manageability tab. (Note this should not have any effect or improvement on the API calls being described here, unless someone is trying to load the Hardware Manageability tab in EMA while also making those API calls).
- You can send the logs via private message, or we can create a case number, so you can reply via email instead of the community
If further assistance is necessary, please do not hesitate to reply.
Regards,
Suneesh S
Intel Customer Support Technician
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JMLooper,
We are following up on this case.
If further assistance is necessary, please do not hesitate to reply.
Regards,
Suneesh S
Intel Customer Support Technician
intel.com/vPro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JMLooper,
We are following up on this case.
If further assistance is necessary, please do not hesitate to reply.
Regards,
Suneesh S
Intel Customer Support Technician
intel.com/vPro
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page