Cluster-aware updating - Self updating not working RRS feed

  • Question

  • Hi,

    I have a Windows Server 2012 failover cluster with 2 nodes, and I am having problems gettign the Self updating to work properly.

    The Analyze CAU Readiness does not report any issues, and I have been able to run a remote update with no problems. I don't get any errors or failure messages in the CAU client, only this message: "WARNING: The Updating Run has been triggered, but it has not yet started and might take a long time or might fail. You
    can use Get-CauRun to monitor an Updating Run in progress."

    In the Event Viewer is see 2 errors and 1 warning for each run, Events 1015, 1007 and 1022.

    1015: Failed to acquire lock on node "node2". This could be due to a different instance of orchestrator that owns the lock on this node.

    1007: Error Message:There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on.

    Does anyone have any idea what is causing this to fail?


    Thursday, April 11, 2013 7:27 AM

All replies

  • Hi,

    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.

    CAU does not 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, 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.

    For more information please refer to following MS articles:

    Cluster-Aware Updating: Frequently Asked Questions
    How WSUS and Cluster-Aware Updating Are Affected by Windows Server 8 Beta Updates


    TechNet Community Support

    • Edited by Lawrence, Friday, April 12, 2013 7:52 AM
    Friday, April 12, 2013 7:15 AM
  • Remove the CAU configuration,  reinstall and reconfigure CAU.

    Regards, Samir Farhat Infrastructure Consultant

    Friday, April 12, 2013 12:46 PM
  • I have removed CAU configuration, and reapplied it several times with no luck. Did it once more now, but it all ended in the same result.

    I hope you are not suggesting to reinstall the servers, I was hoping to avoid that.

    Monday, April 15, 2013 9:39 AM
  • I am having the exact same problem on three different clusters.  They all worked for about two weeks, then began to fail simultaneously (weekly update schedule).  Has anybody found a resolution, or at least a cause?
    Thursday, July 11, 2013 3:52 PM
  • In my case this was caused because we use group policy preferences to enforce membership in the local Administrators group on all of our servers.  Enabling self-updating adds the CAU computer account to the local Administrators group on each cluster node.  I haven't seen this documented anywhere, but figured it out on my own because it would work if a run was initiated right after enabling self-updating, but not on subsequent runs (because a group policy refresh had removed the CAU account from the group).  Modifying the policy to add the CAU account to the list fixed self-updating.
    • Proposed as answer by Jeff.Rash Tuesday, February 24, 2015 9:18 PM
    Wednesday, February 18, 2015 10:55 PM
  • I totally over looked this. I had the exact same situation and adding the cluster "ResourceGroupName" value from the Get-CauClusterRole PowerShell command to the Restricted Group GPO setting corrected this immediately. And by immediately I mean as soon as I ran a GPUPADTE on the cluster nodes. :)


    Tuesday, February 24, 2015 9:18 PM
  • Thanks Jeff!  CAU updating was failing for me for (apparently) the exact same reason.  

    Just to add to this, if you're using a GPO with restricted groups for the local admins group, the GPMC doesn't want to allow you to add a computer account to the local admins directly, so what I did was to create a security group in AD called "mydept-cuagrp", pop the CAU computer account into that group, and then in turn, added that security group to my list of groups allowed to be members of the local admins group within the GPO.  The GPMC happily accepted that, and then after running a gpupdate on my cluster nodes, CAU ran flawlessly.

    Thanks again!

    Wednesday, August 12, 2015 1:04 PM
  • What happened to us is that the Cluster CAU Computer account was too long ( 13 characters ( longer than the Windows)). So it was indeed in the Local Administrators the Computer Account was shown as Pre-Windows 2000 name ( 12 char)

    So I removed CAU. recreated the Computer Account, reconfirgured CAU and it worked.

    What a bug ?

    Tuesday, March 1, 2016 3:08 PM
  • Thanks Gregg,

    We are doing the same thing with controlling local administrators with GPP and I could get CAU to work through powershell commands Ivoke-caurun, but it would not run on its own and I am sure this is why.  Thanks for your time to add the response.


    • Edited by DaveBryan37 Tuesday, April 25, 2017 5:06 PM
    Tuesday, April 25, 2017 5:06 PM
  • It happens to be that I am building a guest cluster right now using scripts in SCVMM.  Here is the command I use.  You will of course need to tweak it for your needs:

    Add-CauClusterRole -CauPluginArguments @{'IncludeRecommendedUpdates' = 'True'} -RequireAllNodesOnline -VirtualComputerObjectName "cau$ClusterName" -GroupName  "cau$ClusterName" -StartDate "7/31/2015 12:00:00 AM" -DaysOfWeek Sunday -IntervalWeeks 1 -EnableFirewallRule -FailbackMode Immediate -Force

    In my case, the cluster name variable is passed by SCVMM.  You could just set it yourself, use Get-Cluster to read it, or replace the variable with string text.  I pre-create the CAU computer name object.  Your problem might be caused by insufficient permissions in AD for the cluster/nodes.  I created AD groups for each type of cluster (Hyper-V, SQL, etc.) and I added all clusters and nodes to their respective group (ie SQL node and cluster computer accounts are added to the SQL Clusters group) and I have granted that group permissions to create and modify computer accounts within the OU where the computer name objects for that type of cluster are put.

    Tuesday, April 25, 2017 7:06 PM
  • Hi,

    I had the same symptoms. For me the problem was that the pre and post update scripts has a space in their names. When I removed the space everything worked fine!

    Wednesday, September 19, 2018 12:34 PM
  • Server 2016, guest VM cluster

    CAU worked for years, today it failed with

    Failed to acquire lock on node . This could be due to a different instance of orchestrator that owns the lock on this node.

    None above makes any difference, it is already in admin group, all AD accounts are correct.

    Like always, when it works it is great, when it fails, it is a nightmare to troubleshoot

    Thursday, April 4, 2019 6:58 AM