How to Manage Security Updates in ConfigMgr - Part 1
One of the questions that I often get surrounds how to manage Software Updates in Configuration Manager. I could just tell you what to do, but I think it is better to explain how the process works and give then give you recommendations on how to manage your updates. This enables you to understand why I make the recommendation and also may prevent you from reinventing the wheel and wasting your valuable time.
In Parts 1 and 2, I will cover how Updates Deployment works and how the WSUS deployment processes were molded to fit within ConfigMgr processes. This won't be a highly technical discussion, but more of process flows and overviews.
First, it might be good to understand that while update deployment is using the Configuration Manager framework for deployment, the process is built upon WSUS so it doesn't meld directly. That is because ConfigMgr deployments are push methods, while Windows Updates are pull methods.
Let me explain: With Windows Update, the client "pulls" just the updates from WSUS based on a catalog of available updates. WSUS provides a list and the client scans and then requests just what it needs from the list. The service then executes commands based on the update catalog information.
With ConfigMgr or SMS, the deployment is built and targeted to a system or group of systems. When the system recognizes they have a deployment to run, they execute it based on the deployment criteria whether they need it or not. As long as the target system meets the requirements, the program is run.
So to sum it up, WSUS is all friendly and says "Come look what I have and take what you like", while ConfigMgr says "This is what I have and your gonna take it, whether you like it or not". I guess that makes ConfigMgr a bit heavy-handed sounding. So how does WSUS's soft approach fit into the heavy-handed design? Well, in Part 2, I will cover the distribution flow for deployments and how WSUS processes have to be tailored to fit within that.