This content is part of the Essential Guide: Catch up on the Windows Server patches of 2017

Ways to adapt to Microsoft patching changes

Microsoft's switch to rollup patching makes it imperative for administrators to streamline the update process for Windows Server systems.

Microsoft switched to rollup patches for Windows Server operating system, which means administrators need to establish some best practices to avoid issues during or after a patch is applied.

In October 2016, Microsoft switched its patching model for Windows Server OS from individual security patches to rollup patches. The company cited a number of reasons for the change, most of which aim to control configuration drift. Choosing which patches to apply means the list could differ from one server to the next. Moving to a rollup patching model aims to ensure consistency across systems and can eliminate a problem that occurs when patches fail because of a dependency on a missing patch.

Following are guidelines for admins working through the new rollup patch process.

Establish a patch management process

Manual patching might work for small shops, but it is an unrealistic practice when the process involves more than a handful of systems.

Develop a rigid patching policy and establish a methodology for patch testing. Admins should also know how and when patches will be applied to production systems.

Some organizations document patch management policies with formal procedures that IT staff must follow, much like how regulatory compliance is enforced. Performing occasional IT audits can help ensure that staff follows the policies.

Minimize disruptions via automation tools, Nano Server

Patching can be troublesome for all involved. It interrupts IT staff; time spent testing and applying patches pulls admins away from other tasks. And patching can disrupt end users, because most patches require the system to reboot to complete the update.

Look to automation to reduce these disruptions. Manual patching might work for small shops, but it is an unrealistic practice when the process involves more than a handful of systems. Microsoft provides automated patch management tools with Windows Server Update Services and System Center Configuration Manager. There also are third-party automation tools for patch management from vendors such as Dell EMC, IBM, BMC Software and SolarWinds.

Admins can also use Nano Server where possible to reduce the number of reboots. Due to its smaller code base, Microsoft estimates Nano Server will require 92% fewer critical patches than a full Windows Server deployment. However, at time of publication, Windows Server 2016 Nano Server supports a limited number of server roles.

Patching requires patience

Few organizations apply patches as soon as Microsoft releases them on Patch Tuesday. Most take a wait-and-see approach, delaying system patches until a significant number of organizations have deployed it. For example, some businesses have a patch management policy that requires IT to wait 30 days after a patch has been released before it is deployed. Similarly, IT can group servers based on their roles and importance to the organization -- pools of less-critical servers are patched days or weeks before the pools of servers that run mission-critical systems, for example. These cautious approaches help administrators get a better feel if the patch will cause problems in their environments.

Keep VMs running with guest clusters

Windows Server admins can also ease the patch management process with guest clusters, which are Windows Server failover clusters in a virtualized environment. The Cluster Aware Updating (CAU) feature, introduced in Windows Server 2012, enables cluster nodes to update one at a time, while highly available workloads continue to run.

Organizations that use Hyper-V can implement failover clusters at host and guest levels. Host-level failover clusters enable CAU to update Hyper-V hosts without taking VMs offline. Guest-level clusters enable admins to patch virtualized nodes and keep highly available applications running. Without guest clusters, the administrator would need to reboot the virtualized application server after an update, even if the VM is configured to be highly available.

Keep an eye on the clock

Schedule patching during off-peak hours -- and double-check the time to be sure the process doesn't occur during business hours. For example, if you accidentally schedule patching to start at noon for more than 70 servers, the resulting storage IOPS and network bandwidth storms will result in severely degraded network performance until the patching operation completes. If patching can't wait until off-peak hours, stagger the application of patches so servers aren't patched simultaneously.

Despite Microsoft's changes to the patch process, two things remain the same: Administrators must test patches and apply them in a timely manner to protect systems from a known vulnerability. And the patching process shouldn't result in any disruptions to the end user.

Next Steps

Microsoft postpones February patch releases

Stay current with Microsoft's 2017 Patch Tuesday releases

How to streamline the server patching process

Dig Deeper on Windows Server troubleshooting