Save to My DOJO
In today’s data center, and for the foreseeable future, the biggest word is “automation”. It doesn’t matter how big your datacenter is, either. Whether your servers have a multi-continental presence or have been relegated to a closet, there’s never enough staff allocated with enough time to manually manage these systems. Even if you did have the time, why would you want to? What benefit is there in opening processes up to human error when you can have the systems babysit themselves?
That’s why I’m surprised that there’s so little written about Cluster-Aware Updating (CAU). This magnificent feature was introduced with Windows Server 2012, and it is a perfect match for Hyper-V. If you’re thinking about converting your single-host system into a single-node cluster for CAU, sorry, I couldn’t find any way to make CAU work like that.
Before I can talk about anything else, I need to give CAU a brief introduction. Simply, this tool manages Windows Updates for an entire cluster in a way that eliminates or reduces requirements for manual intervention and eliminates or reduces guest downtime. Whew. That’s a big sentence. Here are the three takeaways:
- Coordinated Windows Updates for the whole cluster
- No manual intervention
- No guest downtime
I might be overselling it a bit. There may not be zero intervention and there may not be zero downtime. Those should be the outlying cases, though.
Pre-Cluster-Aware Updating Setup
There are a few things you need to do before you can start using CAU.
In order to fully utiilize CAU, you have to install the full set of Failover Clustering tools on each node. When you install Failover Clustering in Server Manager, it queries you to install the tools along with the feature. If you missed it, you can go back in to the Add Roles and Features Wizard and select it under Remote Server Administration Tools.
You can also add them in PowerShell:
Add-WindowsFeature RSAT-Clustering
Cluster-Aware Updating uses its own computer account in Active Directory. This account will exist in the same Organizational Unit as the computer account for your cluster.
You can “pre-stage” this account, which means you use Active Directory Users and Computers or PowerShell to create this computer account yourself. If you don’t do that, then you can allow CAU to create the account. I like creating it myself as CAU uses an automatically-generated name that probably won’t fit your naming scheme.
No matter what, you need to enable at least a few permissions. If you’re going to let CAU create the computer account, you need to access the Security tab of the Organizational Unit and assign Read All Properties and Create Computer Accounts to the current cluster’s computer account. If you don’t want to drill down that far, Read and Create all child objects will cover it.
If you’re going to pre-stage the account, you need to assign the cluster’s computer account Full Control permissions to the Organizational Unit. After you’ve created the account, disable it as shown in the first ADUC screenshot. Otherwise, CAU won’t be able to activate it.
This is enough to get CAU working in its default configuration. Depending on what you choose to do, there may be additional necessary steps. You can find a full walk-through for enabling CAU on TechNet: http://technet.microsoft.com/en-us/library/jj134234.aspx. We’re going to move on into using it.
The Two Faces of Cluster-Aware Updating
Now that the groundwork is laid, you can start with CAU. As with most things Microsoft these days, you can choose between a GUI or PowerShell. You can see all the PowerShell commands with the following:
Get-Command -Module ClusterAwareUpdating
The GUI can be accessed using the Tools menu in Server Manager, as an item in the Start Screen under Administrative Tools, or by a link on the cluster’s home page in Failover Cluster Manager.
Before you can do anything in this tool, enter your cluster name in the text box at the top and click Connect. The PowerShell cmdlets all have a -Cluster parameter you can use.
The Preparation
Once you’ve got the prerequisites out of the way, it’s a good idea to take a moment to be sure that you can expect a CAU pass to work. Microsoft has built a tool to do this for you, quickly and easily. The GUI has the Analyze cluster updating readiness link. PowerShell has the Test-Cau cmdlet. I prefer the GUI version as the output is much easier to read. Here’s a sample of the output from the GUI:
Mine passed, with a warning about the proxy. You only need to enter proxy information if your hosts can’t connect directly to a WSUS system or Microsoft’s Internet-based update servers. If you have any errors on any outputs and need to know what to do, the Microsoft link above shows a table of solutions.
Two Modes
CAU runs in two completely different modes, and the distinctions are important. The first I’m going to talk about is called “remote-updating mode” in the official documentation. I don’t really care for this descriptor as it doesn’t really convey the entire situation. It might be better called “manual-updating mode”, because you have to start it yourself. One reason it might be called “remote-updating mode” is because you have to start it remotely. The GUI will allow you to attempt to start a run from a node (Apply updates to this cluster link), but as soon as that node reboots, the entire run will fail. The PowerShell cmdlet (Invoke-CAURun ) will fail automatically if you try to run it from a node. Be aware that this won’t work at all until Cluster-Aware Updating is enabled on your cluster.
The other mode is self-updating. This is the “set-it-and-forget-it” mode you’ll use most of the time. This is set up through the Configure cluster-aware updating options link, which, conveniently, is also where you enable cluster-aware updating.
Enable Cluster-Aware Updating
Assuming you’ve prepared all the necessary prerequisites, you’re ready to get started. You can enable CAU through PowerShell, but it’s much easier to use the GUI, at least the first time. Click Configure cluster self-updating options to get started.
Skip the first screen. The next is shown if you’ve never enabled CAU. This is where you set up the computer account. Since I pre-staged mine, I set it like this (careful readers will notice that this screenshot has a hyphen in the name while the original does not; the names are actually required to match and the hyphen shouldn’t have been there):
The next screen, which I didn’t take a picture of, has you set the time and date options. You can only pick solid hours here. If you wanted to do something else, don’t despair. We can make everything all better later. Set this screen as close as you can and continue on.
On the next screen, you get a number of options. There is a link at the top that explains some of them to some degree. In the next post in this series, we’ll dive into those deeper. For now, just click Next. You’ll be greeted with a screen that asks about taking recommended updates along with important updates. Check or not, as desired, and continue.
This is the screen we’ve been waiting for. It’s the typical summary screen, with a twist. The very last text field, the one that shows the PowerShell script, is selectable. Highlight all that and save it to a .PS1 file somewhere.
Here’s a look at the script that was generated on mine:
Add-CauClusterRole -ClusterName clhv1 -Force -CauPluginName Microsoft.WindowsUpdatePlugin -MaxRetriesPerNode 3 -CauPluginArguments @{ 'IncludeRecommendedUpdates' = 'False' } -StartDate "4/21/2014 3:00:00 AM" -DaysOfWeek 4 -WeeksOfMonth @(3) -VirtualComputerObjectName CLHV1-CAU -EnableFirewallRules;
Now that you’ve got the script saved, you can apply on the GUI screen, or you can cancel and just work with the pasted script. I’d go ahead and let the GUI set everything up initially, though.
The script that you kept isn’t of the most use. You can use it to repeat the installation for other systems without spending all that time in the GUI. All you have to do is change the -ClusterName and -VirtualComputerObjectName parameters. What you can do, though, is go back into the same wizard and step through to the end. Grab that script, and you’ll get something like the following:
Set-CauClusterRole -ClusterName clhv1 -Force -CauPluginName Microsoft.WindowsUpdatePlugin -CauPluginArguments @{ 'IncludeRecommendedUpdates' = 'False' } -MaxRetriesPerNode 3 -StartDate "4/21/2014 3:00:00 AM" -DaysOfWeek 4 -WeeksOfMonth @(3) -UseDefault -EnableFirewallRules;
Enable-CauClusterRole -ClusterName clhv1 -Force;
I’ve split this out into two separate lines, although the wizard doesn’t. This one is much more useful to save. If you want to make any changes, you can just make them in your .PS1 file and run it. See the time entry there? Make that anything you like. Want to change -DaysOfWeek but don’t feel like muddling through Boolean OR logic? Try something like -DaysOfWeek Monday, Tuesday, Wednesday.
The Process
As Cluster-Aware Updating runs, this is the order of operations:
- All nodes download updates in parallel.
- A node is chosen to be updated (documentation indicates that the node with the fewest roles goes first, then steps through to the node with the most roles; in practice I’m not certain this is true). Another node is chosen as the coordinator.
- If the node has no patches available, the process on that node stops and jumps to step 10. Otherwise, it proceeds to step 4.
- Pre-update scripts are run.
- The node is placed into maintenance mode (roles are drained).
- Patches are applied.
- The system is rebooted if necessary.
- Post-update scripts are run.
- Maintenance mode is ended and roles are retrieved.
- If other nodes are available, the process starts over at step 2.
Any errors at any point halt the entire process. You’ll find that it’s quite thorough. It will even detect if an updating run would cause a cluster to dip below quorum, and won’t run if that’s the case.
Wrapping Up
You don’t really need to do anything else. One thing you definitely don’t want to do is set up Windows Update on the nodes. If you did, go back and set it to nothing more than download only. In the next post, we’ll talk about other options.
What You Get
The outcome of all your work means that, at the specified time and date, the cluster will analyze all the nodes and pick the one with the fewest roles. It will pause the cluster service on that node so that it won’t accept any incoming migrations, then it will move all its resources to other nodes. It will then patch that node, reboot it if necessary, and reverse the process. If there are any errors along the way, it will cancel the entire process and return it to the state it found the cluster in as best it can. Errors can be found in the GUI as shown above and in Failover Cluster Manager.
There are also two logs you can find in the regular Event Viewer called “ClusterAwareUpdating” and “ClusterAwareUpdating-Management”. You can find them under Applications and Services Logs->Microsoft->Windows. The ClusterAwareUpdating-Management log usually contains the best details on any problems.
If there aren’t any errors, CAU retrieves all that node’s roles (VMs), and moves along to the next least-populated system.
What’s Next
This is the basic setup for Cluster-Aware Updating. In the next installment in this series, we’re going to dive in and take a look at some of the more advanced options in more detail.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Eric Siron
22 thoughts on "Cluster-Aware Updating and Hyper-V Part 1: The Basics"
Hello Eric,
in the section “The Process”, step 4, the text should be, I assume, “The cluster NODE is placed into maintenance mode …”
Kind regards,
Zoran
Correct, good catch. Thank you! The post has been updated.
Hello Eric,
in the section “The Process”, step 4, the text should be, I assume, “The cluster NODE is placed into maintenance mode …”
Kind regards,
Zoran
I’ve configured the computer account for CAU, give him full permissions on the OU where the HyperV servers are but it still fails in the end”clustered role failed because a network name resource could not be created”
Any idea?
The cluster’s existing CNO is the account that needs full permissions on the OU. If you pre-create the CAU CNO before assigning those permissions, you’ll then need to assign them directly on the CAU CNO as well because it will not automatically inherit.
I’ve configured the computer account for CAU, give him full permissions on the OU where the HyperV servers are but it still fails in the end”clustered role failed because a network name resource could not be created”
Any idea?
Hi,
is there a reason why the CAU won’t start to the time I set in the options wizard? My time zone here is GMT 1, and the self update always starts that one hour later too, no matter if daylight saving or standard time.
Hi,
is there a reason why the CAU won’t start to the time I set in the options wizard? My time zone here is GMT 1, and the self update always starts that one hour later too, no matter if daylight saving or standard time.
Thank you for this details approach on CAU.
Can I ask what if one to 2 hosts in a cluster also have VMs that are not part of the FC roles, what happens to them since they are stored locally and the roles cannot be drained?
Well, CAU will completely ignore them. So, when it starts its patching of the host, the local VMs will continue running. When it reboots the host, the VMMS service will apply the automatic shutdown action setting for each of those local VMs. When the host starts up after patching, VMMS will apply the automatic startup action for each of those local VMs.
For whatever it’s worth, I have local VMs and everything works just fine. Just take care that the automatic action settings are set to your liking for each local VM.