I am starting a 'CNO Blog Series', which will consist of blogs written by the CORE team cluster engineers and will focus primarily on the Cluster Name Object (CNO). The CNO is the computer object in Active Directory associated with the Cluster Name; it is used as a common identity in the cluster. If you have been working with Failover Clusters since Windows Server 2008, you should be very familiar with the CNO and the role it plays with respect to the cluster security model. Looking over the CORE Team blog site, there have already been some blogs written that focus primarily on the CNO:
With the release of Windows Server 2012, there have been several enhancements added to the Failover Clustering feature that provide for better integration with Active Directory. The Product Team blog (http://blogs.msdn.com/b/clustering/), has a post that discusses creating Windows Server 2012 Failover Clusters in more restrictive Active Directory environments. That blog discusses some of the changes that have been made in the product that directly involve the CNO.
On to today's blog - increasing awareness around the Cluster Name Object (CNO)….
Beginning with Windows Server 2008, when a cluster is created, the computer objected associated with the CNO, unless pre-staged in some other container, is placed, by default, in the Computers container. Windows Server 2012 Failover Clusters give cluster administrators more control over the computer object representing the CNO. The Product Group's blog mentioned earlier, details new functionality in Windows Server 2012, which includes:
Having more control over cluster computer object(s) placement, while desirable, requires a bit more 'awareness' on the part of a cluster administrator. This 'awareness' involves knowing that, by default, the CNO when placed in the non-default location may not have the rights it needs for other cluster operations such as creating other cluster computer objects (VCOs). The first indication of a problem may be when a Role is made highly available in the cluster and that Role requires a Client Access Point (CAP). After the Role creation process completes, and the Network Name associated with the CAP attempts to come Online, it fails with an Event ID 1194.
This event reports a computer object associated with a cluster Network Name resource could not be created. The error message itself provides good troubleshooting guidance to help resolve the issue -
In this case, it is a simply a matter of modifying the security on the AD container so the CNO is allowed to Create Computer Objects. Once this setting is in place, the Network Name comes online without issue. Additionally, the CNO is also given another critical right, the right to change the password for any VCO it creates.
If Active Directory is properly configured (more on that in a bit), the VCO, along with the CNO, can be also protected from accidental deletion.
Protecting Cluster Computer Objects
A call often handled by our support engineers involves the accidental, or semi-intentional, deletion of the computer objects associated with Failover Clusters. There are a variety of reasons this happens, but we will not go into those here. Suffice it to say, things function more smoothly if the computer objects associated with a cluster are protected.
I mentioned new functionality in Windows Server 2012 Failover Clusters where cluster objects will be strategically placed in targeted Active directory containers (OU) automatically. Using this methodology also makes it easier to discern which objects are associated with a Failover Cluster. As you can see in this screenshot of a custom OU (Clusters) that I created in my domain, the objects associated with the cluster carry the description of Failover cluster virtual network name account. The cluster nodes, which are located in the same OU, are traditional computer objects, which do not carry this description.
Examining the properties of one of these accounts using the Attribute Editor, one can see it is clearly an attribute (Description field) of the computer object.
Properly protecting cluster computer objects (from accidental deletion) requires Domain Administrator intervention. This can be either a 'proactive' or a 'reactive' intervention. A proactive intervention requires a Domain Administrator set a Deny ACE (Access Control Entry) for Delete all child objects for the Everyone group on the container where the cluster computer objects will be located.
A reactive intervention occurs after a CNO is placed in the designated container. At this point, the Domain Administrator has a choice. He can either:
1. Set the Deny ACE for Delete all child objects on the container, or
2. Check the Protect object from accidental deletion checkbox on the CNO computer object (which would then set the correct Deny ACE on the container)
Let us step through a scenario from a recent case I worked for one of our customers deploying a new Windows Server 2012 Failover Cluster.
Customer Case Study
In this case, a customer was deploying a 2-Node Windows Server 2012 Hyper-V Failover Cluster dedicated to supporting virtualized workloads. The cluster creation process was completed without issue and the Cluster Core Resources group could move freely between the nodes without any resource failures. The customer had already created four highly available virtual machines, some of which were already in production. The customer wanted to test live migration for the virtual machines. When he attempted to execute a live migration for a virtual machine, it failed immediately on the source cluster node. He attempted a quick migration and that succeeded.
Reviewing the cluster logs obtained from the customer, the live migration error appeared in the cluster log of the source cluster node. The live migration failure was registered with an error code of 1326.
00001274.00001c24::2012/09/18-17:50:16.301 ERR [RES] Virtual Machine <Virtual Machine MRS1SAPPBW31>: Live migration of 'Virtual Machine MRS1SAPPBW31' failed.
00001274.00001c24::2012/09/18-17:50:16.301 ERR [RHS] Resource Virtual Machine MRS1SAPPBW31 has cancelled offline with error code 1326.
00000aa8.00001cf4::2012/09/18-17:50:16.301 INFO [RCM] HandleMonitorReply: OFFLINERESOURCE for 'Virtual Machine MRS1SAPPBW31', gen(0) result 0/1326.
The error code resolved to - 'The user name or password is incorrect'.
Examining the rest of the cluster log indicated the CNO could not log on to the domain controller to obtain necessary tokens. This failure was also causing a failure registering with DNS (customer is using Microsoft dynamic DNS).
00001228.00001a20::2012/09/18-17:43:00.466 WARN [RES] Network Name: [NNLIB] LogonUserEx fails for user HPVCLU03$: 1326 (useSecondaryPassword: 0)
00001228.00001a20::2012/09/18-17:43:00.550 WARN [RES] Network Name: [NNLIB] LogonUserEx fails for user HPVCLU03$: 1326 (useSecondaryPassword: 1)
00001228.00001a20::2012/09/18-17:43:00.550 INFO [RES] Network Name: [NNLIB] Logon failed for user HPVCLU03$ (Error 1326), DC \\<FQDN_of_DC_here>
00001228.00001a20::2012/09/18-17:43:00.550 INFO [RES] Network Name <Cluster Name>: Identity: Obtaining Windows Token for Name: HPVCLU03, SamName: HPVCLU03$, Type: Singleton, Result: 1326, LastDC: \\<FQDN_of _DC_here>
00001228.00001a20::2012/09/18-17:43:00.550 INFO [RES] Network Name <Cluster Name>: Identity: Slow Operation, FinishWithReply: 1326
00001228.00001a20::2012/09/18-17:43:00.550 INFO [RES] Network Name <Cluster Name>: Identity: InternalReplyHandler with event: 1326
00001228.00001a20::2012/09/18-17:43:00.550 INFO [RES] Network Name <Cluster Name>: Identity: End of Slow Operation, state: Error/Idle, prevWorkState: Idle
00001228.00001a8c::2012/09/18-17:43:00.550 WARN [RES] Network Name <Cluster Name>: Identity: Get Token Request, currently doesn't have a token!
00001228.00001a8c::2012/09/18-17:43:00.550 INFO [RES] Network Name: [NN] got sync reply: 0
00001228.00001e0c::2012/09/18-17:43:00.550 ERR [RES] Network Name <Cluster Name>: Dns: Obtaining token threw exception, error 6
00001228.00001e0c::2012/09/18-17:43:00.550 ERR [RES] Network Name <Cluster Name>: Dns: Failed DNS registration with error 6 for Name: HPVCLU03 (Type: Singleton)
Examination of the DNS zone verified there was no A-Record for the cluster name.
At this point, we logged into the domain controller the cluster was communicating with and tried to locate the CNO using the Active Directory Users and Computers (ADUC) snap-in. When the computer object was not found in the Computers container, a full search of active directory revealed it was located in a nested OU structure four levels deep. Coincidentally, it was located with the cluster node computer accounts, which is the expected new behavior beginning with Windows Server 2012 Failover Clusters as previously described. It was clear to me; however, the cluster administrator was not aware of this new behavior.
At this point, it appeared to be a case of the CNO account password being out of synch in the domain. I had the customer execute the following process:
After executing the procedure, the cluster name came back online, and the customer noticed an automatic registration in DNS. He then executed a live migration for a virtual machine and it worked flawlessly. He also checked and verified the dNSHostName attribute on the computer object was now correctly populated. Issue resolved. Case closed.
Moral of the story - Not only do cluster administrators need to become familiar with the new functionality in Windows Server 2012 Failover Clusters (and there are many), but they should also realize that the CNO can have impact in areas that are not necessarily obvious.
Thanks, and come back again soon.
Chuck Timon Senior Support Escalation Engineer Microsoft Enterprise Platforms Support High Availability\Virtualization Team
There's a little over a month to go until Windows 8 hits store shelves. We're going to be taking a short hiatus here on AskPerf while we get our Launch Series content ready. On October 22nd we will roll out the first post of the series – and then expect one post every day through General Availability on October 26th.. We have a lot of ground to cover, so rest assured, we will have our noses to the grindstone for the next month…
The process to compact a dynamically expanding virtual hard disk (vhd) in Windows Server 2012 has changed slightly from previous versions of Windows.
It is still recommended that you defrag the drive in advance. Also be aware, if the virtual hard disk is not NTFS formatted, you must prepare the virtual hard disk for compacting by using a non-Microsoft disk utility program to replace the blank space with zeroes. Lastly, the vhd cannot be in use.
In order to shrink the vhd you must first have an account with administrative privileges on the system mount the vhd as read-only prior to attempting to shrink the disk.
One way to mount the vhd is via Disk Management.
Make sure to place a check mark in the box for Read-only.
Another way to mount the vhd is using PowerShell with the following command.
Note: You must have the Hyper-V Module for Windows PowerShell installed. This is listed under features, under Role Administration Tools \ Hyper-V Management Tools
Mount-Vhd –path <full path the vhd file> -readonly
The next step is to compact the vhd.
Using Hyper-V manager, use the actions menu and select Edit Disk.
Follow the Wizard and choose the Compact option
You can do the same as above using PowerShell with the following command:
Optimize-Vhd -path <full path the vhd file> -Mode Full
Once the process is done you just need to dismount the vhd.
With Disk Management, right click on the left end of the VHD and select DetachVHD
From PowerShell the command is
Dismount-vhd -path <full path the vhd file>
The Optimize-VHD command has several options that can be used depending on if the virtual disk is using the VHD format or the VHDX format. Please see the Optimize-VHD command on technet for more information.
To simplify the above process I created the following PowerShell script.
I put the following into a file named compact-vhd.ps1
Param([string]$Path = $(Throw '-Path is required')) Echo "Attempting to Mount $Path" Mount-vhd -path $Path -readonly Echo "Attempting to compact $Path" Optimize-vhd -path $Path -full Echo "Attempting to dismount $Path" Dismount-vhd -path $Path
Param([string]$Path = $(Throw '-Path is required')) Echo "Attempting to Mount $Path" Mount-vhd -path $Path -readonly Echo "Attempting to compact $Path" Optimize-vhd -path $Path -full Echo "Attempting to dismount $Path" Dismount-vhd -path $Path
The syntax is .\compact-vhd.ps1 -Path <path to vhd>
A few notes for the script:
Robert Simpkins Senior Support Escalation Engineer Microsoft Enterprise Platforms Support
Welcome to the AskCore blog. In this blog, we are going to discuss about the “Windows Virtual Machine” object in the AD DS.
For any Active Directory joined Windows Hyper-V Virtual Machines, a serviceConnectionPoint (SCP) object called “Windows Virtual Machine” is created under the computer object account in the active directory.
You may refer to the below articles to know more about service connection points:
The “Windows Virtual Machine” object is primarily used to distinguish a domain joined Windows Hyper-V Virtual Machine from any physical machine or any other virtualization platform based machine in the domain.
To query all Hyper-V based, domain joined Virtual Machine in the domain you can use AD-PowerShell or dsquery command:
You should run this powershell command from the “Active Directory Module for Windows Powershell” command prompt
Get-ADObject –LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=Windows Virtual Machine))"
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=Windows Virtual Machine))"
This object is first created by the Hyper-V Integration service “Hyper-V Heartbeat Service” when a Hyper-V Virtual Machine running is added to the active directory. In case the object is deleted, it will be automatically re-created when the VM is restarted or the "Hyper-V Heartbeat Service" is restarted. On each restart of the service or virtual machine the integration service checks if the machine is domain joined and if it is domain joined, it checks if the serviceConnectionPoint (SCP) object exists in the domain. If the object doesn’t exist it will attempt to recreate the object.
One of the errors you may get is “ERROR_NO_SUCH_DOMAIN” if the machine is not joined to the domain, or if we are not able to connect to rootDSE due to a network issue. We attempt a maximum of 5 retries between 5 minutes and then fail. The error message with the error code is written in the Hyper-V Integration Component (IC) trace. Further, if we fail to obtain the computer object or if the computer object doesn’t exist, you’ll get a COM exception.
If the machine is a workgroup machine, this record will not be created. You should use other methods to determine if the machine is a virtual machine. You can query the Model and Manufacturer properties of the Win32_ComputerSystem class. A machine is a Hyper-V Virtual Machine if the Manufacturer property returns “Microsoft Corporation” and Model property returns “Virtual Machine”. Here is a sample VBScript which helps find out a Virtual Machine using the logic I just explained:
strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery( _ "SELECT * FROM Win32_ComputerSystem",,48) For Each objItem in colItems If StrComp(objItem.Manufacturer,"Microsoft Corporation") = 0 And StrComp(objItem.Model,"Virtual Machine") = 0 Then Wscript.Echo "Hyper-V Virtual Machine" Else Wscript.Echo "Not a Hyper-V Virtual Machine" End If Next
Troubleshooting Object Creation Failures:
If a domain joined Windows Virtual Machine doesn’t have this object in the active directory, and if you wish to trace why this object is not getting created, you should enable Hyper-V IC tracing and also take a network trace.
To force a retry and collect the trace logs, setup the network and Hyper-V IC tracing and restart the "Hyper-V Heartbeat Service" and monitor the trace for about 5-10 minutes.
We have explained steps to enable hyper-v tracing in one of our blogs. The trace file will contain exceptions and errors for the failure event.
You may have to send the integration service trace to Microsoft Support for analysis.
I hope that this post helps you understand the “Windows Virtual Machine” object better and also troubleshoot the object creation failure issues.
Himanshu Singh Support Escalation Engineer Windows Core - High Availability Group
On September 4th, Microsoft announced general availability of Windows Server 2012.
In a global online launch event Satya Nadella, president of Microsoft Server and Tools Business, announced the general availability of Windows Server 2012. In his keynote speech, Nadella described how Windows Server 2012 is a cornerstone of the Cloud OS, which provides one consistent platform across private, hosted and public clouds.
“The operating system has always been the heartbeat of IT and is now undergoing a renaissance in the new world of continuous cloud services, connected devices and big data,” Nadella said. “Microsoft’s unique legacy in the most widely used operating systems, applications and cloud services positions us to deliver the Cloud OS, based on Windows Server and Windows Azure, helping customers achieve a datacenter without boundaries.”
More information about Windows Server 2012 and the Cloud OS is available here. Read Satya Nadella’s post on The Official Microsoft Blog here. The conversation on Twitter can be followed at #WinServer.
Jeff Hughes Senior Support Escalation Engineer Microsoft Enterprise Platforms Support
Hi AskPerf readers, this is Paul from the Microsoft Remote Resources Support Team. We have been receiving a number of support questions concerning the use of Client Access Points (CAPs) and the use of CNAME alias records when referencing a Failover Clustered Print Spooler Resource.
Unlike a File Share Resource the multiple Client Access Point (CAP) feature is not supported when referencing a Print Spooler Resource. In Windows Server 2008 and 2008 R2 Failover Clusters, the interaction between the Cluster Service and the Server Service has changed and with this change shared printers are now associated with a single Spooler resource and are 'scoped' to the Network Name resource which is part of the Client Access Point (CAP). The share names when using Client Access Points (CAP) in Windows Server 2008 and 2008 R2 do not work in the same manner as they did with Windows Server 2003 Failover Print Clusters. This is due to intentional design changes that enhance the security when making Server Message Block (SMB) connections to the print spooler resource (the print share). A Failover Clustered Print Spooler consists of 3 components; a single Client Access Point (Network Name and IP Address), a single Spooler Resource and a “shared” Disk resource (Cluster Shared Volume; CSV).
The recommended method for accessing the Failover Clustered Print Server Resource is to login to any of the cluster nodes and open the Printer Management Console by clicking “Manage Printers” from the Failover Cluster Manager. This ensures you are accessing the clustered spooler resource and not the local spooler; an area that we receive numerous support calls about.
The Failover Cluster Manager will not prevent an administrator from creating more than one Client Access Point (Name and IP resource) in any group. When this is done in a Spooler resource group it is not immediately evident that this creates a potential configuration problem. The first indicator that this is not supported is when the admin attempts to use the Manage Printers feature from the Clustered Print Servers Action menu.
The Failover Cluster Manager displays the following configuration error clearly stating that the Spooler Resource is not configured correctly if there are multiple Network Names in the group.
An alternative way to manage the clustered Print Spooler Resource is directly through the Print Management Console (PMC). In the PMC, an admin can add the Clustered Spooler Resource Network Name to the list of Managed Print Servers.
If a spooler resource group has multiple CAPs defined and an administrator attempts to use the PMC to manage any of the CAP instances other than the first one defined when the resource was created, they’ll receive the second indicator that there is a configuration issue. Attempts to add a printer to any of the additional CAP names in the PMC the following error is displayed indicating that the target is invalid.
While we have created a valid Network Name we have not created a target object container for the installation of printers:
Performing a query for the meaning of this error message using the NET Helpmsg command (http://technet.microsoft.com/en-us/library/bb490705.aspx). Typing the following command:
C:\>net helpmsg 67 The network name cannot be found. (Net Helpmsg only accepts decimal error messages. 0x43 is 67 in decimal)
C:\>net helpmsg 67
The network name cannot be found.
(Net Helpmsg only accepts decimal error messages. 0x43 is 67 in decimal)
This gives us a more easy to read error - indicating that the configuration is not valid because the target does not exist.
Best practice recommendations around Clustered Spooler CAPs:
1. Choose one CAP to represent the Clustered Print Spooler resource.
2. For consistency the Group name and the CAP name should be the same to minimize confusion.
3. Publish this to the end user community to use only this CAP name to add printers to their workstations.
If the requirement is to provide multiple Client Access Points (CAPs) or Multiple Named references (aliases) then it is recommended that additional print spooler resource groups be created with the desired names and migrate the printers to the new spooler resources using the Print Management Console Export and Import feature.
The bottom line is there can be only one print spooler resource per Cluster Resource Group and a single network name reference to that resource.
Please review the following article which contains a very detailed explanation concerning the use of CNAME alias DNS entries and why they do not work as expected with Windows 2008 and 2008 R2 Failover Clusters:
File Share 'Scoping' in Windows Server 2008 Failover Clusters
There is a new memory dump option introduced in Windows 8 and Windows Server 2012 called “Automatic memory dump.” This is the default option selected when you install Windows.
The “Automatic memory dump” type was created to support the “System Managed” page file configuration.
The “System Managed” page file has been updated to reduce the page file size on disk, primarily for small SSDs but will also benefit servers with large amounts or ram.
The “Automatic memory dump” is not really a new memory dump type. In previous versions of Windows, we already have Mini, Kernel, and Complete memory dump options. The Automatic memory dump option produces a Kernel memory dump, the difference is when you select Automatic it allows the SMSS process to reduce the page file smaller than the size of RAM.
We use the registry to store the memory dump configuration, which can be located in
The value CrashDumpEnabled contains one of the following values to identify the memory dump setting
Complete memory dump
Kernel memory dump
Small memory dump
Automatic memory dump
When configured for Automatic memory dump, and the page file is set to System Managed, the page file should have a minimum size large enough to ensure that a kernel dump can be captured most of the time. Because the minimum size is only large enough most of the time, there is an additional feature to increase the minimum size of the page file. If your system experiences a bug check, we will create the registry key
For the next 4 weeks after this crash, the system managed page file will now have a minimum size that at least that of the amount of ram in the system.
As an example, the screenshots for this were taken from a system that has 16GB of ram installed. For the normally running system my page file is about 5.5GB
After the system experienced a bug check the page file size was increased to about 16.5GB
Now that the page file is larger than the amount of ram installed in the system, we will be able to capture the kernel memory dump in the situations where the smaller size was not large enough.
One question that may come up is “What happens if I change the memory dump type to Kernel instead of Automatic?” The system managed page file will have a minimum size that at least the size of ram.
On a final note, once the system is stable for 4 weeks we will go back to using the smaller reduced page file size. If you have fixed the issue causing the bug check and you want the page file size to return to its reduced size more quickly, you can delete or rename the LastCrashTime value listed above.
Good morning AskPerf! Akash Nema here from the Performance team. Today we are going to chat about how to tweak the printer list presented when using the Add Printer Wizard in Windows 7.
We frequently see situations with Domain joined users on Windows Vista and higher that try to connect to a network printer. When the user accesses the Add Printer Wizard, they are surprised to see the list of printers presented is limited to only 20 entries - this is by design.
The user can still search for a specific network printer by selecting "The printer I want isn't listed" and then selecting "Find printer in the directory based on location or feature".
(For more information on pre-populating this list with network discovery enabled - see the following walkthrough from our friends at MCP Magazine.)
The list of printers limit behavior is controlled by the following Group Policy setting for Printers:
Add Printer wizard - Network scan page (Managed network)
The policy sets the maximum number of printers (of each type) that the Add Printer wizard will display on a computer on a managed network when the computer is able to reach a domain controller (for example, a domain-joined laptop on a corporate network).
To access the Group Policy Object, click Start, click Administrative Tools, and then click Group Policy Management. Or, click Start, click Run, type GPMC.MSC, and then press Enter.
In Group Policy Management Editor, expand the following folders:
+ Administrative Templates
Add Printer wizard - Network scan page (Managed network)
This policy sets the maximum number of printers (of each type) that the Add Printer wizard will display on a computer on a managed network.
In order to view available TCP/IP printers or Web Services printers on your network, ensure that network discovery is turned on. To turn on network discovery, click Start, click Control Panel, and then click Network and Internet. On the page, click Network and Sharing Center. On the Network and Sharing Center page, click Change advanced sharing settings. On the Advanced sharing settings page, click the arrow next to Domain arrow, click turn on network discovery, and then click Save changes.
If this setting is disabled, the network scan page will not be displayed. If this setting is not configured, the Add Printer wizard will display the default number of printers of each type:
If you would like to not display printers of a certain type, enable this policy and set the number of printers to display to 0.
Directory printers are any print queues that the domain print administrators have chosen to publish in Active Directory.
TCP/IP printers are print devices that you access directly using the TCP/IP protocol.
Web Services printers include both IPP and WSPAD print devices that are shared on the network.
Shared printers are print queues that show up in the deprecated “browse list”.
If you are a die-hard fan of users searching for their own printers (how the wizard looked with Windows XP), you can disable the Network Scan Page entirely via this same policy and the Wizard will go directly to the “Find printer in the directory based on location or feature” page of the Add Printer wizard.
My name is Himanshu Singh and I am a Support Escalation Engineer with Windows Core Team at Microsoft. I am writing today to provide a solution to a particular problem many of you have faced with Microsoft Bitlocker Administration and Monitoring (MBAM) version 1.0.
There have been situation where you as a MBAM Admin had to delete the entries of older machine records from the MBAM database. The only solution in this case is to either run SQL queries to delete machines from the database or manually cleaning the MBAM database.
We have now made available a public version of a tool called MBAM Compliance Data Cleanup Tool, aka MBAMCDCT.
This tool provides a way to delete machine records from the MBAM Compliance Status Database. This tool will help delete the old records of the machines from the database which are re-imaged or no longer reporting into the database.
This tool provides two options to delete machine records from the MBAM Compliance Status database:
1. Delete machines which have not reported in last X days.
2. Delete machines specified in a list.
This tool does not delete the recovery information or any other data from MBAM Recovery and Hardware Database. All delete operations are performed strictly on the MBAM Compliance Status Database.
The tool is available for download at http://gallery.technet.microsoft.com/MBAM-Compliance-Data-5ba28187 and is bundled as a self-extractable compressed file, which includes the executable and documentation for your reference.
Hope this tool helps you report the true state of encryption compliance in your environment by deleting the obsolete information from the database.
Himanshu Singh Support Escalation Engineer Microsoft Windows Core Team
This tool and documentation are provided "as-is". You bear the risk of using it. No express warranties, guarantees or conditions are provided. The tool supplied in this document is not supported under any Microsoft standard support program or service. However, you can report issues and bugs in the comments section on this page. Microsoft will, at its sole discretion, address issues and bugs reported