ConfigMgr Provisioning Error post-WS-MAN Translator install

[idata]

Hello,

I am running Microsoft Configuration Manager SP1, and had previously successfully provisioned several vPro systems, including firmwares 3.2.1, 4.0, and 5.0.

Recently, I installed the WS-MAN Translator utility on the server running the OOB Service Point, and now I am unable to provision any systems (even after disabling the Translator integration!). I have tried removing the certificate from the IIS website, I've tried disabling Translator integration on the OOB Component Configuration in ConfigMgr, but I'm still getting this error (during a Management Controller Discovery):

CAMTDiscoveryWSMan::DoConnectToAMTDevice: Failed to establish tcp session to 10.50.34.223:16992.

Server unexpectedly disconnected when TLS handshaking.**** Error 0x178b970 returned by ApplyControlTokenServer unexpectedly disconnected when TLS handshaking.**** Error 0x178b970 returned by ApplyControlTokensession params : http://vprosystem.domain.com:16992 , 111001ERROR: Invoke(get) failed: 80020009argNum = 0Description: The client cannot connect to the remote host specified in the request. Verify that the service on the remote host is running and is accepting requests. You may use the following command to analyze the state of the WinRM service and to configure the service, if necessary: "winrm quickconfig".Error: Failed to get AMT_SetupAndConfigurationService instance.session params : http://vprosystem.domain.com:16992 , 111001ERROR: Invoke(get) failed: 80020009argNum = 0Description: The client cannot connect to the remote host specified in the request. Verify that the service on the remote host is running and is accepting requests. You may use the following command to analyze the state of the WinRM service and to configure the service, if necessary: "winrm quickconfig".Error: Failed to get AMT_SetupAndConfigurationService instance.CSMSAMTDiscoveryTask::Execute - DDR written to D:\SMS\inboxes\auth\ddm.boxAuto-worker Thread Pool: Succeed to run the task . Remove it from task list.

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Hello,

In follow-up to this, it turned out that the devices in question were actually provisioned. I don't know for sure if this was the only cause of the issue, but after some messing around, I got the device to provision again.

Because the operating system's hostname actually matched the AMT hostname on one of the systems, I was able to take advantage of the unprovisionex.exe utility to remotely connect to, and fully unprovision the device. I was actually at home, and VPN'd into the office while doing this, which shows how, in certain scenarios, you don't even have to be physically present to resolve issues with vPro systems.

After I did a full unprovision with unprovisionex.exe, I was able to reprovision the vPro device without any issues.

FYI, the AMT Status/State showed as "Detected" in my Configuration Manager collection during this issue.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation