Community
cancel
Showing results for 
Search instead for 
Did you mean: 
idata
Community Manager
1,350 Views

Question about vPro provision with SCCM 2007 SP2

We are trying to provision our Intel vPro client(Dell OPTIPLEX990) with SCCM 2007 SP2.

 

We created test certificates according to Intel's manual(Quick Start Install Guide for

 

SCCM SP2 Out of Band Management 2.0 ),and config these certificates to OOB management of SCCM 2007.

 

But it always failed to discovery management controllers,the status is "detected".

We can login to vPro with Manageability Commander Tool or Web GUI(http://172.20.230.28:16992 http://172.20.230.28:16992),

 

and control the remote power.

We found the following messages on amtopmgr.log file,but don't know the cause of the problem.

-------------------------------------------------------

 

CAMTDiscoveryWSMan::DoConnectToAMTDevice: Failed to establish tcp session to 172.20.230.28:16993.

 

AMT Discovery Worker: Wakes up to process instruction files

 

AMT Discovery Worker: Wait 20 seconds...

 

Server unexpectedly disconnected when TLS handshaking.

 

**** Error 0x8dab7c0 returned by ApplyControlToken

 

-------------------------------------------------------

 

How can we solve the problem?

 

Thanks in advance.

This is the AMTOPMGR.log on the SCCM Provisioning server:

=============================================================================================

 

AMT Discovery Worker: Wakes up to process instruction files SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Wait 3600 seconds... SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Wakes up to process instruction files SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Reading Discovery Instruction C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\amtopmgr.box\disc\{472EF14B-D4B8-4A68-B759-CEAF94D6CE0D}.RDC... SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetThisSitesNetBiosNames 'SMS00001', NULL, 'NI0' SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 2 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine WIN-MECI-SCCM - 172.20.230.231 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 4 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine WIN-MECI-SCOM - 172.20.230.28 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 5 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine WIN-VM-SCCM - 172.20.230.69 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 6 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine WIN-MECI-AD - 172.20.230.230 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 7 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine POSREADY1 - 172.20.230.222 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 11 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine WIN-ARS-SCCM - 172.20.230.219 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 12 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine POSREADY2 - 172.20.230.223 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetAMTMachineProperties 13 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: CSMSAMTDiscoveryWorker::RetrieveInfoFromCollection: Found machine WIN-MECI-WEBS - 172.20.230.232 from Collection SMS00001. SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Execute query exec AMT_GetProvAccounts SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Finish reading discovery instruction C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\amtopmgr.box\disc\{472EF14B-D4B8-4A68-B759-CEAF94D6CE0D}.RDC SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Parsed 1 instruction files SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: There are 8 tasks in pending list SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Send task to completion port SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

Auto-worker Thread Pool: Current size of the thread pool is 1 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

AMT Discovery Worker: Send task to completion port SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

Auto-worker Thread Pool: Current size of the thread pool is 2 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

Auto-worker Thread Pool: Work thread 6396 started SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 6396 (0x18FC)

 

AMT Discovery Worker: Send task to completion port SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

Auto-worker Thread Pool: Current size of the thread pool is 3 SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

Auto-worker Thread Pool: Work thread 3224 started SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 3224 (0x0C98)

 

AMT Discovery Worker: Send task to completion port SMS_AMT_OPERATION_MANAGER 2011/10/31 17:40:31 4852 (0x12F4)

 

Auto-worker Thread Pool: Current size of the thread pool i...
0 Kudos
12 Replies
idata
Community Manager
121 Views

You mentioned connectiong to the WebUI on your client and using Commander. It sounds like your client is already provisioned, perhaps in basic/SMB mode. That would explain why SCCM only detectes AMT. It sees that it's already listening on port 16992 (non TLS). Try going into the MEBx on the client and unconfiguring network access, then try detecting it again with SCCM. If it continues to just see it as "detected" you may need to add in admin password that you used in the MEBx to the list of possible passwords in SCCM.

idata
Community Manager
121 Views

Thank you,Dan Brunton.

Actually in Our client's log file(oobmgmt.log),"!! Device is already provisioned" is printed many times.

 

We tried to unconfigurate network access and change admin password,but the problem hasn't been resolved.

I wonder that we have wrong certificates,How can we confirm a certificate is correct ?

 

If our provisioning certificate is wrong, the status on SCCM will be "Detected" ?

 

(The Version of AMT isn't diaplayed on SCCM)
idata
Community Manager
121 Views

Yes, if there's a problem with your provisioning certificate it could also cause the problem you are seeing.

Are you using your own, self created, provisioning certificate, or did you get one from a 3rd party cert vendor?

If you created your own provisioning cert and entered it's root cert thumbprint into the MEBx it is deleted when you do a full unprovision. It is retained when you do a partial unprovision.

-Dan

idata
Community Manager
121 Views

 

Thanks.

We created certificates(AMT provisioning certificate,Web server certificate) on our own CA according to the next site:

http://technet.microsoft.com/en-us/library/cc161804.aspx# BKMK_AMTprovisioning2 http://technet.microsoft.com/en-us/library/cc161804.aspx# BKMK_AMTprovisioning2

The CA is running on Windows Server 2008(the same PC as Active Directory environment).

 

The AMT provisioning certificate is created with a pfx file,but Web server certificate is not a pfx file.It is only

 

a certificate template that we can select it on OOB property of SCCM 2007.

 

It is said that Web server certificate should be installed in the AMT firmware in the client computers,

 

but how can we do it?,On My MEBx configuration, we can not find any configuration about writing certificates.

I wander if we configurate certificates(AMT provisioning certificate,Web server certificate) on SCCM,then

 

after discoverying vPro,Web server certificate is to be installed in our client PC ?
idata
Community Manager
121 Views

In order to use your own provisioning certificate you need to get the thumbprint of your root CA into the MEBx using one of two methods.

1) You can key it in manually in the MEBx. Where you go to do this varies some depending on the AMT firmware version you are working with. If you can let me know the version, I can get you specific directions on how to do it.

2) Use a USB key to add the cert to the MEBx using the USBFile utility from the http://software.intel.com/en-us/articles/intel-active-management-technology-software-development-kit... AMT SDK. I've attached the steps you need to do this in a PDF.

idata
Community Manager
121 Views

Thank you very much.

 

After I had writen certificate hashes to the vPro firmware,It seemed I got a little progress.

 

The version of AMT can be displayed on SCCM 2007! However,the status of AMT doesn't have

 

any change,remains a "Detected".

The following message remain in amtopmgr.log file.

 

CAMTDiscoveryWSMan::DoConnectToAMTDevice: Failed to establish tcp session to 172.20.230.28:16993.

Between https connection and SCCM provisioning,I don't know which should be resolved on ahead.

 

maybe they are failed because of the same reason,wrong certificates?

This is our certificate hashes output by ZTCLocalAgent

 

========================================================

Intel ZTCLocalAgent Version: 6.0.2.0

Intel AMT code versions:

 

Flash: 6.1.1

 

Netstack: 6.1.1

 

AMTApps: 6.1.1

 

AMT: 6.1.1

 

Sku: 24584

 

VendorID: 8086

 

Build Number: 1045

 

Recovery Version: 6.1.1

 

Recovery Build Num: 1045

 

Legacy Mode: False

 

Setup and Configuration:

 

Not started

Zero Touch Configuration:

 

enabled

Found 9 certificate hashes in following Handles:

 

0,1,2,3,4,5,6,7,20,

Certificate hash entry:

Friendly Name = VeriSign Class 3 Primary CA-G1

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

74 2C 31 92 E6

 

07 E4 24 EB 45

 

49 54 2B E1 BB

 

C5 3E 61 74 E2

Certificate hash entry:

Friendly Name = VeriSign Class 3 Primary CA-G3

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

13 2D 0D 45 53

 

4B 69 97 CD B2

 

D5 C3 39 E2 55

 

76 60 9B 5C C6

Certificate hash entry:

Friendly Name = Go Daddy Class 2 CA

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

27 96 BA E6 3F

 

18 01 E2 77 26

 

1B A0 D7 77 70

 

02 8F 20 EE E4

Certificate hash entry:

Friendly Name = Comodo AAA CA

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

D1 EB 23 A4 6D

 

17 D6 8F D9 25

 

64 C2 F1 F1 60

 

17 64 D8 E3 49

Certificate hash entry:

Friendly Name = Starfield Class 2 CA

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

AD 7E 1C 28 B0

 

64 EF 8F 60 03

 

40 20 14 C3 D0

 

E3 37 0E B5 8A

Certificate hash entry:

Friendly Name = VeriSign Class 3 Primary CA-G2

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

85 37 1C A6 E5

 

50 14 3D CE 28

 

03 47 1B DE 3A

 

09 E8 F8 77 0F

Certificate hash entry:

Friendly Name = VeriSign Class 3 Primary CA-G1.5

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

A1 DB 63 93 91

 

6F 17 E4 18 55

 

09 40 04 15 C7

 

02 40 B0 AE 6B

Certificate hash entry:

Friendly Name = VeriSign Class 3 Primary CA-G5

 

Default = true

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

4E B6 D5 78 49

 

9B 1C CF 5F 58

 

1E AD 56 BE 3D

 

9B 67 44 A5 E5

Certificate hash entry:

Friendly Name = ProvCert

 

Default = false

 

Active = true

 

Hash Algorithm = SHA1

Certificate Hash:

 

2C 85 F3 17 BE

 

F1 E7 35 E8 C7

 

63 D5 44 18 6E

 

92 FF A8 D8 07

 

========================================================
idata
Community Manager
121 Views

I am happy to see that you are making some progress. One other thing I've noticed in your logs is that SCCM is using the IP address to contact the clients versus the fully qualified domain name. This will potentially cause problems with the AMT provisioning process.

As for seeing the systems as detected, that's not a show stopper. The fact that you can see the firmware version tells us that SCCM is able to communicate with AMT using the remote config cert.

I recommend you try following the steps in the following blog post to try and get one of your clients to provision:

/community/openportit/vproexpert/microsoft-vpro/blog/2008/09/30/using-wmi-to-force-the-sccm-agent-to-check-for-its-amt-auto-provisioning-policy http://communities.intel.com/community/openportit/vproexpert/microsoft-vpro/blog/2008/09/30/using-wm...

The WMI command in the link above will force the SCCM client agent to kick off the provisioning process with the client. You can verify it started properly by looking in the oobmgmt.log on the client. It will tell you if it successfully generated a OTP (one-time password) and sent it to SCCM to start the process. From there, watch the amtopmgr.log on your SCCM system running the out-of-band service point. It will give you details on any failures that occur.

idata
Community Manager
121 Views

It is sad that the problem has not be resolved.

It is very strange that the version of AMT can not be displayed after I wrote new certificate hashes to firmwre.

 

(I think the CA certificate is no any problem)

I found the configuration of AMT is strange too,even if I had writen CA certificate to AMT,

 

but it is displayed 0 certificate,0 trusted root on Manageability Commander Tool.

 

Is this involved in failture of https connection ?
Bruno_Domignues
Employee
121 Views

Hi,

If even after triggering the autoprovision policy, this problem still happens, I would recommend follow this debug flow:

Check if the vPro machine is in fact listening in 16993 port: from SCCM console, open the command prompt and fire telnet 16993

If is not responding, means that is something blocking the connection, and can be Windows Firewall/Antivirus, etc.. and also, a valid test is force ME to listen in this port, executing the following command (attached):

c:\>ZTClocalAgent.exe -activate (w/ administrative rights)

try again the telnet and check any error messages that can be generated running ZTCLocalAgent and test again the telnet.

If after these steps, telnet worked, try again the provisioning from SCCM and if didn't work, send to us the amtopmgr.log from SCCM in order to speed up the troubleshooting.

Best Regards!

-Bruno Domingues

idata
Community Manager
121 Views

 

Hello,Bruno Domingues.Thanks.

I failed to activate AMT configuration using Intel ZTCLocalAgent utility.

c:\>ZTClocalAgent.exe -activate -verbose

==================================================================

 

Failed performing Start Configuration command:

 

PT_STATUS_INVALID_PT_MODE: Command is not permitted in current operating mode.

Activate Intel AMT configuration:

 

Failure

 

==================================================================

What is the problem?

Bruno_Domignues
Employee
121 Views

Possibly, since it is the operation that SCCM agent is trying to do. This can be a problem with actual AMT state. Can you return the AMT to default factory mode and try it again?

Some OEMs enable this feature insite the BIOS, others you have to disable the AMT in BIOS, reboot and enable it again.

Best Regards!

-Bruno Domingues

idata
Community Manager
121 Views

 

Wonderful! The problem has been resolved after I unprovisioned AMT,then activated it with ZTCLocalAgent again.

 

Up till now,I has activated AMT configuration on MEBx menu.Maybe there is a problem in it .

Thank you,Bruno Domingues.Thank you,Dan Brunton.

Reply