SCCM SP1 Provisioning Problem

[idata]

Hello All,

Hoping someone here can help me out with a problem I'm having with provisioning our HP dc 7800 vPro pc's.

Here's the detail.

SCCM SP1, the dc7800's are on bios 1.24 and mBex firmware 3.2.1, we're using an internally issued provisioning cert as I'm still effectively piloting vPro at the moment so I was hoping to avoid buying a cert before I was sure of everything. So basically here's what I'm doing, take one fresh PC, update bios and then update mbex to 3.2.1, login to mbex and add the hash of our provisioning cert, also required to change mbex password. I'm planning on using the in band provisioning method for the time being. I have correctly set the mbex password in the OOBM component configuration and I'm confident I have everything else set up correctly as two of my PC's have managed to provision. Trouble is I can't seem to get the remaining PC's to provision even though they have beenh through the exact same setup process. They are showing as AMT Status: Detected rather than not provisioned which from what I've read means that SCCM knows they are ATM capable but is unable to login to the mbex to take the process any further. I have checked and double checked passwords both on the mbex's and in the OOBM Provisioning Setting tabs and I'm positive they match.

When the provisioning attempt takes place I can see it in the antopmgr.log

I can see it attempt the account I've put the details for and I get these messages;

Warning: Currently we don't support mutual auth. Change to TLS server auth mode.

The provision mode for device wks188.eicltd.com is 1.

Attempting to establish connection with target device using SOAP.

Warning: We don't have an provision certificate with old recorded hash.

Create provisionHelper with (Hash: 8571F29DFEB197A0D034C3EFC6E319EF*****)

Set credential on provisionHelper...

Try to use provisioning account to connect target machine wks188.eicltd.com...

Attempting to try all provision certificate to connect target device.

Failed to send TLS client hello message to server with errorcode=0x2733.

• Error 0x6feb95c returned by ApplyControlToken

Fail to connect and get core version of machine wks188.eicltd.com using provisioning account # 0.

Then it tries with the default account and we get the same messages, then it tries with a randomly generated password account.

Then at the end of the attempts I get this message;

Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 331).

Error: Can NOT establish connection with target device. (MachineId = 331)

At a bit of a loss as to what to try from here as I've tried everything I can find and every line of investigation i can see!

Any help would be really apopreciated!

Adam

[Matthew_R_Intel]

Adam,

Is the hash you enter into the MEBx the hash of the Provisioning Certificate you created or the hash of the Root Certificate Authority Certificate where the provisioning certificate was created from? As a clarifying note, it should be hash of the Root Certificate Authority Certificate you enter into MEBx of the vPro Client.

You mentioned, that you had 2 previous machines complete the provisioning process... Did you use same means to provisioning; was it agent based or did you use the Out of Band Import Wizard? I would agree that this is odd since you have to other clients already provisioned. You wouldn't happen to have the logs of the ones that properly provisioned?

--Matt Royer

[idata]

Scratch all that turns out I had written down the correct hash (of my CA) so I'm back to square one. The logs of a sucessfully provisioned machine run exactly like the logs for one that won't provision up to this point;

Try to use provisioning account to connect target machine ITWKS02.eicltd.com...

Succeed to connect target machine ITWKS02.eicltd.com and core version with 3.2.1 using provisioning account # 0.

Instead of;

Try to use provisioning account to connect target machine WKS130.eicltd.com...

Error 0x80090308 returned by InitializeSecurityContext during follow up TLS handshaking with server.

I'm certain it must be a ssl/tls issue as 80090308 is a standard message and apparently means "The Token supplied to the function is invalid" I'm re-adding the provisioning cert to my oobmp now to check that all is ok there. The other problem is I can't seem to find anyway to speed up initiation of an in band provsioning attempt for a client, so everytime I try something to fix the issue I have to wait for it to try and provision a client before I can see if it's worked. I've read that initiating a Machine Policy Retrieval Cycle should do it but it doesn't seem to make any difference so any ideas there would speed up resolution!

Thanks in advance

doh!

That totally must be it.. the first two provisioned a few weeks ago and since then i lost the bit of paper that I'd written the hash on so I wrote it down again.. but rather this time i wrote down the hash of the provisioning certificate rather than my CA. Annoyingly the messages from SCCM are rather ambiguous as when ever a client tries to provision out of band but is rejected as the machine has the sccm client installed it actually says that has received a correct hash.. Thank you very much for your insightful suggestion I have been going around in circles for days with this and as soon as I read your response it was like doh.. how dumb can i be. I'll add the correct hash on moday and confirm that it has fixed the problem but I'm convinced that will it, I've tried everything else! Thanks a lot

[Matthew_R_Intel]

Can you give me the OEM Make and Model of this platform that is giving you a problem? One thing you can try is...

1. Log into the MEBx

2. Changing the provisioning mode to SMB Mode

3. Exit out of the MEBx and reboot the client

4. Allow it to post through the AMT load screen

5. Reboot the client and log back into the MEBx

6. Perform a Full Unprovision

7. Load the Cert hash back in and try to provision the vPro client within SCCM again

I am wonder if the AMT self-signed cert date is giving you the problem.

--Matt Royer

[idata]

Right then,

The PC's are HP dc7800's.

Basically have sorted it now, I'm pretty sure you are correct about it being an issue with the Self Signed cert that is used to secure the initial conversation before provisioning. I don't need to go as far as switching the provisioning mode as long as I perform a full unprovision (even though it's not yet provisioned) after updating the mbex firmware to 3.2.1 but before entering the cert hash of my CA eveything works as expected I don't even need to reboot inbetween the unprovision and the entering the cert details. I realised that the ones that were working were the ones I'd been messing with longest and I had at some point done a full unprovision on them, I can only presume that a full unprovision causes it to recreate the self signed cert and for whatever reason the freshly created self signed cert is working correctly to secure the initial provisioning coversation.

Further info is that get similar errors when discovering the managment controllers on machines that haven't had a full unprovision before adding our provisioning cert to them. Which further points to some kind of issue with the self signed cert. Errors from amtopmgr.log below

Server unexpectedly disconnected when TLS handshaking.

• Error 0x97eb970 returned by ApplyControlToken

ERROR: Invoke(get) failed: 80020009argNum = 0

Thanks a lot,

Adam