- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
We have rolled out Intel EMA to all our new clients and now have over 4600 Nodes in the database.
We use PKI provisioning with a certificate from digicert. And random passwords for admin and mebx as recommended.
About 90% of our Hardware is the same model. An HP 1040 G10 (x360). There are many successfull provisionings for this model but even more unsuccessfull.
I probably was too fast rolling out because I only belatedly noticed, that the clients showing as Provisioned in the Endpoint Management Assistant overview are mostly only in client control mode and there are thousands of "Failed PKI provisioning"-entries in the EMALog-ManageabilityServer.txt for each day. While only about 30 to 60 are successfull each day.
Because the notebooks are sometimes connected through wifi oder vpn, some unsuccessfull clients are to be expected.
But analyzing the errors I found several notebooks connected correctly only through the hp tbt4 dock in our lan network (I225 adapter supporting AMT and working for other clients). But those are still failing. (Log attached as ClientControlModeOnly.txt)
{quote}Message:Attempting host based provisioning : (someclienthostname,4547632C).
Message:Creating DotNetWSManClient object : (someclienthostname,4547632C).
Message:Checking if unprovisioned : (someclienthostname,4547632C).
Message:Current Control mode - Client : (someclienthostname,4547632C).
Warning:Host Based Setup (1st try) - UNSUPPORTED : (someclienthostname,4547632C).
(...)
Failed PKI provisioning : (someclienthostname,4547632C).{quote}
What does this UNSUPPORTED mean? Could it be this client (and many others) managed to get into client control mode when connected over vpn or wifi and now cannot be configured even when connected correctly?
And then I found another very disturbing case: One client which was provisioned correctly in June (Log attached as ProvisioningSuccessfull.txt). This was directly after os deployment. In July, when the computer was deliverd to the enduser, I see it trying to provision again and failing (Log attached as ProvisioningFailedSameClient.txt). Fist with some error about "The connection was closed unexpectedly." but later also with "Warning:Host Based Setup (1st try) - UNSUPPORTED :"
I cannot tell whether this client was connected through wifi or lan. But since it was already provisioned from June, why should it try again anyway?
Now it's status is "Admin Control Mode" with "Retry Activation on Reconnect" and EMA does not know neither the amt admin, nor mebx password.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JRüeg,
Thanks for sharing the information.
We are checking on the issue and will provide and update as soon as possible.
Regards,
Suneesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After unprovisioning one client which I knew was already connected correctly with the tbt4-dock through the bios, provisioning to admin control mode worked without any other changes. I did not even disconnect the dock/network cable. Before, with the same setup, provisioning has failed over and over the last few days.
Seems like the clients which only made it to "client mode" are in a state that cannot fix itself?
We cannot prevent clients only making it to client control mode. Because the agent tries provisioning independently from an existing ethernet connection and because the users may undock / turn off their device any time. There are just too many affected clients to correct them individually.
Why can ema not provision those clients to admin control mode when it has provisioned them to client mode before?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Jasmin,
Greetings of the day.
We sometimes encounter the NOT_SUPPORTED error during CCM provisioning. This has occurred on a previously functioning AMT system that was re-provisioned after being un provisioned in MEBx.
Possible causes include:
- AMT is still in Client or Admin mode and not fully un provisioned.
- The PC is in EBHC mode, causing provisioning to jump directly into ACM, which EMA cannot handle.
You have a lot of moving parts here You may want to start using Intel EMA Configuration Tool (ECT) if you haven't already. It can help troubleshoot various issues.
You can download the ECT here: https://www.intel.com/content/www/us/en/download/19805/intel-endpoint-management-assistant-configuration-tool-intel-ema-configuration-tool.html
Using ECT will help us diagnose issues related to 85B46483, as seen in your log file. It appears there may also be a missing route. ECT will determine if 85B46483 can route back to the swarm server or if an environmental change is causing the issue.
Regards,
Suneesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Suneesh
Yes, many of our provisioned clients are currently stuck in client control mode. But it was EMA that got them there. We use no other provisioning tool. So we would expect EMA to handle this situation.
Provisioning can only work successfully when the client is connected through the supported TBT4 dock in our network. Which it eventually will be. But provisioning is tried automatically before this and it seems to put the client in a state EMA cannot resolve.
I know no way to prevent clients from getting stuck in client control mode. The EMA agent starts provisioning no matter what network connection the client has. And as far I understand it the agent can get until client control mode when the notebook is connected over wifi, vpn or through a not supported ethernet connection (one or more of this may be the cause of client control mode).
All of this I cannot prevent to happen with our notebooks as they are in use by endusers. They are connected to the dock only when users are in the office and the agent will not first check for this condition. Also I have no control over users suddently changing their connection or shuting down and disconnecting the computer. Isn't it normal that the log would then report a missing route to the client? Shouldn't EMA be able to pick up from where it left of on the last connection?
We do have EMA Configuration Tool installed and we use it to check the provisioning state for the SCCM inventory. I dont see much in the XML except that the client is stuck in client control mode. But I attached one such file, maybe you see more.
It is neither the client nor the network connection which prevents a successful provisioning. A notebook that was connected correctly through the dock but still stuck in client control mode would provoke these Unsupported-Errors in the log and not provision successfully. Once i unprovisioned through bios it would provision successfully through this same network connection.
If I just unprovision all clients provisioned to client control mode now a good portion would get stuck to client control mode again because I have no control whether they are used in vpn/wifi next.
- 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 Jasmin,
Greetings!
We are in the process of confirming the communication between your endpoint and the swarm server. To assist with this, please follow the steps below on both a machine using a VPN and a working machine:
1. Open a command line as Administrator on the endpoint.
2. Navigate to the default path: C:\Program Files\Intel\Ema Agent\
3. Run the command: EmaAgent.exe -swarmserver
Additionally, please confirm the following:
1. Are you provisioning the endpoints remotely, meaning you did not install the EMA agent file on the endpoints?
2. Do you have any duplicate endpoint IDs for the same machine in the EMA console under the Endpoints tab?
Your confirmation and the results of the above test will help us better understand and resolve the issue.
Thank you for your cooperation.
Best regards,
Suneesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good morning Suneesh
1. Are you provisioning the endpoints remotely, meaning you did not install the EMA agent file on the endpoints?
No, we are provisionig by installing the ema agent and the .msh file through software distribution on all clients.
2. Do you have any duplicate endpoint IDs for the same machine in the EMA console under the Endpoints tab?
Only for the machines which have been restaged since installing the ema agent. Those are not the clients I reported here. There are about 20 duplicates but about 600 computers stuck in client control mode. The machines I selected here to analyse the case do not have duplicate endpoint IDs.
I checked and the machines connected through wifi or vpn can reach the ema server (which will be usefull, once they are provisioned). Provisioning to admin control mode won't work though because of the unsupported network adapter. We do not expect provisioning to work while the notebooks are connected through wifi or vpn. The missing route may have been a client changing its ip address or going offline. This is not the typical error. Usually there is only this "unsupported", and often we also see "Expired phase 1 record, will retry on reconnection". Presumably because the server is busy whith those many failing attempts.
With these troubleshooting steps, are we trying to find the reason why clients end up in client control mode or are we trying to find why they cannot move to admin control mode later when connected through intel lan? If the first is the case, I should probably look at the early tries of each client in the older logfiles, not the attemps it makes now.
If they need a working server session to move out of client control mode again I would think clients getting stuck in client control mode is expected behaviour because network connections can change or clients may be shut down while the agent is trying to provision?

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page