Here's my configuration:
- ConfigMgr SP1 AMT Provisioning
- Dell OptiPlex 760 (Intel Standard Manageability 5.0)
- User account with PT Administration permissions
- ConfigMgr SP1 Console running on Windows Vista SP1
Has anyone seen this error message in the oobconsole.log file while attempting a reboot of an AMT system? For a while, I was able to use the Microsoft OOBconsole, but now it isn't working. I am able to control the system using Intel AMT Commander from the Intel Manageability Developer Toolkit (DTK).
Any ideas? For what it's worth, we recently had a problem where the CRL on our internal CA was out of date, which was causing provisioning problems, so is this something that could be certificate / authentication related?
[2/10/2009 7:48:43 AM] :AmtPowerControl with state = MasterBusReset fail with result:0x80338041
[2/10/2009 7:48:43 AM] :Microsoft.ConfigurationManagement.ManagementProvider.SmsException\r\nError occurred when controlling machine power state\r\n at Microsoft.ConfigurationManagement.AdminConsole.OobConsole.Utilities.AmtWSMan.TraceWsmanResult(String operation, Int32 result, String output, String exceptionInfo, Boolean throwException, TraceEventType successTraceEventType)
at Microsoft.ConfigurationManagement.AdminConsole.OobConsole.Utilities.AmtWSMan.AmtPowerControl(PowerState state)
at Microsoft.ConfigurationManagement.AdminConsole.OobConsole.Utilities.AmtDevice.BootSystem(Object sender, DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)\r\nNo details are available for this error.\r\n
FYI, the same error is occuring on a Dell OptiPlex 755, which is running vPro firmware 3.2.1 (BIOS A11), so I do not believe the issue is related to a specific firmware.
Another FYI .... I just tested out the OOBconsole from my Windows 2003 ConfigMgr site server, and it works OK from there. Windows XP and Windows Vista do not work.
My subordinate CA certificates are placed in the Trusted Root CA store. I believe this was a known bug with ConfigMgr.
Now that I read this message, make sure on the XP and Vista that you have your own internal Root CA and any intermediate CAs in the systems trusted root stores. Again, this is not the certs from your provisioning chain, but the certificates from your internal CAs that generate the web server cert for AMT.
Yes, both the [internal] Subordinate CA certificate and the [internal] Trusted Root CA certificates are in both the Trusted Root CA store and the Intermediate CA store. I know that there was some discussion in the past on a bug in ConfigMgr that required either 1) the Subordinate CA certificate to be in the Trusted Root CA store, or 2) the Trusted Root CA certificate to be in the Intermediate CA store.
I don't remember which one was the bug, but I put both in both places just to make sure.
Edit: Also do keep in mind that the Intel Manageability Commander tool works from the same systems that are having issues with the OOBconsole.
do you have the certificate (trust) on your local client that you are using to access the console? matt & I talked about this issue when your client (your PC) does not have the certificate for trust and you are running the console from your PC it will not work and error out. I remember matt said there were specifics posted. I'll find the post.
Thanks for the response. I do remember watching that video recently, and it's definitely a good one. So, I think what you're getting at, is that I need to make sure that the system running the OOBconsole trusts our 3rd party provisioning certificate, correct?
If that is the case, then yes, I do have a valid certificate chain on the system running the OOBconsole.
Here are the steps I am using to validate the above statement:
1. Open MMC
2. Add certificates snap-in for Computer store of ProvisioningServer.mydomain.local
3. Open the Personal\Certificates 'folder'
4. Double-click the provisioning certificate
5. Click the Certification Path tab
6. Validate that each certificate in the chain exists on the system running OOBconsole
Intermediate CA Store - Verisign Class 3 Public Primary Certification Authority - Expires 10/24/2016 - serial # : 46 fc eb ba b4 d0 2f 0f 92 60 98 23 3f 93 07 8f
Trusted Root CA Store - Verisign Class 3 Public Primary CA - Expires 8/1/2028 - serial # : 70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf
Is this what you were looking to have me validate?
You are referring to the provisioning certificate, which is the 3rd party cert you get from a company like VeriSign. You are correct that the same chain of trust must be put in the proper certificate store on the provisioning server (sccm in your case).
However, the video that Matt discussed certificates refers to the second type of certificates involved in vPro. This certificate is the management certificate from you own internal CA. During the provisioning phase of the process, SCCM will connect to your internal CA and request a Web Server certificate for each AMT device it provisions. It will push this Web Server cert down to the AMT firmware. This certificate will be used to secure the management traffic (Ie.g. IDER/SoL) between AMT and the OOB Console in SCCM.
Now this Web Server certificate also has a chain of trust. It might be only one level if it came from your internal Root CA or maybe two levels if is came from a subordinate CA under your Root CA. Either way, this chain of CAs must also be in the proper certificate store on the SCCM server for it to trust the Web Server cert when it is presented to the OOB console during a management session.
I'm not sure this is related to your issue, but I wanted to make sure you and the rest of the community was clear on that point.
Regarding the error you get on reboots, does the same error happen when you try to reboot the system from the OOB console as it does when you perform simple power control in SCCM (right click the system and select Out of Band Management -> Power Control)?