SCCM PKI Fun with Certificates

This was fun problem to sort out.  I was asked to jump in and fix a SCCM server already built to work with PKI.  Attempts to get clients registered with the server would end up with bizarre error messages like this:

RegTask: Client is not registered. Sending registration request
RegTask: Reply for registration was empty. Error: 0x8000ffff

I worked on the problem for about 8 hours at work, then went home and setup PKI in my home SCCM lab in about 30 minutes.  I decided I needed to enlist Microsoft PSS on this issue.

After working with Microsoft for about 2.5 hours: they tracked the problem to the certificate on the management point bound to IIS being “too new”.  Essentially, SCCM has legacy code in it that only understands certificates based on the CSP templates (Windows XP/Server 2003) and not KSP/CNG templates (Windows Server 2008 and later).

This is explained in more detail here:

The funny part is I was actually using a CA template I had found on the production distribution points that were already up and working, but I guess using the wrong certificate template on DPs doesn’t matter, but using the wrong one on the MP does matter for client registration at least!

I had no access to the CA server, so I couldn’t snoop around on the properties of said certificate templates and they were named “2012 or later IIS”.  Of course the management server is running Windows Server 2012 R2, so why wouldn’t I pick that template?

In the end, you have to use the command line to see the cryptographic provider of the certificates (this doesn’t show up in the GUI):

certutil -repairstore my *

It seems that other people are annoyed by this and according to Microsoft the ability to use CNG or more “modern” certificate templates is coming in a newer build of SCCM:

  • Soli Deo Gloria

0x80004005: An error occurred while retrieving policy for this computer

Started a new job recently and one of the techs was having a problem imaging a laptop with a recently replaced motherboard.  We would PXE boot the laptop and then WinPE would bomb out in 10 seconds stating “0x80004005: An error occurred while retrieving policy for this computer”.

Nothing interesting was found on the SCCM side, however when I finally found the SMSTS.LOG in X:\Windows\temp\SMSTSLOG, I didn’t even have to open the file to figure out the problem: it was dated 2016!  Yup: it was a date and time issue.  If your computer skews too far from the current date and time, SCCM won’t talk to your computer.

You can use the commands date and time within cmd (hit the F8 key…you did enable this functionality, right?) to set the correct date and time.

  • Soli Deo Gloria