Cluster Aware Updating for Windows Server 2012 R2

If you would like to read the next part in this article series please go to Cluster Aware Updating for Windows Server 2012 R2 (Part 2).


Prior to the release of Windows Server 2012, applying updates to Windows Servers that were configured to act as cluster nodes was a tedious process. Thankfully, Microsoft introduced cluster aware updating in Windows Server 2012, and this feature continues to exist in Windows Server 2012 R2. In this article series, I will explain what cluster aware updating is, how it works, and I will discuss some best practices for using it.

What is Cluster Aware Updating?

Cluster Aware Updating (which Microsoft sometimes refers to as CAU) is a failover clustering related feature that is designed to make it easier to apply operating system patches to Windows Server 2012 and 2012 R2 servers that are configured to act as failover cluster nodes. Cluster Aware Updating is designed to automate much of the patching process and to perform patching in a way that avoids service outages for clustered roles whenever possible.

The reason why the previous paragraph states that Cluster Aware Updating avoids service outages “whenever possible” is because the level of service that can be expected depends on the clustered role that is being hosted by the server. In most cases, the cluster nodes must perform a planned failover as a part of the patching process. Depending on the clustered roles that are being hosted on the server, this can potentially result in a brief service interruption. However, not every clustered role experiences a service interruption as a result of the patching process. Hyper-V for example works especially well with cluster aware updates because virtual machines can be live migrated to another cluster node.

An Overview of the Cluster Aware Update Process

The way in which cluster aware updating works is actually quite simple. The update process begins by putting the cluster nodes into maintenance mode. Upon doing so, the clustered roles are moved off of one of the clustered nodes. Typically this is accomplished by way of an automated planned failover, but in the case of Hyper-V a live migration is used instead.

Once the clustered roles have been moved off of the cluster node, the updates can be installed to that node. After the update has been completed, the node is typically restarted. Once the reboot completes, the node is automatically taken out of maintenance mode and the clustered role that had previously resided on the node is moved back to the recently updated node. At this point, the cluster aware update repeats the entire process on the next node in the cluster. This goes on until every node has been updated.

Important Considerations and Best Practices for Cluster Aware Updating

There are a number of different considerations which must be taken into account prior to implementing cluster aware updating. The first of these considerations should go without saying, but it is important enough that I will discuss it anyway.

Before you implement cluster aware updating, it is critically important to make sure that your cluster is healthy. Remember that cluster aware updating can only work if the cluster is able to use a planned failover to move clustered roles from one cluster node to the next. If the cluster has any health issues that prevent it from functioning normally then a cluster aware update will likely fail and may even cause an outage in the process.

There are several things that you can check in an effort to ensure that cluster aware updating will work properly within your cluster. Some of these are relatively obvious, but again, they are important.

First, make sure that the cluster has quorum. Cluster aware updating won’t work correctly unless the cluster has quorum.

Next, make sure that you can perform DNS name resolution of the cluster name. While you are at it, it’s a good idea to verify that the Cluster Service is running on all of the cluster nodes. This is a default service that is configured to start automatically, but it is a good idea to double check and make sure that it is running.

One last thing that you should verify is cluster node domain membership. This isn’t really a health check requirement, but rather a prerequisite. Cluster aware updating won’t work unless all of the cluster nodes belong to the same Active Directory domain.

This brings up another point. Cluster Aware Updating can run in two different modes – Self Updating Mode or Remote Updating Mode. In either mode there is a component that is known as the Update Coordinator. Its job is to orchestrate the update process. The biggest difference between the two modes is that when cluster aware updating is operating in self updating mode, the update coordinator runs as a clustered role on a cluster node. When remote updating mode is used, the update coordinator is run on a computer that is not a cluster node. If you are running cluster aware updating in remote updating mode, then the computer that is acting as the update coordinator must belong to the same Active Directory domain as the cluster nodes that are being updated.

Another requirement to keep in mind is that cluster aware updating requires the cluster to have sufficient free capacity to move a clustered role to another node in the cluster. As previously mentioned, updates are not applied to a cluster node until the clustered roles have been moved off of the node and onto another node. If the nodes within the cluster are running at capacity and do not have sufficient resources to host a clustered role that was previously running on another node then the cluster aware updating process will not work.

One more thing to keep in mind is that it is extremely important to take steps to keep Cluster Aware Updating from conflicting with other types of updates that may be occurring on your network. For example, if you use System Center or WSUS to push updates to the computers on your network then you should exclude your cluster nodes from the list of update targets.

One last recommendation that I want to pass along is kind of counter intuitive. Before you use Cluster Aware Updating for the first time, it’s a good idea to apply all of the available patches to your cluster nodes. It admittedly seems awkward to have to manually patch the nodes within your cluster in preparation for deploying a solution that will automate the patching process, but putting the patches in place before you automate the deployment of future patches can help you to make sure that things run smoothly.


The biggest thing to remember before implementing cluster aware updating is that your cluster must be healthy. Microsoft provides some tools that can help with this. The Validate a Configuration Wizard is useful as is the Test-Cluster cmdlet for PowerShell. Microsoft also provides a Best Practices Analyzer for Cluster Aware Updating.

If you would like to read the next part in this article series please go to Cluster Aware Updating for Windows Server 2012 R2 (Part 2).

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top