A while back, I wrote a blog post that detailed how patch management products work with the WSUS API to publish third-party updates (see How patch management products work with Microsoft WSUS). Looking back, this got me thinking about how, from a Patch Manager perspective, WSUS patch management and ConfigMgr/SCCM patch management are essentially the same. However, this surface-level understanding of the process is liable to cause some confusion. This post is intended to help clear that up.
Understanding How ConfigMgr Works with WSUS
My previous post outlines the Patch Manager/WSUS publishing process like so:
- Patch Manager initiates the publishing task:
- It loads the update definition into the WSUS database.
- It compiles the update installer(s) in a cabinet (CAB) file.
- It creates the CAB file on the WSUS server in the ~\UpdateServicesPackages file share.
- WSUS simulates the "File Download" task:
- It renames the CAB file with a 40-character hexadecimal representation of the original CAB file's SHA-1 hash.
- It makes the CAB file available for download by copying it to the appropriate folder in the ~\WSUSContent file share.
The important thing to note here is that the only step ConfigMgr cares about in this process is Step 1.a. So, from a third-party patch management perspective, we initiate the conversation with the WSUS API the same regardless of whether we're publishing updates to WSUS or ConfigMgr; but from a technical perspective, there are a lot of back-end differences between the two procedures. On a side note, even though ConfigMgr doesn't care about the rest of this WSUS procedure, the fact that WSUS still does the work allows third-party patch management products to deploy updates on demand in ConfigMgr environments the same way they can in WSUS-only environments. Here's my blog post about that: Deploy third-party updates to ConfigMgr clients without building deployment packages.
Here's what the publishing and deployment process looks like for ConfigMgr:
- Patch Manager loads the update definition into the WSUS database.
- ConfigMgr admins create deployment packages for target computer groups (called "Collections"). These effectively replace WSUS approvals. More about that here.
- ConfigMgr stores the update files on a separate server called a Distribution Point.
- The Windows Update Agent on each ConfigMgr client scans the WSUS database to find out what updates it needs.
- If a client needs an update, the ConfigMgr agent downloads the requisite files from the ConfigMgr Distribution Point.
So, the takeaway here is that, while publishing third-party updates is essentially the same in both WSUS and ConfigMgr environments, the back-end process is significantly more complex from a ConfigMgr perspective. In addition to using the more-complicated deployment packages instead of WSUS approvals, the ConfigMgr process also requires two servers to maintain updates: the WSUS server for the update definitions, and the Distribution Point for the files themselves.
So...why use ConfigMgr at all?
This is a question I addressed in a previous post (see The differences between Microsoft WSUS and Configuration Manager), but it's worthwhile to summarize the answer in this context. Basically, while the back-end process for handling updates is more complicated for ConfigMgr than it is for WSUS, ConfigMgr offers a lot more functionality beyond the limited scope of straight patch management. Similarly, third-party patch management applications like SolarWinds Patch Manager can offer a lot more to ConfigMgr admins since ConfigMgr provides a broader base of functionality to extend. For larger organizations, it's often more efficient to leverage a pre-built solution like ConfigMgr than it is to try and recreate that functionality with some combination of WSUS and other free tools.
If you're interested in reading more about ConfigMgr and third-party publishing, check out the following post on Patch Zone: Patching 3rd party applications: System Center Configuration Manager compared to 3rd Patch Management Solutions.