Multihomed Domain Controller problem

[Steve March]

Hello,
I am having a problem with our Windows 2003 domain controllers. The
domain is in Windows 2003 native-mode and there are only 2 DC/GC's in the
same subnet that everyone authenicates off of from many different subnets
over the WAN. The hosting company requires us to use 3 NIC's in all of our
servers; 1 for production, 1 for backup, and 1 for management. The first 2
months we ran into a few problems trying to install the other DC and also
Exchange Servers into the domain. We discovered by disabling all but the
production NIC we got around the problem. After we had everything installed
we re-enabled all NIC's and everything worked fine for 2 months until we
rebooted the DC's. After applying 4 security patches and rebooting over the
weekend, everything worked fine until users started to log in Monday
morning. Most users experienced very slow logins and other authentication
processes such as intranet based apps failed. Logging into the DC's were
very slow (minutes). Authentication generally failed but every now and then
things started to clear up to only fail later on.

AD Users and Computers failed to work and DNS MMC would not start up at all.
AD U&C error message: "Naming information cannot be located because : This
operation returned because the timeout has expired".

In the Application event log on the domain controller during the time I
logged in:
Source :UserEnv Event ID: 1006 Description: Windows cannot bind to domain.
(Timeout). Group policy processing aborted.

We backed out the patches but that didn't help. We discovered that if we
disable the non-production NIC's, everything is instantly fixed. The
hanging DNS MMC pops right up, logins return to normal speed, and AD Users &
Computers works fine on the DC's and on remote PC's.

Initially we thought it was a DNS problem. We worked with Microsoft and
applied KB 272294 and 2 registry changes discussed in KB 292822 so that only
the production NIC IP addresses would show up in DNS. After some testing
logging in and authenticating, everything worked fine until the next morning
when users logged in again the problems came right back. We disabled the
non-production NIC's again and the problem was fixed instantly again. So
now we are working fine except our hosting center and manage or backup the
DC's with the other NIC's disabled. We think it may be some routing issue
with the DC's but we are not sure.

Any ideas?

Please respond to the group and not to my address (that is wrong) because I
don't want to receive SPAM.

Thank you,
Steve March, MCSE NT4/2000

 

[Ace Fekay [MVP]]

In

Hello,
I am having a problem with our Windows 2003 domain controllers.
The domain is in Windows 2003 native-mode and there are only 2
DC/GC's in the same subnet that everyone authenicates off of from
many different subnets over the WAN. The hosting company requires us
to use 3 NIC's in all of our servers; 1 for production, 1 for backup,
and 1 for management. The first 2 months we ran into a few problems
trying to install the other DC and also Exchange Servers into the
domain. We discovered by disabling all but the production NIC we got
around the problem. After we had everything installed we re-enabled
all NIC's and everything worked fine for 2 months until we rebooted
the DC's. After applying 4 security patches and rebooting over the
weekend, everything worked fine until users started to log in Monday
morning. Most users experienced very slow logins and other
authentication processes such as intranet based apps failed. Logging
into the DC's were very slow (minutes). Authentication generally
failed but every now and then things started to clear up to only fail
later on.

AD Users and Computers failed to work and DNS MMC would not start up
at all. AD U&C error message: "Naming information cannot be located
because : This operation returned because the timeout has expired".

In the Application event log on the domain controller during the time
I logged in:
Source :UserEnv Event ID: 1006 Description: Windows cannot bind to
domain. (Timeout). Group policy processing aborted.

We backed out the patches but that didn't help. We discovered that
if we disable the non-production NIC's, everything is instantly
fixed. The hanging DNS MMC pops right up, logins return to normal
speed, and AD Users & Computers works fine on the DC's and on remote
PC's.

Initially we thought it was a DNS problem. We worked with Microsoft
and applied KB 272294 and 2 registry changes discussed in KB 292822
so that only the production NIC IP addresses would show up in DNS.

After some testing logging in and authenticating, everything worked
fine until the next morning when users logged in again the problems
came right back. We disabled the non-production NIC's again and the
problem was fixed instantly again. So now we are working fine except
our hosting center and manage or backup the DC's with the other NIC's
disabled. We think it may be some routing issue with the DC's but we
are not sure.

Any ideas?

Please respond to the group and not to my address (that is wrong)
because I don't want to receive SPAM.

Thank you,
Steve March, MCSE NT4/2000

Not saying it doesn't work, but those articles are based on W2k. The
registries are similar, but I know some of the registration entries on W2k
have been changed on W2k3. Part of the issue you're seeing is with mutli
NICs, when opening ADUC or any other domain requests, it maybe getting the
wrong IP that is registered for the SRV resource. BTW- we always suggest to
NEVER mutlihome a DC and especially never to put RRAS on it either. Suggest
a member server for that. But in many cases, I can understand that may not
be possible in your environement.

Suggestions, and keep in mind, when mentioning "other NICs", they are the
subnets that the NICs are on that your AD infrastructure is not on.

1. Insure that all the NICS only point to your internal DNS server(s) only
and none others.

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 NetBIOS on the other NICs (i know you did that thru the reg with
that article, but insure that it's disabled in NIC properties too). May want
to take a look at this to stop NetBIOS on teh RRAS interfaces:
296379 - How to Disable NetBIOS on an Incoming Remote Access Interface [Reg
Entry]:
http://support.microsoft.com/?id=296379

4. Disable File and Print services and disable MS Client on the other NICs.
Uncheck reg this connection in DNS tab of IP properties/Advanced. Now if you
need these for whatever reason for resource access from clients, then you
would probably have to keep them on.

5. In DNS, delete the other NIC references for the LdapIpAddress - the blank
domain FQDN - that looks like (same as parent). To stop it from registering
that info, use this method (taken from
http://support.microsoft.com/?id=295328):
==========================
To disable only the registration of the local IP addresses, set the
following registry value:
Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Registry value: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ
Value: LdapIpAddress
After you set this value, you must manually register your publicly available
IP addresses for your domain to appear as:
Same as parent folder Host "publicIP" DO that by just rt-clicking, new host,
leave the hostname blank, and enter the IP of the internal NIC
==========================

6. In DNS, _msdcs.gc, delete the IP addresses referencing the other NICs. I
would follow this article to stop the GC records from the other NICs
registering sine this is a major cause of concern for logons. You would need
to manually create the GC entry of the internal NIC.
Restrict the DNS SRV resource records updated by the Net Logon service
[including GC]:
http://www.microsoft.com/technet/tr...proddocs/standard/sag_dns_pro_no_rr_in_ad.asp

7. Since this is 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 (for W2K, but may work):
275554 - The Host's A Record Is Registered in DNS After You Choose Not to
Register the Connection's Address:
http://support.microsoft.com/default.aspx?scid=KB;en-us;275554&


I hope this is not overwhelming and is of help




--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory