- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have trouble configuring Out of Band management in SCCM SP1
We have 400 HP DC7700p computers with AMT version 2.2.1. HP doesn't have a firmware with version 3.2.1 for this system. We installed the Intel WS-MAN translator and configured it.
The environment:
· SCCM 2007 SP1 server with hotfix KB960804
· 1 Single Primary Site with one SCCM server and the OOB component installed
· Windows 2008 x64
· Intel WS-MAN translator version 1.0 build 00552
· Provisioning certificate: GoDaddy
We are unable to automatically provision an AMT client. When I configure the PSK in the BIOS of the client the provisioning succeeds, but I cannot connect with the OOB console.
The computer object is created in the Active Directory Container Intel(R) Client Setup Certificate and an webcertificate is enrolled for the AMT client.
Once provisioned I am able to send a reboot and power down command, but a power on command fails.
<p class="MsoNormal" style="margi...- Tags:
- Intel® vPro™
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Sorry to hear about your provisioning troubles. Keep in mind that, while troubleshooting this situation, first-stage AMT provisioning is actually handled by ConfigMgr. What this means is that you should see a successful connection to the AMT device, and first-stage provisioning should complete, before you ever see the WS-MAN Translator come into play.
With that in mind, could you please validate the following?
- Forward (A) and reverse (PTR) DNS records for the client with IP 172.23.16.64
- DHCP option 15 configuration
You will need an A record that contains the client's hostname, and this record should exist in the DNS zone that matches up with the domain that your ConfigMgr OOB service point is in. (eg. sccmsp1.childdomain.domain1.com, and vproclient.childdomain.domain1.com)
Likewise, the PTR record representing the client's IP address should point to the client's FQDN (vproclient.childdomain.domain1.com)
Your DHCP configuration should include option 15, whose value should match the DNS name of your Active Directory domain where the ConfigMgr OOB service point is installed. (eg. childdomain.domain1.com).
From my experience, these are two common configuration problems that have caused the InitializeSecurityContext and ApplyControlToken errors that you're seeing in your amtopmgr.log file.
Please post back with your results!
Thanks,
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Trevor,
Thank you for your reply. DHCP is configured with option 15 and DNS is configured correctly. The client has an A record and an PTR record.
Any other ideas?
Merijn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Merijn,
If you have already messed around with provisioning one of these devices, I would suggest trying a factory reset of the firmware. This can be achieved by removing power and the CMOS battery from the system.
Are all of your systems experiencing this behavior, and if so, are they all experiencing the same symptoms? From your log file, it appears that at least one system got farther than the one with the errors.
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From your post it sound like you enabled PSK (setting a PID/PPS pair in the MEBx), but then tried to provision the AMT client using the SCCM client Agent.
PSK provisioning is not natively supported by ConfigMgr and must depend on the Intel WS-MAN translator. Because PSK provisioning is not natively support, Agent based provisioning (which only supports PKI provisioning) will not work. If you are trying to provision the AMT client using PSK, you must provision the client through Out of Band provisioning; this can be accomplished by importing the client through "Import Out of Band Computers" and then having the Out of Band Service Point receive a PSK hello packet from the AMT client.
In terms of Trevor's comment on first stage provision... Independent of AMT firmware version, SCCM will perform first stage provisioning natively when using PKI; however, when trying to provision with PSK, SCCM will forward the first stage provisioning request to the Intel WS-MAN Translator.
Looking at your AMTOpMgr.log, it appears that first stage provisioning did complete; however, since it was kicked over to the translator I would need to see the translator log for more clarification; second stage provisioning is full of errors, which make me believe first stage did not complete successfully. If Second Stage provisioning did not complete sucessfull, you will have trouble with the AMT use cases.
Since you have a PKI provisioning certificate from GoDaddy, I would recommend the following….
1. On the AMT client you are testing, Perform a Full Unprovision within the MEBx.
2. Ensure the AMT client is set to PKI provisioning. PKI provisioning is the default provisioning mode.
3. Using the SCCM agent with Auto Provisioning enabled, try provisioning again.
--Matt Royer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to provision a machine, which has never been configured before.
I'm unable to connect to the machine. Attached are the logs.
When I try to discover the management controller of a client, the AMT version is not detected.
Any ideas??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does not appear that you are getting past the initial authentication, which the remote configuration certificate is critical to that step. The first thing i would recommend is validating your remote configurationing certificate using the process identified here http://blogs.msdn.com/steverac/archive/2009/05/18/tool-to-verify-amt-certificates.aspx http://blogs.msdn.com/steverac/archive/2009/05/18/tool-to-verify-amt-certificates.aspx. Use the "cscript CertValidator.vbs 1 ".
I'm also assuming that your option 15 in your environment is set to AM.LAN and this is the domain the certificate was issued to? AMT will use option 15 to validate the provisioning certificate.
--Matt Royer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Agreed with Matt about first-stage authentication.
The critical things to check are:
- DHCP option 15
- Forward/reverse lookup records
- Root CA hash of your provisioning certificate (not to be confused with the hash of the provisioning certificate itself)
Also, does your firewall configuration allow ports 16992 - 16995 and 9971?
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When I check the certificate I get:
Copyright (C) Microsoft Corporation. All rights reserved.
ERROR: Expected server auth value was NOT found
in the certificate. Server auth value should be
(1.3.6.1.5.5.7.3.1) in order for the certificate
to be valid.
ERROR: Expected OID AND expected Subject fields
NOT found in the certificate
ERROR: Expected Key Length value was NOT found in
the certificate. Key length should be either 1024,
1536 or 2048 bits to be valid
Thumbprint check: PASSED!
Certificate Starting Date Validity check: PASSED!
Certificate Expiration check: PASSED!
ERROR: Private key NOT found in certificate!
When I open the certificate I see Server and Client Authentication is listed under Enhanced Ket Usage
I'm sure that I selected "export private key" when creating the pfx file
The subject - OU contains: Intel(R) Client Setup Certificate
Key lenght is: 1024
DNS Option 15 is configured to: AM.LAN
No ports on the firewall are closed between the server and the client
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you absolutely sure that the certificate OU name is spelled correctly? Can you double and triple check it? Are there any spaces in it at all? This is absolutely critical for remote provisioning through ConfigMgr to occur properly.
Perhaps you could post some screenshots of the certificate properties? At least the certificate chain appears to be validating, otherwise you wouldn't be returned a validated hash.
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When manually provisioning an AMT client an warning message is logged in the event log of the OOB service point:
Log Name: System
Source: Schannel
Date: 10-6-2009 11:09:07
Event ID: 36875
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: AM019.AM.LAN
Description:
The remote server has requested SSL client authentication, but no suitable client certificate could be found. An anonymous connection will be attempted. This SSL connection request may succeed or fail, depending on the server's policy settings.
Event Xml:
http://schemas.microsoft.com/win/2004/08/events/event">
36875
3
0
0x80000000000000
69279
System
AM019.AM.LAN
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Merijn,
From your screenshots, the provisioning certificate does appear to be correct, assuming there isn't any white space after the verbage in the OU name (I don't know if this is even possible, or if it's truncated).
As a next step, I would suggest that you reset the CMOS on the client by pulling power and the CMOS battery for roughly 10 seconds. This will reset the firmware to factory defaults, and may resolve the issue.
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Trevor,
I was out of the Office last week, so I couldn't reply to you r post.
I already tried to reset the machine to the factory defaults, but no results. The provisioning still fails.
I also opend a case with Microsoft, I hope they can help.
Any other idea's?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Merijn,
During a provisioning attempt, what are you seeing in your oobmgmt.log file on the AMT client? This log file should be in your %WINDIR%\System32\ccm\logs folder, if you have not changed the logging location from the default.
I'm afraid I'm starting to run out of suggestions. Without having had experience on the 64-bit platform, I really don't know whether or not there could be some sort of compatibility issue with AMT provisioning in ConfigMgr.
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page