Netdiag.exe hangs

Hi All,

We were having some problems with authenticating to a Windows Server 2003 DC
on a mixed Windows 2000/2003 server network. Terminal Services clients were
taking 4 or 5 minutes to logon. We tried using different ports on different
switches, but this didn't help. Due to the problems, we were fairly sure
that the problem was related to the domain controler, but not DNS. The
errors we were seeing at the terminal services systems' event logs were:

Source: Userenv
Event ID: 1000
Description: Windows cannot establish a connection to domain.com with (0).
~~~~~~~~~~~~~~~~
Source: Userenv
Event ID: 1000
Description: Windows cannot query for the list of Group Policy objects.
A message that describes the reason for this was previously logged by
this policy engine.

Eventually, the users would be able to logon. Trying to ping domain.com
from a TS client would resolve to the ip address of the domain controller.

I thought I'd start diagnosing the problem using NETDIAG.EXE. However, when
I run it on the server, it hangs before reporting any information. I just
get a row of dots across the command prompt window. And I've left it for as
long as a half hour. We've tried the second network port on the same
server, but it didn't help.

The server is a HP Proliant DL360 G4, and since we had just installed a
brand new HP DL360G4p, we pulled the drives out of the original server and
installed them in the second. While the main problem (slow authentication)
seems to have been resolved for the moment, I find that I'm still getting
the hanging netdiag. Obviously, this puts a crimp into my being able to run
diags to figure out what was causing the problem in the first place.

The original server is currently off-line, and I'm running the HP
diagnostics on it. However, this doesn't explain why netdiag is still
hanging on the new server as well.

I'm quite worried about this, since the problem has migrated to a brand new
server, which means that the problem was not hardware related, and I'm
worried that the slow authentication will come along to the new server as
well.

Any ideas would be very much appreciated.

Mark

In news:%(E-Mail Removed),
Mark Levy <no-(E-Mail Removed)> stated, which I commented on below:
> Hi All,
>
> We were having some problems with authenticating to a Windows Server
> 2003 DC on a mixed Windows 2000/2003 server network. Terminal
> Services clients were taking 4 or 5 minutes to logon. We tried using
> different ports on different switches, but this didn't help. Due to
> the problems, we were fairly sure that the problem was related to the
> domain controler, but not DNS. The errors we were seeing at the
> terminal services systems' event logs were:
> Source: Userenv
> Event ID: 1000
> Description: Windows cannot establish a connection to domain.com
> with (0). ~~~~~~~~~~~~~~~~
> Source: Userenv
> Event ID: 1000
> Description: Windows cannot query for the list of Group Policy
> objects. A message that describes the reason for this was previously
> logged by
> this policy engine.
>
> Eventually, the users would be able to logon. Trying to ping
> domain.com from a TS client would resolve to the ip address of the
> domain controller.
> I thought I'd start diagnosing the problem using NETDIAG.EXE. However,
> when I run it on the server, it hangs before reporting any
> information. I just get a row of dots across the command prompt
> window. And I've left it for as long as a half hour. We've tried
> the second network port on the same server, but it didn't help.
>
> The server is a HP Proliant DL360 G4, and since we had just installed
> a brand new HP DL360G4p, we pulled the drives out of the original
> server and installed them in the second. While the main problem
> (slow authentication) seems to have been resolved for the moment, I
> find that I'm still getting the hanging netdiag. Obviously, this
> puts a crimp into my being able to run diags to figure out what was
> causing the problem in the first place.
> The original server is currently off-line, and I'm running the HP
> diagnostics on it. However, this doesn't explain why netdiag is
> still hanging on the new server as well.
>
> I'm quite worried about this, since the problem has migrated to a
> brand new server, which means that the problem was not hardware
> related, and I'm worried that the slow authentication will come along
> to the new server as well.
>
> Any ideas would be very much appreciated.
>
> Mark

Long logon times are (*usually) indicative of the wrong DNS addresses in IP
properties. As we all know, only the internal DNS server (no ISP's) must be
used on any machine (DC, member server and internal clients). If it's a TS
issue, then it possibly leads me to believe the TS (or the DC in your case)
possibly has an ISP's address in it. I'm not sure of your configuration, so
it's somewhat guesswork at this point. Netdiag issues can arise from
possibly the wrong version of netdiag. If you installed SP1, there is an
updated netdiag available, as well as dcdiag on Microsoft's site. I don't
have the link with me at this time, but a search should find it. Another
issue is if the DC is multihomed. This causes multiple issues with DNS
registration and the ability for a client (the DC is an AD client as well)
to "find" the domain.

I hope that helps. If you like, please post an ipconfig /all to get a better
idea of your DC's configuration. It will at least be a starting point for
diagnosis. Find the latest netdiag and dcdiag and post the errors sections
of these commands:

dcdiag /v /fix > c:\dcdiag.txt
netdiage /v /fix > c:\netdiag.txt

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

If you are having difficulty in reading or finding responses to your post,
instead of the website you are using, if I may suggest to use OEx (Outlook
Express or any other newsreader of your choosing), and configure a newsgroup
account, pointing to news.microsoft.com. This is a direct link into the
Microsoft Public Newsgroups, and it is FREE and DOES NOT require a Usenet
account with your ISP. With OEx, you can easily find your post, track
threads, cross-post, and sort by date, poster's name, watched threads or
subject.

Not sure how? It's easy:
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Assimilation Imminent. Resistance is Futile.
Infinite Diversities in Infinite Combinations.
=================================

Thanks for your reply!

I realize that a very common problem is having the ISP's DNS servers
addresses in the networking properties, but that's not the case here.

We think that we _MAY_ have found the problem. First off, the domain has
2 DCs, both of which are also the DNS servers for the AD and DNS domains.
One DC (the primary DNS server) is local, while the other DC is at a remote
site. When we would ping the domain, we actually were getting the remote DC
address, rather than the local one. However, the local DC did return pings
with no problems. And logging on with a domain account locally was deadly
slow, although using RDP to logon with a local user account was quite fast,
so the NIC seemed to be OK. We believe that all of the DNS and AD traffic
was being routed to the remote site, due to a failure in the hardware or
networking software. We had a brand new identical server that I had just
gotten up and running, so I pulled the array drives out of the main DC and
plugged them into the new server, shut down the remote site's DC, and did an
IPCONFIG /FLUSHDNS at all the servers, and suddenly logins were back to
being fast. We thought that it was a hardware problem, but the old server
has passed every diag, and when I moved the drives from the original server
to the new server, the problem with netdiag.exe moved along with the drives.
Also, since I reloaded Windows Server 2003 on the "old" DC hardware in a
test environment, netdiag is working just fine! I'm thinking that there's a
problem in the networking software on the domain controller, and that it
would be a good idea to bring up a new server, make it a domain controller,
and then take this DC off the network altogether. It would also be a good
idea to have a second DC on the local network as well, so I'm trying to
convince management to let us have a total of 3 DCs, 2 locally, and one
off-site for disaster protection / recovery. As I said, right now, we just
have 2, one local, one remote, and as far as I'm concerned, the main (local)
DC is suspect.

Mark

"Ace Fekay [MVP]"
<PleaseSubstituteMyActualFirstName&LastNameHere@ho tmail.com> wrote in
message news:eqeDsZ%(E-Mail Removed)...
> In news:%(E-Mail Removed),
> Mark Levy <no-(E-Mail Removed)> stated, which I commented on below:
>> Hi All,
>>
>> We were having some problems with authenticating to a Windows Server
>> 2003 DC on a mixed Windows 2000/2003 server network. Terminal
>> Services clients were taking 4 or 5 minutes to logon. We tried using
>> different ports on different switches, but this didn't help. Due to
>> the problems, we were fairly sure that the problem was related to the
>> domain controler, but not DNS. The errors we were seeing at the
>> terminal services systems' event logs were:
>> Source: Userenv
>> Event ID: 1000
>> Description: Windows cannot establish a connection to domain.com
>> with (0). ~~~~~~~~~~~~~~~~
>> Source: Userenv
>> Event ID: 1000
>> Description: Windows cannot query for the list of Group Policy
>> objects. A message that describes the reason for this was previously
>> logged by
>> this policy engine.
>>
>> Eventually, the users would be able to logon. Trying to ping
>> domain.com from a TS client would resolve to the ip address of the
>> domain controller.
>> I thought I'd start diagnosing the problem using NETDIAG.EXE. However,
>> when I run it on the server, it hangs before reporting any
>> information. I just get a row of dots across the command prompt
>> window. And I've left it for as long as a half hour. We've tried
>> the second network port on the same server, but it didn't help.
>>
>> The server is a HP Proliant DL360 G4, and since we had just installed
>> a brand new HP DL360G4p, we pulled the drives out of the original
>> server and installed them in the second. While the main problem
>> (slow authentication) seems to have been resolved for the moment, I
>> find that I'm still getting the hanging netdiag. Obviously, this
>> puts a crimp into my being able to run diags to figure out what was
>> causing the problem in the first place.
>> The original server is currently off-line, and I'm running the HP
>> diagnostics on it. However, this doesn't explain why netdiag is
>> still hanging on the new server as well.
>>
>> I'm quite worried about this, since the problem has migrated to a
>> brand new server, which means that the problem was not hardware
>> related, and I'm worried that the slow authentication will come along
>> to the new server as well.
>>
>> Any ideas would be very much appreciated.
>>
>> Mark
>
> Long logon times are (*usually) indicative of the wrong DNS addresses in
> IP properties. As we all know, only the internal DNS server (no ISP's)
> must be used on any machine (DC, member server and internal clients). If
> it's a TS issue, then it possibly leads me to believe the TS (or the DC in
> your case) possibly has an ISP's address in it. I'm not sure of your
> configuration, so it's somewhat guesswork at this point. Netdiag issues
> can arise from possibly the wrong version of netdiag. If you installed
> SP1, there is an updated netdiag available, as well as dcdiag on
> Microsoft's site. I don't have the link with me at this time, but a search
> should find it. Another issue is if the DC is multihomed. This causes
> multiple issues with DNS registration and the ability for a client (the DC
> is an AD client as well) to "find" the domain.
>
> I hope that helps. If you like, please post an ipconfig /all to get a
> better idea of your DC's configuration. It will at least be a starting
> point for diagnosis. Find the latest netdiag and dcdiag and post the
> errors sections of these commands:
>
> dcdiag /v /fix > c:\dcdiag.txt
> netdiage /v /fix > c:\netdiag.txt
>
> --
> Ace
>
> This posting is provided "AS-IS" with no warranties or guarantees and
> confers no rights.
>
> If you are having difficulty in reading or finding responses to your post,
> instead of the website you are using, if I may suggest to use OEx (Outlook
> Express or any other newsreader of your choosing), and configure a
> newsgroup account, pointing to news.microsoft.com. This is a direct link
> into the Microsoft Public Newsgroups, and it is FREE and DOES NOT require
> a Usenet account with your ISP. With OEx, you can easily find your post,
> track threads, cross-post, and sort by date, poster's name, watched
> threads or subject.
>
> Not sure how? It's easy:
> How to Configure OEx for Internet News
> http://support.microsoft.com/?id=171164
>
> Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
> Microsoft MVP - Windows Server Directory Services
> Microsoft Certified Trainer
> Assimilation Imminent. Resistance is Futile.
> Infinite Diversities in Infinite Combinations.
> =================================
>
>
>

In news:(E-Mail Removed),
Mark Levy <no-(E-Mail Removed)> stated, which I commented on below:
> Thanks for your reply!
>
> I realize that a very common problem is having the ISP's DNS servers
> addresses in the networking properties, but that's not the case here.
>
> We think that we _MAY_ have found the problem. First off, the
> domain has 2 DCs, both of which are also the DNS servers for the AD
> and DNS domains. One DC (the primary DNS server) is local, while the
> other DC is at a remote site. When we would ping the domain, we
> actually were getting the remote DC address, rather than the local
> one. However, the local DC did return pings with no problems. And
> logging on with a domain account locally was deadly slow, although
> using RDP to logon with a local user account was quite fast, so the
> NIC seemed to be OK. We believe that all of the DNS and AD traffic
> was being routed to the remote site, due to a failure in the hardware
> or networking software. We had a brand new identical server that I
> had just gotten up and running, so I pulled the array drives out of
> the main DC and plugged them into the new server, shut down the
> remote site's DC, and did an IPCONFIG /FLUSHDNS at all the servers,
> and suddenly logins were back to being fast. We thought that it was
> a hardware problem, but the old server has passed every diag, and
> when I moved the drives from the original server to the new server,
> the problem with netdiag.exe moved along with the drives. Also, since
> I reloaded Windows Server 2003 on the "old" DC hardware in a test
> environment, netdiag is working just fine! I'm thinking that there's
> a problem in the networking software on the domain controller, and
> that it would be a good idea to bring up a new server, make it a
> domain controller, and then take this DC off the network altogether. It
> would also be a good idea to have a second DC on the local network
> as well, so I'm trying to convince management to let us have a total
> of 3 DCs, 2 locally, and one off-site for disaster protection /
> recovery. As I said, right now, we just have 2, one local, one
> remote, and as far as I'm concerned, the main (local) DC is suspect.
> Mark

Hmm, I wonder if the problem is more in the SRV records? Do you have AD
Sites created to control logon and replication traffic?

Ace