Applying servicing stack updates and cumulative updates within organisations that use maintenance windows in SCCM has become a growing problem. Microsoft seem to be aware of the problem but little is being done to help solve it.
So what is the issue?
Servicing stack updates for Windows update the components responsible for updating the operating system. They are basically a patch for the patching system. Microsoft has started making some servicing stack updates (but not all) a pre-requisite for a monthly cumulative update. This means that the software update scan will not report to WSUS that the cumulative updated is required until the servicing stack update has been applied. Since the servicing stack update does not require a reboot (which forces a software update scan) and a software update scan typically runs every 24 hours (or 7 days) then if updates are deployed during a maintenance window then the cumulative update will not be installed. The result of this is that systems will remain unpatched until the next maintenance window which potentially leaves them vulnerable.
One obvious solution Microsoft could implement is to add an option to the SCCM software updates deployment which will trigger a software update scan after deployment. However at time of writing nothing has been done and organisations are being left to solve the issue for themselves.
What can you do about it?
There are a number of options organisations can choose from but none of these are ideal. The main ones are below:
Option 1: Implement 2 maintenance windows each month, the first one to install any servicing stack updates and the second to install remaining updates. These maintenance windows could be on consecutive days. Microsoft has started setting the title of servicing stack updates to include “Servicing Stack Update”. Assuming you are using automatic deployment rules this title could be excluded from the normal monthly deployment package and a second monthly deployment package created just containing the servicing stack update. The deployment package containing the servicing stack update can be deployed first, followed by normal monthly deployment package. This however may not be an option for some organisations, but is the cleanest fully automated solution.
Option 2: Run a command against each computer to run a software update scan after deployment of the servicing stack update. Once the next cycle of SSCM software update summarization occurs (typically every hour or it can be executed ad-hoc) then the cumulative update should be set as required all systems needing it.
Clearly this option requires more manual monitoring to ensure that all systems install the required updates.
The below command will trigger the software update scan:
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000113}” /NOINTERACTIVE
Option 3: Reboot all computers following the installation of a servicing stack update. Since a reboot triggers a software update scan then rebooting all computers will ensure that they update to WSUS that the cumulative update is required. Again you would need to wait for SCCM summarization to occur. This option is less desirable since it can cause an application outage and if the updates to be installed next require reboots then it results in twice as many reboots.
Option 4: Do nothing and accept that occasionally systems may be out of date by a month. It should sort itself out on the next month’s patching. Microsoft has only made the servicing stack update a pre-requisite for a cumulative updates twice and it may not happen again. So if your organisation is not that strict about being completely up to date with patching then you may choose to do nothing.
In summary, Microsoft really needs to help sysadmins out with this. Either add options within SCCM or simply stop making cumulative updates dependant on servicing stack updates released within the same month.