SCCM 2012 client deployment fails in HTTPS mode

During a recent SCCM 2012 deployment I noticed an issue when deploying the client using WSUS integration. We had deployed a PKI specifically so that we could use HTTPS only mode (Native mode as it used to be called) to secure all traffic between the client and server. I found that when the environment was configured for HTTPS only a client install triggered from WSUS would not try and use it’s client certificate to talk back to the management point and so could not complete it’s installation. I raised this with MS support who confirmed that this is an issue and that there are a few workarounds you can use while they are (hopefully) developing a fix for this issue…

Background

In SCCM there are two main methods (ignoring manual deployment)  of pushing out the SCCM client….

Client Push Installation

The first called “Client Push” does what it says, you supply SCCM with an account that has local admin rights on the endpoint and SCCM then tries to access the Admin$ share to upload it’s client and then triggers a remote install using WMI. This method can be very messy as you have to have an account that has local admin rights on each pc, you also need to make sure you have a bunch of ports open on any firewalls between your SCCM server and the client (for CIFS and WMI). If any of these factors are out, or the remote machine is turned off when SCCM tries to install, you can end up getting heap of error messages in your SCCM logs that will ultimately show your hierarchy as being unhealthy.

Note that when doing a client push installation you can specify custom install strings directly in the SCCM GUI (more on this later)

Software Update-Based client installation

Alternatively SCCM allows you to deploy it’s client using WSUS… this method is much easier and simpler to achieve in an AD domain environment & really if your planning on using SCCM to control patching for your organisation is the only choice you should consider. It works using the instance of WSUS that you need to make SCCM do patch management (As you may or may not know SCCM uses WSUS as a “filter” to talk to Microsoft to get it’s information about patches. Also when doing client side patching the SCCM client agent uses WSUS to figure out what patches it’s missing).

When you enable “Software update client install” SCCM talks to the WSUS instance you have configured and then injects it’s client as a legitimate update. This then means that any client that is configured to use your SCCM WSUS instance checks in and is then told that it’s missing the SCCM client and starts installing.

No faffing about with access rights or firewall ports as built in OS components for deploying patches are used. To make things even better you can easily control the required client settings using a Group Policy Object (GPO). Additionally using a GPO you can easily control your deployment by applying it selectively against your OU’s or with WMI filtering to target it.

Your GPO would need to do three things:

1. Tell the client to use your SCCM WSUS instance
2. Tell the client to check in for updates
3. Allow Automatic Updates immediate installation – This basically just tells the client to install any updates flagged as not needing a restart, or interrupting services immediately

Issue

So now that you’ve seen how awesome a WSUS based client install can be lets talk about the specific issue that I had…

The GPO was in place. The client was reporting into WSUS. Client installation was starting up but then bombing out. After looking at the logs on the client machine (in c:\windows\CCMSetup) I found the following entries…

<![LOG[Client is not allowed to use PKI issued certificate thus it can not talk to HTTPS server.]LOG]!>
<![LOG[GetDPLocations failed with error 0x80004005]LOG]!>

So it looked like the client could find the DP, was trying to talk to it but because I was running HTTPS only mode, the DP was requesting the client present a valid certificate. The client had a valid certificate but didn’t think”that it was allowed to use it… – pretty useless!

I did some experiments and found that if I changed the setting in SCCM to allow either “HTTP or HTTPS”  then the client would install itself correctly (and do so using HTTPS!). This meant that I didn’t have an issue with certificates or my PKI in-general. This confirmed my suspicions that the client simply wasn’t authorising itself to use it’s certificate.

After some closer inspection of the CCMSetup logs from each scenario I found the following lines:

HTTPS only mode:

MSI properties: SMSSITECODE=BIB CCMHTTPPORT=”80″ CCMHTTPSPORT=”443″ CCMHTTPSSTATE=”255” CCMCERTISSUERS=”CN=Test CA; O=Test; L=test; C=GB” CCMFIRSTCERT=”1″

HTTP or HTTPS mode:

MSI properties: SMSSITECODE=BIB CCMHTTPPORT=”80″ CCMHTTPSPORT=”443″ CCMHTTPSSTATE=”480” CCMCERTISSUERS=”CN=Test CA; O=Test; L=Test; C=GB” CCMFIRSTCERT=”1″

The crucial bit seemed to be the value of CCMHTTPSTATE. This tied in with some forum posts (for SCCM 2007) that I’d found where they talked about needing to set the value to 63 for an install to work in certain circumstances. I did some testing and found that if I forced this value via a GPO then the installation would proceed and work as expected.

So where does that place the issue? It’s hard to tell if it’s the SCCM server’s fault for incorrectly setting the value of CCMHTTSSTATE to 255 or if it’s a client issue where the client is incorrectly interpreting the value and not allowing the use of it’s client certificate when it should be. Either way it doesn’t help workaround the issue…

Workaround

So there are two workarounds for this issue and which one your implement is up to you:

Fix CCMHTTPSSTATE using Group Policy

You can modify your existing SCCM WSUS GPO to include a custom MSI installer value for SCCM setup…

Simply add the SCCM 2012 ConfigMgrInstallation.adm (what’s with MS not adopting their own ADMX standard?!) from the SCCM DVD (<CD>\SMSSETUP\TOOLS\ConfigMfrADMTemplates) and then add the value “CCMHTTPSSTATE=63”. This will make SCCM inject your value into the install string as installation runs.

Allow HTTP/HTTPS but force HTTPS on MP/DP

Alternatively if you don’t want to mess about any more with GPO’s (this method was my choice – don’t want to force too much config onto the clients vai GPO when it should be automatic) then you can leave HTTP/HTTPS enabled on your primary site server but then force HTTPS for all your Management Points and Distribution Points.

This means that SCCM is still fully secured but that when you expand your topology you need to remember to force HTTPS for any new MP/DP’s

Management point:

Distribution point:

This was my preference for a workaround until MS produce a patch for the issue (honestly how did this not get detected in beta or TAP? It’s quite basic functionality – Enable HTTPS, deploy client from WSUS).

If I spot any news about a patch I’ll update the post, or if anyone has seen something please put a note in the comments. Thanks