In the last few years SCCM has been introducing new features to the software update workflow to help with server update scenarios. Features such as Server Groups, maintenance windows, and Pre and Post deployment actions allow an unprecedented level of control over how and when servers are patched.
Top 10 Reasons to use SCCM for Server Updates
So what are some of the benefits of using SCCM to update servers compared to other tools like WSUS? Consider the following:
- Granular Deployment Control – Unlimited number of Collections based on Technology and Business requirements
- Automated Maintenance Windows – Patches will only deploy during scheduled maintenance windows
- Pre and Post Automation – Run Scripts before and after Updates (Example: Create a VM snapshot)
- Restart Management – Control over Server restart behaviour
- Automated Deployment Rules – Automate repetitive business logic based patching scenarios based on predetermined selection criteria such as platform, product, classification etc.
- Update Templates – Create scenario based templates to accelerate patching and minimize errors
- Rich reporting – Dozens of canned reports for updates management and status as well as the option for custom reports
- Bandwidth management and optimization – Use local repositories and peer caching to minimize the amount of network load and accelerate deployments. Schedule and throttle bandwidth usage based on time of day.
- Server Group Control – Logic based on number, percent and order of servers to be patched at any given time. Ideal for clusters and load balanced services.
- Query based targeting – richer targeting based on asset inventory data
That’s a lot of control and conceptually difficult to understand. I used to love the superflows in the old SMS documentation. I’ve created a miniflow of my own to help you understand how some of the new features can be used to take better control of the server update process.