SCCM Software Update PART 5 – Best practices

• SCCM Software Update PART 1 – Introduction to SCCM and WSUS
• SCCM Software Update PART 2 – Software Update Point configuration
• SCCM Software Update PART 3 – Automatic Deployment Rules
• SCCM Software Update PART 4 – Create deployment packages manually
• SCCM Software Update PART 5 – Best practices

 

To conclude the SCCM Software Update subject, I will present some SCCM software update best practices to manage Micorosft updates in production environments.

Subscribes to news site about updates and security

It is important to be aware about the last updates (often the second Tuesday of the month) but also the last security issue. Sometime an emergency update is released by Microsoft to fix a vulnerability so it is necessary to patch quickly and to reduce the risk to be attacked. There are many solutions to make a technology watch: RSS (ex: Microsoft bulletin), Twitter (@msftsecresponse: #security #updates) or Microsoft Security Bulletin Notification. A good source for security purpose is the CERT (sorry it is a French link J).

Create standard baselines

All your system should be set on the same way to ease management and find the issue. That means that systems should be based on the same image installation, same Operating System (as much as possible) and application version and so on. Same baseline should be gathered in the same SCCM collection to ease software updates.

Create a pre-production to validate updates

Updates should be tested before the installation on production environment. Make sure to have a pre-production environment reflect the production environment. That means that pre-production environment contains every operating system and applications that you have on production. So when Tuesday patches are released, first update pre-production environment and test that everything is ok for one or two weeks.

Create packages with pre-determined criteria

To ease the management of update packages, create them with pre-determined criteria such as products, languages, classification and release date. This avoids to reconfigure update packages every month.

Create collections for each Operating System version

Organize collections by operating system ease update packages management. In this way make an update package containing every update for the related operating system and apply it to the collection. So every month, update this update package with new updates (view next point).

Reuse update packages when possible

To limit the number of update packages and so ease management, you should reuse deployment packages most of the time. So in a perfect world, you should have one update package per operating system version (including service pack), and one per application (example: SQL Server, System Center DPM etc.).

Create an emergency procedure

Sometime Microsoft releases a security update outside of Tuesday patch process because a 0-day vulnerability has been discovered for example. That happens one or two times per year. A process to make an emergency patching for this case should exist. Usually the emergency update should take a short time such as 10 to 15 days for pre-production and production environment patching.

Enforce a deadline to install updates

I recommend to enforce install updates when the deadline is reached. However I don’t suggest to force servers restart. I recommend that because everyone knows a colleague that will never install updates because he does not give a damn! With enforcing install updates on deadline, this administrator will have to be aware about updates.