In Order

Microsoft introduced Cluster-Aware Updating (CAU) with Windows Server 2012. This service allows you to update the operating system and server applications in clusters without cluster services malfunctioning. A cluster automatically transfers resources to other nodes, so that a server within the cluster can receive an update. In this article, I show you how to use this feature and how to manage the pitfalls.

You can only use CAU in clusters that are running Windows Server 2012 or 2012 R2. Windows Server 2008 R2 does not support this function. CAU works with all applications running on clusters in Windows Server 2012 (R2), as well as the special cluster APIs and PowerShell Cmdlets.

You can also use CAU with System Center Configuration Manager (SCCM) 2012 (R2). Companies that want to use both services in parallel must plan carefully to ensure that everything is working as desired. System Center Virtual Machine Manager (SCVMM) also has a component to update Hyper-V clusters. However, this function can only be used with Hyper-V; you cannot automatically update other cluster services with SCVMM. CAU, on the other hand, supports all cluster roles in Windows Server 2012 (R2), including Hyper-V.

Only the entire cluster can be selected in the CAU configuration for updating; you cannot use CAU if you want to update individual nodes. Also with CAU, you have to control the Windows Update function and move the active cluster roles to other nodes manually using scripts.

If you use SCVMM, you will require additional licenses, whereas CAU is available free of charge as a feature of failover clusters for all editions of Windows Server 2012 (R2). If you are already using SCVMM, you can update Hyper-V clusters in this way, and in this case, you do not have to rely on CAU.

CAU will use the API for the Windows Update Agent by default. Therefore, in addition to configuring CAU, you need to specify how updates should be installed. For this purpose, it is best to use a Windows Server Update Services (WSUS) infrastructure and Group Policy for connecting to WSUS. CAU then uses the appropriate updates and the source that you have specified in the Group Policy for the installation. Without WSUS, CAU uses the Windows Server 2012 (R2) internal update function. It is also important to know that CAU automatically installs only those updates that can also be installed via Windows Update.

Configuring CAU as a New Role

By configuring CAU in a cluster, you create a new role that performs future software updates completely independently. This new server role is the central component for automatically updating cluster nodes. It also takes over the configuration of the maintenance mode on individual cluster nodes and can restart cluster nodes, move cluster roles back to the correct cluster nodes, and more. Moving cluster roles to other nodes equates to a planned failover of the roles. Such failovers can also be conducted manually.

Before setting up CAU, you should check carefully whether individual server services or cluster roles have any problems with a failover (Figure 1). When running Hyper-V clusters, especially, it is important to check in advance whether the individual VMs are compatible with failover. CAU can also only update the cluster nodes. If you are running a Hyper-V cluster, the function will not be able to update individual virtual servers. In this case, you should work with WSUS and Windows Update settings via Group Policy.

The new server service takes care of updating the cluster in the background without affecting its operation. You can start the operating system update manually or define a schedule for the updates.

After a cluster is commissioned, CAU is not yet active, so you first need to set up the function. To create CAU for a new cluster, create a new computer object in the Active Directory Users and Computers snap-in.

This procedure is optional because the CAU wizard can also create the computer object itself later. However, this computer object is the basis for the new cluster role for setting up automatic updates. You do not need to make any adjustments for the object, you just need to create it. You can deal with the configuration later when setting up CAU. As an example, use the cluster name with the addition of cau, such as cluster-cau. However, you can use any name. The computer object is connected to the cluster later.

Firewall Settings

You also need to create an inbound firewall rule on all cluster nodes that are supposed to participate in CAU. Use Predefined | Remote Shutdown as a rule type. You can start the management program for the firewall by entering wf.msc. If the rule already exists, you can enable it via the context menu. The purpose of the rule is that, if required, the CAU service can also restart the cluster nodes after updates have been installed.

If you have conducted the setup, search for the Cluster-Aware Updating setup program on the homepage and start the tool. You can make the basic adjustments for CAU with this program. As a first step, connect to the cluster for which you want to enable CAU. Then, click on the Analyze cluster updating readiness link. The wizard will then check whether you can enable CAU in the cluster and whether all important conditions are met.

Enabling CAU for the Cluster

If you have connected to the desired cluster and carried out the analysis, you can then start the CAU setup via a wizard. You can access this via the Configure cluster self-updating options link. On the first page of the wizard, you will receive a summary of everything the wizard configures. On the next page, enable the Add the CAU clustered role, with self-updating mode enabled, to this cluster option. Next, enable the I have a prestaged computer object for the CAU clustered role option. Enter the name of the computer object that you created in advance in the field.

The wizard can also create the object automatically, which simplifies the configuration in test environments. However, completing such tasks in advance can be useful in production environments. Often, there are also different administrative groups for Cluster and Active Directory. In this case, you should also create the object in advance.

On the next page, you can specify the schedule for when the cluster and the individual nodes are automatically updated. Of course, the updates will also depend on the availability of updates. On the Advanced Options page, you can make further adjustments to adapt CAU for your environment, but these are optional. Here, for example, the option that ensures that the update will only be started if all cluster nodes are online and available is useful. This is especially important to rule out other maintenance work. CAU must move the resources operating on the cluster nodes to other servers in the cluster during the installation. The other nodes should ideally be available at this point.

Automation with Scripts

For script automation, you enable the True option in RequireAllNodesOnline on the Advanced Options page. Another possibility is to record scripts that are started before or after the cluster service update. In this way, you have every opportunity to engage in the update. For example, email can be sent or certain services checked automatically using the scripts. For this approach, it is best to work with PowerShell scripts. Before the update, the script is performed on each cluster node before the corresponding node is paused and updated. The script starts after the update on each cluster node after CAU has installed the updates. You can find all available options in Microsoft TechNet [1].

You do not, however, need to make advanced adjustments when setting up CAU. The wizard for enabling CAU also includes an update execution editor. With this, you can prepare the adjustments, save them as an XML file and simply use this XML file when setting up CAU (Figure 2).

On the next page, you can determine how the cluster service should deal with recommended updates when setting up CAU and whether they play the same role as critical updates. Here you can specifically set how updates should be installed. You will then receive a summary, and the service is finally created when you click Apply. If CAU starts an update, the service will now carry out a failover for the cluster roles. After a node has been updated, the cluster roles are moved back to the original cluster node via a failback.

Updates via PowerShell

Rather than starting the update with PowerShell, you can manage CAU with other Cmdlets (Figure 3). You can, for example, set up CAU in PowerShell with Add-CauClusterRole or export a report with Export-CauReport. You will receive all interesting Cmdlets, including their help, most quickly if you enter get-command -module ClusterAwareupdating.

Troubleshooting the Device

If the wizard displays an error, check the rights for the computer object for the cluster update that you have created in advance. Give the cluster account full access rights to the new CAU account in the object's properties. Alternatively, you can let the wizard create the computer object itself. In this case, the wizard sets the rights. With errors, simply carry out the analysis once and make the same adjustments again.

No more errors should appear in further tests, either. You can determine which patches the service ultimately installs by sharing the patches on a WSUS server. Alternatively, you can enable the local update management on the server. You will receive the list of patches that the service installs next in the management program for CAU if you click on Preview updates for this cluster. The service uses information from Windows Update on the server. If you are working with WSUS, the WSUS updates are downloaded; if you are working with Windows Update, this function will again directly use the Windows Update function on the Internet.

To start an immediate update after setup – or later, if you currently have a fixed maintenance window, for example – click on Apply updates to this cluster. The service will begin updating the individual cluster nodes immediately. You can see the status of current installations in the CAU management tool, which you have already used to set up the service. During the update, the corresponding node is placed in maintenance state. The cluster resources, such as the VMs, are moved to other nodes. The update is started, and then the resources are transferred back again. After that, the next node is updated.

Updates on a Schedule

CAU supports different update modes in which you can schedule updates. With remote updating, you can start an update manually for the cluster. As described above, you can use the user interface for this or use the Cmdlet Invoke-CauRun in PowerShell. The remote upgrade is the default update mode for CAU. With the task scheduler, you can also start the Cmdlet at a time that suits you as specified in a schedule. Make sure, however, not to use a cluster node; instead, use a server running Windows Server 2012 (R2) that is not a member of a cluster.

With the self-update function, the cluster based on a defined profile can update itself automatically. If you want to enable the self-update mode, add the CAU cluster role to the cluster, as described above. The CAU self-update feature works like any other cluster service. You can also use it for planned and unplanned failovers.

By default, CAU uses the level of activity to determine the sequence of nodes to be updated. The service first updates the nodes on which the fewest cluster roles are hosted, but you can specify a sequence. To do this, use the settings in the CAU user interface. With options, you determine the number of nodes that may be offline if CAU starts the update. CAU also provides export options via PowerShell and the user interface. The commands in PowerShell are typically faster:

Invoke-CauScan | ConvertTo-XmlGet-CauReport | Export-CauReport

The CAU Cmdlets and graphical user interface are available if you have installed the Failover Cluster Management Tools. You can use both the Server Manager and the Remote Server Administration Tools (RSAT) for Windows 8.1 [2].

If you want to download the updates from the Internet, but the cluster has no direct connection to the Internet, you can also use a proxy server. You can, for example, set preferences in the command line using netsh:

netsh winhttp set proxy [name]

or

netsh winhttp set proxy [proxy]:[port] "<local>;*.[domain]"

In the command, enter the name or the IP address and proxy port, with the exceptions in quotation marks. Here, enter your internal domain, as well as the option <local> to configure all local servers as an exception.

Conclusion

Companies often face the question of how to update clusters. Cluster-Aware Updating is a valuable tool if no maintenance windows are available. No lengthy failures occur, because the cluster resources are enabled on other servers. However, make sure all cluster nodes in the network can cope with the additional load if a node is shut down for upgrades and its resources are distributed in the cluster.