Re: Domain Controller Stops Processing All Login Requests Randomly

Herb,

Thanks for the help. I really appreciate it. I have made the necessary
changes and so far everything is working fine. This coming Thursday will
mark a week with no problems. I will keep this thread active with updates
to status of the problem. The unfortuate nature of the problem is that it
takes 2 to 7 days to reoccur. Hopefully I will report that I have nothing
to report later this week!

Josh

"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:uU5CfGdTFHA.336@xxxxxxxxxxxxxxxxxxxxxxx
> "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]
>> >
>> >
>>
>>
>
>


.

Loading