Cluster-Aware Updating in Windows Server 2012

Driving down the management overhead of IT systems is a top priority for most organizations today. One way to achieve this goal is to minimize the work associated with patching OSs, including minimizing the number of patches that are needed. I'll first discuss how to reduce the number of patches, then show you how to automate the patching process for the patches that remain.

Reducing the Number of Patches

Since Windows Server 2008, the Server Core configuration level has been available. In a Server Core environment, the graphical interface, management tools, and management infrastructure are removed from the Windows deployment. This typically means about 50 percent fewer patches and, more important, longer times between reboots, because the patches that are no longer required are typically those that require reboots.

The main challenge with Server Core in Windows Server 2008 R2 and Server 2008 is that Server Core has to be set at installation time and can't be changed without reinstallation. This is a big risk for organizations not used to managing Windows Server from a command prompt or remotely. In addition, in Server 2008 R2 and Server 2008, Server Core is supported for only infrastructure roles (i.e., roles that are part of Windows Server itself) and not for other applications.

Server Core in Windows Server 2012 has completely changed. Server Core is now the default installation option for Server 2012. The graphical interface, management tools, and management infrastructure can now be added and removed at any point in a server's life cycle, with only a reboot required. This gives you a lot more flexibility and granularity, because you can choose to have the management infrastructure but not the graphical interface, for example.

In addition, Server Core is now an application platform, so applications (e.g., SQL Server 2012) can run on it. This means the patching overhead can be greatly reduced, without losing capabilities for Server 2012. You'll still need to patch and reboot, but you won't have to patch and reboot as often.

Rebooting a server typically means the services running on that server have to be unavailable during that time. In the case of a Hyper-V host, this means all the virtual machines (VMs) and the services running on them will be unavailable. However, this doesn't have to be the case. This is where the Failover Clustering feature comes into play. When hosts are in a failover cluster, you can move a service (including a VM) between the nodes without downtime, provided that the service supports a zero-downtime migration technology, such as live migration of VMs or leveraging the Server Message Block (SMB) 3.0 transparent failover. This means that patching and the associated reboots aren't a big deal in terms of availability, because there's no impact on availability.

However, the patching process can be time-consuming. Consider that to manually patch a cluster in Server 2008 and later, you need to perform the following steps:

This update process sounds simple enough, but if you have a 64-node cluster, it's a lot of work. You can purchase products that can reduce the amount of work. For example, Microsoft System Center Virtual Machine Manager (VMM) 2012 provides one-click patching of Hyper-V hosts in a cluster and there are System Center Orchestrator 2012 runbooks to automate the patching of a cluster. However, if you're running Server 2012, you can take advantage of a new built-in capability named Cluster-Aware Updating (CAU).

Automating Patching with CAU

CAU is part of Server 2012's Failover Clustering feature. With CAU, the update process for an entire Server 2012 failover cluster can be performed automatically. It's important to note this is only for Server 2012 failover clusters. It's not backward compatible with Server 2008 R2 (or earlier) clusters. There's no limitation on the applications that will work with CAU. If it's a cluster application, it should be supported. For example, VMs, file shares, and SQL Server will work with CAU. Each application's native migration technology is used as part of the CAU process.

The source for the patches can be either Windows Update or your on-premises Windows Server Update Services (WSUS) implementation. If using WSUS with CAU, you need to make sure you're using WSUS 4.0 (which is part of Server 2012) or WSUS 3.0 SP2 with the KB2734608 update applied. In addition, CAU supports a plug-in model, which allows patches from other sources. For example, Microsoft.HotfixPlugin is a nondefault plug-in supplied with CAU. It lets you select hotfixes that aren't deployed through Windows Update. You can also use it for non-Microsoft updates, such as driver and firmware updates from your hardware vendors.

With this plug-in model, CAU might eventually be able to use Microsoft System Center Configuration Manager (SCCM) as the source for the patches. However, at the time of this writing, this plug-in hasn't been written, which means you can't use SCCM as the patch source when using CAU.

After CAU is enabled in your cluster, you have a flexible yet simple patch capability for your clusters. You can trigger it manually or schedule it to run. You can even run pre-update and post-update PowerShell scripts on each node as part of the patching process.

Understanding the CAU Modes and Requirements

CAU works on physical clusters and clusters configured inside VMs. There are two modes: self-updating and remote-updating.

With the self-updating mode, the Failover Clustering management tools are installed on each node in the cluster so there are no external dependencies. Plus, a CAU clustered role is installed.

With the remote-updating mode, the Failover Clustering management tools are installed on a remote Server 2012 or Windows 8 computer, which controls the patching application in the remote clusters. If the Failover Clustering management tools aren't installed on the cluster nodes when using remote-updating, the only restriction on functionality relates to the running of debug-type information, which isn't generally used by administrators anyway.

The advantage of using the self-updating mode is that the cluster is completely self-managed and can effectively patch itself on autopilot. The advantage of using the remote-updating mode is that many different clusters can be patched from the box configured as the remote-updating coordinator. Because the coordination is being done remotely, there's no need for the Failover Clustering management tools to be installed on the cluster nodes (or even PowerShell and the Microsoft .NET Framework if you aren't using pre-update and post-update scripts), which means the cluster nodes can be running the Server Core configuration level. In addition, remote-updating gives a more verbose feedback, which is ideal when close attention is needed (but there's still no manual administrator action required).

To use CAU, the cluster nodes need to meet a few requirements:

Installing and Configuring CAU

After the requirements are met, you can install and configure CAU. I'll be walking you through setting up CAU in the self-updating mode. If you want to use the remote-updating mode, you simply install the Failover Clustering management tools, then use the GUI or the PowerShell cmdlets in the Failover Cluster Module to start the update process.

To install and configure CAU in the self-updating mode, follow these steps:

After the configuration is complete, click the Cluster-Aware Updating link for your cluster to bring up the various CAU actions. I recommend that you run the Analyze cluster updating readiness action. This will check the cluster nodes to ensure that CAU will operate correctly. CAU is now ready to apply updates following the schedule you specified.

Performing CAU Updates Manually

At any time, you can check the updates that need to be applied and manually run those updates. To do so, click the Cluster-Aware Updating link for your cluster to bring up the various CAU actions. Next, click the Preview updates for this cluster action to bring up the Preview Updates dialog box. By selecting your plug-in and clicking the Generate Update Preview List button, you can generate a list of all the updates that need to be applied to all the hosts in the cluster, as shown in Figure 3.

Figure 3: Previewing the Updates That Will Be Applied

To manually install those updates, close the Preview Updates dialog box and click the Apply updates to this cluster action. This will bring up the Cluster-Aware Updating Wizard. You just need to click Next on the Getting Started page, then click Update on the Confirmation page. CAU will then update the cluster using the existing settings.

The order in which hosts are updated is based on the number of resources currently hosted on the node. CAU will first update the node with the fewest number of resources, then update the node with second fewest resources, and so on, until all the nodes are patched.

You can monitor the progress of the updates. As Figure 4 shows, detailed information is given, including the updates being downloaded, the nodes being placed into maintenance mode, the updates being applied, the nodes being rebooted, and so on.

Figure 4: Monitoring the Updates While They're Being Applied

When you're using the self-updating mode, you'll see that the Update Coordinator will move between nodes as boxes are rebooted. (If you're doing remote updating, the Update Coordinator will remain on the remote box.) The Update Coordinator is the brains of CAU. It scans, downloads, and installs the patches on each node, controls scripts, and so on.

After all the updates are applied to a node, CAU will reboot the node and check again for any new updates that might need to be applied. If there are new updates, CAU will apply them, reboot the node, and check again for updates. This will continue until no new updates are found. After CAU has finished patching that node, it will then move to the next node. The video "Patching a Cluster with Cluster-Aware Updating (CAU)" shows this update process as well as demonstrates some other CAU-related activities. After CAU completes the update process, you can click the Generate report on past Updating Runs action to obtain a report that shows the details of the CAU execution.

Note that CAU supports a "configured but on hold" setup in which the update cycle is always manually forced and never scheduled. With this setup, you need to trigger the update application manually or use some other process to trigger it. For more information about this setup, see "Advanced Options and Updating Run Profiles for CAU."

What You Need to Keep in Mind

CAU is a fantastic feature, but it's still very important that you test the updates using the standard update validation processes before allowing CAU to deploy them. So, if you plan to let CAU run on autopilot, you need to make sure that you allow enough time for this testing when scheduling the updates.

In addition, you need to make sure you don't have other update processes going on, such as automatic updates applied outside of CAU, because this could cause downtime to your cluster. Keep in mind that CAU isn't a new patching technology. It's an orchestration technology that leverages your existing patching technologies.

Finally, CAU is one technology you don't want to tell your boss about. As far as he or she is concerned, you're still working all weekend patching your 14 separate clusters!