SCCM 2. 01. 2 client deployment fails in HTTPS mode. During a recent SCCM 2. I noticed an issue when deploying the client using WSUS integration. The policy of using the WSUS server by its clients depends largely on the organizational structure of the Active Directory OU (organization units) and update. 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. 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. 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: Tell the client to use your SCCM WSUS instance. Tell the client to check in for updates. 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 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. The client had a valid certificate but didn’t think”that it was allowed to use it. 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=”8. This tied in with some forum posts (for SCCM 2. I’d found where they talked about needing to set the value to 6. 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 2. Either way it doesn’t help workaround the issue. This will make SCCM inject your value into the install string as installation runs. Allow HTTP/HTTPS but force HTTPS on MP/DPAlternatively 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
August 2017
Categories |