Multihomed DCs with DNS, RRAS, and/or PPPoE adapters

Multihomed DCs with DNS, RRAS, and/or PPPoE adapters

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

Published 4/2009
First compiled January, 2003
Updated July, 2006
Updated 5/2010 with a new Step #10
Updated 10/14/2010 adding a new section about AD communications across a NAT
Updated 1/22/2011 – Added about NIC teaming NOT supported by Microsoft. Better to disable the additional NIC then use teaming.


What is a Multihomed DC?

A Multihomed DC is a domain controller with more than one NIC and/or IP address, and/or RRAS installed on it (for VPN, routing, dialup, etc), or with a PPPoE adapter from your ISP’s ADSL line.

Multihomed DCs wiill cause numerous issues. The only exception to the rule are SBS servers, but that is a completely different topic which I will not address in this blog, but I can add that even the SBS gurus recommend to single-home it.

It’s highly recommended to single-home all DCs and use a non-DC for multihoming purposes. If it’s the internet gateway, such as using the DC as a NAT device, not only will the multihomed DC cause AD problems, but you’re also exposing the DC directly on the internet. To overcome both of these issues, I recommend disabling the outer NIC and purchasing an inexpensive cable/DSL firewall/router or other type of firewall/NAT device for this purpose. My preference is a Cisco ASA device. There are also less expensive options, such as a Linksys wireless N router for less than USD $150, and there are less expensive models under it. If the hardware device is compromised by an internet attacker remotely, it can’t further compromise the rest of the internal network, nor your DC.

If you have a PPPoE adapter installed (such as the WinPoet software from Verizon for ADSL lines), it will cause the same problems, for after all, they are additional interfaces.


Internet Connection Services (ICS) on a DC

If attempting to use Internet Connection Serivices (ICS) on a DC, this further complicates matters with DC functionality, because ICS has it’s own built-in DNS and DHCP service that is non-configurable, and cannot be fixed with the following steps outlined in this article. I suggest disabling it.


AD’s reliance on DNS

To explain why multhoming a DC causes problems will require a little background on AD and DNS.

You can’t use your ISP’s DNS in your DC and workstation NIC properties

Let’s put this into layman’s terms: Let’s say the NFL SUperbowl is tomorrow, and I invited a few friends over. I went out and bought two cases of beer for the game. I put them into the refridgerator. So I know those cases are in the rerfidgerator before I went to bed. I wake up to find half the case is gone. No one else was in the house last night. I walk out front and see my neighbor washing his car. I yell over to him, “Hey, do you know where my beer went that I had in my refridgerator?” He responds that he has no idea. Nor that I would expect him to know. THis is the same as if I used Comcast’s or some other ISP’s DNS address in my DC or my workstations. When the workstation or DC needs AD communications and functionality, it will be asking the Comast DNS servers, “Hey, what is the IP address of my domain controller?” Will it have that answer? No, it won’t.

To understand the specifics behind AD’s reliance on DNS, please read the following article:

Active Directory’s Reliance on DNS, and using an ISP’s DNS address:

Also, you can’t mix an external DNS address with your internal address. THis is due to the way the client side resolver service works. You need to only use your own internal DNS address. For efficient internet name resolution, you can configure a Forwarder to your ISP’s DNS server. That’s done in DNS properties, Forwarders tab. To understand this process, please read the following article:

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.

Bascially, AD required DNS

Basically, AD requires DNS. DNS stores AD’s resource and service locations in the form of SRV records, hence how everything that is part of the domain will find resources in the domain. If the ISP’s DNS is configured in the any of the internal AD member machines’ IP properties, (including all client machines and DCs), the machines will be asking the ISP’s DNS ‘where is the domain controller for my domain?”, whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP’s DNS does not have that info and they reply with an “I dunno know”, and things just fail. Unfortunately, the ISP’s (or your router as a DNS server) DNS doesn’t have information or records about your internal private AD domain, and they shouldn’t have that sort of information.

Also, AD registers certain records in DNS in the form of SRV records that signify AD’s resource and service locations. When there are multiple NICs, each NIC registers. IF a client, or another DC queries DNS for this DC, it may get the wrong record. One factor controlling this is Round Robin. If a DC or client on another subnet that the DC is not configured on queries for it, Round Robin will kick in offering one or the other. If the wrong one gets offered, it may not have a route to it. On the other hand, Subnetmask Priortization will ensure a querying client will get an IP that corresponds to the subnet it’s on, which will work.

AD’s reliance on DNS MUST BE FULLY understood to understand why multihoming causes problems. Once again, to understand the specifics behind AD’s reliance on DNS, please read the following article:

Active Directory’s Reliance on DNS, and using an ISP’s DNS address:

After reading the above article. you should now understand and realize that if you are using your ISP’s DNS addresses, some other external DNS address that doesn’t host the internal AD zone, or using your router as a DNS address in your IP configuration (DCs or workstations), they must be removed. If these external DNS addresses are used, it’s guaranteed to cause additional problems. If not sure what I mean that you can’t use a DNS server other than your internal DNS servers, please re-read the above article.


 Errors caused by using a DNS address that does not host the AD zone

I usually see errors (GPOs not working, can’t find the domain, RPC issues, replication taking a nose dive, dcdiag and replmon errors, etc), when the ISP’s or some other non-internal DNS servers are listed on a client, DCs and/or member servers, or with multihomed DCs. If you have an ISP’s (or some other outside DNS server or even using your router as a DNS server) DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). Otherwise, expect problems. Surprisingly I’ve heard of some customers say, “I’ve been using it for years this way and have never had problems.” Consider yourself lucky.


If you have multiple IPs on one NIC, you can control which gets registered into DNS

You can control the default DNS registration process of registering multiple IPs that have been configured on a single NIC. If this is the scenario, then you won’t need to follow the procedure later in this blog. However, if you have multiple NICs, this does not work.

“All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2”


To insure everything works, stick with one NIC

Since this DC is multi-homed, it requires additional configuration to prevent the public interface addresses from being registered in DNS. This creates a problem for internal clients locating AD to authenticate and find other services and resources such as the Global Catalog, file sharing  and the SYSVOL DFS share and can cause GPO errors with Userenv 1000 events to be logged, authenticating to shares and printers, logging on takes forever, among numerous other issues.

But if you like, there are some registry changes to eliminate the registration of the external NIC or simply use the internal networking routing to allow access.

Another problem is the DC now becomes part of two Sites. This is another issue that can be problematic.

But believe me, it’s much easier to just get a separate NAT device or multihome a non-DC then having to alter the DC. If the both NICs are internal, I would suggest to pick a subnet, team the NICs and allow your internal routers handle the traffic between subnets – Good luck!


NIC Teaming on a Domain Controller – Not recommended nor Supported by Microsoft!

Although teaming sounds like a good idea to eliminate a multihomed scenario for such cases where both NICs are on the same segment and you have the NIC vendor software installed that offers teaming, but I must point out that teaming NICs on DCs, or any other servers, is not recommended, nor is it supported by Microsoft:

Teamed network cards for domain controllers? (Thread Answered by a great write-up by Jared Crandall, former Microsoft Support Engineer)

Using teaming adapters with network load balancing may cause network problems

however did you know Nic teaming NICs on a DC, or any other Windows box is not a good idea,



The following are the manual steps to configure a Multihomed DC

1. Insure that all the NICS only point to your internal DNS server(s) only and none others, such as your ISP’s DNS servers’ IP addresses.

2. In Network & Dialup properties, Advanced Menu item, Advanced Settings, move the internal NIC (the network that AD is on) to the top of the binding order (top of the list).

3. Disable the ability for the outer NIC to register. The procedure, as mentioned, involves identifying the outer NIC’s GUID number. The following link will show you how:

246804 – How to Enable-Disable Windows 2000 Dynamic DNS Registrations (per NIC too):

4. Disable NetBIOS on the outside NIC. That is performed by choosing to disable NetBIOS in IP Properties, Advanced, and you will find that under the “WINS” tab.
You may want to look at step #3 in the following article to show you how to disable NetBIOS on the RRAS interfaces if this is a RRAS server.

Chapter 11 – NetBIOS over TCP/IP

Or enable/disable NetBIOS on an interface in the registry:

To do it in the registry  but you will need to identify the GUID of that interface – (this may not apply to PPP interfaces)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters\Interfaces, find the GUID(s) with NetbiosOptions set to 0 and set them to 2.

Using WMIC:

First, get the list of interfaces:
wmic nicconfig get caption,index,TcpipNetbiosOptions

Then use the “index number” in the next command:
wmic nicconfig where index=1 call SetTcpipNetbios 2

SetTcpopNetbios options are:

0 – Use NetBIOS setting from the DHCP server
1 – Enable NetBIOS over TCP/IP
2 – Disable NetBIOS over TCP/IP

More info on the wmic commands and the registry entries can be found in this forum thread link:

Thread – Configuring NetBIOS over TCP/IP

Configure TCP/IP to use WINS  

A standard Windows service, called the “Browser service”, provides the list of machines, workgroup and domain names that you see in “My Network Places” (or the legacy term “Network Neighborhood”). The Browser service relies on the NetBIOS service. One major requirement of NetBIOS service is a machine can only have one name to one IP address. It’s sort of a fingerprint. You can’t have two brothers named Darrell. A multihomed machine will cause duplicate name errors on itself because Windows sees itself with the same name in the Browse List (My Network Places), but with different IPs. You can only have one, hence the error generated.

5. Disable the “File and Print Service” and disable the “MS Client Service” on the outer NIC. That is done in NIC properties by unchecking the respective service under the general properties page. If you need these services on the outside NIC (which is unlikely), which allow other machines to connect to your machine for accessing resource on your machine (shared folders, printers, etc.), then you will probably need to keep them enabled.

6. Uncheck “Register this connection” under IP properties, Advanced settings, “DNS” tab. 

7. Delete the outer NIC IP address, disable Netlogon registration, and manually create the required records

      a. In DNS under the zone name, (your DNS domain name), delete the outer NIC’s IP references for the “LdapIpAddress”. 

      b. If this is a GC, you will need to delete the GC IP record as well (the “GcIpAddress”). To do that, in the DNS console, under the zone name, you will see the _msdcs folder. Under the _msdcs folder, you will see the _gc folder. To the right, you will see the IP address referencing the GC address. That is called the GcIpAddress. Delete the IP addresses referencing the outer NIC.

            1. To stop these two records from registering that information, use the steps provided in the links below:

                Private Network Interfaces on a Domain Controller Are Registered in DNS

             2.. The one section of the article that disables these records is done with this registry entry:

                   (Create this Multi-String Value under it):
                    Registry value: DnsAvoidRegisterRecords
                    Data type: REG_MULTI_SZ
                    Values: LdapIpAddress

                     The following link provides more information on the LdapIpAddress and GcIpAddress, as well as other Netlogon Service records:

                      Restrict the DNS SRV resource records updated by the Netlogon service[includingGC]:

                3. Then you will need to manually create GcIpAddress and IpAddress records in DNS with the IP addresses that you need for the DC. To create the LdapIpAddress, manually create a new host under the domain, but leave the “hostname” field blank, and provide the internal IP of the DC, which results in a record that  looks like:
(same as parent) A              ( is used for this example)

                 4. You need to also manually create the GcIpAddress as well, if this is a GC. That would be under the _msdcs._gc SRV record under the zone. It is created in the same fashion as the LdapIpAddress mentioned above.

8. In the DNS console, right click the server name, choose properties, then under the “Interfaces” tab, force it only to listen to the internal NIC’s IP address, and not the IP address of the outer NIC.

9. Since this is also a DNS server, the IPs from all NICs will register, even if you tell it not to in the NIC properties. See this to show you how to stop that behavior (this procedure is for Windows 2000, but will also work for Windows 2003):

275554 – The Host’s A Record Is Registered in DNS After You Choose Not to Register the Connection’s Address:  

10. Disable the round robin functionality on the DNS server. To do so: (This step added 5/2010)
                    1. Click Start, click Settings, click Administrative Tools, and then click DNS.
                    2. Open the properties for the DNS server’s name.

11. If you haven’t done so, configure a forwarder. You can use and, if not sure which DNS to forward to until you’ve got the DNS address of your ISP. How to set a forwarder? Good question. Depending on your operating system, choose one of the following articles, depending on your operating system.

300202 – HOW TO: Configure DNS for Internet Access in Windows 2000 
323380 – HOW TO: Configure DNS for Internet Access in Windows Server 2003 (How to configure a forwarder): 

Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2

Active Directory and NAT

I thought to touch base on this overlooked fact about AD communication through a NAT.

If a planned resources is to be provided in the AD infrastructure that uses AD authentication (Kerberos) that must traverse a NAT, it basically won’t work. This is due to secure RPC communications and NAT not being able to translate the traffic due to the encryption. If you really need to make it work, there are solutions to work around it, such as a Direct VPN between the services across the NAT devices, or additional NICs directly connecting them. More on it in this link, and Microsoft’s take and solution on it:

Description of support boundaries for Active Directory over NAT;en-us;978772&sd=rss&spid=12925

Active Directory communication fails on multihomed domain controllers 


Source IP address selection on a Multi-Homed Windows Computer

There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection.

Source IP address selection on a Multi-Homed Windows Computer


For multihomed non-DCs that have DNS installed: 

In instances where you are running a separate DNS server internally to host public records and the server is configured with a private IP and different internal name than your hostname server records, you will need to disable registration due to the NS and SOA records that get created and manually create the records under the Nameserver tab, and change the SOA record under the General tab. To disable registration:

To disable registration on Windows 2003 SP2 and 2008 and newer:

The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

RegistrationEnabled    (This DWORD registry entry is a global setting that affects all interfaces on a machine.)
Value = 0   (Disabled = 0, Enabled =1)

More info on these registry settings can be found here:

 Windows 2003 & 2008 DNS Registry Settings:


Related Links

More links to read up and understand what is going on with multihoming and the implications it causes.

Multihoming a Windows Server, by Gunner

292822 – Name Resolution and Connectivity Issues on Windows 2000 Domain Controller with Routing and Remote Access and DNS Insta {DNS and RRAS and unwanted IPs registering]: 

Active Directory communication fails on multihomed domain controllers 

246804 – How to enable or disable DNS updates in Windows 2000 and in Windows Server 2003  

295328 – Private Network Interfaces on a Domain Controller Are Registered in DNS [also shows DnsAvoidRegisterRecords LdapIpAddress to avoid reg sameasparent private IP]:  

306602 – How to Optimize the Location of a DC or GC That Resides Outside of a Client’s Site [Includes info LdapIpAddress and GcIpAddress information and the SRV mnemonic values]: 

825036 – Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 (including how-to configure a forwarder): 

291382 – Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS 

296379 – How to Disable NetBIOS on an Incoming Remote Access Interface [Registry Entry]: 

Rid Pool Errors and other multihomed DC errors, and how to configure a multihomed DC, Ace Fekay, 24 Feb 2006  

257623 257623 Domain Controller’s Domain Name System Suffix Does Not Match Domain Name

Additonal Links added 5/21/2010:

157025 – Default Gateway Configuration for Multihomed Computers;en-us;157025&Product=win2000

Default gateways

Default Gateway Behavior for Windows TCP/IP

159168 – Multiple Default Gateways Can Cause Connectivity Problems

Name resolution and connectivity issues on a Routing and Remote Access
Server that also runs DNS or WINS

272294 – Active Directory Communication Fails on Multihomed Domain

191611 – Symptoms of Multihomed Browsers;EN-US;191611

Microsoft Windows XP – Multihoming Considerations

2 Replies to “Multihomed DCs with DNS, RRAS, and/or PPPoE adapters”

  1. Pingback: Anonymous

Leave a Reply