If you are using Configuration Manager to manage and patch your client estate then you already know that it’s great to have your Software Updates in the same console as your Application Delivery and the way in which Configuration Manager 2012 R2 manages Software Updates is a big leap on usability over Configuration Manager 2007 however the missing piece of the puzzle for many is managing non-Microsoft updates and for that, we need to enlist the help of a free product from Microsoft called System Center Update Publisher.
Before we start anything with Configuration Manager, WSUS or SCUP however, we do have the small matter of prerequisites to cover off and in this case it requires a certificate and a Group Policy setting or two. The certificate we are interested in is a Code Signing certificate which unless you are familiar with signing PowerShell scripts that you author, you may not have come across previously and your internal CA may not be setup to issue. You can buy these certificates for Code Signing from an external third-party CA if you wish but it is easiest and best done internally as after all, the code you are going to be signing is for updates to your internal clients.
Creating the Code Signing Certificate Template
On your Certificate Authority, we need to configure it to issue a Code Signing certificate. You can either use the native Code Signing template or you can create a custom template just for SCUP so that you can limit the scope of the certificate template to selected users or a group of users accordingly. If you want to create a new template then duplicate the existing Code Signing certificate for the purpose.
Once you have decided on the template to use, configure the CA to issue the certificate. In my lab, my template is called SCUP Code Signing and the security on the template limits users in an Active Directory Group called SCUP Code Signing Users to being able to Enroll the certificate which prevents users, malicious or otherwise from requesting the certificate.
Request the Code Signing Certificate
Once you have configured everything on the CA, you need to request a certificate based on this template. Using the Certificates MMC snap-in for your user account, you can request to enrol the certificate from your Active Directory Enrollment Policy.
If you based your new Certificate Template on the Code Signing template or you used the Code Signing template, you don’t need to enter additional information and the request will be built from Active Directory user attributes. Once you have created the certificate, you need to export it twice. For the first export, export the certificate only in .cer format and do not export the private key. This portion of the certificate will be used in the Group Policy Object shortly. The second export is required to be in .pfx format and include the private key and is used in SCUP for configuring it once installed.
Configure the Trusted Publishers Group Policy Setting
Once you have issued the certificate and you have exported it twice; once as a .cer file and once as a .pfx file, we need to configure the Group Policy for the Trusted Publishers. Put simply, in order for your client PCs to install updates that are not signed by Microsoft, the clients need to trust the updates. In order for the updates to be trusted, they need to be signed with a certificate that the clients trust. Having a certificate from your internal CA isn’t enough for this though. Once you have a certificate, a client will trust it as it is from a Trusted Root Certification Authority but it will not be trusted for code signing unless added to the appropriate certificate store.
Using ether a new Group Policy Object or an existing object which contains your other Certificate Services related settings, we need to add the .cer certificate exported earlier to the policy.
Within the Group Policy Object, expand the Computer Configuration folder and then drill into Security Settings followed by Public Key Policies. Within the Public Key Policies folder, open the Trusted Publishers folder. In here, you need to import the Code Signing certificate .cer file that was previously exported. Doing this allows your clients to trust updates signed with this certificate for the publishing of software and applications.
Make sure you use the .cer export and not the .pfx export here as we only want the clients to have and trust the public key portion of the certificate. Distributing the .pfx would give these clients the private key also and that would be bad to have sent throughout the entire environment on every machine linked with the GPO.
Next, we need to change one setting in relation to the Windows Update Agent on the clients. In the same GPO or in another GPO if you have one dedicated to Windows Update related settings, navigate to Computer Configuration, Administrative Templates, Windows Components, Windows Update. Here, you need to change the status of the Allow signed updates from an intranet Microsoft update service location setting from Not Configured to Enabled. This second setting allows the Windows Update Agent to actually detect and download updates from your WSUS and SCCM environment if they are not signed by Microsoft and this setting is paired with the Trusted Publisher certificate above to make non-Microsoft updates trusted on the client.
With these all the above completed, you are now set and ready to deploy System Center Update Publisher and a follow-up post I will be publishing soon will cover the SCUP installation and setup.