One of the most helpful features of Microsoft System Center is the ability to centrally manage updates. Yet System Center doesn’t include a way to manage third party updates natively. That’s where System Center Updates Publisher has come in. It’s a system that has always had more promise than it could deliver. For example, a few vendors provide free catalogs for SCUP of their updates (including Adobe and Dell). Others force you to rely on third-party catalog vendors, such as Shavlik (now Ivanti) and PatchMyPC (including Java). For the convenience these offer a reasonably priced option, but it would be nice if every major vendor integrated with something like Windows Update. I can’t help but think they would, if only Microsoft’s solution was more polished and functional.
For years, users of System Center Updates Publisher have been stuck with a version released in 2011, which on modern versions of Windows barely works, requiring you to manually choose to run the program as administrator. While you can automate the deployment of Windows updates with SCCM, SCUP doesn’t have any Powershell automation features or even GUI scheduling features. In March Microsoft released a new version of System Center Updates Publisher that works on modern Windows. The automation piece is still missing, but at least it’s now better integrated into Windows releases newer than 2008.
Installing Updates Publisher (2018 release) on a computer with System Center Updates Publisher 2011
I installed what Microsoft seems to have renamed to just “Updates Publisher” on Server 2012 R2, and it took me some time to find where it was installed. The type to search function in the Start Screen doesn’t seem to index Updates Publisher very well if you already have SCUP 2011. I had to type almost the full name before it was displayed as a suggestion.
Once you launch the 2018 release, Updates Publisher prompts you to migrate and import settings from previous releases.
The publication settings are not migrated for you and must be setup again. However, in my (common?) scenario of installing SCUP on the same server as WSUS and SCCM, using the defaults and then “test connection” saved me from any typing.
The import process was flawless for me. Once I imported my settings, I was able to import the actual updates. A nice new feature is a single-screen overview of all of the publishers and the option to approve them in advance.
After completing the initial import and approving vendors, we’re left with an interface that’s mostly unchanged. The edges and colors look a little softer and more in keeping with Server 2016.
It looks like the default is now to publish full content, which is helpful when speeding through approving updates as this is what I normally require when adding updates to System Center for deployment to workstations.
Publishing the updates is the same as in SCUP 2011. Unfortunately, for unsigned updates, you will still need to monitor the publishing process to accept any updates that you trust. With my chosen PatchMyPC catalog, I was prompted to approve an unsigned update to 7-zip.
The rest of the process of using SCUP is unchanged. You still need to launch SCUP every so often and publish any new updates, synchronize your software update point in SCCM, and then deploy the updates in SCCM. You must also ensure that you are subscribed to all of the update categories and vendors in SCCM: it is not enough to publish them from SCUP. You can use an automatic deployment rule in SCCM once the updates are published.
Overall, the SCUP 2018 release fixes the glaring issues with SCUP 2011, but fails to solve the real problem of automating third-party updates. I still look with envy at Linux package managers like Debian’s APT. With competition in the SMB space from vendors like Ninite and PDQ Deploy and Microsoft’ focus on integrating PowerShell, it’s hard to understand why patching third-party software with Microsoft’s premier endpoint management tool is still so clunky.