We’re back with our series on how to utilize Windows Server Update Services (WSUS) for deploying updates beyond what Microsoft offers. In this last part in the series, we are going to investigate the WSUS size of the environment to get the updates approved and targeted as a platform for deploying the SCCM client.
If you need to catch up: In part one, I introduced Windows Server Update Services and showed you how to prepare the code signing certificate. In part two, I discussed how to have clients trust updates that are not explicitly published by Microsoft, and I introduced System Center Update Publisher (SCUP).
As you might expect the next obvious step in our quest maybe to launch the WSUS console, and search for your new update. Unfortunately, I am sorry to burst your bubble: It is not going to be there. This is actually quite troubling at first, as you start to doubt the success of the publishing activities that we completed in the last post.
Before you begin to scream and pull your hair out, you don’t really believe that I would guide you down this path, just to leave you stranded and abandoned, do you? Of course not, and neither has the community. Sure, Microsoft would rather that you use System Center Configuration Manager (SCCM) for your update deployment, and with great reason, but all good things take planning and foundations need to be created. Luckily, some folks have come to the rescue with a free tool called Wsus Package Publisher, which is exactly what the doctor ordered. To proceed in our objective, I recommend that you proceed to visit the CodePlex site and download the tool.
This tool is delivered without an installer as a ZIP file. Simply download the file, unblock it, and extract the content to a suitable folder. Then locate the executable WSUS Package Publisher and launch it. If you happen to be running on the WSUS server, the tool will automatically detect this and add the server to the console. Otherwise you will be presented with a dialog to add a connection to your WSUS server.
To approve your update for deployment we can now perform essentially the same task we would in the WSUS console for regulate updates.
Now, with the update finally approved, all that remains is that we verify that the update is indeed getting published and our clients should proceed with the installation.
Within the WSUS Package Publisher console:
In the event the update fails to install and you are presented with an error, the most common message to expect will be Code 800B0004. This message is a clear signal that your code signing certificate is not in the Trusted Publishers store of the computer. You should resolve this by checking your GPO that you created at the beginning while organizing your client trust. Once you have resolved this, you can check that the GPO is applied with RSOP.MSC, and also that the certificate is correctly in the Local Computers certificate store for Trusted Publishers.
As a software deployment tool, WSUS is not a bad starting point. The SCUP tool is pretty simple to use when we approach packaging our own updates, and with the use of the WSUS Package Publisher community tool, it provides an experience which is not a far stretch of what we are already comfortable with while using the WSUS console. As you begin to investigate the SCUP tool for other tasks, you will quickly come to appreciate its usefulness with deploying updates for our hardware, e.g. HP/DELL/etc., and addressing problem applications like Oracle Java and Adobe.
And the best part of all this is that the experience gained using SCUP with third-party applications will also be directly transferable to SCCM.