In previous releases of Windows, the server updating tools (e.g. WSUS) did not factor in the fact that a group of servers could be members of a highly-available cluster. As failover clusters are all about high availability of services hosted on the cluster, one would almost never patch all cluster nodes at the same time. So patching a failover cluster usually meant a fair number of manual steps, scripting/tools, and juggling administrator’s attention across a number of clusters to successly update them all during a short monthly maintenance window. Addressing this was always the #1 ask for Windows Server 2012, during all the discusssions we had with customers in early days of release planning. Cluster-Aware Updating (CAU) is an exciting new feature that we have added in Windows Server 2012 that addresses precisely this gap. Once you have decided to try the CAU feature in Windows Server 2012 to update your failover cluster, you will very quickly apreciate its simplicity and power.
CAU allows you to update clustered servers with little or no loss in availability during the update process. During an Updating Run, CAU transparently puts each node of the cluster into node maintenance mode, temporarily fails over the “clustered roles” off it to other nodes, installs the updates and any dependent updates on the first node, performs a restart if necessary, brings the node back out of maintenance mode, fails back the original clustered roles back onto the node, and then proceeds to update the next node. CAU is cluster workload-agnostic, and it works great with Hyper-V, and a number of File Server workloads.
CAU can work in one of two modes:
1. Self-Updating: Once configured by you, CAU can run on a cluster node that it is meant to update. You would simply configure the updating schedule and let CAU update the cluster
2. Remote-Updating: CAU can run on a standalone Windows 8/Windows Server 2012 computer that is not a cluster node. You can then have CAU “connect” to any failover cluster using appropriate administration credentials, and update the cluster on demand
For an overview of the scenario, check out the CAU Scenario Overview.
For this blog post, I will focus on the first mode above: Self-Updating. The beauty of self-updating is that it lets you configure your failover cluster to be on “auto pilot” in terms of patching, and once set up, the cluster updates itself on the schedule you have defined in a way that it causes either no impact to service availability, or the least possible – depending on the types of workloads (e.g. Hyper-V cluster updating experience would be truly continuously available with Live Migration, with zero down time to Hyper-V VM users).
At a high level, there are three things you need to do to get the end-to-end scenario working and operating seamlessly with your existing patching infrastructure such as Windows Server Update Services (WSUS), on a Windows Server 2012 failover cluster:
1. Install CAU tools on the Windows Server 2012 (or Windows 8 Client) computer that you want to run it from.
2. Configure self-updating on the desired failover cluster
3. Confirm that the scenario works by previewing the updates and prompting a Self-Updating Run
Then you simply sit back and enjoy watching cluster self-updating in action!
Let’s start with the first step.
1. Install CAU tools
Installation of CAU is very easy: CAU tools are a part of Failover Clustering Tools. As Failover Clustering Tools are by default auto-selected for installation when the Failover Clustering feature is installed on a cluster node, your cluster nodes most likely already have CAU tools pre-installed. The net is that you can safely skip this step if you are running it from one of the cluster nodes. If you had of course explicitly chosen not to install Failover Clustering Tools on the cluster nodes, you will need to install them now with this step.
If you plan to run CAU from a computer different from the cluster nodes, that is still easy! Look at the following screen shot for how to install it from Server Manager on that computer:
Alternatively, you can also install CAU tools via PS cmdlet option. See this screen shot below:
As you can see I am installing the “RSAT-Clustering” Windows Feature, which installs the “ClusterAwareUpdating” PS module. And then I am sanity checking that the module was properly installed by listing all the CAU cmdlets.
The same cmdlets are included below in text for convenience:
Add-WindowsFeature RSAT-Clustering –verbose
Get-Command –Module ClusterAwareUpdating
To make sure that CAU GUI application was properly installed along with CAU PS cmdlets, you can sanity check that Server Manager is ready to launch CAU, as in the next screen shot. See the first item under “Tools” menu in the screen shot.
2. Configure self-updating on the desired failover cluster
You can configure self-updating for a cluster either via the CAU GUI application, or through CAU PS cmdlets. Let us look at the GUI approach first, so you can be familiar with the cmdlet options for usage later in the blog post.
You always start off by connecting to a cluster as in the following screen shot:
Look at the two highlighted areas in red in the above screen shot – you can type in the desired cluster name, and hit the “Connect” button right next to it. You of course can also click the down-arrow right next to the cluster name text box, which will show all the available cluster names, as known to local AD. This list is auto-populated for you everytime GUI starts up.
Then look at the Cluster Action circled in green in the previous screen shot – “Configure cluster self-updating options”. This is the action you choose to start the self-updating configuration process for your failover cluster. Once you click on this action, it pops up the “Getting Started” wizard page as shown in the next screen shot:
As the Getting Started text says, this wizard is smart enough to figure out that you do not have self-updating currently configured on the connected cluster, and automatically offer you the option to add it. Now, if you had self-updating already configured for your cluster, the wizard would give you three different options – to disable, re-enable and remove the self-updating functionality. So in effect, this wizard is your “one-stop shop” for all things related to self-updating configuration.
When you click the “Next” button, you see the screen as in the following screen shot:
Note that you must choose the red-circled “Add the CAU clustered role..” action, in order to get to the next wizard screen. CAU clustered role is the Self-Updating functionality for the cluster. Just in case you are wondering, the reason we call it the “CAU clustered role” on this screen is to make sure that you notice that it is a clustered role (aka “resource group”) that can failover and fail back to other cluster nodes. The nice aspect of this design is that CAU self-updating is a clustered service in its own right, that is highly available. It means that if the node that is acting as the Update Coordinator for a Self-Updating Run fails in the middle of the Run, the CAU Update Coordinator would simply failover to a new cluster node and continue from where it left off.
Once you hit “Next” on this screen, you will see the next wizard screen as in the screen shot below:
Most enterprises tend to have a monthly updating schedule, that generally tracks Microsoft monthly “Patch Tuesday” schedule. But the wizard also allows you to define either a daily or a weekly updating schedule if you prefer. In the screen shot shown, I am selecting 3AM on Third Tuesday of every month as my updating schedule, that is roughly a week after the monthly security bulletin notification from Microsoft. The next “Advanced Options” wizard screen shot is shown below:
You most likely do not have to bother about changing the options in the screen shot, as the defaults are fairly conservative and benign. However, you may change them if your data center processes need it. Don’t forget to read what the options mean though first! There’s a static help file hyper-linked from this page, or you can check out the Add-CauClusterRole cmdlet parameters for more and current guidance, whose names are intentionally identical to the advanced option names on this screen.
If you had selected the Microsoft.WindowsUpdatePlugin as the operational plug-in for the Self-Updating Run (I plan to come back to plug-ins in a future blog post, but if you are really curious, you can check out the public CAU plug-in API specification and the CAU plug-in sample code on MSDN), you will see a wizard screen specific to Windows Update, as in the screen shot below:
In this additional update options screen, I am choosing to have “Recommended” updates be automatically installed on all the cluster nodes just as the “Important” updates (BTW, this is the same terminology that Windows Update uses). But you can choose to just have CAU install Important updates alone.
That’s it! When you hit the “Next” button on the screen above, you will arrive at the final Confirmation page of the wizard, as in the next screen shot. You simply confirm all your previous selections, and click on the “Apply” button to complete the self-updating configuration process.
Since we have already talked about a number of foundational concepts – e.g. schedules, prestaging, advanced options, update types – in the preceding text, we can now jump directly to the Windows PowerShell version of the same now. Look at the screen shot below, Add-CauClusterRole cmdlet does what we need, and the parameter and argument names should all be self-explanatory.
The same cmdlet here again in text:
Add-CauClusterRole -ClusterName CAUClu8330-29 -Force -CauPluginName Microsoft.WindowsUpdatePlugin -MaxRetriesPerNode 3 -CauPluginArguments @{ 'IncludeRecommendedUpdates' = 'True' } -StartDate "5/7/2012 3:00:00 AM" -DaysOfWeek 4 -WeeksOfMonth @(3) –verbose
In fact, I admit I cheated a bit here…. I have simply copied and pasted the PS cmdlet string shown in the wizard confirmation screen GUI and added the -verbose parameter to it. Hopefully that also illustrates to you how well CAI GUI and the PS cmdlets are integrated here, transitioning from one to the other is super-easy.
In the next blog post, I will talk about the third and final step of confirming that the end-to-end scenario works, and the things to watch out for. Stay tuned!