Two Scenario we are experiencing and looking for any advice you might have:
A number of client and member servers in our AD domain are connecting to
different DC's in multiple Sites. We see this through a low level
conversation report on our WAN analyzer. If they were connecting to the
PDC emulator, it would make sense, however these are other DC's. Any
ideas?
I presume you mean that clients from one Site are
authenticating to a DC in a another Site?
If so this calls into question your Sites setup.
Do you have the Sites defined in Sites and Services
with the proper Subnets assigned to each AND with
the DCs located in the correct site?
For instance, if you set up sites AFTER the creation
of the DCs and neglected to move them in Sites and
Services from the default site to the proper site you
might actually have DCs with the wrong site, and thus
sites with "no" DC.
You might also have a DNS problem (*see below) wherein
not all DCs are fully/properly registered with DNS. Most
common if it works partially is that some DCs are not
clients of the INTERNAL DNS solely or cannot find the
Primary (or AD-integrated Set of) DNS services which
can accept their registrations using DDNS.
Also, note that you need a GC in each Site -- if you have
only one domain you can make ALL DCs GCs with no
significant downside.
DC to DC traffic - In the same conversation report, we are seeing DC's
communicating with other DC's that are NOT part of the Site replication
Again it sounds like misconfigured Sites or misplaced
DCs.
CA's, and are not configured to pull any DNS information as secondaries from
any of those DC's.
That configuration is automatic, you do not normally
control it and the concept of "secondaries" doesn't
exist among Win2000+ DCs.
We do have the _msdcs.xxx.com zone on each DC, for
forest-wide/GC information access, however they are again, not pulling from
those DC's. Any ideas?
You can look in Sites and Services and SEE the connection
objections created by the KCC -- you might be tempted to
manual adjust this, but your first steps should be to correct
whatever misconfiguation caused the KCC to make incorrect
decisions. (i.e., Sites, Subnets, DC placement in Sites.)
*DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domain (either directly or indirectly)
Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:
nltest /dsregdns /server
C-ServerNameGoesHere
Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.
Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.
Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]