I've gotten to provision approximately 200 vPro clients using SCCM SP1. The process was running nice and smoothly for months now. However, do to unforeseen circumstances, our Network group had to rebuild our CA. Supposedly, everything has been restored to the way it once was, however, I am seeing a consistent break in the process.
Going to our OOB MP and looking at the amtproxymgr.log file, I see: "ERROR: ICertRequest2->Submit failed: 0x80070005."
I've seen this error early on when first building out our infrastructure. We have a multi-domain hierarchy and our CA sits in our top level "Domain1.com" and the OOB Management point sits in "Domain2.com". Refering to Microsoft's guidance here http://technet.microsoft.com/en-us/library/cc161803.aspx, we needed to add SCCM.Domain2.com to CERTSRV_DOM_ACCESS sitting in Domain1.com.
In the past, this resolved our issue and we were able to begin provisioning. Now, hoever, with the assurances that were given about the environment being restored, we are seeing the same issue where the chain is not being validated due to a block in rights.
My question is this, do we need to remove and then rebuild the OOB Mgmt Role on our Management Point for the provisioning process to be restored? Or could it be that there is still an oversite in that our OOB was not actually added to the correct Security group to manage the provisioning certificate?
Any help would be GREATLY appreciated.
The submit failure usually cased by... Not being able to find the Issuing CA or the SCCM Site Server not having sufficent permission to request the certificate. I would recommend checking the following...
Like I said, the environment was happily chugging along until the CA was rebuilt. I really don't want to rebuild the OOB Role from scratch if I don't have to because nothing was touched. Is it a matter of a GUID changing or something that would cause this to happen? I'm just trying to get an understanding of why.
Thanks for the pointer. It ended up being that the OOB MP wasn't actually placed in the CERTSRV_DCOM_ACCESS Security Group for the CA in our top domain. After a reboot, the provisioning started working. It's brought up another interesting problem, but I am going to start a new thread for that.