AD and Exchange Quantum Singularity : multihomed domain contrrollers

EventID 1054

acefekay — Thu, 12 Aug 2010 14:31:00 GMT

EventID 1054

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

8/12/2010

Summary

There are a number of reasons this event may occur, no matter which Source Name its related to. One of the main reasons this behavior may occur is if the address for the configured preferred DNS server unreachable. One fothe first things to offer is to check EventID.net's link to see if it applies to your scenario:
http://eventid.net/display.asp?eventid=1054

Summary of possibilities:

1. Using a DNS address that doesn't have the AD zone data. Make sure the only DNS addresses on the NIC are the internal DC/DNS servers. Remove the ISP's or the router's as a DNS address. They do not have AD's zone data that is required for AD to function properly.

Active Directory's Reliance on DNS, and why you should never use an ISP's DNS address or your router as a DNS address
Published by acefekay on Aug 17, 2009 at 7:35 PM
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx

2. Multihomed DCs. If the DC is multihomed, numerous issues can result, too long to list. See the following for more info:

Multihomed DCs with DNS, RRAS, and/or PPPoE adapters
Published by acefekay on Aug 17, 2009 at 9:29 PM
http://msmvps.com/blogs/acefekay/archive/2009/08/17/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

3. AD DNS Domain Name is a Single Label Name. The name has no TLD, such as "domain" rather than domain.net, domain.local, etc. This can cause numerous problems, too lengthy to list. It also causes Windows XP SP3 and newer operating systems to fail the ability to resolve DNS names properly. See the following link for more information.

Active Directory DNS Domain Name Single Label Names
Published by acefekay on Nov 12, 2009 at 6:25 PM
http://msmvps.com/blogs/acefekay/archive/2009/11/12/active-directory-dns-domain-name-single-label-names.aspx

4. There are unknown LdapIpAddress entries. This is the "same as parent" name under the zone. There should only be one for each DC in the domain. If there are others, it will cause numerous issues with AD, GPOs, DFS, and other AD functions.

5. Multiple A records for the DC. Make sure there is only one IP address for each DC. If not, it falls under the multihomed DC issue in #2.

6. Multiple GcIpAddresses. Check the _gc_msdsc.yourDomain.local record to make sure there is only one entry for each GC. If there are multiples for one GC, that will cause problems, and falls under the multihomed DC issue in #2.

7. Unknown NS names in the zone. Go into each zone properties (yourDomain.local and _msdcs.yourDomain.local), Nameservers tab, and make sure only your DC/DNS servers show up. If there are others, please remove them. This tab indicates which NS and SOA is for the zones, and if any unkown servers are listed, the client machine may be trying to query for them during resolution and registration, and will cause problems.

8. AMD Opeteron CPUs are known to cause issues. One poster in the Microsoft forums reported EventID 1054 issue on a Dell T105 (circa 2010) with Dual Core Opterons. It was found the AMD Opeteron processor has timing issue. From previous reports, Microsoft supposedly fixed it in Windows 2003 SP2, but something may have changed in recent AMD core releases causing it again. One key test was to ping the server's own IP. If you receive negative ping times, timing is skewed. A reboot fixes it for a while but then it drifts and EventID 1054 resume.

There are AMD processor patches that you can find at AMD's website. Another workaround is to add the "/usepmtimer" switch to boot.ini. KB895980 provides more specifics about this issue.

Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP
http://support.microsoft.com/?id=895980

9. Make sure time is configured properly. You never know, this is one that many do not think about that can cause many issues, which may or may not possibly cause EventID 1054 errors, but it would not hurt to make sure the time service is operating properly. See the following link for more information:

Configuring the Windows Time Service for Windows Server
Published by acefekay on Sep 18, 2009 at 8:14 PM
http://msmvps.com/blogs/acefekay/archive/2009/09/18/configuring-the-windows-time-service-for-windows-server.aspx

Steps to help narrow down this issue:

Let's start by using nslookup to see if you get the proper resonse when querying for LDAP SRV records.

1. Type nslookup, and then press ENTER.
2. Type set q=all, and then press ENTER.
3. Type _ldap._tcp.dc._msdcs.domain.com and then press ENTER.

You will be looking for the domain controllers to respond to this query. If they do not, then we need to look at your SRV records as well as whether any of the above summarized causes are contributing to the non-DC responses, such as using an ISP's DNS, the router, multihomed DCs, single label name, etc.

More possible causes:

In addition, These errors may occur because link status fluctuates as the network adapter (also known as the network interface card, or NIC) driver initializes and as the network adapter hardware negotiates a link with the network infrastructure. The Group Policy application stack executes before the negotiation process is completed and can fail because of the absence of a valid link.

Resolution 1:

To resolve problem related to link status fluctuation use the steps in 239924 -
"How to disable Media Sensing for TCP/IP in Windows" at
http://support.microsoft.com/?id=239924 .

To prevent your network adapter from detecting the link state:

1. Open Registry Editor (Regedt32.exe).

2. Go to the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

3. Add the following registry value:

Value Name: DisableDHCPMediaSense
Data Type: REG_DWORD -Boolean
Value Data Range: 0, 1 (False, True) Default: 0 (False)

Resolution 2:

Contact the vendor of the network card or visit their web site to obtain updated
drivers for the Gigabit NIC.

Examples of NICs known to exhibit this issue:
- Broadcom Gigabit Adapter
- Intel Gigabit Ethernet PRO Adapter, Intel Pro/1000
- Intel 82544EI-based XT Gigabit Adapter (82540EM chipse)
- Compaq/HP NIC dual interface 10/100/1000 doing teaming (HP NC7170)
- Dell Inspiron laptops using an on-board Broadcom BCM4401 NIC

Resolution 3:

A sever may have a Dual Port NIC or multiple NIC's with one port or NIC set to
Disabled. The disabled port or NIC should not be at the top of the binding order
in the Network Advance Properties.

1. Click Start, point to Settings, and then click "Network and Dial-up
Connection".

2. On the Advanced menu, click "Advanced Settings".

3. On the "Adapters and Bindings" tab, in the connections list, select the NIC that
the clients use to connect to the server and move it to the top of the list.

Resolution 4:

Disabling spanning tree on the switches (Cisco Catalyst)

Note: STP=Spanning Tree Protocol. Turning off STP can cause issues in your network
if a loop ever develops. If you are running a Cisco Series switch or any other
switch that runs Spanning Tree, it is best to leave spanning tree turned on, but
enable PORTFAST on all the ports except uplink and fiber trunks. (I.E any ports
that aren't connected to a workstation directly should not have it enabled, ports
that do go directly to a workstation or computer should have it turned on.)
PORTFAST eliminates the 50 second waiting period that STP has, but allows you to
keep the functionality of STP.

References:

326152 PRB: Cannot Connect to Domain Controller and Cannot Apply Group Policy
http://support.microsoft.com/kb/326152

298656 Event ID 1054 Is Logged in the Application Event Log
http://support.microsoft.com/kb/324174/en-us

239924 How to Disable Media Sense for TCP/IP in Windows
http://support.microsoft.com/kb/239924

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

acefekay — Tue, 18 Aug 2009 01:29:00 GMT

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:
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx

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.
http://msmvps.com/blogs/acefekay/archive/2009/11/29/dns-wins-netbios-amp-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.aspx

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:
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx

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"
http://support.microsoft.com/kb/975808/EN-US

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)
http://social.technet.microsoft.com/Forums/en/winserverDS/thread/f5dea401-5a3b-4ddb-8bb8-8d2b2e2db55b

Using teaming adapters with network load balancing may cause network problems
http://support.microsoft.com/kb/278431

however did you know Nic teaming NICs on a DC, or any other Windows box is not a good idea,
http://tinyurl.com/4pbpnfp

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):
http://support.microsoft.com/?id=246804

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

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
http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/d18bd172-e1a0-4a61-ba52-0952a1e3cabc/

Configure TCP/IP to use WINS
http://technet.microsoft.com/en-us/library/cc757386(WS.10).aspx

Note:
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
http://support.microsoft.com/?id=295328

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

                   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
                   (Create this Multi-String Value under it):
                    Registry value: DnsAvoidRegisterRecords
                    Data type: REG_MULTI_SZ
                    Values: LdapIpAddress
                                  GcIpAddress

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

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 192.168.5.200 (192.168.5.200 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:
http://support.microsoft.com/?id=275554

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 4.2.2.2 and 4.2.2.3, 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
http://support.microsoft.com/?id=300202

323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003 (How to configure a forwarder):
http://support.microsoft.com/d/id?=323380

Configure a DNS Server to Use Forwarders - Windows 2008 and 2008 R2
http://technet.microsoft.com/en-us/library/cc754941.aspx

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
http://support.microsoft.com/default.aspx?scid=kb;en-us;978772&sd=rss&spid=12925

Active Directory communication fails on multihomed domain controllers
http://support.microsoft.com/kb/272294

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
http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx

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:

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

AD and Exchange Quantum Singularity : multihomed domain contrrollers

EventID 1054

EventID 1054

Summary

Summary of possibilities:

Steps to help narrow down this issue:

More possible causes:

Resolution 1:

Resolution 2:

Resolution 3:

Resolution 4:

References:

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

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

What is a Multihomed DC?

Internet Connection Services (ICS) on a DC

AD's reliance on DNS

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

Bascially, AD required DNS

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

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

To insure everything works, stick with one NIC

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

The following are the manual steps to configure a Multihomed DC

Using WMIC:

Active Directory and NAT

Source IP address selection on a Multi-Homed Windows Computer

For multihomed non-DCs that have DNS installed:

Related Links

Additonal Links added 5/21/2010: