Cluster-Aware Updating: Frequently Asked Questions

Yes. CAU supports updating Storage Spaces Direct clusters regardless of the deployment type: hyper-converged or converged. Specifically, CAU orchestration ensures that suspending each cluster node waits for the underlying clustered storage space to be healthy.

No. CAU coordinates the cluster updating operation only from computers running Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1, or Windows 8. The failover cluster being updated must run Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012.

No. CAU is agnostic to the type of the clustered application. CAU is an external cluster-updating solution that is layered on top of clustering APIs and PowerShell cmdlets. As such, CAU can coordinate updating for any clustered application that is configured in a Windows Server failover cluster.

Yes. By default, CAU is configured with a plug-in that uses the Windows Update Agent (WUA) utility APIs on the cluster nodes. The WUA infrastructure can be configured to point to Microsoft Update and Windows Update or to Windows Server Update Services (WSUS) as its source of updates.

Yes. By default, CAU is configured with a plug-in that uses the Windows Update Agent (WUA) utility APIs on the cluster nodes. The WUA infrastructure can be configured to point to Microsoft Update and Windows Update or to a local Windows Server Update Services (WSUS) server as its source of updates.

Yes. Limited distribution release (LDR) updates, also called hotfixes, are not published through Microsoft Update or Windows Update, so they cannot be downloaded by the Windows Update Agent (WUA) plug-in that CAU uses by default.

However, CAU includes a second plug-in that you can select to apply hotfix updates. This hotfix plug-in can also be customized to apply non-Microsoft driver, firmware, and BIOS updates.

Yes. If the cumulative updates are general distribution release updates or LDR updates, CAU can apply them.

Yes. CAU supports the following updating modes, both of which allow updates to be scheduled:

Self-updating Enables the cluster to update itself according to a defined profile and a regular schedule, such as during a monthly maintenance window. You can also start a Self-Updating Run on demand at any time. To enable self-updating mode, you must add the CAU clustered role to the cluster. The CAU self-updating feature performs like any other clustered workload, and it can work seamlessly with the planned and unplanned failovers of an update coordinator computer.

Remote-updating Enables you to start an Updating Run at any time from a computer running Windows or Windows Server. You can start an Updating run through the Cluster-Aware Updating window or by using the Invoke-CauRun PowerShell cmdlet. Remote-updating is the default updating mode for CAU. You can use Task Scheduler to run the Invoke-CauRun cmdlet on a desired schedule from a remote computer that is not one of the cluster nodes.

Yes. CAU doesn't impose any constraints in this regard. However, performing software updates on a server (with the associated potential restarts) while a server backup is in progress is not an IT best practice. Be aware that CAU relies only on clustering APIs to determine resource failovers and failbacks; thus, CAU is unaware of the server backup status.

CAU is a tool that coordinates software updates on a cluster node, and Configuration Manager also performs server software updates. It's important to configure these tools so that they don't have overlapping coverage of the same servers in any datacenter deployment, including using different Windows Server Update Services servers. This ensures that the objective behind using CAU is not inadvertently defeated, because Configuration Manager-driven updating doesn't incorporate cluster awareness.

Yes. For running the CAU tools, CAU needs administrative credentials on the local server, or it needs the Impersonate a Client after Authentication user right on the local server or the client computer on which it is running. However, to coordinate software updates on the cluster nodes, CAU requires cluster administrative credentials on every node. Although the CAU UI can start without the credentials, it prompts for the cluster administrative credentials when it connects to a cluster instance to preview or apply updates.

Yes. CAU comes with PowerShell cmdlets that offer a rich set of scripting options. These are the same cmdlets that the CAU UI calls to perform CAU actions.

Clustered roles (formerly called applications and services) that are active on a node, fail over to other nodes before software updating can commence. CAU orchestrates these failovers by using the maintenance mode, which pauses and drains the node of all active clustered roles. When the software updates are complete, CAU resumes the node and the clustered roles fail back to the updated node. This ensures that the distribution of clustered roles relative to nodes stays the same across the CAU Updating Runs of a cluster.

CAU relies on clustering APIs to coordinate the failovers. The clustering API implementation selects the target nodes by relying on internal metrics and intelligent placement heuristics (such as workload levels) across the target nodes.

CAU doesn't load balance the clustered nodes, but it attempts to preserve the distribution of clustered roles. When CAU finishes updating a cluster node, it attempts to fail back previously hosted clustered roles to that node. CAU relies on clustering APIs to fail back the resources to the beginning of the pause process. Thus in the absence of unplanned failovers and preferred owner settings, the distribution of clustered roles should remain unchanged.

By default, CAU selects the order of nodes to update based on the level of activity. The nodes that are hosting the fewest clustered roles are updated first. However, an administrator can specify a particular order for updating the nodes by specifying a parameter for the Updating Run in the CAU UI or by using the PowerShell cmdlets.

The administrator who initiates an Updating Run can specify the acceptable threshold for the number of nodes that can be offline. Therefore, an Updating Run can proceed on a cluster even if all the cluster nodes are not online.

No. CAU is a cluster-scoped updating tool, so it only allows you to select clusters to update. If you want to update a single node, you can use existing server updating tools independently of CAU.

No. CAU can only report Updating Runs that are initiated from within CAU. However, when a subsequent CAU Updating Run is launched, updates that were installed through non-CAU methods are appropriately considered to determine the additional updates that might be applicable to each cluster node.

Yes. CAU offers the following dimensions of flexibility to suit enterprise customers' unique IT process needs:

Scripts An Updating Run can specify a pre-update PowerShell script and a post-update PowerShell script. The pre-update script runs on each cluster node before the node is paused. The post-update script runs on each cluster node after the node updates are installed.

Advanced Updating Run options The administrator can additionally specify from a large set of advanced Updating Run options such as the maximum number of times that the update process is retried on each node. These options can be specified using either the CAU UI or the CAU PowerShell cmdlets. These custom settings can be saved in an Updating Run Profile and reused for later Updating Runs.

Public plug-in architecture CAU includes features to Register, Unregister, and Select plug-ins. CAU ships with two default plug-ins: one coordinates the Windows Update Agent (WUA) APIs on each cluster node; the second applies hotfixes that are manually copied to a file share that is accessible to the cluster nodes. If an enterprise has unique needs that cannot be met with these two plug-ins, the enterprise can build a new CAU plug-in according to the public API specification. For more information, see Cluster-Aware Updating Plug-in Reference.

For information about configuring and customizing CAU plug-ins to support different updating scenarios, see How Plug-ins Work.

CAU offers export options through the command-line interface and through the UI.

Command-line interface options:

• Preview results by using the PowerShell cmdlet Invoke-CauScan | ConvertTo-Xml. Output: XML

• Report results by using the PowerShell cmdlet Invoke-CauRun | ConvertTo-Xml. Output: XML

• Report results by using the PowerShell cmdlet Get-CauReport | Export-CauReport. Output: HTML, CSV

UI options:

• Copy the report results from the Preview updates screen. Output: CSV

• Copy the report results from the Generate report screen. Output: CSV

• Export the report results from the Generate report screen. Output: HTML

A CAU installation is seamlessly integrated into the Failover Clustering feature. CAU is installed as follows:

• When Failover Clustering is installed on a cluster node, the CAU Windows Management Instrumentation (WMI) provider is automatically installed.

• When the Failover Clustering Tools feature is installed on a server or client computer, the Cluster-Aware Updating UI and PowerShell cmdlets are automatically installed.

CAU doesn't need a service running on the cluster nodes. However, CAU needs a software component (the WMI provider) installed on the cluster nodes. This component is installed with the Failover Clustering feature.

To enable self-updating mode, the CAU clustered role must also be added to the cluster.

• System Center Virtual Machine Manager (VMM) is focused on updating only Hyper-V clusters, whereas CAU can update any type of supported failover cluster, including Hyper-V clusters.

• VMM requires additional licensing, whereas CAU is licensed for all Windows Server. The CAU features, tools, and UI are installed with Failover Clustering components.

• If you already own a System Center license, you can continue to use VMM to update Hyper-V clusters because it offers an integrated management and software updating experience.

• CAU is supported only on clusters that are running Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012. VMM also supports Hyper-V clusters on computers running Windows Server 2008 R2 and Windows Server 2008.

Yes. A failover cluster in a self-updating configuration can be updated through remote-updating on-demand, just as you can force a Windows Update scan at any time on your computer, even if Windows Update is configured to install updates automatically. However, you need to make sure that an Updating Run is not already in progress.

Yes. CAU supports a number of Updating Run options that determine how the Updating Run behaves when it updates the cluster. These options can be saved as an Updating Run Profile, and they can be reused across any cluster. We recommend that you save and reuse your settings across failover clusters that have similar updating needs. For example, you might create a "Business-Critical SQL Server Cluster Updating Run Profile" for all Microsoft SQL Server clusters that support business-critical services.

• Cluster-Aware Updating Plug-in Reference

• Cluster Aware Updating plug-in sample

• Cluster-Aware Updating Overview