printQueue AD objects for 2003 Cluster

Print queue objects in AD provide a useful facility when users are trying to find printers, but with a 2003 MSCS clustered virtual print spooler, occasionally the information in AD does not reflect the current state of printers. This post describes some problems I've come across with duplicate/incorrect information and some ideas of how to automatically combat the problem.

Print Queue Objects in AD

Print queue objects in 2003 clustering are named with the virtual print server name, but they are children off a physical computer account. Which computer account the printers are children of is determined by the physical node that owned the cluster spooler resource when the printer was originally published in AD. As a virtual print server fails between nodes, the printer objects in the directory are not re-published (I assume unless the object is not found in the directory).

It's intuitive that print queue objects would be republished on failover to the node that currently owns the spooler, but that could potentially be hundreds or thousands of printer objects being created/deleted with each failover so it's practical not to. It appears the printer object is confirmed using the virtual print server name, and no change is made if the object is found - regardless of which physical node the print queue object is a child of.

In the scenario of a stand-alone printer server, when a printer is deleted, the spoolsv service also removes the directory object. In a clustered virtual print server this also occurs, however, it appears that in a 2003 cluster the object is not automatically removed from the directory if the node that owns the object when deleted is different than the publishing node.

None of this really matters if everything is working perfectly, but in a 2003 MSCS I have seen the following situations:

1. Print queues that no longer exist still being visible through a search in AD
2. Duplicate print queue objects, published against each physical none in the cluster that has hosted the virtual print spooler.

The first was a bigger problem, and I believe the following scenario will result in stale print queue objects persisting:

1. You have a two node cluster, CL01 and CL02. CL01 owns a virtual print spooler and other cluster groups, under which you create all the print queues.
2. At a later time you decide that the load could be better split, and move the virtual print spooler to CL02
3. You then clean up your print queues from the virtual server, also expecting that they will be automatically removed from AD.

In the scenario above, the print queue objects would not be removed from AD, as the physical node that owns the spooler (CL02) does not own the original print queue objects - as they were created when CL01 owned the resources. In this state, the invalid print queue objects will not be purged. Note that this is assuming you aren't using AD printer pruning - by disabling the spooler service on your DCs or using Group Policy to control pruning.

I'm unsure of the exact scenario that caused the duplicate print queue objects, presumably there was some problem finding the existing record, so at some point it was created off the other node as well - resulting in duplicate results in a search (both of which would work, but still).

Some low maintenance ideas to correct this problem:

1. Use AD printer pruning, which will ensure print queue objects in AD are managed. Note that this sounds like the obvious solution, but does have caveats and may not suit all environments.
2. Periodically remove published records from all but the designated primary node, toggle the published attribute on those printers no longer having a record in AD, causing the printers to be republished against the primary node. This could easily be scripted and scheduled
3. Modify printer creation change control processes to ensure that new printers are only created and deleted when the preferred owner is hosting the virtual print server

In an ideal world, three above followed by one make the most sense, but if you needed option two you could do something like this:

1. dsrm CN=%virtual_server%-%QueueName%,CN=%physical_server%,DC=domainRoot
2. cscript prncfg.vbs -s -b \\%virtual_server%\%QueueName% -published
3. cscript prncfg.vbs -s -b \\%virtual_server%\%QueueName% +published
4. dsquery * -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName distinguishedname find /i "%QueueName%"

This removes the AD object against the 'incorrect' node, toggles the published flag (using prncfg from the Resource Kit Tools - see 'Network Printing Tools and Settings' reference below), and then queries AD to verify the printQueue object has been created.

Printer Pruning in AD

Pruning of printer objects in Active Directory is controlled either by the server that deletes the printer from its local spooler, or Domain Controllers through periodic printer pruning. Printer pruning is a domain/site-wide activity which processes all printQueue objects.

In a clustered solution, I believe when a Domain Controller looks up the printqueue objects, it will connect to the virtual print spooler node to verify the printers still exist. So regardless of which physical is publishing the printer, as long as the printer is contactable through the virtual server it shouldn’t be pruned.

As long as the spooler service is enabled on at least one Domain Controller, it will prune printers (at the default of 3x8 hour checks). There are risks of doing this, primarily that if the print server is down for longer than 24 hours (or if the DC can’t contact the server), all printers will be pruned from the directory. This logs an Event 50 for each pruned printer in the system event log of the DC that pruned the object - at least it’s easy to trace.

Printer Commands

Query and compare the printers published from each server to determine duplicates:

• dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported > CL1.txt
• dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported > CL2.txt
• for /f "skip=1" %i in (CL1.txt) do @find /i "%i" CL2.txt

The following two commands help identify mismatches in printers published in AD versus those shared through the virtual print server.

Count the number of printers published in AD:

• find /i /c "%virtual_server%" CL?.txt

The number of printers shared against a node:

• rmtshare \\%physical_server% find /i "\\%virtual_Server%" /c

Query printers published against a physical server:

• dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported

References:

Network Printing Tools and Settings
http://technet.microsoft.com/en-us/library/cc778201.aspx

Printer Pruner May Prune All the Print Queue Objects on Its Site
http://support.microsoft.com/kb/246906

Printer Pruner May Not Remove Printer Queue Objects from Active Directory
http://support.microsoft.com/kb/246174/

A server does not prune printers on a Microsoft Windows Server 2003-based server cluster
http://support.microsoft.com/kb/908128

Useful Windows Printer command-line operations:
http://waynes-world-it.blogspot.com/2008/09/useful-windows-printer-command-line.html

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

VirtualCenter Physical to Virtual

This post describes a process I executed to replace a physical VMware VirtualCenter box with a virtual equivalent running in its own cluster. There were no VM outages of machines running on the cluster – each ESX kept merrily running the virtuals until everything was sorted out with the VC layer.

Note that this was done in a lab instance of ESX 3.5 and VirtualCenter 2.5, had this been production I probably would have taken a little more care.

I don’t think there is any compelling reason why you wouldn’t run a virtual VC box, it would be hypocritical of VMware to suggest virtualizing your application servers, except VirtualCenter which should be physical. Having said that, this process could also be used in reverse, taking a VM VirtualCenter instance physical should the need arise. This would also be useful for a VirtualCenter disaster recovery scenario.

The configuration before completing these steps

1. Physical VirtualCenter 2.5 running on Windows Server 2003, called vc01, static IP
2. Virtual Windows Server 2003 computer running in the cluster, called vc02, dynamic IP \
3. SQL 2005 database for VC, running on a separate SQL server.
4. ESX 3.5 VC 2.5, single network, iSCSI shared storage

Prerequisites

1. The IP address of the VirtualCenter server
2. The ESX host of the VM becoming the new VC server
3. The path to your VMware FlexLM license file (assuming you’re using a license server)
4. The logon details for the SQL connection between vpxd and the database

Steps Taken

On the physical VirtualCenter box that is going to be decommissioned:

1. Take note of the physical ESX host running the VM becoming the new VC server
2. Stop the vpxd service and change the startup to manual (sc stop %service%, sc config %service% start= demand)
3. Stop the vmountVpx, vmware-ufad-vci, vmware-converter and webAccess services change the startup to manual
4. Stop the flexlm instance and set the startup to manual
5. Take a backup of your .lic license file
6. Change the IP address to dynamic (assuming it is static)
7. Power off the physical machine
8. Delete the computer account for vc01 from the domain
9. On the SQL server hosting the VirtualCenter database, backup the VC database and log file with the following command executed through management studio:
   
   

   BACKUP DATABASE [VMVC]
   TO DISK = N'c:\temp\VC_PreMoveToVM.bak'
   WITH
   DESCRIPTION = N'VirtualCenter Pre-move to VM backup'
   , INIT
   , NAME =
   N'VC Pre move to VM'
   GO
   
   RESTORE VERIFYONLY
   FROM DISK =
   N'c:\temp\VC_PreMoveToVM.bak '
   WITH FILE = 1
   GO
   

10. In the service console of one of the ESX hosts, backup the current certificates (just in case):
1. mkdir /tmp/cert_backup
2. cp /etc/vmware/ssl/* /tmp/cert_backup
11. On the VM becoming the new VirtualCenter server running on a host in the cluster: Rename the server from vc02 to vc01, with the same static IP as the previous vc01
12. Restart the virtual machine
13. Install the SQL Native Client - required for VC 2.5 SQL connectivity on a non-SQL server
14. Install VirtualCenter including FlexLM, connecting to the existing database and using the license file copied off the physical server
15. In VirtualCenter, disconnect the first ESX host in the cluster - maintenance mode is not possible at this stage – login errors occur because of the incorrect certificate
16. Copy the new VC certificates - I use pscp here, but whatever you normally use to copy files to ESX would be fine:
    
    1. cd "C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\ssl"
    2. pscp rui.crt vcadmin@esx01:/etc/vmware/ssl/
    3. pscp rui.key vcadmin@esx01:/etc/vmware/ssl/"
17. In the service console of the ESX node you’ve just updated the certificates on, restart the management interface, the ESX host did not seem to pick up the new certificate dynamically (maybe it would on a schedule without a restart):
    1. service mgmt-vmware restart
18. Connect the ESX host to VC through the VI Client interface
19. Repeat steps 15-18 for each other ESX host in the cluster
20. In VirtualCenter, run 'Reconfigure for HA' on each ESX node
    
    Testing
    
    
21. Ensure the vpxd.log file reports no problems with host connectivity or certificates (also check the VC/ESX logs)
22. Ensure each ESX host is receiving licenses from the 'new' license server, either through the VI client or the FlexLM admin tool.
23. Ensure you can perform simple tasks such as powering on a virtual machine
24. Ensure VMotion/HA/DRS is working

The (untested) rollback plan if something goes wrong:

1. Shutdown the new VirtualCenter VM
2. Restore the database from the backup taken
3. Power on the physical VC box, change the IP to the static IP
4. Restart the vpxd and VMware License Server services
5. For each ESX host in the cluster, disconnect the host, restore the old certificates, restart the management service and connect the ESX host to the old VirtualCenter instance

Additional notes:

• Even though user login errors were returned when the vpxd service tried to form the cluster - which points to the vpxuser account used by VC to manage ESX hosts - this was misleading as this username and password is stored in the VC database – which had not been modified (in the vpx_host table). The next logical step was certificates, which lead to certificate update process used above.
• Manually copying the certificates may not be strictly required, as when I went part-way to reconnecting a host without updating the certificates, I was prompted that another VC instance was managing these servers, would I like to continue. Presumably it would have automatically updated the certificates as required.

Read more!

Virtual 2003 MSCS Cluster in ESX VI3

This post shares a method I've used to create test-lab instances of standard 2003 file and print Microsoft Cluster Services (MSCS) clusters in a VMware ESX VI3 virtual environment. The resultant solution is not supported and definitely not production-ready, but if you want a real multi-node MSCS cluster in an ESX lab environment, this process might be helpful with a minimum set of requirements.

With my usual theme of repeatable command-line execution, most of these operations can be completed via the command-line, either in the ESX service console or a command-prompt from the virtual MSCS nodes.

I followed bits and pieces of the VMware supported method - which is very specific and quite restrictive. Note that I’m a little dubious that this cluster would be particularly stable – the SCSI reservations MSCS uses to lock disks are in no way supported when using a shared VMDK through a shared SCSI adapter (I think RDM is the only supported method), but it does work and at least provided me with a test environment.

The shared nothing model of 2003 MSCS clustering dictates that only one node accesses the partition at any one time, but the disk still needs to be visible to both nodes. A limitation of this solution is that both MSCS nodes need to be hosted on one ESX server – a requirement you could satisfy with a DRS rule to keep the two nodes together. However, if DRS decided to migrate both VMs, the cluster would almost certainly break during the failover (and possibly after).

If you follow the steps below, you should end up with two virtual x64 2003 enterprise servers, both members of a single MSCS cluster. In the cluster there will three shared disks (VMDKs), one for the quorum and one each for file and print – with a virtual server and relevant cluster resources. A test file share is created, along with drivers and a test printer. You'll need to modify the commands that reference the public adapter and IP addresses

Steps involved:

1. Create an area for storage of the shared disk on your datastore:
   1. mkdir /vmfs/volumes/%datastore%/cluster01
2. Create a 5GB quorum disk:
   
   1. vmkfstools -d thick -a lsilogic -c 5G /vmfs/volumes/%datastore%/cluster01/MSCS-Quorum.vmdk
3. Create a 5GB disk for shared data:
1. vmkfstools -d thick -a lsilogic -c 5G /vmfs/volumes/%datastore%/cluster01/MSCS-disk01.vmdk
4. Create two 2003 x64 enterprise virtual machines, either through cloning, deployment with templates or whatever your standard build process may be
5. If cloning was used, run sysprep on both nodes to give a unique SID and join your lab domain
6. Shutdown the first node and add the shared disk
1. Add the quorum disk, mounted under scsi 1:0 (which adds a new SCSI adapter)
2. Set the newly created SCSI Adapter to SCSI bus sharing virtual
3. Add disk01, attached as scsi 1:1
7. In the first VM, use disk administrator (or diskpart) to initialise the quorum and disk01 disks, partitioned with basic. Record the signature of the disk and the drive letter used (although this is the disk volume when the disk is owned by the OS, not the cluster).
8. Add a service account for the cluster service:
1. dsadd user "CN=clustersvc,CN=Users,DC=test,DC=local" -pwdneverexpires yes -pwd password -disabled no -desc "MSCS VM cluster service account"
2. Ensure the service account is an administrator of each virtual 2003 node
9. Use Cluster Administrator to install the cluster on the first node, with your chosen cluster name, using the created quorum disk and service account
10. Verify correct operation of the single-node cluster, and then add the second VM node to the cluster.
11. Create a new port group to allow a second private adapter on each ESX server:
1. esxcfg-vswitch -A MSCS-Private Private
2. Add a second interface to each VM cluster node, allocated separate address space
3. Verify connectivity (ping) and configuration following cluster best practices (no gateway, no DNS etc)
4. Mark as a private heartbeat connection for the cluster, prioritised above the LAN connection.
12. Create a virtual resource group, creating IP, network name and disk resources in the group, the following commands will create a group called v01, in the lab01 cluster. For these steps, you’ll need the drive letter to use (M: below), the disk signature, the public network name, IP Address and subnet mask of the virtual server being created:
1. cluster /cluster:lab01 group "v01" /create
2. cluster /cluster:lab01 res "v01 Disk01" /create /group:"v01" /type:"physical disk"
3. cluster /cluster:lab01 res "v01 Disk01" /priv Drive="M:"
4. cluster /cluster:lab01 res "v01 Disk01" /priv signature=0x%disksignature%
5. cluster /cluster:lab01 res "v01 Disk01" /prop Description="M: disk01"
6. cluster /cluster:lab01 res "v01 Disk01" /On
7. cluster /cluster:lab01 res "v01 IP" /create /group:"v01" /type:"IP Address"
8. cluster /cluster:lab01 res "v01 IP" /priv Network="%publicNetwork%"
9. cluster /cluster:lab01 res "v01 IP" /priv Address=192.168.10.10
10. cluster /cluster:lab01 res "v01 IP" /priv SubnetMask=255.255.255.0
11. cluster /cluster:lab01 res "v01 IP" /priv EnableNetBIOS=1
12. cluster /cluster:lab01 res "v01 IP" /priv OverrideAddressMatch=0
13. cluster /cluster:lab01 res "v01 IP" /AddDep:"v01 Disk01"
14. cluster /cluster:lab01 res "v01 IP" /On
15. cluster /cluster:lab01 res "v01" /create /group:"v01" /type:"Network Name"
16. cluster /cluster:lab01 res "v01" /priv RequireKerberos=1
17. cluster /cluster:lab01 res "v01" /AddDep:"v01 IP"
18. cluster /cluster:lab01 res "v01" /priv Name="v01"
19. cluster /cluster:lab01 res "v01" /On
13. Install ABEUIamd64.msi on each node if Access Based Enumeration is required
14. To create a test directory, share and ABE resource on the new virtual server on the cluster (v01):
1. md \\v01\m$\Dir01
2. cluster /cluster:lab01 res "v01 Dir01 Share" /create /group:"v01" /type:"File Share"
3. cluster /cluster:lab01 res "v01 Dir01 Share" /priv path="M:\Dir01"
4. cluster /cluster:lab01 res "v01 Dir01 Share" /priv Sharename=Dir01
5. cluster /cluster:lab01 res "v01 Dir01 Share" /priv Remark="Dir01 File Share"
6. cluster /cluster:lab01 res "v01 Dir01 Share" /prop Description="Dir01 File Share"
7. cluster /cluster:lab01 res "v01 Dir01 Share" /priv security=Everyone,grant,F:security
8. cluster /cluster:lab01 res "v01 Dir01 Share" /AddDep:"v01"
9. cluster /cluster:lab01 res "v01 Dir01 Share" /AddDep:"v01 Disk01"
10. cluster /cluster:lab01 res "v01 Dir01 Share" /On
11. cluster /cluster:lab01 res "v01 Dir01 ABE" /create /group:"v01" /type:"Generic Application"
12. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv CommandLine="cmd.exe /k abecmd.exe /enable Dir01"
13. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv CurrentDirectory="%SystemRoot%"
14. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv InteractWithDesktop=0
15. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv UseNetworkName=0
16. cluster /cluster:lab01 res "v01 Dir01 ABE" /prop SeparateMonitor=1
17. cluster /cluster:lab01 res "v01 Dir01 ABE" /prop Description="Access Based Enumeration for Dir01 File Share"
18. cluster /cluster:lab01 res "v01 Dir01 ABE" /AddDep:"v01"
19. cluster /cluster:lab01 res "v01 Dir01 ABE" /AddDep:"v01 Disk01"
20. cluster /cluster:lab01 res "v01 Dir01 ABE" /AddDep:"v01 Dir01 Share"
21. cluster /cluster:lab01 res "v01 Dir01 ABE" /On
15. Additional shared cluster disks can be created as required, eg:
1. vmkfstools -d thick -a lsilogic -c 5G /vmfs/volumes/%datastore%/cluster01/MSCS-disk02.vmdk
2. Add the disks to one node, (scsi 1:2 in this example). Initialise and allocate in the cluster (as in step 7 above)
16. To create a virtual print server (assuming you’ve mounted disk02 from step 15 for use in the cluster):
1. cluster /cluster:lab01 group "v02" /create
2. cluster /cluster:lab01 res "v02 Disk02" /create /group:"v02" /type:"physical disk"
3. cluster /cluster:lab01 res "v02 Disk02" /priv Drive="P:"
4. cluster /cluster:lab01 res "v02 Disk02" /priv signature=0x%disksignature%
5. cluster /cluster:lab01 res "v02 Disk02" /prop Description="P: print01"
6. cluster /cluster:lab01 res "v02 Disk02" /On
7. cluster /cluster:lab01 res "v02 IP" /create /group:"v02" /type:"IP Address"
8. cluster /cluster:lab01 res "v01 IP" /priv Network="%publicNetwork%"
9. cluster /cluster:lab01 res "v01 IP" /priv Address=192.168.10.11
10. cluster /cluster:lab01 res "v01 IP" /priv SubnetMask=255.255.255.0
11. cluster /cluster:lab01 res "v02 IP" /priv EnableNetBIOS=1
12. cluster /cluster:lab01 res "v02 IP" /priv OverrideAddressMatch=0
13. cluster /cluster:lab01 res "v02 IP" /AddDep:"v02 Disk02"
14. cluster /cluster:lab01 res "v02 IP" /On
15. cluster /cluster:lab01 res "v02" /create /group:"v02" /type:"Network Name"
16. cluster /cluster:lab01 res "v02" /priv RequireKerberos=1
17. cluster /cluster:lab01 res "v02" /AddDep:"v02 IP"
18. cluster /cluster:lab01 res "v02" /priv Name="v02"
19. cluster /cluster:lab01 res "v02" /On
17. Create v02 print spooler:
1. cluster /cluster:lab01 res "v02 Spooler" /create /group:"v02" /type:"print spooler"
2. cluster /cluster:lab01 res "v02 Spooler" /priv DefaultSpoolDirectory="P:\Spool"
3. cluster /cluster:lab01 res "v02 Spooler" /prop Description="v02 Print Spooler"
4. cluster /cluster:lab01 res "v02 Spooler" /AddDep:"v02 Disk02"
5. cluster /cluster:lab01 res "v02 Spooler" /AddDep:"v02"
6. cluster /cluster:lab01 res "v02 Spooler" /On
18. On v02, add a standard Laserjet 4000 retail driver for x64 and x86, run from a cluster node:
1. rundll32 printui.dll,PrintUIEntry /ia /c \\v02 /m "HP LaserJet 4000 Series PCL6" /h "x64" /v "Windows XP and Windows Server 2003"
2. rundll32 printui.dll,PrintUIEntry /ia /c \\v02 /m "HP LaserJet 4000 Series PCL6" /h "x86" /v "Windows 2000, Windows XP and Windows Server 2003"
19. Create a test printer on v02 called printer01 using the LJ 4000 driver, with a record in DNS, published in AD, set to duplex by default, with customised permissions using the standard winprint processor:
1. dnscmd %DNSserver% /recordadd %zone% printer01 A 192.168.10.100
2. cscript //nologo portmgr.vbs -a -c \\v02 -p printer01 -h 192.168.10.100 -t LPR -q printer01
3. cscript //nologo prnmgr.vbs -a -c \\v02 -b printer01 -m "HP LaserJet 4000 Series PCL6" -r printer01
4. cscript //nologo prncfg.vbs -s -b \\v02\printer01 -h printer01 -l "%Location%" +published
5. setprinter.exe \\v02\printer01 8 "pDevMode=dmDuplex=2,dmCollate=1,dmFields=duplex collate"
6. subinacl /printer \\v02\printer01 /grant=%domain%\%group%=F
7. setprinter \\v02\printer01 2 pPrintProcessor="WinPrint"

References

VMware Support method of running MSCS clusters:
http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_mscs.pdf

Implementing an MSCS 2003 server cluster Cluster
http://waynes-world-it.blogspot.com/2008/03/implementing-mscs-2003-server-cluster.html

subinacl 5.2.3790.1180:
http://www.microsoft.com/downloads/details.aspx?FamilyID=E8BA3E56-D8FE-4A91-93CF-ED6985E3927B

Windows Server 2003 Resource Kit Tools:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

Finding duplicate DNS records

Internal DNS in many organisations is usually a little messy and if tasked with cleaning it, my first step would be to identify duplicate records in DNS - either an IP address that is recorded against multiple host names or a host name with multiple host (A) records. Assuming you have a file containing one record per line, this is fairly simple to report on.

The following examples use dnscmd.exe, which assumes Windows 2000/2003 DNS, but you could use any input, as long as it contains a name and an IP.

The two commands:

1. dnscmd %dnsServer% /enumrecords test.local @ /additional /continue | find /i /v "Aging:" | find /i "192.168" > DNSRecords.txt
2. echo. > DuplicateIPs.txt & (for /f "tokens=1,4" %i in (DNSRecords.txt) do @if "%j" NEQ "" @find /i "%j" DuplicateIPs.txt >nul & if errorlevel 1 for /f "tokens=1" %m in ('"findstr /i "%j$" DNSRecords.txt | find /i /c "%j""') do @if %m GTR 1 (@echo %j,%m: & findstr /i "%j$" DNSRecords.txt & echo.) >> DuplicateIPs.txt) & type DuplicateIPs.txt

The first command uses dnscmd to enumerate the records from the root of the test.local zone and exclude aging (dynamic DNS) records. The last find command further filters the output by IP, which can be useful when targeting specific subnets/sites. You might also want to check aging dynamic records instead of static to see how well scavenging is working – if you do, just change the tokens to 1,5 instead of 1,4 (as the aging data is another token separating the name and IP).

The second command:

1. Creates a new file called DuplicateIPs.txt in the current working directory
2. Iterates through each line in the DNS record dump, extracting the first and fourth token (Name and IP)
3. The commands in the first FOR loop check there is a value, then check the value hasn't already been processed in the duplicate list (otherwise you'd have duplicates of each duplicate) and then counts the duplicates and appends them to the file.
4. The final command types the duplicate IP file created by the for loop iteration.

For example, supposing your DNS export contained the following records:

printer1 3600 A 192.168.10.100
printer2 3600 A 192.168.10.101
printer3 3600 A 192.168.10.100
printer4 3600 A 192.168.10.102
printer5 3600 A 192.168.10.103
printer6 3600 A 192.168.10.100
printer7 3600 A 192.168.10.102

After running the second command above, a file called DuplicateIPs.txt would be created and then typed to the prompt:

192.168.10.100,3:
printer1 3600 A 192.168.10.100
printer3 3600 A 192.168.10.100
printer6 3600 A 192.168.10.100

192.168.10.102,2:
printer4 3600 A 192.168.10.102
printer7 3600 A 192.168.10.102

The command below is modified to report duplicate names instead of IP addresses. This was done by using the first token (%i) instead of the second (%j), and modifying the findstr command to use a literal string search ending with a space rather than the regular expression EOL:

echo. > DuplicateIPs.txt & (for /f "tokens=1,4" %i in (DNSRecords.txt) do @if "%i" NEQ "" @find /i "%i" DuplicateIPs.txt >nul & if errorlevel 1 for /f "tokens=1" %m in ('"findstr /i /c:"%i " DNSRecords.txt | find /i /c "%i""') do @if %m GTR 1 (@echo %i,%m: & findstr /i /c:"%i " DNSRecords.txt & echo.) >> DuplicateIPs.txt) & type DuplicateIPs.txt

If you wanted a summary rather than the detail of each duplicate, you could also run the following command:

echo. > DuplicateIPSummary.txt & (for /f "tokens=1,4" %i in (DNSRecords.txt) do @if "%j" NEQ "" @find /i "%j" DuplicateIPSummary.txt >nul & if errorlevel 1 for /f "tokens=1" %m in ('"findstr /i "%j$" DNSRecords.txt | find /i /c "%j""') do @if %m GTR 1 (@echo %j,%m) >> DuplicateIPSummary.txt) & type DuplicateIPSummary.txt

In the example above, this would produce the following report:

192.168.10.100,3
192.168.10.102,2

I use this sort of command to generate reports on duplicates, in this case from DNS, but it could also be useful in DHCP, WINS, or any number of Active Directory objects/attributes. People (myself included) are often wary of automated processes that make changes, but this is an excellent example of how powerful read-only automated commands can be – you can take thousands of objects and produce a report in seconds to quickly identify inconsistencies in an environment.

Dnscmd Overview
http://technet.microsoft.com/en-us/library/cc778513.aspx

Read more!