Re: Domain Controller Stops Processing All Login Requests Randomly

"Josh-UCDHSC" <noJCspam@xxxxxxxxxxxxx> wrote in message
news:#z5hZqRTFHA.1896@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
> news:Og2Y5iPTFHA.2872@xxxxxxxxxxxxxxxxxxxxxxx
> > "Josh-UCDHSC" <noJCspam@xxxxxxxxxxxxx> wrote in message
> > news:#uxqWvMTFHA.3544@xxxxxxxxxxxxxxxxxxxxxxx
> >> I have a windows 2003 server running as a Domain Controller in a lab
> >> setting. Randomly the server will stop responding to workstation
client
> >> login requests in the lab and at the server's terminal as well.
> > Eventually
> >> users in the lab will be able to login, however no GPOs are applied and
> >> their mapped network drive is absent. At the server itself, if I login
> >> as
> >> Admin it takes about 7 to 10 minutes and I then have to reboot the
> >> server.
> >
> > Usually this type of thing is due to MULTIPLE DNS servers
> > from different "sets" (e.g., ISP and Internal, or lab vs. production)
> > being listed on either the DC or the Client NICs.
>
> I have two DC doing multi-master replication. They use split-brain DNS
> where the main BIND servers on campus are the only forwarders.

Then if the BIND servers are only used for the forwarders in a split DNS or
shadow DNS setup they are irrelevant. As long as NO client (including DCs)
try to use them directly on their NIC->IP properties which is the mistake
that matches your symptoms most closely.

> Both list
> themselves as the only DNS entries in their NIC TCP/IP configurations,
now.

That is fine too -- as long as they are replicating AD successfully.

(There is a lot of naive advise floating around, even some MS KB,
that claims you should point them at their opposite DC but this is
NOT correct if you have replication working.)

> This is something that Microsoft fixed as I had both DC IP addresses
listed
> in the DNS

That's FINE.

> entry as well as the main BIND servers added as well.

This is NOT. You must only use the "internal DNS server set"
on domain clients.

> Incidently, the clients have all four DNS entries listed in their NIC
> configuration. I can see why that would cause a problem on the DC's. The
> fact that all the clients go down at once would indicate to me that it
isn't
> the clients problem but the DCs.

The clients must NOT list DNS server from outside the domain set --
i.e., DNS servers which cannot resolve the AD-internal version of the
domain.

This is your problem - -change the clients.

There may be OTHER problems due to some (likely temporary) DC
glitch, but the problem is persistent and worse due to this
misconfiguration.

> As a precaution, I am ghosting the TCP/IP
> DNS configuration out to all the clients tonight where the DCs are the
only
> DNS entries.

That is correct. It is not really a precation but a serious requirement.

> > DNS clients expect that EVERY DNS server listed will return the
> > SAME answers.
> >
> >
> >> After a reboot, the problem disappears (usually anywhere from two to
> >> seven
> >> days). Before rebooting I run dcdiag, whose output I have
> >> added below (incidentally, to produce this output dcdiag takes forever
to
> >> run
> >> as well). When I run dcdiag when the system is healthy; there are no
> >> errors.
> >
> > This jibes with the scenario above -- after reboot the client
> > (or the DC) accidentally picks the other (correct or incorrect)
> > DNS server.
> >
> >> I am/was working with Microsoft Support on the issue and we thought it
> >> was
> >> fixed last week. Unfortunately the problem reoccurred today.

Likely the support person doesn't understand this issue -- it is a random
and intermittent problem.


> > Check this stuff:
> >
> >
> > --
> > DNS for AD
> > 1) Dynamic for the zone supporting AD
>
> check - secure only
>
> > 2) All internal DNS clients NIC\IP properties must specify SOLELY
> > that internal, dynamic DNS server (set.)
>
> ghosting this change tonight. Why would they all go down at once? Does
it

Well, if you had a glitch where the DCs got slow while replicating, or a
switch
was overloaded (or anything) then the clients would try the BIND DNS and
will "latch on" for a while.

Eventually they usually go back to the first or earlier DNS but they don't
do
this right away.

> matter if the two DCs IP addresses of themselves in the DNS configuration
of
> the NIC are in the same order? Does each one have to be pointing to
itself
> first?
>
> > 3) DCs and even DNS servers are DNS clients too -- see #2
>
> So my DC are DNS servers, using the main forwarders on campus. If they
> somehow loose connection to these two forwarders, could that cause the
> problem?

No, because that would affect the INTERNET resolution, not the internal
AD resolution.

> > 4) If you have more than one Domain, every DNS server must
> > be able to resolve ALL domains (either directly or
indirectly)
>
> I have only one domain. It is its own forest separate from the main
campus
> domain.

The for you the word 'all' means 'one' but the truth of the sentence
remains.

The word all is there to cover those who have 2 or more domains and forget
to arrange for domain1 to find domainC etc.

> > netdiag /fix
>
> I do get a warning: "[WARNING] At least one of the <00> 'WorkStation
> Service', <03> 'Messenger Service', <20> 'WINS' names is missing."
> WINS service test. . . . . : Skipped
> There are no WINS servers configured for this interface.

If you have more than one subnet (for domain clients and servers) then
you need WINS server and need to configur ALL NIC->IP properties
for WINS server to use the same "set of WINS servers" - this includes
DCs and other servers.

> The netdiag /fix added the second PASS line.
> DNS test . . . . . . . . . . . . . : Passed
> PASS - All the DNS entries for DC are registered on DNS server
> '132.194.21.250' and other DCs also have some of the names registered.
> PASS - All the DNS entries for DC are registered on DNS server
> '132.194.21.96' and other DCs also have some of the names registered.
> > ...or maybe:
> >
> > dcdiag /fix
>
> No errors or warnings..

This is because the two DCs are using only the internal, dynamic DNS'
server set (e.g., themselves) for DNS client settings.

Your problem is (mostly) on you clients that refer to the BIND servers
in those NIC properties.

> What is the difference between dcdiag and dcdiag2k3?

It's named DCDiag.exe in both cases and I don't pay attention
to any differences.


> > (Win2003 can do this from Support tools):
> > nltest /dsregdns /server:DC-ServerNameGoesHere
>
> C:\Documents and Settings\Administrator>nltest /dsregdns /server:WAIMEA
> Flags: 0
> Connection Status = 0 0x0 NERR_Success
> The command completed successfully
>
> > http://support.microsoft.com/kb/q260371/
>
> reading... thanks!
>
> >
> > Ensure that DNS zones/domains are fully replicated to all DNS
> > servers for that (internal) zone/domain.
>
> _msdcs
> _sites
> _tcp
> _udp
>
> all show up in the DNS (AD integrated)...

That's because the DCs are correct.

> > Also useful may be running DCDiag on each DC, sending the
> > output to a text file, and searching for FAIL, ERROR, WARN.
>
> No problems on either DC...

Right.

> > Single Label domain zone names are a problem Google:
> > [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
>
> I am looking into exactly what this means - single label domain names.
I've
> not heard of it before...

You must NOT (although it is legal for some silly reason) name an AD
domain like this: "domain", but must use at least "domain.com" or even
"child.domain.edu".

> Thanks for your help!
>
> For awhile I was blocking all external access to the DCs with a separate
> linux firewall. I've turned that off and instead I am only blocking
> specific ports. Perhaps the DCs where sending out DNS requests and the
> responses were being blocked.

Perhaps. Firewalls between DCs or between DCs and their clients are
POSSIBLE but tricky to get right.

> I'm not sure, the firewall should allow
> through all related and established connections but Microsoft support said
I
> should try it turned off.

Probably until you get the rest fixed. But you might open the
filter up selectively to just your domain subnets IF you can isolate
YOUR domain machines by subnet (e.g., they don't come in from
through the university, dorms, wan from home, etc.)

> Let me know if there is anything in my response that appears out of the
> ordinary or is suspicious.

Fix the clients And then we will look for anything that is "slowing" or
hosing up the Client to DC or DNS access.

> > --
> > Herb Martin, MCSE, MVP
> > Accelerated MCSE
> > http://www.LearnQuick.Com
> > [phone number on web site]
> >
> >
>
>


.