Intel vPro® Platform
Intel Manageability Forum for Intel® EMA, AMT, SCS & Manageability Commander
2947 Discussions

SCCM - Find Out of Band Management Controllers

idata
Employee
3,874 Views

I'm working towards provisioning Vpro. Today i took the step of having SCCM find all Out of Band Management Controllers.

It does seem to have worked for some machines, but there are many entries like the ones below in the amtopmgr.log.

What I find strange about these are the IP addresses. 192.168.1.103 would be their local IP address if they were using their home router and connecting to our network via VPN. However their VPN IP address would be 10.30.*.* So why would SCCM be looking for the machine their private IP address? Is there a way to change this behavior? I did try setting up a boundary and setup 192.168 as a Slow subnet. Doesn't seem to have made a difference though.

CAMTDiscoveryWSMan::DoConnectToAMTDevice: Failed to establish tcp session to 192.168.1.103:16993. SMS_AMT_OPERATION_MANAGER 6/15/2009 7:15:00 PM 5132 (0x140C)

 

CAMTDiscoveryWSMan::DoIcmpPingForAMTDevice - failed to recieve reply from 192.168.1.103 SMS_AMT_OPERATION_MANAGER 6/15/2009 7:15:00 PM 5132 (0x140C)

 

Error: CSMSAMTDiscoveryTask::Execute, discovery to (192.168.1.103-CCIC10594L)failed SMS_AMT_OPERATION_MANAGER 6/15/2009 7:15:00 PM 5132 (0x140C)

Thanks

Paul Martin

0 Kudos
9 Replies
idata
Employee
1,746 Views

Paul,

I am pretty sure that ConfigMgr uses the IP address that was last inventoried (read: it doesn't use DNS) from the machine. How often is your hardware inventory set for your clients? Can you validate the inventoried IP addresses for the clients you're having trouble with?

Above and beyond this issue, where are you at with provisionining? Have you already requested a provisioning certificate from a supported certificate vendor? Have you gotten your PKI configuration completed, and configured your OOB Component Configuration on your ConfigMgr site server(s)?

Let me know what sort of help you need to get up and running, and I will do my best to facilitate that.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
idata
Employee
1,746 Views

Hey Trevor thanks for the reply. Had the day off yesterday, but now I'm back at it. I ran the report entitled "IP - Information for a specific computer" and then searched by the computer name listed in the following log.

CAMTDiscoveryWSMan::DoConnectToAMTDevice: Failed to establish tcp session to 192.168.1.104:16993. SMS_AMT_OPERATION_MANAGER 6/17/2009 10:05:12 AM 7440 (0x1D10) 

CAMTDiscoveryWSMan::DoIcmpPingForAMTDevice - failed to recieve reply from 192.168.1.104 SMS_AMT_OPERATION_MANAGER 6/17/2009 10:05:12 AM 7440 (0x1D10)

 

Error: CSMSAMTDiscoveryTask::Execute, discovery to (192.168.1.104-CCIC10463L)failed SMS_AMT_OPERATION_MANAGER 6/17/2009 10:05:12 AM 7440 (0x1D10)

 

The IP address 192.168.1.104 does not match any of the ones listed in the report for that machine, but the correct address does. (10.30.60.217)

Not sure why there are so many blank entries though, and I'm not sure which is the latest. Screenshot of that report below:

DNS comes back with the correct IP as well.

Above and beyond this issue, where are you at with provisionining? Have you already requested a provisioning certificate from a supported certificate vendor? Have you gotten your PKI configuration completed, and configured your OOB Component Configuration on your ConfigMgr site server(s)?

Yes, We do have the certificate . (Which I think is finally correct.) PKI, and the OOB component are configured.

Hardware inventory was set to 14 days. I just changed it to 2 days.

Right now I'm working with a small collection of IT Dept machines. 3 Laptops, and one desktop. The AMT status is unknown for all but one of the laptops.

The AMT version is showing up for all machines. 4.0.3 for the laptops (Dell Latitude E6500s) and 3.2.3 for the Desktop (Optiplex 755). The desktop has the bios update to bring it up to 3.2.3. I'll need to push this update to the rest of the company before provisioning starts.

Paul Martin

Systems Engineer

Crown Castle USA

0 Kudos
idata
Employee
1,746 Views

As I mentioned in my previous message one of the Laptops does not come back with Unknown under AMT Status.

This one comes back as detected. (CCIC10465L) I do have the Test collection configured for Auto Provisioning, but this machine doesn't appear to have been provisioned.

Attached is the log file from about 9am till now. Let me know what you think.

Thanks for the assistance.

Paul Martin

0 Kudos
idata
Employee
1,746 Views

I found a possible issue with our Cert from GoDaddy. I don't think this is the issue, but while I was digging through the log file I decided to verify the hash values matched between SCCM and the MEBX on one of my clients. What I found is that our Go Daddy certificate doesn't have the correct hash value.

Hash Embedded in Dell Bios: 2796-BAE6-3F18-01E2-7726-1BA0-D777-7002-8F20-EEE4

Hash of our cert: 317A-2AD0-7F2B-335E-F5A1-C34E-4B57-E8B7-D8F1-FCA6

I did some searching and I found others with the same issue using Go Daddy Certs. It seems it has something to do with the Root CA being Valicert rather than Go Daddy.

http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/744180d4-e63d-44fb-9306-576596ca4852 http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/744180d4-e63d-44fb-9306-576596ca4852

/thread/1764?start=15&tstart=0 http://communities.intel.com/thread/1764?start=15&tstart=0

If you read these threads you'll see that they were eventually eventually able to get a cert with the correct Hash value from GoDaddy.

One of my coworkers is going to work with Go Daddy to try to resolve that issue. I think that maybe why the one test machine that was detected hasn't provisioned.

Paul

*UPDATE*

We found a possible fix for the cert issue here:

/openport/blogs/proexpert/2008/03/03/steps-to-purchase-a-godaddy-certificate-for-the-purpose-of-vpro-remote-configuration http://communities.intel.com/openport/blogs/proexpert/2008/03/03/steps-to-purchase-a-godaddy-certificate-for-the-purpose-of-vpro-remote-configuration

 

/message/28046# 28046 Nov 18, 2008 7:18 PM Alireza Mikailli says:

<!-- [DocumentBodyStart:0bedfbab-536a-431a-8690-78bee91b160f] -->

When you order certificate from Godaddy using the instruction described in Bill York's blog, you will receive a certificate bundle similar to the one listed below:

http://www.valicet.com/ http://www.valicet.com/

Go Daddy Class 2 Certification Authority

Go Daddy Secure Certification Authority

"yourserver_FQDN" (e.g. server.domain1.com"

If you load (import)the above certificates to your server according to Godaddy's instruction, it won't work with vPro provisioning as the SSL provisioning certificate (e.g. server.domain1.com) is chained to an incorrect root CA (http://www.valicet.com/)for http://www.valicet.com/)for vPro provisioning.

In order to correct the problem, you need to install the GoDaddy Root and Intermediate CA and then re-export the certificate (e.g. server.domain1.com). It should chain up correctly. Make sure you remove the valicert Intermediate and root prior to doing it.

• Go Daddy Class 2 Certification Authority Root Certificate: Download from https://certs.godaddy.com/repository/gd-class2-root.crt https://certs.godaddy.com/repository/gd-class2-root.crt

gd-class2-root.crt:

Certificate Thumbprint Algorithm: sha1

Certificate Thumbprint: 27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4

• Go Daddy Secure Server Certificate (Intermediate Certificate. Download from: https://certs.godaddy.com/repository/gd_intermediate.crt https://certs.godaddy.com/repository/gd_intermediate.crt

gd_intermediate.crt

Certificate Thumbprint Algorithm: sha1

Certificate Thumbprint: 7C 46 56 C3 06 1F 7F...

0 Kudos
idata
Employee
1,746 Views

HAZAAA!!! I was able to get one of my machines to successfully provision. We finally got the cert right.

I sent a reboot request, and it worked as well.

I was able to connect to the machine via the OOB Console, but it took forever to connect and now refuses to disconnect.

Also, The IDE redirect options were grayed out in the console. (I do have it enabled in the OOB Management component.)

I think setting the hardware inventory interval to 2 days instead of 14 will help with the original IP address issue.

0 Kudos
idata
Employee
1,746 Views

Hi Paul,

Welcome back!

I'm glad to hear you've gotten provisioning working. I would recommend that, if you have a successfully provisioned client (does it show as "provisioned" in the AMT status field in the ConfigMgr console?), that you test out its functionality using the Intel AMT Developer Toolkit tools. There is a utility included with the DTK called AMT Commander, which gives you comprehensive access to all (or at least the majority of) AMT functions. Using this tool, you should be able to determine if there is truly a problem with IDE-R or not.

You can download the Intel AMT DTK here:

http://softwarecommunity.intel.com/articles/eng/1034.htm http://softwarecommunity.intel.com/articles/eng/1034.htm

-----------

Regarding hardware inventory, keep in mind that the inventoried IP address is only used for AMT controller discovery and provisioning. Once the device is provisioned, the Microsoft OOB Console should use DNS to resolve the IP address and hostname of the device.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
idata
Employee
1,746 Views

Ok, I've been able to provision one Laptop and One Desktop. The only trouble is these are the two machines that I reset the Admin password manually on.

I had been poking around in the MEBX locally on these two machines and had manually reset the password using the same password I entered on the OOB Component and as my only defined Provisioning account. The other handful of machines I'm testing with still have the default password. I've read that SCCM automatically tries the default admin/admin account/password pair. From what i see in the log below that doesn't appear to be working.

To confirm this I'm going to manually reset the password on the machine shown below and then trigger the provisioning process via WBEM.

This machine is an Latitude E6500.

>>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<< SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)<p> 

Provision target is indicated with SMS resource id. (MachineId = 51 CCIC10506L.us.crowncastle.com) SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Found valid basic machine property for machine id = 51. SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Warning: Currently we don't support mutual auth. Change to TLS server auth mode. SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

The provision mode for device CCIC10506L.us.crowncastle.com is 1. SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Attempting to establish connection with target device using SOAP. SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Found matched certificate hash in current memory of provisioning certificate SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Create provisionHelper with (Hash: CF788D5A7CCC3E1F23DBD519A51BAE33ECA78AD3) SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Set credential on provisionHelper... SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Try to use provisioning account to connect target machine CCIC10506L.us.crowncastle.com... SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:07 PM 4872 (0x1308)

 

Fail to connect and get core version of machine CCIC10506L.us.crowncastle.com using provisioning account # 0. SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:09 PM 4872 (0x1308)

 

Try to use default factory account to connect target machine CCIC10506L.us.crowncastle.com... SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:09 PM 4872 (0x1308)

 

Fail to connect and get core version of machine CCIC10506L.us.crowncastle.com using default factory account. SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:10 PM 4872 (0x1308)

 

Try to use provisioned account (random generated password) to connect target machine CCIC10506L.us.crowncastle.com... SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:10 PM 4872 (0x1308)

 

Fail to connect and get core version of machine CCIC10506L.us.crowncastle.com using provisioned account (random generated password). SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:11 PM 4872 (0x1308)

 

Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 51) SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:11 PM 4872 (0x1308)

 

Error: Can NOT establish connection with target device. (MachineId = 51) SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:11 PM 4872 (0x1308)

 

>>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<< SMS_AMT_OPERATION_MANAGER 6/18/2009 1:54:11 PM 4872 (0x1308)<p> 
0 Kudos
idata
Employee
1,746 Views

Hello,

Yes, ConfigMgr does try the default (UserID: admin, Remote MEBx password: admin) credentials after it attempts to use a custom-defined provisioning account (if applicable). This is the section where the log file reads "default factory account". If this is not authenticating properly, and you are not receiving error messages like "InitializeSecurityContext" or "ApplyControlToken", then most likely you're best off resetting AMT back to factory defaults.

Regards,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

0 Kudos
idata
Employee
1,746 Views

I think it's a DNS issue. The one I was working with yesterday was coming back with the wrong IP.

I think that's a pretty good reason for it to fail. :-)

0 Kudos
Reply