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.
· 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...
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?
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!
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?
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.
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.
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.
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.
Agreed with Matt about first-stage authentication.
The critical things to check are:
Also, does your firewall configuration allow ports 16992 - 16995 and 9971?
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
(22.214.171.124.126.96.36.199.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
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.
When manually provisioning an AMT client an warning message is logged in the event log of the OOB service point:
Log Name: System
Date: 10-6-2009 11:09:07
Event ID: 36875
Task Category: None
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.
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.
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?
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.