Windows Server 2012 AD Cloning, Snapshot Support & Preventing USN Rollbacks

Updated 4/16/2014


Virtualization is a valuable asset for many organizations, including cloud computing. However, there were some drawbacks that many administrators weren’t aware of when implementing a Hyper-V infrastructure.

For example, there are ramifications of cloning servers without Sysprepping the base image first. Sysprep generate a new SID (the unique Security Identifier each machine has) upon first-time boot up. There are also ramifications with the Virtual host time service, which provides time to the virtual guests, but if the guests are part of an AD infrastructure, or if the guests are DCs, then the host time synchronization service will cause problems with the default AD forest time hierarchy, due to Kerberos’ five minute skew tolerance. Easy enough, it’s recommended to disable time synchronization on the host to prevent this from occurring.

One of the more important ramifications, which we will discuss in the section, involves virtualized snapshots and domain controllers and using the Revert feature to roll back a virtual machine to a previous point in time using a previously saved snapshot. The ramifications can effectively make a DC useless.

In this blog, we’ll talk about:

  • What is a Snapshot?
  • What is the USN?
  • What is a USN Rollback?
  • Windows Server 2012 Snapshot Support
  • Windows Server 2012 Cloning Support

What is a Snapshot?

Hyper-V provides the ability to create a point-in-time copy of a virtual guest. The point-in-time copy is called a snapshot. The snapshot can be used to “revert” the virtual guest back to the point-in-time the snapshot was created.

Snapshots are a convenient means to return a virtual machine to a previous state, such as to return to a state prior to installing an application that is no longer behaving properly.

What is the USN?

The USN, or Update Sequence Number, is the basis of how Active Directory Replication works.

The USN is a value stored with each attribute that changes by either a local change, or a replicated change from a partner domain controller. Each domain controller keeps track of its own changes, and other domain controllers in the infrastructure are aware of all other domain controller USN value.

Active Directory replication relies on Update Sequence Numbers (USNs) on each domain controller. The USN acts as a counter. Each DC’s USN value is unique to a domain controller. The replication system is designed with this restriction in mind.

When an inbound replication partner domain controller sees its partner has a higher USN value for any attribute, a replication pull request is made to replicate the changes to the partner.

Active Directory Replication does not depend on or use time displacement or a time stamp to determine what changes need to be propagated. Time based propagation as some directory services use, are based on a time stamp with the “last writer wins” rule, however this can pose a problem if the clock were to be rolled back.

A time stamp is used in Active Directory, but it’s only used to determine and resolve a conflict when an attribute has been modified at two different DCs simultaneously. In this case, the DC receiving the update will use one of three values to resolve a conflict:

  1. The Version number that is incremented on an attribute by the original writer
  2. The originating time of the original writer
  3. The originating DSA value, which is the GUID of the domain controller (found in ADSI Edit and in the DNS zone).

And because these USN counters are local to each DC, it ensures and is determined that the USN to be reliable by replication partner DCs, because the local DC keeps track of all its own changes.

The USN can never “run backward” (decrease in value). If it does, replication partner DCs will recognize the decreased value, and determine it as an inconsistency, and will remove the DC from its own replica set. This is called a USN Rollback. Although they can be repaired, in many cases, it’s easier and more time efficient to simply force remove the DC with the USN Rollback, and re-promote it back into the domain.

You can use Ldp.exe or ADSI Edit to read the current USN, which is the highestCommittedUsn attribute that can be found on the RootDSE object properties for the domain controller.

Up-to-Dateness, High-Watermark, Propagation Dampening, InvocationID

Replication takes into account specific values and follows a pre-defined algorithm to insure replication consistency among domain controllers to reduce or eliminate divergence, such as the following:

Up-To-Dateness vector

  • This is a value that the destination domain controller maintains for tracking the originating updates that are received from all source domain controllers.
    • This value helps the source DC filter irrelevant attributes (and entire objects if all attributes are filtered) on the basis of the relationships between all sources of originating updates and a single destination.
    • To see the Up-to-datenes vector value, run the repadmin /showvector command.


  • This is a value that the destination domain controller maintains to keep track of the most recent change that it has received from a specific source domain controller for an object in a specific directory partition.
    • This value prevents irrelevant objects from being considered by the source domain controller with respect to a single destination.
    • To see the value of the High-watermark, run repadmin /showreps /verbose and look for each line that starts “USNs:”. The high-watermark USN is the number that is followed by “/OU”.

Propagation Dampening

Fault tolerance is helpful by installing multiple DCs, and provides multiple replication paths between them to reduce latency; however, you might expect the same replication change to be replicated in an endless loop. The Up-to-dateness vector eliminates this possibility along with the InvocationID. The InvocationID of a domain controller and its USN combined provides a unique identifier in the forest associated with every write-transaction performed on each domain controller.

Replication example

To understand the consequences of snapshots prior to Windows Server 2012 requires a brief explanation and basic understanding of how Active Directory replication works.

Scenario: Single Domain, single AD Site, three DCs. DC-A, DC-B, and DC-C, all are replication partners between each other.

Replication Steps

  • DC-A updates a password. The USN is set to 3.
  • DC-B detects a USN change on DC-A
  • DC-B requests the change from DC-A
  • DC-B sends its high-watermark and up-to-dateness vector to DC-A

—–> DC-A looks at the high-watermark and up-to-dateness vector values, and the object that was changed, (the password attribute).
—–> DC-A sees that the originating DSA for the password change is DC-A (itself).
—–> DC-A reads the up-to-dateness vector from DC-B and finds that DC-B is guaranteed to be Up-To-Date from the change from DC-A (itself), but has a USN value of 2.
—–> DC-A sees that the originating USN is 3 on that password attribute.

  • Based on the fact 3 is greater than 2, DC-A sends the changed password to DC-B.


In summary, propagation dampening occurs if DC-B already received the changed password from DC-C, which received it from DC-A, therefore, DC-B will not request the changed password from DC-A.

Additional reading, and summarized from:
Tracking Updates (Active Directory Replication)


Pre-Windows 2012 Virtualized DC recommendations

  • Do not take snapshots or revert back to a snapshot of a domain controller virtual machine.
  • Do not copy the domain controller VHD file.
  • Do not export the virtual machine that is running a domain controller.
  • Do not restore a domain controller or attempt to roll back the contents of an Active Directory database by any other means than a supported backup solution.


Undetected USN Rollback

From: Running Domain Controllers in Hyper-V


Detected USN Rollback

From: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)


Repairing USN Rollbacks

To repair a USN Rollback may be difficult. You can use the replication monitoring and diagnostic tools to determine the extent of the damage. If severe where the USN Rollback is undetected, such as when the VHD file attached to a different virtual host is copied and run on another virtual host, which will make it extremely difficult to determine the cause due to duplicate DC SID numbers, besides the rollback, or if the USN on a restored DC has increased past the last USN that the other domain controller has received. In this case, the USN values of the originating DC are different than what the replication partner believes they should be.

The easiest way to repair a USN rollback is to force remove the domain controller that was reverted, run a metadata cleanup to remove the domain controller’s reference from the AD database, and re-promote it.

Reverting back to a snapshot can cause ramifications with other types of services. For one, you must keep in mind of the secure channel that is used by Active Directory members to communicate to the domain. The secured channel uses a password that gets renewed every seven days. For example, if you revert the machine back prior to the point with a previous password, it may no longer be able to communicate. To repair such a scenario, you can reset the machine account, or disjoin it then rejoin it back to the domain. For servers, such as a Microsoft Exchange server, the implications can be much deeper. Besides the secured channel, users will lose any emails that were received between the current time and snapshot time.


Windows Server 2012 Snapshot Support Prevents USN Rollbacks

Until the introduction of Windows Server 2012, cloning, snapshotting, or copying, are unsupported. The only supported method to repair a DC is to potentially either using Windows Backup, or a third party backup that supports non-Authoritative or Authoritative restores, or simply force demote and rebuild the DC from scratch and promote it back into the domain. Otherwise, as we’ve discussed, snapshots and cloning have serious ramifications that can result in USN rollbacks or lingering objects, just to name a few.

Windows Server 2012 now supports DC cloning and snapshot restore of domain controllers. The requirements to support the new feature are:

  • Hypervisor that supports VM-GenerationID. Window Server 2012 Hyper-V supports VM-GenerationID. If using a third party Hypervisor, check with the vendor if their latest version supports this feature.
  • The source virtual domain controller must be running Windows Server 2012.
  • A Windows Server 2012 PDC Emulator FSMO Role must be running and available for the cloned DC.


How does the VM-GenerationID work?

When you promote a domain controller in a supported Hypervisor, AD DS stores the VM-GenerationID (msDS-GenerationID attribute) in the DC’s computer object in the Ad database. This attribute will now be tracked by a Windows driver in the virtual machine.

If you revert to a snapshot, the driver looks at the current VM-GenerationID value and compares it to the value in the AD database on its computer object. The comparison also occurs each time a DC is rebooted.

If the VM-GenerationID are different:

  • The InvocationID is reset
  • The RID pool is deleted
  • The new value is updated in the AD database, thus preventing any possibility of the USN values to be re-used.
  • A non-authoritative SYSVOL synchronization occurs to safely restore and re-initialize SYSVOL (to prevent a JRNL-WRAP error).
  • Each time a DC is rebooted, the value is compared, and if they are different, this rule and action applies.
  • These actions also safeguards shutdown virtual DCs.

If the VM-GenerationID are the same:

  • The snapshot and transaction is committed.


Windows Server 2012 Cloning

In Windows Server 2012, administrators no longer need to use Sysprep to clone a machine, promote it to a domain controller, then complete any additional tasks such as Windows Updates, or install organization standard applications. After the first domain controller is freshly installed from scratch or using Sysprep in a domain, Administrators can now safely deploy cloned domain controllers by simply copying an existing virtual domain controller.

This feature is domain specific. A domain must have at least one DC installed that can be copied. You still want to properly configure DNS settings, validate each DC’s health, replication status, and run the Active Directory Best Practice Analyzer after each Dc deployment.

This feature provides the following advantageous and benefits:

  • Rapid DC deployment
  • Quick restores
  • Optimize private cloud deployments
  • Rapid DC provisioning to quickly meet increased capacity needs

What if I Don’t Want the VM-Generation ID Mechanism to Kick In?

Perhaps there’s a time when you don’t want this protection, such as if you are trying to clone your environment to a lab. If you follow the rules, the VM-Generation ID will protect the USN and probably not give you what you want, and worse, if the DCs you’re trying to clone are having trouble replicating SYSVOL, you have more problems to deal with.

One way around it to prevent the VM-Generation ID to kick in at the hypervisor level is to shut down the VMs, and simply do a flat file copy to another hypervisor, then create a new VM from using the existing files.That should help the attribute mechanism from kicking in. More info on this and other thoughts:

Cases where VM-GenerationID doesn’t help make Active Directory virtualization-safe -Part 1

Why Windows Server 2012 AD VM-Generation ID functionality is not an alias for Active Directory anti-USN Rollback functionality


Additional Reading:

Tracking Updates (USN & Active Directory Replication)

Running Domain Controllers in Hyper-V

How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2

Steps for deploying a clone virtualized domain controller

Virtual Domain Controller Cloning in Windows Server 2012

By Ace Fekay

MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer

Comments are welcomed.

How to Recover a Journal Wrap Error (JRNL_WRAP_ERROR) and a Corrupted FRS SYSVOL from a Good DC – What option do I use, D4 or D2? What’s the Difference between D4 and D2?

Original: 11/21/2013
Updated 8/30/2014


Ace here again. I’ working on updating all of my blogs. If you see any inconsistencies, please let email me and let me know.


Are you seeing Event ID 13508, 13568, and anything else related to SYSVOL, JRNL_WRAPS, or NTFRS?

Note – I will not address Event ID 2042 or 1864. That’s an issue with replication not working beyond the AD tombstone. If you are seeing them, you’re best bet is to forcedemote the machine, run a metadata cleanup, and re-promote it, and make sure you configure your firewall and/or AV to allow replication traffic or stop using the ISP’s or router as a DNS address, or disable IP routing and WINS Proxy, to prevent this in the future. And while you’re at it bump up your AD tombstone to 180 days,

As for the NTFRS, after talking to numerous folks whether directly assisting a customer, or through the TechNet forums, there seems to be some confusion associated with how to handle Journal Wrap errors, what caused them, and what are the differences between the D2 and D4 options. I’ll try to quell this confusion in this blog, as well as provide an easy step-step and providing an explanation for the steps, to get out of this error. Note: The steps are from Microsoft KB290762. I just thought to further break it down so a layman will understand them.

Reference KB: Using the BurFlags registry key to reinitialize File Replication Service Replica Sets

For Windows 2008/2008 R2/2012/2012 R2 with DFSR

Follow this KB to fix it:

How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like “D4/D2” for FRS)

Backing Up and Restoring an FRS-Replicated SYSVOL Folder 

What Caused the Journal Wrap?

First you have to ask yourself, what caused this error on my DC? What did I do to get here? In a nutshell, JRNL_WRAPS are caused by SYSVOL corruption.

The usual culprit can be a number of things:

  • Abrupt shutdown/restart. I don’t usually see this unless there are power issues in the building with not power protection or UPS battery system.
  • Disk errors – corrupted sectors. This is a common issue with a DC on older hardware.
  • AV not configured to exclude SYSVOL, NTDS and the AD processes. This is the typical culprit I’ve seen in many cases.

Ok, So what do I have to do to fix this?

To get yourself out of this quandary, it’s rather simple. Yea, you might say yea, right, this is not so simple, but it really isn’t that hard. It just requires a little understanding of what you have to do, which is all it’s doing is simply copying a good SYSVOL folder and subfolders from a good DC to the bad DC (the one with the errors.

Basically, you first choose which DC is the good DC to be your “source” DC for the SYSVOL folder. Then you you stop the NTFRS service on all DCs. Yes, NTFRS must to be stopped on all DCs to perform this. Then set the registry key on the good DC and the bad DC. That’s it. The process will take care of itself and reset the keys back to default after it’s done.

  • If you only have one DC, such as an SBS server, and SYSVOL  appears ok, or restore just the SYSVOL from a backup. Then just follow the “Specific” steps I’ve outlined below.
  • If more than one DC, but not that many where you can’t shutdown the NTFRS on all of them, such as if you have 40 DCs, pick and choose the best one and set Burflags to D2 on the bad and D4 on the good.
  • If there are numerous DCs, such as a large infrastructure, simply run dcpromo /forcedemote the DC with the error, run a metadata cleanup, then re-promote to a DC back into the domain. If you unplug the DC and run a metadata cleanup, then you will have to rebuild the DC from scratch. The forcedemote switch removes the AD binaries off the machine allowing you to re-promote it.


To summarize:

You have two choices as to a restore from a good DC using FRS:

  1. D2 is set on the bad DC: Non-Authoritative restore: Use the D2 option on the DC with the empty SYSVOL folder, or the SYSVOL folder with the incorrect data. This way it will get a copy of the current SYSVOL and other folders from the good DC that you set the BurFlags D4 option on.
  2. D4 is set on the good DC: Authoritative restore: Use the BurFlags D4 option on the DC that has a copy of the current policies and scripts folder (a good, not corrupted folder).


The BurFlags option – D4 or D2? What do I use?

The steps refer to changing a registry setting called the BurFlags value. If the BurFlags key does not exist, simply create it. It’s a DWORD key.

More importantly, it references change the BurFlags to one of two options: D4 or D2. Therefore, before going further, I would like to squelch the confusion on what the D2 and D4 settings mean:

D2/D4 – Which is which?

  • D2, also known as a Nonauthoritative mode restore – this gets set on the DC with the bad or corrupted SYSVOL
  • D4, also known as an Authoritative mode restore – use this on the DC with the good copy of SYSVOL.
  • You must shut the NTFRS service down on ALL DCs while you’re doing this until instructed to start it.
  • You’ll probably want to copy the current SYSVOL structure on the good DC to another folder as a backup prior to doing this.

The D2 option on the bad DC will do two things:

  1. Copies the current stuff in the SYSVOL folder and puts it in a folder called “Pre-existing.” That folder is exactly what it says it is, it is your current data. This way if you have to revert back to it, you can use the data in this folder.
  2. Then it replicates (copies) good data from the GOOD DC (D4) to the bad guy (D2).

Once again, simply put:

  • The BurFlags D4 setting is “the Source DC” that you want to copy its good SYSVOL folder from, to the bad DC.
  • The bad DC BurFlags is set to D2, which tells it to pull from the source DC, the one you set D4 on.


Here are the steps summarized:

  1. For an Authoritative Restore you must stop the NTFRS services on all of your DCs
  2. In the registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
    1. Set the BurFlags setting to HEX “D4” on a known DC that has a good SYSVOL (or at this time restore SYSVOL data from backup then set the Burflag to D4)
    2. Then start NTFRS on this  server.
    3. You may want to rename the old folders with .old extensions prior to restoring good data.
  3. Clean up the folders on all the remaining servers (Policies, Scripts, etc) – renamed them with .old extensions.
  4. Set the BurFlags to D2 on all remaining servers and then start NTFRS.
  5. Wait for FRS to replicate.
  6. Clean up the .old stuff if things look good.
  7. If the “D4” won’t solve the problem try the “D2” value.


So circling back, to fix this and make it work, just copy the contents of SYSVOL to another location, then follow the KB, which simply states you must stop the NTFR service on ALL DCs. Then pick a good one to be the “Source DC.”

Of course, as I’ve stated above, if you have a large number of DCs, the best bet is to forcedemote the bad DC, run a metadata cleanup to remove its reference from AD, then re-promote it.

If you have a small number of DCs, and if you have a good DC and a bad DC, on the good DC, you would set the BurFlags to D4, and on the BAD DC you would set the Burflags to D2.

Example run:

In the example below, if you set BurFlags to D4 on a single domain controller and set BurFlags to D2 on all other domain controllers in that domain, you can rebuild the SYSVOL from the D4 DC (the source DC).

I’ve also heard of admins manually copying the SYSVOL folder, then set the BurFlags options as mentioned, which works too. But no, I haven’t tested it. That would be for a lab on another day. 🙂

Authoritative Restore Example

Use the BurFlags D4 option on the DC that has a copy of the current policies and scripts folder (a good, not corrupted folder).

  1. Stop the FRS service on all DCs. To do this to all DCs from one DC, you can download PSEXEC and run “psexec \\otherDC net stop ntfrs” one at a time for each DC.
  2. On a good DC that you want to be the source, run regedit and go to the following key:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
    In the right pane, double-click “BurFlags.” (or Rt-click, Edit DWORD)
       Type D4 and then click OK.
  3. On the bad DC, run regedit and go to the following key:   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
       In the right pane, double-click “BurFlags.” (or Rt-click, Edit DWORD)
       Type D2 and then click OK.
  4. Quit Registry Editor, and then switch to the Command Prompt (which you still have opened).
  5. On the good DC, start the FRS service, or in a command prompt, type in “net start ntfrs” and hit <enter>
  6. On the bad DC, start the FRS service, or in a command prompt, type in “net start ntfrs” and hit <enter>
  7. On the bad DC, check the Sysvol folder to see if it started populating.
  8. Check for EventID 13565 which shows the process started
  9. Check for EventID 13516, which shows it’s complete
  10. Start FRS on the other DCs.

The following occurs after running the steps above after you start the FRS service (NTFRS):

  • The value for BurFlags registry key returns to 0.
  • Files in the reinitialized FRS folders are moved to a <var>Pre-existing</var> folder.
  • An event 13565 is logged to signal that a nonauthoritative restore is started.
  • The FRS database is rebuilt.
  • The member replicates (copies) the SYSVOL folder from the GOOD DC.
  • The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.
    Note: The placement of files in the <var>Pre-existing</var> folder on reinitialized members is a safeguard in FRS designed to prevent accidental data loss. You can copy this stuff back if it didn’t work, but I have not yet seen when this has not worked!


I hope this helps cleaning up your FRS and SYSVOL replication issues.

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
Complete List of Technical Blogs:

This blog is provided AS-IS with no warranties or guarantees and confers no rights.

DNS Dynamic Updates in a Workgroup

Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
   Microsoft Certified Trainer
   Microsoft MVP: Directory Services
   Active Directory, Exchange and Windows Infrastructure Engineer and Janitor


So the machines and devices you want to register into DNS are not in an Active Directory. Therefore, that means none of your Windows computers have been configured with a Primary DNS Suffix. When you join a computer to a domain, one of the many things that occur on the computer is that the Primary DNS Suffix is automatically configured, which matches the name of the AD DNS domain name, which should also be identical to the DNS zone name.

And further, as we already know, that’s what a computer needs to register into a zone with the same name. If you weren’t aware of this basic requirement, you can catch up on how Dynamic DNS registration works by reading my other blog:

AD & Dynamic DNS Updates Registration Rules of engagement

Primary DNS Suffix

However, workgroup computers normally do not have a Primary DNS Suffix, unless you’ve already manually configured all of them. Neither do other devices, such as mobile phones, tablets and other non-Microsoft products.

No fret. We can make this work without a Primary DNS Suffix. After all, non-Windows devices, such as phones and tables, do not have such a setting to configure.

There are actually a number of ways to get this to work. One way is to force the Primary DNS Suffix on your Windows workgroup computers by using a registry script (outlined later below). However, that will only be good for your Windows computers. What about those non-Windows devices?

To register your Windows computers and non-Windows devices, an easier way to go about it is to use Windows Server DHCP to register all leases into the DNS zone. We can do this by using the DHCP service on a non-AD joined Windows Server configured with DHCP credentials, DHCP Option 015, and configured to force all leases to register into the zone whether the device has the ability to register on its own or not.

The credentials allows DHCP to own the record, so in case the device leaves and returns at a later date and gets a new IP, the DHCP service can update the old host record in DNS with the new IP. Without credentials, the device will update, but it may not be able to update its old record, which then you may wind up with duplicate host entries in the zone. Of course, we wouldn’t want that.

Use Windows DHCP to Force Register All Leases

The first thing we need is a Windows Server with the DHCP and DNS services installed and running. To provide a 30,000’ view of what’s involved, we start by creating a regular, non-Administrator, local user account on the server that will be used to configure the DHCP scope to use as credentials for registration. And to stress what I just said, it does NOT have to, nor should it be, an Administrator account. It should just be a plain-Jane user account, but give it a really strong password. In an AD domain environment, the credentials would be a plain-old AD Domain User account. But in this case, it’s a local User account. Then configure DHCP to force update all records, whether the entity can register or not.

Zone’s NS & SOA Entries

For the DNS service to properly work, the DNS server itself must have its own host (A) record reregistered into the zone, as well as registered its record as an NS record in the zone’s properties. This means that the Windows server DNS is installed on, must be configured with a Primary DNS Suffix matching one of the zones that DNS will be authoritative for (meaning that DNS is hosting the zone). We usually pick the main zone for the company environment. Once configured, then this part will automatically occur. If it doesn’t have a Primary DNS Suffix, then this automatic part will not happen.

You can easily tell if any Windows computer has a Primary DNS Suffix by a simple ipconfig /all, however I’m sure you already know if your server has one configured one or not, since this must be manually done on a workgroup computer. As stated, an AD joined computer (server or workstations) will automatically configure itself with a Primary DNS Suffix that matches the AD DNS domain name,

Detailed Steps:

  1. First, assuming you haven’t already installed DNS and created a zone in DNS, let’s go ahead and install and create your zone.
  1. You can install the DNS service Role (yes, it’s a Role, not a Feature), using Server Manager in Windows Server 2008, 2008 R2, 2012, and newer.
    Install a DNS Server
  2. Once installed, create your zone, such as Also in the zone properties, make sure you allow Updates. And note, with DNS on a non-DC, the only option you have is either “None,” or “Nonsecure and secure.” You have no choice other than “Nonsecure and secure.”
    (Click image to see a larger version of the image in a new window)
  • Obviously it’s important that the DNS & DHCP server is set to a static IP configuration. Pick an IP, and stick to it. Then make sure that the server itself is ONLY using its own IP for DNS entry in its NIC. No others must be in here, otherwise you’ll get unexpected and possibly undesired results.
    (Click image to see a larger version of the image in a new window)
    1. I need to stress that this is extremely important.
    2. If you have any computers in the environment that have a static IP address configured (not getting an IP from DHCP), you must also make sure they are configured with only your own Windows DNS server’s IP.
    3. If you’ve configured it with your ISP’s DNS, because you thought that’s what you need for internet resolution, then that’s wrong, and more importantly, that computer will not register nor be able to resolve internal hosts. 
    4. Same thing using your router (either ISP provided, or something you bought from a retail store such as a Linksys, Dlink, etc). Do not use your router as a DNS address. They are not DNS servers, and they only proxy to an external DNS, which is useless if you are running DNS internally.
    5. And no, you CAN’T mix internal and external DNS entries. It doesn’t work that way. It’s not a DNS server thing, rather it’s based on a DNS client, specifically it’s based on how the client side resolver algorithm works. For a technical explanation for the technically curious, please read my blog explaining it:

    7. The DNS server can use Root Hints to resolve internet names. Or you can configure a Forwarder:
    8. Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2 (Includes info on how to create a forwarder)
      (Click image to see a larger version of the image in a new window)

  • Configure a Primary DNS Suffix on your Windows Servers that’s hosting DNS. To do that:
    Go to Start
    Right-click Computer, properties
    In the computer name tab click change settings
    Then click change
    Then click More
    Type your domain name here.
    Click Ok a few of times, and restart the server.
    (Click image to see a larger version of the image in a new window)

  • After the restart, make sure it registered into the your zone, for example, You can simple check by running an ipconfig /all. Look for the Primary DNS Suffix name.
    (Click image to see a larger version of the image in a new window)

    For more information on all the info that an ipconfig /all provides, please read the following:
  • Why do we ask for an ipconfig /all, when we try to help diagnose AD issues and other issues?

  • In the zone properties, Nameserver tab. Make sure it registered itself. If not, manually add it by clicking Add, then type in the server’s FQDN, and click Resolve. If all things are configured correctly, then it should resolve it. Click OK.
    (Click image to see a larger version of the image in a new window)
  • On the “Start of Authority (SOA)” tab click “Browse…” next to the Primary server field and browse for the server’s A record in the zone. Click OK.
    (Click image to see a larger version of the image in a new window)
  • Repeat step 4 for the reverse zone, and any other zones you’ve created in DNS.
  • DHCP Options
    1. DHCP Option 015 must be set to your zone, such as This provides a way to work for the interface to use that zone for registration, as well as for the DHCP server to use it to register into the zone.
    2. DHCP Option 006 must be set to only your internal DNS servers. Do not use your router as a DNS address (it’s really not a DNS server anyway), or your ISP’s DNS servers.
      (Click image to see a larger version of the image in a new window)
  • Configure scavenging. The scavenging NoRefresh and Refresh values combined should add up to or greater than the lease length. For example, if the DHCP lease length is 8 days, then the NoRefresh value should be 4, and the Refresh value should be 4.
    More info:
  • Good article by Sean Ivey, MSFT:
    How DNS Scavenging and the DHCP Lease Duration Relate
    (Make the NoRefresh and Refresh each half the lease, so combined, they are equal or greater than the lease).

  • In DHCP properties, DNS tab (note -this tab is actually DHCP Option 081, even though it doesn’t say it), choose to force DHCP to update all records whether a DHCP client asks or not. And configure it to register records for machines that can’t.
    (Click image to see a larger version of the image in a new window)
  • Configure a user account to be used for DHCP Credentials (as I said above), then go into DHCP, IPv4, properties, Advanced, Credentials, and enter the credentials.
    (Click image to see a larger version of the image in a new window)
  • Restart the DHCP service.
  • It should now work.

    Example of what you should see after it’s configured and working:

    (Click image to see a larger version of the image in a new window)

    Other notes and references:

    There are a number of ways to get this to work. Read the following discussion for more info:

    Technet thread: “Server 2008 R2: DNS records not dynamically registering in workgroup situation” 12/31/2010

    Registry summarized:

    Not that this will work for your non-Windows devices, but I’m providing this information if you want to only configure your Windows computers.

    You can create and remotely run a registry script for the interface on the workgroup machines using a tool called PSEXEC (free download from Microsoft). Of course you must have the local admin account credentials on all your computers to run this remotely, and the remote Registry service started, and possibly antivirus software and Windows firewall configured to allow this.

    You’ll want to target and populate the following two registry entries with your zone name, such as

    • HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\domain
    • HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\NV domain

    Using the above two keys, try this VB script:
    SET WSHShell = CreateObject(“WScript.Shell”)
    WSHShell.RegWrite “HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\NV domain”, ““, “REG_SZ”
    WSHShell.RegWrite “HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\domain”, ““, “REG_SZ”

    If you are in an AD Environment

    Oh, and if you’re curious how DHCP should be configured in an AD environment to force updates, etc, read my blog on it, please:

    DHCP Service Configuration, Dynamic DNS Updates, Scavenging, Static Entries, Timestamps, DnsUpdateProxy Group, DHCP Credentials, prevent duplicate DNS records, DHCP has a “pen” icon, and more…
    Published by Ace Fekay, MCT, MVP DS on Aug 20, 2009 at 10:36 AM  3758  2  

    Good summary:
    How Dynamic DNS behaves with multiple DHCP servers on the same Domain?


    I hope you’ve found this helpful. Any suggestions, errors, comments, etc., are all welcomed!

    Ace Fekay

    DNS Zone Types Explained, and their Significance in Active Directory

    Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
       Microsoft Certified Trainer
       Microsoft MVP: Directory Services
       Active Directory, Exchange and Windows Infrastructure Engineer and Janitor


    Original publication 4/30/2013


    Ace here again. I thought to touch base on DNS zones, and more so, focus on what AD integrated zones are and how they work. This blog almost mimics my class lecture on this topic. Check back for updates periodically, which I will notate with a timestamp above with whatever I’ve added or modified.

    This topic was also briefly discussed in the following Microsoft Technet forum thread:
    Technet thread: “Secondary Zones?”


    AD Integrated Zones AD Database Storage Locations

    First up is a background on the various parts of the Active Directory database and what gets stored in them. This will help understand where DNS data is stored as I discuss it later in this blog.

    The Active Directory Data Store (the AD database):

    There are three possible storage locations for DNS zone storage in the Active Directory database:

    • DomainNC – This was the only available location with Windows 2000. This replicates to all DCs only in a specific domain.
    • DomainDnsZones partition – Introduced in Windows 2003 and used in all newer operating systems. This replicates to all DCs only in a specific domain in the forest.
    • ForestDnsZones partition. This replicates to all DCs in the forest.

    You can see how not all partitions are replicated forest wide. It depends on the partition:


    Ok, Now the DNS Basics:

    • A Secondary is a read-only copy
    • A Secondary zone stores it’s data in a text file (by default in the system32\dns folder)
    • A Secondary gets a copy of the zone data from the Primary
    • A Primary is the writeable copy
    • A Primary stores it’s zone data in a text file (by default in the system32\dns folder)
    • There can only be one Primary, but as many Secondary zones as you want.
    • You must allow zone transfer capabilities from the Primary zone if you want to create a Secondary.
    • AD integrated zones do NOT need zone transfers to be allowed (see below for specifics)

    Active directory Integrated Zones changes this a bit:

    AD Integrated zones are similar to Primary zones, however their data is stored as binary data in the actual AD database and not as a text file. The specific place in the AD database depends on the DC’s operating system version and replication scope, which means what “logical” part of the physical AD database it’s stored in, which will affect which DCs in the forest it will replicate to.

    • The “only one Primary Zone” rule is changed by introducing the Multi-Master Primary feature. This is because the data is not stored as a text file, rather it is stored in the actual, physical AD database (in one of 3 difference logical locations or what we call the Replication Scope), and any DC that has DNS installed (based on the replication scope) will be a writeable copy.
    • The zone data is replicated to other DCs in the replication scope where the data is stored (based on one of the 3 logical locations)
    • Each DC in the replication scope that has DNS installed, will automatically make available the zone data in DNS
    • Each DC that hosts the zone can “write” to the zone, and the changes get replicated to other DCs in the replication scope of the zone/
    • The DC that makes a change becomes the SOA at that point in time, until another DC makes a change to the zone, then it becomes the SOA
    • An AD Integrated zone can be configured to allow zone transfers to a Secondary, but the Secondary CANNOT be a DC in the same replication scope as the zone you are trying to create as a Secondary, otherwise the DC you are attempting to create the Secondary on will automatically change it to AD integrated, since it “sees” it in the AD database. In some cases, if this is forced or done incorrectly, it can lead to duplicate or conflicting zones in the AD database, which is problematic until fixed.

    And if you install DNS on another DC, the zone data will *automatically* appear because DNS will recognize the data in the AD database. AD integrated zones can also act as a Primary zone for secondary zones, whether they are on Windows machines, BIND (on Unix) or any other name brand.

    Remember, AD integrated zones still follow the RFCs, but have more features.


    Duplicate or Conflicting zones?

    Since I touched based on duplicate and conflicting zones, you may want to check if they exist in your AD database. You have to check each partition, and if you have more than one domain, you have to check the DomainDnsZones and DomainNC of each domain. You may even have to check it on multiple DCs in various AD Sites to see if they all “see” the same copy or different copies. You would be surprised what I’ve seen with AD replication problems and seeing different DCs “seeing” something different in its own database. This issue also manifests as a symptom in more than just a DNS problem, where you create a user on one DC and it never replicates to another DC.

    Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones


    Primary Standard Zone, Secondary Standard Zones & Zone Transfers

    Zone transfers allow you to create a read only copy (a Secondary zone) on another DNS server, that will pull a copy (transfers) from the read/writable zone (the Primary zone).

    Primary and Secondary zones store their data as text files.

    On a Windows machine, the zone files can be found in the \system32\dns folder with a file name such as “”. You can have numerous read only copies, but there can only be one read/write of that zone.

    Please keep in mind, the authoritative DNS server listed in the registrar for a public domain name (zone) does not have to be a Primary, it’s just the host nameserver listed as authoritative. It can get it’s data from a Primary that is not listed, hence the writable copy is actually hidden and protected from public access.

    Do I need Zone transfers Allowed for AD Integrated Zones if I do not have Secondaries Zones?

    The short answer: NOPE.

    The reason is that the term “AD Integrated” means the zone is stored in the AD database, and the zone will replicate to other domain controllers within the same replication scope (domain-wide or forest-wide) automatically as part of the AD replication process.

    By default, AD integrated zones are configured to not allow zone transfers.

    Allowing zone transfers is an option provided to support non-DC DNS servers, BIND or any other name brand DNS server that you want to allow zone transfers to a secondary on those servers.

    Rotating SOA

    Additional security options of AD integrated zones, is one of the feature of AD integrated zones, as well as the fact that there can be more than one Primary zone copy of it. This is because all DNS servers that host the zone in a domain or forest has the ability to be a writable copies and becomes the actual “start of authority” (SOA) of that zone when a specific DC/DNS accepts a write operation, such as a client machine registering, or the DC itself updating its SRV records.

    For example, if a DC updates it’s SRV and other records at the default 60 minute interval (all other machines register every 24 hours), it will update its data into the DNS server listed as the first DNS address in the network card. This server now writes it into DNS and NOW becomes the SOA of the zone. That data is replicated to other DC/DNS servers with default AD replication. Now all other DC/DNS servers will see the change.

    To further explain, since the zone is AD integrated, each and every DC in the replication scope of the zone, can accept changes, due to an AD integrated zone’s Multi-Master Primary Zone features. Based on the definition of what an SOA is, that is being the DNS server that’s authoritative to accept writes, therefore, whichever DC/DNS accepted a change to the zone, that specific DC/DNS will become the SOA for that moment in time. Then when the next DC/DNS that accepts a change, it will now become the new SOA. The SOA constantly changing in an AD environment is accepted, and default behavior.

    That is why you can watch the SOA name on AD integrated zones change. The data is replicated automatically as part of the AD replication process because it is stored in the AD database.

    Active Directory-integrated DNS zone serial number behavior (SOA default behavior) 



    Configure AD Integrated Zones
    (When converting to AD integrated zones)
    Quoted: “Only primary zones can be stored in the directory. If a zone is configured on other domain controllers as a secondary zone, these zones will be converted to primary zones when you convert the zone to AD integrated. This is because the multimaster replication model of Active Directory removes the need for secondary zones when a zone is stored in Active Directory. Conversion of the zone from secondary to primary will occur when AD DS is restarted.”

    Understanding DNS Zones

    Understanding stub zones: Domain Name System(DNS)
    Jan 21, 2005 – The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary …

    AD & Dynamic DNS Updates Registration Rules of engagement

    Keep in mind, for the most part it automatically works “out of the box” without much administrative overhead.

    Original Compilation: 11/19/2012
    Updated: 9/5/2013


    What I’ve tried to do is accumulate all pertinent information about configuring dynamic DNS registration in an AD environment. I hope I haven’t missed anything, and that I’ve explained each numbered bullet point well enough and removed all ambiguity, to fully understand each point.

    And yes, this blog is regarding an AD environment. If you have a non-AD environment with a Windows DNS server that you want your computers to register, please read the following blog:

    DNS Dynamic Updates in a Workgroup




    1. The machine’s DNS entries in the NIC, must be ONLY configured to use the internal DNS servers that host the zone. No others.
          a. DHCP Option 006 MUST only be the internal DNS server(s) you want to use, otherwise if using an ISP’s DNS or your router, expect undesired results.
    2. The Primary DNS Suffix on the machine MUST match the zone name in DNS.
      1. For joined machines, this is default. 
      2. For non-joined machines, the Primary DNS Suffix must be manually configured or scripted.
    3. If using DHCP Option 015 (Connection Specific Suffix), it must match the zone name and have “Use This Connection’s DNS Suffix in DNS Registration” along with “Register This Connection’s Addresses in DNS” checked in the NIC’s IPv4, Advanced, DNS tab.
      1. For additional information on how to configure updates in a workgroup:
        DNS Dynamic Updates in a Workgroup
    4. The Zone must be configured to allow updates.
    5. For AD Integrated Zones where you have it configured for “Secure and Unsecure Updates:
      1. If the machine’s network card DNS address entries have been statically configured:
              – They must only point to the internal DNS servers that host the AD zone or to servers that have a reference to the zone (such as stubs, secondary zones, conditional forwarders, or forwarders)
              – It must be joined to the domain in order to authenticate using Kerberos to update.
      2. If statically configured and not joined to the domain, the client can’t update its record if the zone is set to Secure Only. 
      3. For non-joined domain DHCP clients, you can configure DHCP to update in lieu of the client updating into a Secure Only zone.
    6. For any non-Windows statically configured machine, it must support the DNS Dynamic Updates feature and the zone configured to allow Secure and Unsecure updates.
    7. If the DNS server is multihomed and not configured properly to work with multihoming, it may cause problems with Dynamic Updates.
      1. Read the following for more info:
        Multihomed DCs (with more than one unteamed NIC or multiple IPs) with DNS, RRAS, iSCSI, Clustering interfaces, management interfaces, backup interfaces, and/or PPPoE adapters – A multihomed DC is not a recommended configuration, however there are ways to configure a DC with registry mods:
    8. If the zone is single label name, such as ‘domain’ instead of the proper minimal format of ‘,’ ‘,’ etc., it will NOT update.
    9. The client will “look” for the SOA of the zone when it attempts registration. If the SOA is not available or resolvable, it won’t register. Keep in mind with AD integrated zones the SOA rotates among the DCs because of the multimaster feature. This is default and expected behavior, but if there are any DCs that have any problems, and the client resolved the SOA to that DC, it may not accept the update.
    10. The zone in DNS must NOT be a single lable name, such as “DOMAIN” instead of the required minimum of two hierarchal levels such as, domain.local,,, etc. Single label name zones are problematic, do not conform to the DNS RFC, and causes excessive internet traffic to the Root Servers when DNS tries to resolve a single label name query, such as querying for computername.domain – in such a query, the domain name is actually treated as a TLD. ISC has made a note of the excessive traffic generated by Microsoft DNS servers configured with a single label name in 2004 with Microsoft, which in turn disabled the ability for Microsoft DNS in Windows 2000 SP4 and newer to resolve single label names without a registry band aid. More info on this:
      1. Active Directory DNS Domain Name Single Label Names – Problematic
        Published by Ace Fekay, MCT, MVP DS on Nov 12, 2009 at 6:25 PM  641  0
    11. For Windows 2008 and all newer operating systems, IPv6 must not be disabled. If disabled, it will cause other problems:
      The Cable Guy – Support for IPv6 in Windows Server 2008 R2 and Windows 7, by Joseph Davies, Microsoft, Inc.
      Quoted by Joseph Davies, MSFT:
      “IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. “Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.”
      1. Arguments against disabling IPv6
        Demoire, [MSFT], 24 Nov 2010 12:37 AM
      2. IPv6 for Microsoft Windows: Frequently Asked Questions
        (Basically Microsoft is saying in this KB article to not disable IPv6)


    Full explanation:

    1. Active Directory’s DNS Domain Name is NOT a single label name (“DOMAIN” vs. the minimal requirement of “” “domain.local,” etc).
    2. The Primary DNS Suffix MUST matches the zone name that is allowing updates. Otherwise the client doesn’t know what zone name to register in. You can also have a different Connection Specific Suffix in addition to the Primary DNS Suffix to register into that zone as well.
    3. AD/DNS zone MUST be configured to allow dynamic updates, whether Secure or Secure and Non-Secure. For client machines, if a client is not joined to the domain, and the zone is set to Secure, it will not register either.
    4. You must ONLY use the DNS servers that host a copy of the AD zone name or have a reference to get to them.
      1. Do not use your ISP’s, an external DNS address, your router as a DNS address
      2. Do not use any DNS that does not have a copy of the AD zone.
      3. Internet resolution for your machines will be accomplished by the Root servers (Root Hints), however it’s recommended to configure a forwarder for efficient Internet resolution.
    5. The domain controller is multihomed (which means it has more than one unteamed, active NIC, more than one IP address, and/or RRAS is installed on the DC).
    6. The DNS addresses configured in the client’s IP properties must ONLY reference the DNS server(s) hosting the AD zone you want to update in.
      1. This means that you must NOT use an external DNS in any machine’s IP property in an AD environment.
      2. You can’t mix internal and external DNS server. This is because of the way the DNS Client side resolver service works. Even if you mix up internal DNS and ISP’s DNS addresses, the resolver algorithm may still pick the incorrect DNS to query. Based on how the algorithm works, it will ask the first one first. If it doesn’t get a response, it removes the first one from the eligible resolvers list and goes to the next in the list. It will not go back to the first one unless you restart the machine, restart the DNS Client service, or set a registry entry to cut the query TTL to 0. The rule is to ONLY use your internal DNS server(s) and configure a forwarder to your ISP’s DNS for efficient Internet resolution.
      3. There is a registry entry to cut the query to 0 TTL (normally this is not necessary, but I’m posting it as a reference).
        1. The DNS Client service does not revert to using the first server …The Windows 2000 Domain Name System (DNS) Client service (Dnscache) follows a certain algorithm when it decides the order in which to use the DNS servers …

      4. The DNS Client Service Does Not Revert to Using the First Server in the List in Windows XP (applies to all Operating Systems, too)
      5. For more info, please read the following on the client side resolver service:
        DNS, WINS NetBIOS & the Client Side Resolver, Browser Service, Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down Does a Client logon to Another DC, and DNS Forwarders Algorithm if you have multiple forwarders.
    7. For DHCP clients, DHCP Option 006 for the clients are set to the same DNS server.
    8. If using DHCP, DHCP server must only be referencing the same exact DNS
      server(s) in it’s own IP properties in order for it to ‘force’ (if you set
      that setting) registration into DNS. Otherwise, how would it know which DNS
      to send the DNS registration request data to?
    9. If the AD DNS Domain name is a single label name, such as “EXAMPLE”, and not the proper format of “” and/or any child of that format, such as “”, then we have a real big problem. DNS will not allow registration into a single label domain name.
      This is for two reasons:
      1. It’s not the proper hierarchal format. DNS is
                   hierarchal, but a single label name has no hierarchy.
                   It’s just a single name
      2. Registration attempts causes major Internet queries
                   to the Root servers. Why? Because it thinks the
                   single label name, such as “EXAMPLE”, is a TLD
                  (Top Level Domain), such as “com”, “net”, etc. It
                  will now try to find what Root name server out there
                  handles that TLD. In the end it comes back to itself
                 and then attempts to register. Unfortunately it doe NOT
                 ask itself first for the mere reason it thinks it’s a TLD.
      3. Quoted from Alan Woods, Microsoft, 2004:
        “Due to this excessive Root query traffic, which ISC found from a study that discovered Microsoft DNS servers are causing excessive traffic because of single label names, Microsoft, being an internet friendly neighbor and wanting to stop this problem for their neighbors, stopped the ability to register into DNS with Windows 2000 SP4, XP SP1, (especially XP,which cause lookup problems too), and Windows 2003. After all, DNS is hierarchal, so therefore why even allow single label DNS domain names?”
      4. The above also *especially* applies to Windows Vista, Windows 7, &, 2008, 2008 R2, Windows 2012, and newer.
    10. ‘Register this connection’s address” on the client is not enabled under the NIC’s IP properties, DNS tab.
    11. Maybe there’s a GPO set to force Secure updates and the machine isn’t a joined member of the domain.
    12. With Windows 2000, 2003 and XP, the “DHCP client” Service is not running.  In Windows 2008, Windows Vista and all newer operating systems, it’s now the DNS Client Service.
      1. This is a requirement for DNS registration and DNS resolution even if the client is not actually using DHCP.
      2. Dynamic DNS Updates Do Not Work if the DHCP Client Service Stops (2000/2003/XP only)
    13. You can also configure DHCP to force register clients for you, as well as keep the DNS zone clean of old or duplicate entries. The following has more information on how to do that:
      1. DHCP, Dynamic DNS Updates, Scavenging, static entries & timestamps, and the DnsProxyUpdate Group (How to remove and prevent future duplicate DNS host records)
        Published by acefekay on Aug 20, 2009 at 10:36 AM  3758  2


    What will stop AD SRV registration:

    1. Any DNS server referenced in TCP/IP properties that does not host the AD zone name, or does not have a reference to the internal AD zones name.
      1. External DNS servers do not host or have a reference, therefore must NOT be used.
      2. AD Domain machines must never be pointed at an external (ISP) DNS server or even use an ISP DNS server as an “Alternate DNS server” because they do not host the internal AD zone, or have a reference to it.
        1. Only use internal DNS servers when part of an Active Directory domain. Active Directory’s Reliance on DNS, and why you should never use an ISP’s DNS address or your router as a DNS address, or any other DNS server that does not host the AD zone name

    2. Are any services disabled such as the DHCP Client service or the DNS Client Service? They are required services, whether the machine is static or DHCP.
      1. No DNS registration functions if DHCP Client Service Is Not Running (2000/2003/XP only)
      2. Dynamic DNS Updates Do Not Work if the DHCP Client Service Stops (2000/2003/XP only)
      3. For all Windows 2008, Windows Vista and all newer operating systems, it’s the DNS Client Service.
    3. The AD/DNS zone not configured to allow dynamic updates.
    4. Make sure ‘Register this connection’s address” in DNS is enabled under TCP/IP properties.
    5. Missing or incorrect “Primary DNS suffix” or “Connection-specific DNS suffix” of the domain to which the machine belongs. 
      1. I one of these are incorrect, the client side service cannot find the correct zone to register into. If missing or incorrect, it is called a Disjointed Domain Namespace.
    6. Is the firewall service enabled? (disable it).
    7. Were the default C: drive permissions altered and was a hotfix installed a recently?
      1. “Systems that have changed the default Access Control List permissions on the %windir%\registration directory may experience various problems after you install the Microsoft Security Bulletin MS05-051 for COM+ and MS DTC”
      2. For more info about this issue, see:
    8. If the zone is set to Secure Updates Only, the computer may not have authenticated to the domain (which can be due to DNS misconfiguration or DNS server problem), which of course causes more problems than just DNS  registration.
    9. Is the File and Print services enabled?
      1. It must be enabled.
    10. Microsoft Client Services enabled?
      1. If not,  it must be enabled.
    11. Is DNS service listening on the private LAN interface?
      1. Check under the Interfaces tab under DNS server properties in the DNS console.
    12. More than one NIC on a client?
      1. The wrong one may be registering.
    13. Updates allowed on the zone?
      1. This is an obvious one.
    14. Primary DNS suffix matches the zone name in DNS and the AD domain name?
      1. If not, then it won’t register into the zone.
    15. Was Zone Alarm ever installed on these machines?
      1. If so, ZA leaves SYS files and other remnants that continue to block traffic.
    16. Any Event log errors?
    17. Was a Registry entry configured to stop registration?
      1. 246804 – How to Enable-Disable Windows 2000 Dynamic DNS Registrations (per NIC too):
    18. Spyware or something else such as DotNetDns installed on it?
      1. Download the free tool at and run a malware scan.
      2. Download the free Malicious Software Scanner from Microsoft and run a scan
      3. Download TrendMicro HouseCall free scan tool and run it.
    19. Single Label Domain Name?
      1. Active Directory DNS Domain Name Single Label Names – Problematic – And this applies to any DNS zone name, not just AD.
        Published by Ace Fekay, MCT, MVP DS on Nov 12, 2009 at 6:25 PM  641  0
    20. Netlogon and DFS services must be started.
    21. Malware or virus altering network services preventing it from registering.
      1. Some sort of firewall in place, whether the Windows firewall disabling File and Print Services, or a 3rd party firewall, which many AV programs now have built in and must be adjusted to allow this sort of traffic and exclude the NTDS and SYSVOL folders.
      2. If Windows Firewall, run the following to see what settings are enabled:
        netsh firewall show config
    22. Is IPv6 disabled? That will stop registration.
      1. Enable it.
    23. Do any duplicate AD integrated zones exist in the AD database?
      1. This will cause major problems. Any duplicates found must be deleted. The cause must also be determined to eliminate it from occurring again.
      2. Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones
        Published by acefekay on Sep 2, 2009 at 2:34 PM  7748  2
    24. Were imaged machines cloned without the image being Sysprepped first? 
      1. If not, duplicate SIDs will cause machines to fail authentication to register into the zone.


    Suggestions, Comments, Corrections are welcomed.

    Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
       Microsoft Certified Trainer
       Microsoft MVP: Directory Services
       Active Directory, Exchange and Windows Infrastructure Engineer and Janitor

    Troubleshooting the Browser Service

    By Ace Fekay, , MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP: Directory Services
    Active Directory, Exchange and Windows Infrastructure Engineer




    Each subnet has it’s own master browser, and if you are using WINS, the master browser works together with the WINS service to enumerate an infrastructure wide browse list.

    If not using WINS, it uses broadcasts, however, you’ll only see what’s on your own subnet, because NetBIOS broadcasts are more than likely blocked by routers, which is default, and many routers don’t allow NetBIOS broadcast across subnets to be enabled.

    If you are in a multi-subnetted environment, and you want full browsing capabilities, to get around routers blocking NetBIOS broadcasts, it’s suggested to use WINS.

    And the default WINS settings out-of-the-box, work fine, as long as you set up DHCP WINS options correctly. There is no need to adjust WINS’ registry parameters, otherwise you’ll find yourself trying to change registry entries on multiple servers and mis-keying something. Here’s more info on configuring WINS:

    WINS – What Is It, How To Install It, WINS Replication Partner Design Guidelines, How to Configure DHCP Scopes For WINS Client Distribution, and more:

    If you’ve just upgraded your PDC from Windows 2003 to Windows 2008 or Newer

    The Computer Browser service on Windows 2008 and newer is disabled by default. If you want the PDC Emulator to do it’s job as the Master Browser and not have some workstation win the election (read below what that means), then I suggest to set it to Automatic and start it. Otherwise, browsing will not work properly and you’ll be chasing a ghost trying to figure out why. I usually just enable it on all of my DCs. More info in the following link:

    NetBIOS browsing across subnets may fail after upgrading to Windows Server 2008

    Preferably install at least one server OS on each subnet:

    If there is a server OS, and it’s not multihomed, especially if a DC on the subnet and it’s not multihomed (multihoming a DC is a really bad idea), then it should win, unless there’s a problem with the machine itself, such as some sort of security setting in your antivirus blocking traffic, or firewall blocking traffic on it.

    And as mentioned, if you just upgraded the PDC emulator to 2008 or newer, set the Computer Browser service to Automatic and start it.

    If you find workstations are becoming masters, that means there are no server operating systems on those subnets, in such cases, the workstation will win Master Browser election.

    And I realize in many large infrastructures, it would be nearly impossible to put a server operating system on each subnet. However, as long as there is a desktop using the latest client operating system that is always up and running 24/7, that will do the trick.

    If a newer client OS were to be introduced, then it would start a master browser election, and win the election (OS version and server role is a factor in the election process). And any machine that someone clicks on Network Neighborhood or clicks a Browse button somewhere, would invoke an election, but if a desktop is running on the subnet 24/7, it will win the election, since it’s already up and running.

    If you don’t want any other client machine to win the election and were to opt for only that one machine, you can set a registry entry using a GPO to disable participating in the browse list for all the machines in the subnet other than the client machine you chose to keep up and running 24/7:

    Set the client machine of your choosing to:
    Emulator MaintainServerList=Yes, IsDomainMaster=True

    All other clients on the subnet, set it to:

    I’m not saying this is a perfect solution, but it’s something to consider. Otherwise, if no specific machine is up and running 24/7 on any given subnet, the browse list will be rebuilt each time everyone shuts down, then brings their machines up in the morning, and the cycle starts from scratch to rebuild the list of machines on that subnet.


    Third Party Devices Participating in the Browser Service

    I would like to point out that if you have any 3rd party devices, such as a Seagate BlackArmor NAS, it will jump in on the election process and may win, which in case will snafu your browse list. I had one of those devices at a customer site last year causing numerous problems with the browse list, which in turned snowballed to cause problems with Symantec BackupExec, and other services that rely on browsing.

    After some troubleshooting, I found that the BlackArmor NAS was consistently winning the election causing the problems. I couldn’t find anything specific on how to disable browser service participation on the device. It has the latest firmware. I contacted Seagate, and they said they couldn’t help me to disable the device’s ability to participate in the Browser Service.

    I finally moved it on to its own VLAN so it can be king of itself on that subnet, so to speak. I gave it it’s own island. Smile


    Browse List Propagation:

    We have to keep in mind with troubleshooting the browser service, there is a time period you have to wait for the list to fully enumerate and become available on the master. A good example is when a server is shut off on a segment, and the workstations kick in, or the server is rebooted, wins the election, and begins a new cycle to enumerate the browse list from WINS and/or broadcasts. This can take a minimal of 12 minutes, upwards to the 48-minute full propagation cycle in a multiple-segment domain environment.


    When to Troubleshoot

    Below are the generic troubleshooting steps I used to troubleshoot the browser service that helped me find out the BlackArmor device was the culprit.

    If you are seeing problems with the browser service, such as computers disappearing from the browse list, whether the cause is a third party device, Unix/Linux machine running Samba, or simply based on the infrastructure’s design, it might be a good idea to start troubleshooting to find the culprit.


    Prepare to Troubleshoot:

    • Make sure the Computer Browser service is Started. Make sure NetBIOS is enabled on al machines.
    • On Windows 2003 and 2000, install the Support Tools (from the Windows CDROM) in order to have the “browstat” utility available.
    • With Windows 2008 and newer, the utility is already installed as part of the operating system files.
    • If there are any antivirus software, third party firewalls, or firewall rules between locations blocking WINS traffic (TCP 42), it could block browser traffic, too. This of course, assumes the Computer browser service is running.


    Firewall blocks – Test it with PortQry

    You can use the Portqry.exe utility to test if the Browser, SMB, WINS and the ephemeral (service response) ports are permitted.

    • Browser: UDP 137/138, TCP 139
    • SMB: TCP 445
    • WINS: TCP 42
    • Ephemeral (Service Response Ports): Varies depending on OS:
      • Windows 2000/2003/XP: TCP/UDP 1024-5000
      • Windows 2008/Vista and newer: TCP/UDP 49152-65535

    Description of the Portqry.exe command-line utility

    Active Directory Firewall Ports – Let’s Try To Make This Simple 


    Multihomed DCs:

    And if you have any multihomed DCs, among numerous other problems, that is a major cause of browser problems. Multhoming DCs is not recommended for multiple reasons, including a “Multihomed Browser” scenario. I suggest to disable one of the interfaces.

    More info regarding multihoming DCs and why not to do it:

    Multihomed DCs (with more than one unteamed NIC or multiple IPs) with DNS, RRAS, iSCSI, and/or PPPoE adapters – A multihomed DC is not a recommended configuration, however there are ways to configure such a DC to work properly.


    Troubleshooting Steps:

    Run a browstat status to see who the browse master is for the segment. If it’s not the PDC Emulator, and some other device won the election, that can cause a problem.

    To check current status of the browse service on the domain, run:
    browstat status

    You should get a response similar to:
    Browsing is active on domain.
    Master browser name is: <serverName>

    Note, the machine that is the current master browser will either be, depending if the machine type exists on the segment: the PDC Emulator, a replica DC on the segment, a member server, joined workstation, or workgroup member, Unix or Linux with SAMBA, etc.

    If you find a device is winning the election, then we need to disable that ability in the device. If there are no features for that, contact their support department, or put the device behind it’s own subnet or VLAN to prevent it from winning the election on the production network.

    To find the current browse master on a segment, you’ll have to find the TransportID:
    First run:

    browstat getmaster \device\netbt_el59x1 <domainname>

    It will error out because the “netbt_el59x1” probably doesn’t exist, and will respond with the transports currently bound to the browser. Copy and paste the transport that does show up into your next command:

    browstat getmaster \Device\NetBT_Tcpip_{C2055954-4F86-446F-ACBA-E00BE731C3FB} <domainname>

    Force an election by running:
    browstat elect \device\netbt_ieepro1 <domainname>

    Then check the event logs to see which machine won the election. If it’s a device, such as I’ve found that Linux/Unix with SAMBA, or devices such as a Seagate NAS, may win the election and cause browsing havoc within an environment and get that familiar, but unwanting “Access Denied” when trying to browse.


    Master Browser Election Process

    I know, most of you probably wondered what the order of who would be the winner during a Master Browser election. The winner of a browse master election process is based on operating system version and role. It’s also based on each subnet.

    So if a Windows XP client is on a subnet by itself, then yes, it may become an MB if nothing else beats it.

    And if a Windows Server 2008 R2 DC is on subnet and on subnet there are only a bunch of Windows XP and 2000 computers, then the XP will win.

    If the DC is multihomed, then that will definitely throw a wrench into it. Do NOT multihome your DC. Really, believe me, you don’t want to do it.

    The following list shows the order of precedence of which operating system will win. And keep in mind, it’s subnet specific.

    1. DC – PDC Emulator (no matter what OS)
    2. DC – Non-PDC Emulator (no matter what OS)
    3. Windows Server 2012
    4. Windows 8
    5. Windows Server 2008 R2
    6. Windows 7
    7. Windows Server 2008
    8. Windows Vista
    9. Windows Server 2003 R2
    10. Windows Server 2003
    11. Windows XP
    12. Windows Server 2000
    13. Windows 2000 Pro
    14. Windows NT 4.0
    15. Windows ME
    16. Windows 98
    17. Windows 95
    18. Windows for Workgroups 3.11
    19. Windows 3.1 with NDIS
    20. DOS



    Troubleshooting the Microsoft Browser Services:

    Browser Elections 

    Description of the Microsoft Computer Browser Service



    Updated 10/18/2014

    I hope this helps! I’m sure I may have missed something. Comments and suggestions are welcomed.

    Ace Fekay
    MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP – Directory Services

    clip_image002[6] clip_image004[6] clip_image006[6] clip_image008[6] clip_image010[6] clip_image012[6] clip_image014[6]

    Complete List of Technical Blogs:

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    So you want to change your IP range?

    By Ace Fekay, , MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP: Directory Services
    Active Directory, Exchange and Windows Infrastructure Engineer


    So you are looking at a major IP migration from a public range to a private range and not simply extending the current scopes, or you simply want to change the current IP range.

    One good reason to change the internal IP range, is the current range matches many of the retail box store router default IP subnets, such as from Linksys, Netgear, etc. The identical subnets cause issues when users at home are using VPN to the company network. If the subnets are identical, routing won’t work, therefore they are never able to connect or access internal company resources.

    Depending on the size of the infrastructure, changing the IP range can either be easy, or pretty involved and will have a major undertaking on your hands. Let’s see…


    First come up with an IP Range

    Come up with a plan that includes an IP range for all servers and static set hosts, as well as an IP range for each floor, building, etc., depending on the scope of this project, and the subnets currently in place.

    You could use the same subnet for the whole building, which makes it easier to deal with, but not necessarily as efficient with network traffic, and especially if the number of hosts is so large (into the thousands), it becomes a rather large subnet broadcast domain. Also with one big subnets, you are reducing the ability to create efficient AD Sites appropriately.

    For example, if one were to choose one subnet for a large building with 3000 users, you could use one subnet, such as, which will give you 65,000 IPs:

    If you want to keep with the separate subnets for each floor, which is ideal, of course considering if you have layer 3 VLAN capable switches, that may be your better bet. Some may think it complicates matters with DHCP and routing, but looking at the network efficiency, I think it’s a better bet.

    For example, if you have multiple subnets or buildings with less than 4000 total hosts (servers, users, printers, etc.), a good example is the following breakdown, which will give you 4096 hosts for each subnet (and this is just an example – your mileage may vary):

    •   ( –
    • ( –
    • ( –
    • ( –
    • etc


    Procedure (steps are not in stone)

    1. Inventory all applications that have been configured with hardcoded IP addresses in their configuration, then change the IPs to the new IPs.
    2. Ask users to shutdown all workstations.
    3. Change the DC/DNS server’s’ IP addresses.
      1. In NIC properties, change it to the new IP address.
      2. In NIC properties, change the DNS IP addresses to the new IP.
      3. Re-register the DCs in DNS so it re-creates new records.
        1. ipconfig /all
        2. restart netlogon service
      4. Reference: Change the static IP address of a domain controller
    4. Check DNS:
      1. Server properties, Nameservers tab, insure the new IPs are listed.
      2. Remove the old ones and re-enter if needed.
      3. Check DNS zones – Make sure all old IP references are manually removed if the registration process above does not overwrite the old ones, which it should.
      4. Check the GC records (located in gc. _msdcs.domain.local).
      5. Check the LdapIpAddress records – the “same as parent” A records that each DC registers.
    5. Create a new reverse zone for the planned IP subnets. Make sure updates are allowed.
      1. Delete the old reverse zone.
      2. In lieu of deleting and recreating the reverse zones, if you’re energetic:
        1. Change the AD integrated reverse zone to a Primary Standard zone (this takes it out of AD and puts it into a text file in system32\dns.
        2. Open the system32\dns\zoneName.dns file, and change all the IPs in the zone file, save it, reload the zone. You should see all the new IPs
        3. Then change it back to AD integrated again.
    6. Change the DHCP Server’s scope.
      1. You will need to delete and re-create the scope from scratch.
      2. If you have Scope Options recreate the Scope Options.
      3. If you have Server Options, simply change the IP addresses they point to.
        1. If using WINS, change DHCP Option 044 to the new IP address of the WINS server.
        2. Option 003 is the router
        3. Option 006 is for DNS addresses
    7. If using Windows RRAS for VPN, and you are using a static IP pool, change the pool to a range in the new IP range.
      1. If using any other VPN solution, likewise.
      2. If using a Relay Agent or IP Helper, change the IP it’s pointing to.
    8. If using RRAS for NAT, change the configuration to the new internal interface’s IP.
    9. Change all of your other servers’ IPs.
      1. Run ipconfig /registerdns
    10. Change any static hosts, including printer cards, and other IP static entries.
      1. Restart the printers to take effect.
    11. With Windows machines, start them up.
      1. If they haven’t been shut down, then run ipconfig /registerdns on each.
    12. Make sure the above works, AD is functional, the DCs and servers can get to the printers, etc.
    13. You can run tests such as for Windows 2000 – 2008 R2, dcdiag /v /fix, and if Windows 2003 and older, run netdiag /v /fix.
    14. Check Event logs for any errors.
    15. Change the internal IP of the router.
    16. Recreate port-mappings (port translations) on the firewall, if required.


    Do Multiple Internal Subnets exist?

    1. If using multiple internal subnets that you are currently connected to, change the static route entries on the edge firewall/router to insure communications work to the other subnets. The same on their end.
    2. Once again, check event logs for any errors.
    3. Test internet connectivity from your DCs and servers.
    4. DHCP – Take note of exclusions, reservations, SuperScopes, etc. Delete all scopes.
    5. Create a new big scope, or multiples if you had separate scopes, Superscopes, etc.
    6. Test DHCP by firing up a couple of workstations, logons, internet connectivity, printers, resource access, etc.
    7. Once again, check event logs for any errors.

    I’m sure I may have missed a few steps and only briefed over others, but it should give you a good start and a guideline, because every infrastructure is different and unique.


    Comments, corrections and suggestions are welcomed.

    Why do we ask for an ipconfig /all, when we try to help diagnose AD issues?

    Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP: Directory Services
    Active Directory, Exchange and Windows Infrastructure Engineer

    Ace here again. Yea, I had to post a blog about this because many people ask, why do you want that? Just for the IP address??

    Nope. Not just for the IP.

    Good question.

    There is quite a bit of information that an ipconfig /all provides us configuration data as a precursor for a diagnosis. Sometimes the ipconfig /all results will help us fix it, but not always.

    Many admins are reluctant to provide this sort of information citing security reasons.

    In some cases, I sympathize and agree, but in many cases, security really isn’t much of a concern, because for one, your internal IP range is a private range, and two, you can substitute your actual internal domain name with something more generic, such as substituting “microsoft.local” with “mydomain.local. You should also substitute your DC names using something generic, such as dc-01. dc-02, etc. But definitely keep track of the substituted DC names if we have additional questions regarding them.

    Let’s take a look at each value in an ipconfig /all

    Believe it or not, the results of an ipconfig /all has numerous information that helps us get an inside view of a DC’s basic network configuration, as well as basic service configuration.

    Let’s break it down:

    C:\>ipconfig /all

    Windows IP Configuration

    Host Name . . . . . . . . . . . . : company-dc-01  

    • Name is under 15 characters – good for NetBIOS compatibility. Not a huge concern for many compani
    • Possibly indicates more than one DC based on the –01 portion of the name

    Primary Dns Suffix  . . . . . . . : 

    • The AD DNS Domain name is not a single label name.
    • In some cases, we’ll also ask for the name in ADUC. If the name in ADUC does no match this name, then it’s a Disjointed Namespace condition).
    • Node Type . . . . . . . . . . . . : Hybrid   

      • If Hybrid is set, it tells me that WINS is in use.
      • Hybrid mode, specifically 0x8 (as you would set a WINS server Hybrid mode in DHCP Option 046), tells the client side resolver to use WINS first when attempting to resolve a single name query, and if it can’t resolve it, to then try a broadcast to resolve it. Of course, this is only after DNS resolution fails, since DNS is used first anyway, where the client side resolver will suffix the Search Suffix when attempting to resolve it as a DNS hostname query.
      • If the Node Type is set to “Unknown,” then no big deal. It just means that WINS is not being used, and the resolver service will use broadcast for a  single name resolution.
      • IP Routing Enabled. . . . . . . . : No

        • Means RRAS is not installed
        • If set to Yes, it means RRAS is installed, and it will interfere with AD communications on this DC. 

        WINS Proxy Enabled. . . . . . . . : No  

        • On a DC, “No” is what we want to see.
        • If set to Yes, then it means “Enable broadcast name resolution” is checked under General tab in RRAS properties.
          • If this is set to Yes, and there is only one NIC. it could mean either:
          • RRAS is installed only for VPN use
          • RRAS was disabled, but the setting stuck
        • Either way, if it is set to Yes, it will cause problems with AD communications.

        DNS Suffix Search List. . . . . . :

        • This is what the client side resolver will use when attempting to resolve a single name query. For example, if I run nslookup against a single name such as computer1, the resolver will suffix to it, resulting in a query of
        • If there are multiple domains in the forest, such as a parent and child domain, or multiple child domains, then each domain must be configured with a search suffix for all other domains in order to be able to resolve everything in the forest. This is also true for additional Trees in the forest.
        • The in this example, was devolved from the Primary DNS Suffix.
          • If the Primary DNS suffix has multiple levels, such as, then the resolver will devolve it to show search suffixes of,, and
          • However, if is the parent root domain, if using Windows 2008 or newer, it will only devolve to Windows 2000 and 2003 devolved all levels, which led to some confusion.

        Ethernet adapter Team 1:

        • Obviously this interface is a team.

        Connection-specific DNS Suffix  . :

        • If this is a DHCP client, and DHCP Option 015 is configured with a domain suffix, then it will populate this value. It’s used for a specific interface that gets this configuration, such as if it is a wireless, then that value will populate the wireless connection, but not the wired connection, and will be used as suffix for identification and DNS registration only for that interface, but it is not used as a search suffix.

        Description . . . . . . . . . . . : BASP Virtual Adapter

        • This is the vendor brand name of the adapter

        Physical Address. . . . . . . . . : 00-18-8B-47-F0-D1

        • This is the MAC address of this adapter or Team.

        DHCP Enabled. . . . . . . . . . . : No

        • This means the NIC has a static configuration.

        IP address, mask and subnet

           IP Address. . . . . . . . . . . . :
           Subnet Mask . . . . . . . . . . . :
           Default Gateway . . . . . . . . . :

        • In the above three values, we make sure the IP address and mask are on the same subnet as an ipconfig /all of another machine, if one was provided. You would be surprised how many times we’ve seen subnets mis-configured with an incorrect subnet mask. 

        DNS Servers . . . . . . . . . . . :

        • What we look for with DNS address, is only to specify the internal DNS servers hosting the AD zone. If an external DNS addresses are specified, or your router’s DNS address is specified (for example,, then you should expect to see numerous problems. This is because your machine is sending the external DNS servers or your router a query whenever it tries to login, authenticate, find domain resources, etc. The external DNS servers or your router, does not have an answer when queried for internal resources. It’s the same as me asking the first person I see walking by out front of my house, “Where’s that beer that was in my refrigerator last night?” Besides the person not having an answer, he’ll probably give me a funny or dirty look. Your DNS server and DC won’t give you a funny look, but you’ll probably get some sort of error and your machine will fail to find your AD domain.
        • The addresses you see listed in this example are showing that it is pointing to a partner DC as the first entry, and itself as the second entry.
          • You may also find in some configuration the loopback as the second entry. This is ok, too. DCPROMO puts in the loopback. Matter of fact, if you were to run the AD BPA, one of the things it looks for is the loopback as the second entry. You can leave it there if you like, or you can change it to the IP of itself, but if you do, just ignore the BPA’s warnings, if you were to run it again.

        Primary WINS Server . . . . . . . :

        • This tells me the server is running WINS. Why? Because it is pointing to itself, as it should be for a WINS server.
        • If a WINS server is pointing to any other WINS servers, it will cause numerous problems with WINS record ownership.

        NetBIOS over Tcpip. . . . . . . . : Enabled

        • Of course this one is obvious. But here’s one for you. If you have NetBIOS disabled, but you are using WINS, what’s the point??

        AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL)

        By Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007, 2010 & 2013, Exchange 2013, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
          Microsoft Certified Trainer
          Microsoft MVP: Directory Services
          Active Directory, Exchange and Windows Infrastructure Engineer

        Updated 12/12/2013


        Ace here again with something I really would like to discuss, since this topic comes up from time to time.

        To properly designed an AD multi-site infrastructure, there are a few things that need to be taken into account. I won’t bore you with all the background techno babble, rather I’m going to discuss a no-nonsense, get down to business on why you need to either keep Auto Site Link Bridging enabled, or why you need to disable it, both of which depends on your physical routed topology design.

        AD Sites

        First, a basic understanding of Active Directory Sites is important to understand before I go further.

        Some of the biggest questions I hear about AD Sites are:

        • What are AD Sites?
        • What are AD Sites for?
        • Why can’t I create an AD Site without a domain controller in the Site?

        These are all valid questions. A little research will usually result in an answer, but you may have to dig through piles of technical details to get to it. Let’s address each one:

        What are AD Sites?

        An AD Site defines a highly-connected, physical network locations in Active Directory. We define them by IP subnet or subnets. And yes, you can have multiple subnets that are highly-connected by routers within a location. In some cases, for example, if you have a very high-speed backbone, such as an OC-1 (51.84Mbps or higher), between locations, you can put all those subnets in one AD Site. However, in many cases, we probably don’t want to do that. Hang in there, I’ll be getting to that in a few minutes.

        What are AD Sites for?

        AD sites are basically used for two things:

        1. To facilitate service localization. In simple English, this means to control logon and authentication traffic to DCs in a specific location, or Site. After all, we don’t want a client in NYC to pick a DC in Seattle, Japan, or somewhere else, to send its logon or authentication request (such as when accessing a folder), do we? Nope. The client side DC Locator process will find a DC in its own Site by using the client’s IP address.
        2. To manage DC replication traffic. In simple English, this means to control DC replication traffic across WAN links between the bridgeheads (the DCs in a Site that communicate with DCs in other Sites). By default, replication between Sites are compressed down to 15% of total traffic. And with Sites, we can control frequency of replication, and when we’re allowing it to happen.’

        Why can’t I create an AD Site without a DC in the Site?

        Good question. If you look at what AD Sites are for, then it should be pretty obvious that you need a DC in it. After all, if there is no DC in it, and a client picks a Site based on its IP subnet, then looks for a DC, it won’t find any, will it? Nope, so it may wind up randomly picking a DC in another location, such as that DC in Seattle or Japan.

        DC Locator Process

        I don’t want to dwell on this, but I will briefly mention it because this is part of the reason why we want to create AD Sites anyway.

        There is a process that a client uses to pick a DC. Here’s a quick view of how a client picks a DC. I should add a #9 to the list in a scenario when no DC exists in the Site, then it uses Automatic Site Coverage, and this ONLY if you created an IP Site link to another Site that you want the DCs to cover that site.

        If you didn’t create an IP Site link for a Site that has no DCs, then it will pretty much become a random process, sort of, by using other factors, such as subnet netmask ordering and Round Robin. If you want to read up on this subject, here are two good TechNet Forum discussions on it:

        Briefly, here are the DC Locator process steps, and these steps were directly quoted from How Domain Controllers Are Located in Windows XP

        1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
        2. DNS server returns list of DC’s.
        3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
        4. DC returns…
          1. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
          2. The site that the current domain controller is in.
          3. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
        5. The client decides whether to use the current DC or to look for a closer option.
          1. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
          2. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.

        Brief overview:

        For a full-sized image, click on the images.

        Let me point out again, that if there are no DCs in a Site, then Automatic Site Coverage will take over.

        To me, it’s a process to “find” a DC that will authenticate a user in a Site without a DC. However, my take on it is I would rather associate the location’s subnet to a current Site so as to not make the client go through this process. Besides, there may be scenarios that not having a DC in a Site can directly affect directory enabled applications and services such as DFS site referrals, SCCM or Exchange with it’s high dependency on GCs and DSAccess.

        Here’s the DC Locator process, directly quoted from the Technet article, “How DNS Support for Active Directory Works:”

        1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
        2. Build a list of candidate sites — sites that have domain controllers for this domain.
        3. For every target site, follow these steps:
          1. Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
          2. Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
          3. If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
          4. If more than one, break ties by choosing the site that is first alphabetically.
          5. Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

        If there are no DCs in a Site, you can use PowerShell to figure out which DC in which Site will be picked. If you like, you can further read up on the commands used to figure this out in Sean Ivey’s blog:

        Sites Sites Everywhere…, By Sean Ivey, Microsoft DS PFE

        So wouldn’t you want your clients to pick a DC in its own Site?

        Moving forward, do we really want a client to pick a DC in some other site or go through the Automatic Site Coverage process? Would you want that? I ‘m sure you already know the answer to that.

        Therefore, if you have a location that have no DCs, then simply create an IP subnet object, and associate the subnet object to an existing AD Site that you want those users to use. In this case, you may base your own pick on a site linked by the fastest WAN link, or the only WAN link.

        And if there are any subnets that are not associated with an AD site, then any DC is game to authenticate a client, as seen in the process above. To check for clients which subnets are not configured to AD Sites & Services, among other things, enable Netlogon logging, and check the system32\config\netlogon.log file. Here’s more info:

        Enabling debug logging for the Net Logon service, Last Review: May 3, 2011 – Revision: 11.0, Applies to: all operating systems.

        Auto Site Link Bridging

        This now brings us to bridging, what it is, etc.

        Within an AD Site, the KCC (Knowledge Consistency Checker) will automatically assume that all DCs can directly reach each other, and create Intrasite replication partnerships between the DCs in the Site. The one point that I want to be clear about that no matter how many DCs are in a Site, and there can be hundreds of DCs in a Site, the KCC will make sure that the  partnerships created are done so that all DCs in a Site will have an updated replication set for any changes by any of the DCs in the site, within 15 minutes. If you add a new DC to the Site, the KCC jumps in and evaluates the new guy and adds it so it gets updated data from other DCs under 15 minutes. How does it do that? It follows a set algorithm, but that is beyond this discussion.

        When there are multiple Sites, and more specifically three or more Sites, and keeping in mind that by default AD automatically assumes that all the Sites have direct physically connectivity and communications between each other. This means you can literally ping a DC from in any Site to any other Site.

        Here’s where the ISTG (Intersite Topology Generator) kicks in. The ISTG is a component of the KCC. It evaluates the overall topology, and builds connection objects between servers in each of the sites to enable Intersite replication— DC replication between sites.

        Here’s a fully routed infrastructure, For the full-sized image, click here.


        If remote sites cannot directly communicate with each other and only to the hub site

        However, if your physical network topology is designed where each site does not have direct communications with each other, and you leave all the default “Auto Site Link Bridge” setting enabled as is, then lots of things will go wrong, such as replication problems, duplicate AD integrated zones, and more … keep reading. But I won’t address duplicate zones. You can click the link in the previous sentence for more on that.

        If the network topology was a hub and spoke and BASL wasn’t disabled and individual sites links between the hub and each site weren’t created until recently, then there may be replication problems. This is a whole different subject. What I can say, besides checking to see if there are duplicate zones, as I mentioned in the previous paragraph, I would also run the Active Directory Replication Status Tool to check replication status. It will provide a report, and anything amiss will show up in Red. Pretty cool tool. Download it here:

        Download The Active Directory Replication Status Tool (ADREPLSTATUS):
             Note: This tool requires .Net Framework 4. If it’s not installed, download and install it:
               Microsoft .NET Framework 4 (Web Installer)

        Remember, by default, the KCC assumes all sites can directly communicate, therefore it will create partnerships between Bridgeheads in all sites. And any DC in a site can automatically become a bridgehead.

        So if corporate headquarters is in NYC, and you have three remote locations, Miami, Chicago and Seattle, and direct communications does not exist, meaning that each remote location can only communicate with headquarters, and IP routing has not been configured between the remote locations, and the KCC creates a connection object (partnership) between a DC in Miami and a DC in Seattle, what will happen?

        Since they can’t directly communicate, then replication fails. And if the Seattle partnership is the only connection object Miami may have, but Seattle happens to have one to NYC, and keeping in mind, replication is a PULL request, then Seattle will receive replication from NYC, but Miami can’t pull anything from Seattle, because there is no direct or indirect communications. So Miami winds up being in a secluded island.

        In Miami’s DC’s view, it thinks no one wants to talk to it, so it will complain (you will see multiple event log errors) that others having replicated with it. And according to the DCs in the other sites, they will all think the same thing about Miami.

        So who’s right? Of course, they all are. If the lack of replication goes beyond the AD Tombstone, then Miami would need to be demoted. Then again, you can’t even do that because it doesn’t have direct communications with its partner. Then if it does pick a DC in headquarters to demote, you will see an error stating that the headquarters DC already thinks the DC no longer exists. In the case of trying to demote it, or even forcedemoting it beyond the Tombstone, then your only option is to unplug it, run a metadata cleanup and re-promote it. But wait, then the same thing will occur if you don’t disable BASL.

        So is it right that we do the same thing over and over and expect different results? Nope. Let’s configure AD to make sure it will not happen again, by disabling BASL.

        Here’s a non-fully routed infrastructure. For the full-sized image, click here.

        Disable BASL

        Simply put, what we need to do is disable BASL (Bridge All Site Links) in a non-fully routed infrastructure to tell the KCC to only partner DCs across a specific site link.

        Yes, that means you also have to create specific IP site links between headquarters in NYC to each site, as the image above shows.

        And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, otherwise the KCC will partner with a DC that it may not have direct communications with.

        How to disable BASL. For the full-sized image, click here.


        If you want to make sure your AD infrastructure is properly purring along and doing its job, then by all means let’s design it properly, make the necessary modifications, and other changes, to get it going in the right direction.

        Oh, and you can’t forget to bone up on your DNS knowledge and how it supports AD. All Sites get registered in DNS by the netlogon service. Read more:

        How DNS Support for Active Directory Works

        And to understand the DNS SRV records registered by a DC’s Netlogon service, read Sean Dubey’s blog, with DNS SRV records examples, once again, I refer you to Sean Ivey’s blog:

        Sites Sites Everywhere…, By Sean Ivey, Microsoft DS PFE


        Designing the Site Topology

        Detailed branch office deployment guide (downloadable doc)

        Best Practice Active Directory Design for Managing Windows Networks

        You may want to take a look at the design IPD guide (Infrastructure Planning and Design) for AD – Download Details: IPD guide for Active Directory Domain Services – version 1.0

        Download the complete Infrastructure Planning and Design (IPD) Guide Series v2.0 including links for AD IPD, SCCM IPD, and more.

        Comments & Corrections are welcomed.

        Ace Fekay

        Nslookup suffixing behavior

        By Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
        Microsoft Certified Trainer
        Microsoft MVP: Directory Services
        Active Directory, Exchange and Windows Infrastructure Engineer

        Original compilation: 2/17/2013



        Many IT folks who are not familiar with nslookup’s suffixing behavior in some cases may believe it’s a DNS issue. Nope, it’s not a DNS issue, rather a combination of nslookup’s suffixing behavior, which DNS server nslookup is using, Forwarders if configured, and the operating system’s Search Suffixes.


        NSLOOKUP and requiring a trailing dot

        Keep in mind, nslookup’s resolver service has its own built-in resolver service and is totally *independent* of the operating system’s client side resolver algorithm, (although it will use the machine’s suffixes to devolve names), and will behave differently than if you were to say ping a host by single name.

        When using nslookup, you need to fully qualify the name (querying an FQDN), instead of a single name, then you must supply a trailing dot with the query.

        If not, it will append the current context, that is the suffix(es) configured on the machine, which it will suffix each one in the order they are configured.

        If you want to use a better tool for nameserver queries, I suggest to use DIG. DIG is downloadable as part of ISC’s BIND DNS server. You can  download BIND for free from Expand the files into a folder, and the tools will be available for use. No, this doesn’t mean you have to install the BIND DNS server service, I’m just suggesting to download and use the utilities in the folder. Matter of fact, BIND also has its own version of nslookup that some say works better than Microsoft’s nslookup, but I haven’t found that true. I’ve found DIG very beneficial when trying to troubleshoot DNS issues.

        Additional nslookup information

        Here are some links explaining nslookup’s behavior. The first one is a doc that explains more of this in greater detail. This doc actually was compiled from KB200525, the second link, which is also mentioned in the Microsoft Official Curriculum Course# 688, “Using TCP/IP,” Courseware.

        Using NSlookup (File Format: Microsoft Word) – “Nslookup will always devolve the name from the current context. If you fail to fully qualify a name query (that is, use trailing dot), the query will be …; “

        Using NSlookup.exe

        Using NSlookup – (Microsoft Word Doc)
        ”Nslookup will always devolve the name from the current context. If you fail to fully qualify a name query (that is, use trailing dot), the query will be … “

        Nslookup, Sep 28, 2007 … This applies when the set and the lookup request contain at least one period, but do not end with a trailing period. Nslookup /set srchlist …

        As the last link suggests, you can run nslookup with the /set srchlist, such as nslookup /set srchlist to set your own search lists that changes the default search suffix nslookup uses that it grabs from the operating system’s Search Suffixes. You can also set it in interactive mode by the following and leaving it blank to remove any search suffixes it’s pulling from the machine:

        > set srchlist


        Will removing the Primary DNS Suffix affect AD functionality?

        Yes and No. Yes if you remove the Primary DNS Suffix, which the default search list comes from and the machine uses in such cases as DirectSMB connectivity, among other things. And no, nslookup’s requirement of using a dot doesn’t affect or indicate any issues with AD, it’s just an nslookup thing.


        In summary:

        No, it’s not something that’s saying there is a DNS problem. To determine if you have a DNS problem, I suggest to use nslookup querying FQDNs with a trailing dot, or better, download and use DIG.

        Further, you will need to use the trailing dot (a period) unless you remove the search suffix. You can also remove the suffix from the machine, and it will work without a trailing dot. But the search suffix is derived from the Primary DNS Suffix, which is set by the domain it’s joined to. You can remove it in the registry and not touch the Primary DNS Suffix.

        You can also uncheck the computer’s client side resolver behavior, as shown in this screenshot (


        Additional links to read on this subject:

        Thread: “Weird NSLOOKUP results” 6/10/2010

        Windows Appending Domain Suffix To All Lookups

        Thread: “DNS server strange behavior” 2/9/2013

        It’s just something to keep in mind when using nslookup.

        I hope you find this info helpful.

        Ace Fekay

        Comments, corrections and suggestions are welcomed.