On a Windows Server Failover Cluster for each Network Name resource there is a logical name which has a corresponding computer object (CO) created. The computer object associated with the Cluster Name this is commonly referred to as the Cluster Name Object (CNO) and for all other Network Name resources these are commonly referred to as Virtual Computer Objects (VCO). The cluster service creates and manages these CNO and VCO computer objects.
Because CNO and VCO’s are managed by the cluster, they can at times have slightly different behavior than normal computer objects. Understanding these differences can be important when trying to identify when computer objects are stale and no longer being used, so that it is safe to delete them.
If you are running a Windows Server 2008 R2 or higher Domain Functional Level for your Active Directory forest, I recommend turning on the Active Directory Recycle Bin feature (which is disabled by default). Here is the step-by-step guide . Active Directory Recycle Bin helps minimize directory service downtime by enhancing your ability to preserve and restore accidentally deleted Active Directory objects without restoring Active Directory data from backups, restarting Active Directory Domain Services (AD DS), or rebooting domain controllers. This is critical for being able to quickly and seamlessly recover from accidental computer object deletion.
There are a couple different attributes commonly used by domain administrators as hints to identify computer objects that are no longer in use and are safe to be deleted:
- pwdLastSet – This is the last time the password was changed.
- Windows Server 2003 – The computer object password is not periodically rotated on Windows Server 2003 and below clusters. This attribute should not be used to identify stale objects for deletion on Windows 2000 Server or Windows Server 2003 clusters which have the Enable Kerberos Authentication option turned on. Note that computer objects were not created by default for cluster Network Name resources in these legacy releases.
- Windows Server 2008 or later – A feature was added in Windows Server 2008 that failover clustering will rotate the CNO and VCO passwords exactly the same as a normal machine computer object. The default domain policy for MaximumPasswordAge will be honored, which is every 30 days by default. Failover Clustering will also honor if DisablePasswordChange is set, to disable password rotation. Password rotation for CNO and VCO's is initiated when the age reaches 75% of expiration to ensure passwords are rotated within the policy, so with the default settings cluster will rotate the password on the 23rd day.
- LastLogonTimeStamp – This is the last time a logon occurred. This is a new attribute introduced with a Windows Server 2003 functional level domain.
- When the cluster Network Name resource comes online, it will logon and the LastLogonTimeStamp attributed will be updated. The credentials are cached by clustering and used for the lifespan of the system. If a failure or failover occurs, during the next Network Name resource online a logon will re-occur. When the password for a CNO or VCO is changed per the MaximumPasswordAge policy described above, the credentials are updated and a logon occurs.
- Using the LastLogonTimeStamp attribute can be an inaccurate hint to identify if a cluster computer object is stale. This is because if a production cluster is up and stable no logon’s will occur and the LastLogonTimeStamp attribute will not be updated until 75% expiration of MaximumPasswordAge. Using LastLogonTimeStamp as a hint can result in accidental CNO and VCO deletion. It is recommended that LastLogonTimeStamp be greater than 30 days (at an absolute minimum) to determine if an object is stale.
Given that CNO and VCO computer objects are associated with mission critical high availability systems, your domain administrators may simply choose to avoid automated / scripted deletion of cluster computer objects. This can be accomplished by querying and excluding computer objects that contain a service principal name (SPN) of “MSClusterVirtualServer” from deletion. Another technique is to move all CNO and VCO's to a custom organizational unit (OU) and exclude that OU from running CO deletion scripts.
As an extra safety mechanism you can protect CNO and VCO's from accidental deletion by simply checking the "Protect object from accidental deletion" box on the objects in the Active Directory Users and Computers snap-in. See this blog for more details
Another hint which can be used to identify stale cluster computer objects is if the computer object is in a Disabled state. By default, when a cluster Network Name resource is deleted or if a cluster is destroyed, the CNO and VCO’s are placed in a disabled state. Any cluster computer object which is in a Disabled state are no longer being used by the cluster.
When destroying a cluster, you may wish to delete the computer objects instead of leaving them in a disabled state. This can be accomplished by passing the –CleanupAD switch to the Remove-Cluster PowerShell cmdlet when destroying the cluster.
Remove-Cluster -CleanupAD
If you are reading this after you have already run a script that accidently deleted a CNO or VCO computer object, here is a blog which has a step-by-step guide on how to recover the computer objects:
If you do not have the AD Recycle Bin feature, follow this blog:
http://blogs.technet.com/b/askcore/archive/2009/04/27/recovering-a-deleted-cluster-name-object-cno-...
If you do have the AD Recycle Bin feature, follow this blog:
http://blogs.technet.com/b/askcore/archive/2011/05/18/recovering-a-deleted-cluster-name-object-cno-...
Thanks!
Elden Christensen
Principal PM Manager
Clustering & High-Availability
Microsoft
