EMA Config Tool - Unable to communicate with the AMT device. Limited data will be retrieved.

[Jools86]

I am seeing this error message:

Do you know what this means? It works sometimes on the same machine then this happens. I am testing ACUConfig provision/deprovision as part of an automated process.

Does AMT lock out if it gets provisioned/deprovisioned too much?

In my script it runs EMAConfigTool, de-provisions using ACUConfig, then runs EMAConfigTool to check AMT really has been de-provisioned.

On second call to EMAConfigTool (After the de-provision), I start seeing this error message.

[Jools86]

I am testing this link I found, which looks like it could be related:

Failed to Test the Connection to the Intel® AMT Device after...

[Jools86]

I am unsure if this fixed the issue. I saw the error even though I injected the reg key into the build.

Are there any gotchas that could cause the above error message when running EMAConfigTool.

LMS is started, drivers are installed. The message seems random.

[Jools86]

Just so you can see what is going on.

• We run EMA Config Tool - Works fine
• We then run ACUConfig, wait 20 seconds then:
• We re-run EMA Config Tool - the error happens.

[JoseH_Intel]

Hello Jools86,

Thank you for joining the community.

ACUconfig is intended to be used with the old SCS software. The EMAconfigtool is the EMA equivalent to ACUconfig. So what is your purpose for using ACUconfig? is it just to unprovision the endpoints?

Regards

Jose A.

Intel Customer Support Technician

[Jools86]

Hi Jose,

Thanks for the reply.

1000 of our endpoints have been provisioned with AMT Client Mode.

We want to ensure rebuilds (as we change PC name on rebuild) un-provision AMT before we install the EMA Agent (which then auto-provisions).

So our process during MDT (Windows 10 Build) is as follows

1. BIOS - Enable AMT (if not enabled)
2. Install IME Drivers
3. De-provision AMT using ACUConfig (if provisioned)
4. Install EMA Agent

[JoseH_Intel]

Hello Jools86,

Thank you for the update. So, to understand better, do you have over 1000 systems previously provisioned with SCS in Admin Control Mode? So you need to un-provision them before reimaging and reprovisioning with EMA?

Regards

Jose A.

Intel Customer Support Technician

[Jools86]

Hi Jose,

We have 2000 machines that were manually AMT provisioned into Client Control mode that we want to de-provision before installing EMA Agent.

With my automation during MDT, I also want to ensure the AMT chip is deprovisioned for existing Intel EMA (Admin Control) managed PCs that are rebuilt. The reason we need to de-provision these too is that we are not allowed to use the same computer name, so when a PC gets rebuilt it will have a new hostname.

EMAConfig Tool works fine within on our Windows 10 build using SCCM / Altiris, so EMAConfigTool works fine after ACUConfig is run,

The issue I have with the above is if I want to de-provision during a rebuild which is running via MDT then EMAConfigTool stops working after ACUConfig /deprovision is run for some reason.

Because EMAConfigTool works fine after an ACUConfig in a deployed Windows 10 build (Altiris/SCCM), and not during a REBUILD (MDT), there must be some policy or registry setting, or extra service we need to run to avoid the error I mention in my first message.

I hope the above is making sense.

[JoseH_Intel]

Hello Jools86,

Thank you for providing a clear picture of your environment. Looking at the error you mentioned in the original post, it makes sense for the EMAconfigtool not to be able to communicate with the target machine after being unprovisioned.

Regards

Jose A.

Intel Customer Support Technician

[Jools86]

Hi Jose,

To me it doesn't make sense, as it works when the Windows 10 machine is fully built just after we run ACUConfig.. As in EMA Config Tool is robust.

I suppose a better way to word the question would be as follows:

• What environmental factors/settings/services does EMA Config tool rely on to run?

For example, I know it needs the following to run properly, but there must be a couple more which are preventing it from running during our MDT build process:

• Intel LMS Service
• WINRM
• Intel WMI provider for ME
• *(there must be more).

regards,

Julian

[JoseH_Intel]

Hello Jools86,

Let me research a bit deeper on this.

Regards

Jose A.

Intel Customer Support Technician

[JoseH_Intel]

Hello Jools86,

After researching about this configuration you are attempting, we found that the system must be un-provisioned, then reimaged, and then re-provisioned again. In short when you reimage the OS AMT that has already been provisioned is wondering what this new OS is doing talking to it. The trust relationship between AMT and the OS is broken. AMT doesn't know who the new OS is, which is why you have to un-provision it and then after installing the new OS reestablish the relationship with AMT by re-provisioning it.

Not sure if this somehow answers your question, but I think this is the root cause of the issues you are facing.

Regards

Jose A.

Intel Customer Support Technician

[Jools86]

Thanks Jose for getting the reason.

It doesn't really explain why (the same process) this works when MDT is finished. But dont waste your time on this anymore. I have removed error checking from my build process to compensate.

[JoseH_Intel]

Hello Jools86,

Thank you for letting us know. Been that the case we will proceed to mark this thread as closed. If you have further issues or questions just go ahead and submit a new topic.

Regards

Jose A.

Intel Customer Support Technician