Remote Server Administration for Windows 2012 R2

Prologue

Ace here again. This discusses remote administration. Simple, right? Maybe not!

Remote Server Administration for Windows 2012 R2

Server Manager in Windows Server® 2012 R2 can be used to perform various management tasks on remote servers. By default, remote management is enabled on Windows Server 2012 R2.You can add remote servers to the Server Manager Server pool in Windows Server 2012 R2 Server Manager.

Objectives

Discuss the following remote admin methods

What is Remote Management?
How to Enable and Disable Remote Management
Remote Management and Tools Commands
Server Manager
WinRM
PowerShell Remoting
Remote Desktop
Remote Server Administration Tools (RSAT)
SCONFIG

What is Remote Management?

Windows Server 2012 R2 provides the ability to remotely manage multiple servers with a number of methods. One of the newest features in Windows Server 2012 is the ability to use Server Manager for this task.

In addition to Windows Remote Management, you can also use Remote Shell and Remote Windows PowerShell to manage remote computers. This provides you the ability to locally load Windows PowerShell modules, such as Server Manager, and execute PowerShell cmdlets available in the loaded module on remote servers. This allows you the ability to run PowerShell commands and scripts. This works including when the script is only on the local server

Windows Remote Management (WinRM) is the Windows implementation of WS-Management, which is an industry standard, Web-based services based protocol. Windows runs the WinRM as a service under the same name, WinRM. WinRM provides secure local and remote communications for management applications and scripts.

In addition, Windows Remote Management is one of the components of the Windows Hardware Management features to allow secure local and remote Windows Server management across a firewall using standard Web service-based protocols.

If the server hardware has an optional, built-in Baseboard Management Controller (BMC) provided by the hardware vendor, you can also remotely manage a system even if the Windows operating system has not yet booted or has failed. This also allows access to the server’s BIOS.

A BMC is an option m provided by hardware vendors, that consists of a microcontroller and an independent network connection that you can communicate to if the server ever becomes offline.

When a server is not connected to a BMC, WinRM can still be used to connect to WMI remotely in situations where firewalls may block DCOM communications, because WinRM uses the secure web-based port, TCP 443.

Additional Reading on WinRM:

About Windows Remote Management
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384291(v=vs.85).aspx

Hardware Management Introduction (includes BMC information)
http://technet.microsoft.com/en-us/library/f550cac0-5344-41cb-8e89-6e5c93236886

.

How to Enable and Disable Remote Management

There are a number of methods to administer WinRM.

· Winrm.cmd – Command line tool that allows administrators to configure WinRM, get data, or manage resources. For syntax, you can run winrm /? for online help.

· Win-RM Scripting API – Allows you to create remote administration scripts that expose the WS-Management APIs and protocols.

· Winrs.exe –A command line tool to execute CMD commands on remote servers using WS-Management APIs. For example, to remotely get an ipconfig /all from a remote machine, you can run:
winrs –r:DC12.trimagna.com “ipconfig /all”;tasklist

You can also use the help command to see all possible options and syntax:
winrs –?

· IPMI and WMI Providers – The IPMI provider and drivers allow remote hardware management using BMC. These can be used programmatically.

· WMI Service – Using the WMI plug-in, WMI runs together with WinRM to provide data or control functions for remote management.

· WS-Management protocol – SOAP based protocol using XML messages. It is a web-based, firewall friendly protocol running across secure TCP 443 providing industry-standard interoperability to transfer and exchange management information.

Remote Management Tools and Commands

There are a number of ways to enable, disable and configure Remote Management.

Server Manager

To enable or disable Remote Management, in Server Manager Local Server node, click the text next to Remote Management icon.

WinRM Command

You can use the WinRM command to enable, disable, and configure Remote Management.

The syntax is:

WinRM OPERATION RESOURCE_URI [-SWITCH:VALUR [-SWITCH:VAKLUE] …] [@{KEY=VALUR [;KEP=VALUE]…}]

You can use the following to check the current Remote Management configuration and status:
winrm get winrm/config

Or you can run it remotely on another server using the WinRS command:
winrs –r:DC12-1.trimagna.com “winrm /config”;tasklist

To enable or disable Remote Management:
WinMR qc

When the WinRM qc command is run, it performs a number of steps to enable and configure the Remote Management service:

Configures and changes the WinRM service from Manual to Automatic startup.
Starts the WinRM service.
Creates and configures a listener that will accept WinRM requests on any IP address.
Creates a Windows Firewall exception for WS-Management traffic for the HTTP protocol.

If the Windows Firewall is disabled, you will see one of the following error messages:

WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.
Error number: -2147023143 0x800706D9
There are no more endpoints available from the endpoint mapper.

To view the command syntax and options, you can run winrm -?

WinRM supports the following commands:

PUT
GET
ENUMERATION
INVOKE

WinRM Examples:

Start a service on a remote machine:
winrm invoke startservice wmicimv2/Win32_Service?name=w32time -r:DC12

Reboot a remote machine:
winrm invoke reboot wmicimv2/Win32_OperatingSystem -r:FS1

Additional Reading on the WinRM commands:

An Introduction to WinRM Basics – From the EPS Windows Server Performance Team
http://blogs.technet.com/b/askperf/archive/2010/09/24/an-introduction-to-winrm-basics.aspx

PowerShell Remoting

There a number of cmdlets that use WMI for remote administration. The cmdlets invoke a temporary connection the remote computer using WMI, runs the command, then closes the session.

These cmdlets do not use WS-Management based remoting, therefore the computer does not require to be configured for WS-Management nor does it have to meet the system requirement for WS-Management. Because they are not WS-Management service related, you can use the ComputerName parameter in any of these cmdlets

You can run the Invoke-Command cmdlets to run commands on other computers.

For example, to get a list of all services on a remote computer that are either running or stopped, you can run the following command
Invoke-Command –computername DC12 –scriptblock {get-service)

Or to see the status of a single service:
Invoke-Command –computername DC12 –scriptblock {get-service WinRm)

Additional Reading on Remote PowerShell:

Windows PowerShell Remoting – Complete list of commands
http://msdn.microsoft.com/en-us/library/windows/desktop/ee706585(v=vs.85).aspx

.

Remote Server Administration Tools (RSAT) for Windows

Remote Server Administration Tools for Windows® includes Server Manager, Microsoft Management Console (MMC) snap-ins, consoles, Windows PowerShell® cmdlets and providers, and some command-line tools for managing roles and features that run on Windows Server 2012 R2.

SCONFIG

For Server Core, you can use the SCONFIG command and choosing Option #4, then choosing Option #1 to Enable Remote Management, or Option #2 to Disable Remote Management.

Additional Reading on WinRM tools

About Windows Remote Management
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384291(v=vs.85).aspx

.

Remote Desktop

Remote Desktop has been used for a number of years, and it is the most common method to remotely administer a remote machine. To use Remote Desktop, it must be enabled first on the remote computer. To enable Remote Desktop on the full version of Windows Server 2012, perform the following steps”

Open Server Manager
Click the Local Server Node
Click the “Disabled” status next to Remote Desktop.
The System Properties page appears and is focused on the Remote tab.
Under the Remote tab, select one of the following:

Don’t allow connections to this computer – Default disabled.
Allow connections only from Computers running:

Checkbox: Allow Remote Desktop with Network Level Authentication – If you check this box, this setting enables and only allows secure connections from Remote Desktop clients that support network-level authentication.

You can also enable Remote Desktop on Sever Core using the SCONFIG command.

==================================================================

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

October 17, 2013April 16, 2014

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

Updated 4/16/2014

Preamble

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:

The Version number that is incremented on an attribute by the original writer
The originating time of the original writer
The originating DSA value, which is the GUID of the domain controller (found in ADSI Edit and in the _msdcs.contoso.com 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.

High-watermark

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.

Summary

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)
http://technet.microsoft.com/en-us/library/cc961798.aspx

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
http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#usn_and_usn_rollback

Detected USN Rollback

From: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)
http://technet.microsoft.com/en-us/library/hh831734.aspx

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
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2013/08/28/cases-where-vm-generationid-doesn-t-help-make-active-directory-virtualization-safe-part-1.aspx

Why Windows Server 2012 AD VM-Generation ID functionality is not an alias for Active Directory anti-USN Rollback functionality
http://blog.joeware.net/2013/02/20/2675/

Additional Reading:

Tracking Updates (USN & Active Directory Replication)
http://technet.microsoft.com/en-us/library/cc961798.aspx

Running Domain Controllers in Hyper-V
http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#usn_and_usn_rollback

How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2
http://support.microsoft.com/kb/875495

Steps for deploying a clone virtualized domain controller
http://technet.microsoft.com/en-us/library/hh831734.aspx#steps_deploy_vdc

Virtual Domain Controller Cloning in Windows Server 2012
http://blogs.technet.com/b/askpfeplat/archive/2012/10/01/virtual-domain-controller-cloning-in-windows-server-2012.aspx

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.

February 24, 2013December 13, 2013

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

Preface

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:

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.
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

Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
DNS server returns list of DC’s.
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).
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.
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:”

Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
Build a list of candidate sites — sites that have domain controllers for this domain.
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
http://blogs.technet.com/b/askds/archive/2011/04/29/sites-sites-everywhere.aspx

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.
http://support.microsoft.com/kb/109626

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):
   http://www.microsoft.com/en-us/download/details.aspx?id=30005
     Note: This tool requires .Net Framework 4. If it’s not installed, download and install it:
       Microsoft .NET Framework 4 (Web Installer)
       http://www.microsoft.com/en-us/download/details.aspx?id=17851

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.

Summary

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
http://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx

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
http://blogs.technet.com/b/askds/archive/2011/04/29/sites-sites-everywhere.aspx

References

Designing the Site Topology
http://technet.microsoft.com/en-us/library/cc787284(WS.10).aspx

Detailed branch office deployment guide (downloadable doc)
http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=en

Best Practice Active Directory Design for Managing Windows Networks
http://technet.microsoft.com/en-us/library/bb727085.aspx

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
http://www.microsoft.com/en-us/download/details.aspx?id=732

Download the complete Infrastructure Planning and Design (IPD) Guide Series v2.0 including links for AD IPD, SCCM IPD, and more.
http://technet.microsoft.com/en-us/library/cc196387.aspx

–

Comments & Corrections are welcomed.

Ace Fekay

November 28, 2012

AD Upgrade Checklist and Procedure

AD migration checklist and procedure:
Technet Thread: "Migrating from AD 2003 to AD 2008 R2:"
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/906266b9-62c9-462f-b16e-3b801c7e2fc3/

Here’s a quick summary from:
Transitioning your Active Directory to Windows Server 2008 R2
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2010/05/26/transitioning-your-active-directory-to-windows-server-2008-r2.aspx

ADPREP

Run adprep with the following switches.
If you are running it on a 32 bit machine, use the adprep32.exe version.

adprep /forestprep
adprep /domainprep /gpprep      Run after the foresprep and in each domain on the IM Role (enable Resultant Set of Policy (RSOP) Planning Mode functionality)
adprep /domainprep              Run after the forestprep and in each domain
adprep /rodcprep                Run on the DNM Role. Optional only if you expect to install an RODC.

You can also use the /wssg switch so you can get a detailed result code instead of a 0 for success, or 1 for an error.

Alllow replication time. Go get a cup of coffee, cold refreshment, or a beer.

Then check your schema version:

repadmin /showattr * "cn=schema,cn=configuration,dc=domain,dc=tld" /atts:objectVersion

Run it on all DCs. You can use PSEXEC – Microsoft Technet to remotely run it in a command prompt, or create a script.

When all your Domain Controllers report Schema version 47, you’re good to go. If not, check the event logs and the C:\Windows\Debug\Adprep\Logs\adprep.log.

More info if needed:
Troubleshooting ADPREP Errors
http://blogs.technet.com/b/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx

Then raise the Domain Functional Level.

This adds two features:
1. Authentication Mechanism Assurance – Type of authentication is added to the user’s Kerb ticket.
2. Automatic SPN Management – Allows the use of Managed Service Accounts (MSAs) instead of Domain User accounts to run a service under.
Allow a bit of time to replicate. Go get a cup of coffee, a beer, whatever.

Then raise the Forest Functional Level.

This basically adds one thing:
1. The ability to enable the new Active Directory Recycle Bin feature.

If you want to enable it, go to Start, Programs AD Powershell, then run:
Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=domain,DC=tld’ -Scope ForestOrConfigurationSet -Target ‘domain.local’

Allow replication time, too. Go get another beer.

Run the AD BPA

1. Server Manager, expand the Roles node
2. Select the Active Directory Domain Services role.
3. Scroll down to the Best Practice Analyzer section.
4. Click on the Scan This Role link on the right hand side.

Windows Server 2008 R2 Upgrade Paths
http://technet.microsoft.com/en-us/library/dd979563(WS.10).aspx

How to upgrade Windows Server 2003 R2 to Windows Server 2008 on a computer that includes a Baseboard Management Controller and a root-enumerated IPMI device
http://support.microsoft.com/kb/953224

Ace Fekay

Corrections, suggestions, & comments are welcomed

November 28, 2012November 28, 2012

Install a Replica DC with DNS AD Integrated Zones

This blog provides an overview to add an additional replica DC in the same domain. This assumes the operating system versions are the same and you are not upgrading to a newer operating system version or upgrading Active Directory.

If you are upgrading your AD domain, please see this:
Install a replica DC with DNS AD Integrated Zones

If you have multiple sites, read this article:
Best Practices for Adding Domain Controllers in Remote Sites:
http://technet2.microsoft.com/windowsserver/en/library/6405bc5f-b8bf-449e-b11a-f116d22f858a1033.mspx?mfr=true

Here’s a good article on promoting a machine to a DC and other factors:
How do I install Active Directory on my Windows Server 2003 server?:
http://www.petri.co.il/how_to_install_active_directory_on_windows_2003.htm

IF you have not done so, then install DNS. For assistance, read this article:
How To Install and Configure DNS Server in Windows Server 2003:
http://support.microsoft.com/kb/814591

Assuming the current zone is AD integrated, DO NOTHING ELSE.
Do NOT create it manually or you will cause numerous problems and headaches.
Sit there and wait. Go to lunch. Upon return, you will find the zone has
automatically populated. Because AD integrated zones are in the actual AD
database, it will automatically replicate to the new machine by the default
AD replication process. There is really nothing else to configure on this
part, that is assuming the zone is already AD integrated. Is it AD
integrated? If so, what scope is it set to on both machines?

More information on DNS AD Integrated Replication Scopes:
http://technet2.microsoft.com/windowsserver/en/library/6c0515cf-1719-4bf4-a3c0-7e3514cef6581033.mspx?mfr=true

More detailed information on how to change AD Integrated DNS zone replication Scopes:
http://technet2.microsoft.com/windowsserver/en/library/e9defcdc-f4e5-43cd-9147-104f9b9d015a1033.mspx?mfr=true

If there is a problem where you cannot change the scope, read this:
You cannot change the replication scope of an Active Directory integrated DNS zone in Windows Server 2003
http://support.microsoft.com/kb/842560

Change the ip properties of this DC to use one of the other DCs as the first
entry, the second as itself. That;s it for this part. I fnot sure how,
follow this article:
825036 – Best practices for DNS client settings in Windows 2000 Server and
in Windows Server 2003
http://support.microsoft.com/?id=825036

Go into DNS properties, configure a Forwarder to your ISP’s DNS. If not sure
how, this article will show you:
Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2 (Includes info on how to create a forwarder)
http://technet.microsoft.com/en-us/library/cc754941.aspx

HOW TO Configure DNS for Internet Access in Windows Server 2003 (forwarding) :
http://support.microsoft.com/?id=323380

Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2 (Includes info on how to create a forwarder)
http://technet.microsoft.com/en-us/library/cc754941.aspx

WINS

If you have a multi-segmented infrastructure (remote locations), install WINS.
This is done in Add/Remove, Windows Components, Network Services, click on WINS.
For assistance, read these article:

WINS – What Is It, How To Install It, WINS Replication Partner Design Guidelines, How to Configure DHCP Scopes For WINS Client Distribution, and more:
http://msmvps.com/blogs/acefekay/archive/2010/10/27/wins-what-is-it-how-to-install-it-and-how-to-configure-dhcp-scopes-for-wins-client-distribution.aspx

How To Install a WINS server:
http://technet2.microsoft.com/windowsserver/en/library/e4d3c3d8-a846-49b9-aac6-e04f2907aac51033.mspx

If using Windows 2003, when you install WINS, make sure you are using an SP2 integrated i386 source. With Windows 2008 and newer, it’s not necessary. The following will assist with Windows 2003:
How to slipstream SP2 into the i386 folder (good for XP, 2000 and 2003):
http://www.theeldergeek.com/slipstreamed_xpsp2_cd.htm

On the WINS server itself, go to IP properties, Advanced, WINS tab, ONLY point the WINS
address of itself to itself ONLY. Do not add any other WINS addresses. For assistance, see this article:
WINS Best Practices (Use ONLY itself in ip properties):
http://technet2.microsoft.com/windowsserver/en/library/ed9beba0-f998-47d2-8137-a2fc52886ed71033.mspx

This assumes you will be configuring RRAS properties to get client IPs from Windows DHCP and not a manual range or from your firewall/perimeter router (such as your Comcast, Linksys, etc., router).

Once that is done, in DHCP, change the WINS address to the new server in DHCP Option 046. Make sure you have DHCP Option 044 set to 0x8.

•DHCP Option 044: IpAddressOfYourWINSserver
•DHCP Option 046: 0x8

If not sure how to do the above, please read this article:
DHCP Options Not Set by SBS Setup (this is good for SBS and WIndows Server 2003, 2008, 2000, etc):
http://support.microsoft.com/kb/218636

FSMO roles

If you say the other DCs are that unreliable, transfer all the FSMO roles to
this new server.If not sure how, follow this article:
How to view and transfer FSMO roles in Windows Server 2003
http://support.microsoft.com/kb/324801

If you are not sure which server to set a FSMO role, read this:
FSMO placement and optimization on Active Directory domain controllers:
http://support.microsoft.com/kb/223346

Make this DC a GC. If you need assistance: follow this article:
http://technet2.microsoft.com/windowsserver/en/library/93ffc6d8-e4c9-4a5b-8b4c-7d426bcba5a11033.mspx?mfr=true

Matter of fact, make all DCs a GC. More on this:

Global Catalog and FSMO Infrastructure Master Relationship
Published by Ace Fekay, MCT, MVP DS on Oct 1, 2010 at 1:05 PM
http://msmvps.com/blogs/acefekay/archive/2010/10/01/global-catalog-and-fsmo-infrastructure-master-relationship.aspx

Phantoms, tombstones and the infrastructure master.
The GC role will conflict with a global catalog in a multi-domain forest. To overcome this conflict, all DCs are recommended to be GCs.
http://support.microsoft.com/kb/248047

Global Catalog vs. Infrastructure Master
"If a single domain forest, you can have all DCs a GC. If multiple domains, it is recommended for a GC to not be on the FSMO IM Role, unless you make all DCs GCs"
This is the recommendations by AD Microsoft engineers, AD MVPs, and other engineers.
http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/03/08/37975.aspx

Ace Fekay

Suggestions, comments, corrections, etc, are all welcomed.

September 2, 2009September 2, 2014

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

Revisions:

Original publication 3/2006
Recompiled 6/10/2010
Updated 12/9/2010
Updated 8/31/2014
—

Prologue

Ace here again. I’m cleaning up my blogs for technical and syntax errors. If you see anything that needs correction, please let me know.

Preface and Scope Of this Article

This blog explains how to use ADSI Edit to determine if duplicate zones exists in the AD database and to delete them.

When using ADSI Edit, the duplicate zones show up in the partitions with names that are prefixed with an “In Progress….” or “CNF…” and suffixed with a long GUID number. You will be checking EACH DC. When you find them, you will simply delete them. because they are useless and cause substantial problems.

This blog also explains how duplicate zones will appear to make zone records disappear.

Introduction to Duplicate Zones

Duplicate zones can cause numerous issues for the mere fact that the DNS zone that DNS is showing you on a specific DC may not have the latest up to date data. It literally may be missing data that you see on other DCs. If there are duplicate or conflicting zones, the zone data can’t replicate, resulting in each DC may have a different copy of the zone, which then results in unreliability and AD issues.

And to further complicate it, there are three different storage locations that AD can store AD integrated DNS zones – DomainDnsZones, ForestDnsZones, and the DomainNC partitions. You can read more on specifics in one of my other blogs:

DNS Zone Types Explained, Storage Locations in the AD database, and their Significance in Active Directory.
https://blogs.msmvps.com/acefekay/2013/04/30/dns-zone-types-explained-and-their-significance-in-active-directory/

Symptoms?

You may have a duplicate zone or a conflicting zone if a zone exists in both the Domain NC and/or in one of the Application Partitions. Some of the symptoms include:

Trying to change the replication scope, you receive an unusual error message stating, “The name limit for the local computer network adapter card was exceeded.”

Event ID 4515
An admin may see the data on a different DC is not there and will manually create records.
Zone data is disappearing, or it appears to be. This can be caused by:

Someone is intentionally or unintentionally deleting the data (usually unlikely but can occur). If you think someone is deleting zone data, enable auditing.
DNS Records Disappearing and DNS Auditing
http://msmvps.com/blogs/acefekay/archive/2010/12/09/dns-records-disappearing-and-dns-auditing.aspx

The data on each DC is different, and you are wondering why replication isn’t brining the zone data up to date, but it won’t because replication will either not occur or won’t occur if AD sees a duplicate.

Causes?

You’ve installed DNS on another DC and you don’t see the zone under DNS that is on the other DCs, so you manually created the AD zone because you didn’t have the patience to wait for replication to occur, which it would have automatically populated.
You’ve promoted a new DC in another site and didn’t have the patience to wait for the zone data to replicate.
Antivirus not configured to exclude AD communications (common cause).
At one time, or currently, the AD environment is a mixed Windows 2000/2003/2008 environment and DNS is installed on all operating system versions. On Windows 2000, if the zone is AD Integrated, it is in the DomainNC partition of the AD database, and should be set the same in Windows 2003’s or newer DC/DNS server to keep the zone data compatible and allow both operating system versions to be able to read and use them.
Someone must have attempted to change it in Windows 2003 or 2008 DNS to place the zone in the DomainDnsZones partition no realizing the implications, hence the duplicate. In a scenario such as this where you want to use the Windows 2003 application partitions, you then must insure the zone on the Windows 2003 is set to the DomainNC, then uninstall DNS off the Win2000 machine, then once that’s done and AD replication has been given time to occur, you can go to the Windows 2003 or newer DNS and change the partition’s replication scope to one of the application partitions.
A new domain controller was promoted into the domain, and the administrator manually created the zone name in DNS. This causes a duplicate. The proper way was to simply install DNS, and allow AD replication to occur. The zone will auto-populate into DNS.

I usually don’t want to assume someone’s deleting data. That’s would be the far end of the spectrum, especially if more than one DC is showing inconsistent zone data.

I feel the best approach to find out which is occurring is to first find out if there is a duplicate zone. This is because auditing is time consuming, and you need to parse through all the events generated in the Event Security Logs. It’s easier to run ADSI Edit to find if there are duplicates. Once you’ve determined it’s not a duplicate zone issue, then you can move on to DNS auditing. If it is a duplicate zone issue, follow the procedure below to remove them.

AD Integrated Zones Storage Locations

First, a quick review on the partitions. Hopefully you’ve taken a few moments to read my blog link that I posted above to understand the partitions. If not, I’ll just touch base on it here so you understand it and can relate to it. For specifics and the nitty gritty, read my other blog above.

Windows 2000:

the physical AD database is broken up into 3 logical partitions, the DomainNC (Domain Name Context, or some call the Domain Name Container), the Configuration Partition, and the Schema Partition. The Schema and Configuration partitions replicate to all DCs in a forest.

The DomainNC is specific only to the domain the DC belongs to. That’s where a user, domain local or global group is stored. The DomainNC only replicates to the DCs of that specific domain.

When you create an AD Integrated zone in Windows 2000, it gets stored in the DomainNC. This causes a limitation if you want this zone to be available on a DC/DNS server that belongs to a different domain. The only way to get around that is for a little creative designing using either delegation, or secondary zones. This was a challenge for the _msdcs.contoso.com zone, which must be available forest wide to resolve the forest root domain, which contains the Schema and Domain Name Masters FSMO roles.

Windows 2003 and newer:

There were two additional storage locations added to the AD database for DNS storage use. These areas are called “partitions,” specifically the DomainDnsZones and ForestDnsZones Application Partitions, specifically to store DNS data. They were conceived to overcome the limitation of Windows 2000’s AD Integrated zones. Now you can store an AD Integrated zone in either of these new partitions instead of the DomainNC. If stored in the DomainDnsZones app partition, it is available only in that domain’s DomainDnsZones partition. If you store it in the ForestDnsZones app partition, it will be available to any DC/DNS server in the whole forest. This opens many more design options. It also ensures the availability of the _msdcs.contoso.com zone to all DCs in the forest. By default in Windows 2003, the _msdcs.contoso.com zone is stored in the ForestDnsZones application partition.

Selecting the Replication Scope in Windows 2003 and newer:

When selecting a zone replication scope in Win2003, in the zone’s properties, click on the “Change” button. Under that you will see 3 options:

“To all DNS servers in the AD forest example.com” The top button. This option puts the zone is in the ForestDnsZones Application Partition. This setting will allow the zone data to replicate to all domain controllers to every domain in the forest, including if additional Trees exist in the forest.
“To all DNS servers in the AD domain example.com” The middle button. This option means the zone is in the DomainDnsZones Application Partition. This setting allows the zone to be stored and replicated in the DomainDnsZones Application Partition in the specific domain that it exists in. This setting is not compatible with Windows 2000 domain controllers. If Windows 2000 domain controllers exist in the domain, then the bottom option (below) will need to be used.
“To all domain controllers in the AD domain example.com” The bottom button. This option means the zone is in the DomainNC (Domain Name Context) portion of the actual AD database. This is only for Windows 2000 compatibility, that is if you have any Windows 2000 domain controllers in that specific domain you are administering.

If you receive an Event ID 4015 or the following error, it may indicate there is a duplicate or conflicting zone that exists in the DomainNC, the DomainDnsZones Application partition and/or in the ForestDnsZones partition.

DNS Duplicate zone - Scope Replication error - The Replication scope could not be set- The name limit for the local computer network adapter was exceeded.

*

Non-AD Integrated Primary and Secondary Zones

A Primary or Secondary zone that is not stored in AD is stored in a text file in the system32\dns folder. This type of zone storage has nothing to do with the above types ONLY unless it is truly a secondary with the Master being a DC transferring a copy of the zone. This types of zone storage is obviously not secure.

Now **IF** you did manually create a zone (whether intentionally or unknowingly) on one DC while it already existed on another DC, then you may have a duplicate.

Duplicate zone names will start with the letters, “CNF…” or “InProgress…”

If there is a duplicate, you can use either ntdsutil or ADSI Edit to take a look. I will outline in this article on how to use ADSI Edit to look for the duplicate.

A duplicate zone name will appear in ADSI Edit that starts with an “In Progress….” or “CNF…” with a long GUID number after it.

The “CNF…” means it’s in conflict due to a duplicate in the AD database.
The “In Progress….” means it is trying to replicate, but it can’t because there’s another identical zone name but with a different USN version number (USNs are used for replication control between DCs) on another domain controller, which also means there’s a duplicate zone.

You can simply delete them, which will clean up the whole problem. Yep, a simple deletion. The “CNF” data is not used by AD, but yet it will conflict with the zone that is actually used, and needs to be deleted.

But before doing anything about it just yet, let’s read on to explain more about this and what may have caused it.

Preventing Duplicate Zones

AD Integrated Zones will auto-populate when adding replica domain controllers

If an AD integrated zone exists on a DC, and the DNS service is install DNS on another DC in the domain or forest, depending on the replication scope, it will automatically appear on the new DNS installation without any interaction on your part. You may have to wait a certain period of time for it to populate depending on if the other DC is in the same AD Site or not, but it WILL AUTO-POPULATE.

However, if you attempted to manually create the zone, believing that you need to do this to make the zone available on that DC, then you’ve just introduced a duplicate zone in the AD database. It doesn’t matter if the zone say originally exists in the DomainNC, and you manually create the zone on the other DC and put it into the DomainDnsZones application partition, AD will still recognize it in the AD database.

Duplicate zones cause numerous AD communication and access problems.

The point is, AD is smarter than you think. Let it do it’s thing.

An Example of what an AD Duplicate Zones looks like in ADSI Edit

This image shows “In Progress…” entries. They need to be deleted.

Using ADSI Edit to look at your AD Partitions

This is a manual step by step. For a screenshot step by step, see the next section.

This section assumes you have a little familiarity withe ADSI Edit. If not, I suggest to get yourself familiar with it once you’ve connected into the various partitions as outlined below. Be careful deleting anything, for once deleted, it’s a destructive process and basically it’s gone. There is no “Back Button” or “Undelete,” or “Undo” button. To restore data, you will need to run an Authoritative Restore from your backup program restoring that specific object that was deleted.

Determine if there are any duplicate zone.

While in ADSI Edit, if you see the same exact named zone in multiple partitions, such as seeing the same zone name in the Domain NC (Name Container) Partition, in the DomainDnsZones App partition), and/or in the ForestDnsZones application partition, you have duplicate zones. If this is the case, then you must choose which zone you want to keep.

I will select a DC that isn’t having a problem and delete the duplicates and conflicts off all other DCs.

Multiple domains or multiple tree forest?

If the AD forest is a multidomain forest with child domains and/or multiple trees, you must look at each domain’s DomainNC and DomainDnsZones partition, because each domain has one.

To view the DomainNC Partition (Default Naming Context)

In ADSI Edit, rt-click ADSI Edit, choose “Connect To,” in the Connection Point click on “Well known Naming Context”, then in the drop-down box, select “Domain”. If this is Windows 2003 or newer, this option shows up as “Default Naming Context”
Expand DomainNC or Default Naming Context, then expand your domain name. Drill down to CN=System. Under that you will see CN=MicrosoftDNS.
You will see any zones that are in the DomainNC partition under the MicrosoftDNS folder.
If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

To view the ForestDnsZones Application Partition:

[ForestDNSZones]

Click Start, click Run, type adsiedit.msc, and then click OK.
In the console tree, right-click ADSI Edit, and then click “Connect To.”
Click Select or type a Distinguished Name or Naming Context, type the following text in the list, and then click OK:
DC=ForestDNSZones, DC=contoso, DC=com
In the console tree, double-click DC=ForestDNSZones, DC=contoso, DC=com.
Double-click CN=MicrosoftDNS, and click the zone (contoso.com).
You should now be able to view the DNS records which exist in this DNS partition.

If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

To view the DomainDnsZones Application Partition

[DomainDNSZones]

Click Start, click Run, type adsiedit.msc, and then click OK.
In the console tree, right-click ADSI Edit, and then click “Connect To.”
Click Select or type a Distinguished Name or Naming Context, type the following text in the list, and then click OK: DC=DomainDNSZones,DC=contoso,DC=com.
In the console tree, double-click DC=DomainDNSZones,DC=contoso,DC=com
Double-click CN=MicrosoftDNS, and click the zone (contoso.com).
You should now be able to view the DNS records which exist in this DNS partition.

If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

Procedure with Screenshots:

Procedure to Delete the Duplicate zones

The easiest is to simply delete any duplicates you find in ADSI Edit. Choice #1, to delete them, can actually be safely done during production. Matter of fact, things may just start to work after you delete them! But Choice #2, which is a lengthy procedure, must be done during non-production hours.

Choice #1 (Recommended)

Just go into ADSI Edit and delete the duplicate zones you’ve found.

You can do this during production, and frankly, I’ve done it with a large infrastructure during production hours without any problems. This is my personal choice as long as there are no true duplicate zones, that is if there are duplicate zones without seeing any zone names prefixed with either an “In Progress….” or “CNF…” with a long GUID number after, and you truly see a duplicate of your actual zone, such as a domain.com in any of the partitions, then you must perform Choice #2.

Choice #2 (Not recommended)

This is a multi-step process to first change the zone to a Standard Primary Zone, which removes it from the AD database, allow AD replication to complete, delete the duplicates, then change the zone to AD integrated, and allow AD replication to complete.

Choose only one DC to perform this action.
- For example, if the duplicate is in the DomainDnsZones partition or DomainNC partition of a child domain, perform it only on a DC in that domain.
- If the Duplicate is in the ForestDnsZones partition, you can choose any DC in the forest.
Right-click the zone name, Choose Properties.
Under the General tab, click on the “Change” button next to the “Type” section.
Then uncheck the box that says “Store the zone in Active Directory (available only if the DNS servers is a domain controller.”
Click Ok, Don’t click Ok again just yet. Just click on Apply.
IMPORTANT – You must allow AD replication to occur to replicate the change to all DCs that are in the replication scope of the zone. If you have DCs in another AD Site and have replication schedule set for example, to 3 hours, then you must WAIT for 3 hours.
This action makes the zone a Standard Primary zone. This means it is now stored in the system32\dns\ZoneName.com.dns text file and is no longer in the AD database.
You can also force replication, as well. If there are AD Sites configured, and the replication schedule on the Site Connection objects is say 3 hours, you can reduce the replication schedule on the Site Connection objects to the minimal time allowed, which is 15 minutes. Then force replication by choosing the partner DC’s NTDS Setting, right –click, and choose Replicate Now.
Once confirmed that replication has occurred, and refreshing the ADSI Edit window and seeing the zones no longer exist in any of the partitions, then you can now safely delete the duplicate zones.

Note: Just to be clear, you will be deleting any zone names that you find that are prefixed with an “In Progress….” or “CNF…” and suffixed with a long GUID number after it.
Also Note: Deleting a zone is a destructive operation. Make sure you are only deleting duplicates!

Click Start, point to All Programs, point to Administrative Tools, and then click DNS.

In the console tree, right-click contoso.com, point to All Tasks, and then click Restart.

Change the zone back to AD Integrated into the Replication Scope it’s supposed to be in.

Once the duplicates have been deleted, once again, you MUST allow AD replication to occur. If you had changed the Replication Schedule on the Site Connection objects to quicken AD replication, you will want to reset them to their original setting.

References

DNS zone replication in Active Directory
http://technet.microsoft.com/en-us/library/cc779655(WS.10).aspx

Oops, our AD Integrated DNS zone’s are missing in Windows 2003!
http://blogs.technet.com/b/networking/archive/2007/05/10/oops-our-ad-integrated-dns-zone-s-are-missing-in-windows-2003.aspx

Directory Partitions:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbg_dat_favt.asp

kbAlertz- (867464) – Explains how to use ADSI Edit to resolve app partitions issues:
http://www.kbalertz.com/kb_867464.aspx

Event ID 4515 is logged in the DNS Server log in Windows Server 2003
http://support.microsoft.com/kb/867464

Summary

It seems like a lot of steps, but it really isn’t. Just read it over a few times to get familiar with the procedure. You may even want to change it into a numbered step by step list if you like. If you only have one DC, and one Site, then it’s much easier since you don’t have to mess with secondary zones or play with the site objects.

I hope that helps!

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 and Videos: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

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

Suggestions, Comments and Corrections are Welcomed!