join domain "the network path was not found"

[Jaz]

Randomly, some XP Pro clients cannot be added to my AD domain. After
providing the AD user/pass for joining the system, I get:
"The network path was not found."

Googling, I found these solutions but none worked:

1. Local Security Policy | Domain member | Digitally encrypt secure
channel data (when possible): Enable (I made no change);

2. Enable NetBIOS over TCP (already enabled);

3. Check for firewalls/filters (none -- disabled Windows firewall);

4. Check DNS server (OK -- note that this is a client-specific
problem), and DNS setup on client;

5. Add WINS (still fails);

5. Windows Updates;

6. Check that Computer Browser service is running (OK);

7. Try adding computer to AD on server before client join attempt
(nope);

8. Try DNS lookup using type SRV (looks ok -- I get the proper "srv
hostname = myADserver.mydomain.com" &
"_ldap._tcp.dc._msdcs.mydomain.com SRV service location" entries);

9. Try an LDAP test using dnslint.exe (this fails on systems that are
successfully operating under AD! -- M$, are your people on crack?);

10. Try joining using joindom.exe (I get error 53);

That there isn't more meaningful info available from Windoze is
frustrating/infuriating.

Can anybody help? Thanks in adavance.

BTW, I once knew how to authenticate to a remote server on command
line (without actually mapping a drive etc.), which might make the
difference. It used it to authenticate before I needed to map a drive
because the login while mapping a drive is os a darn unreliable
(frequently get the same message: path not found.) Can anybody congure
up that command?

-Jaz
[please excuse the burp when replying]

 

[Herb Martin]

Randomly, some XP Pro clients cannot be added to my AD domain. After
providing the AD user/pass for joining the system, I get:
"The network path was not found."

The word "randomly" makes me think the MOST LIKELY reason
is you have (some of) your XP clients NIC->IP->DNS server set
to the ISP or a MIXTURE of ISP and internal.

You must set internal AD clients (and servers for that matter)
to STRICTLY use the INTERNAL DNS server (set.)

Googling, I found these solutions but none worked:

1. Local Security Policy | Domain member | Digitally encrypt secure
channel data (when possible): Enable (I made no change);

Usually only an NT and 9x issue.

2. Enable NetBIOS over TCP (already enabled);

Not relevant for THIS if you are in the same forest but a GOOD IDEA anyway.

3. Check for firewalls/filters (none -- disabled Windows firewall);

Double check, especially the SERVERS (DCs etc.)

4. Check DNS server (OK -- note that this is a client-specific
problem), and DNS setup on client;

So what is the DNS setup on the client?

5. Add WINS (still fails);

This is mostly for browsing and some odds and ends features.

5. Windows Updates;

6. Check that Computer Browser service is running (OK);
ditto

7. Try adding computer to AD on server before client join attempt
(nope);

Right. It's a problem finding or reaching the DCs.

8. Try DNS lookup using type SRV (looks ok -- I get the proper "srv
hostname = myADserver.mydomain.com" &
"_ldap._tcp.dc._msdcs.mydomain.com SRV service location" entries);

Use DCDiag on EVERY DC instead.

Must more comprehensive testing. Fix all indicated problems or post the
results here.

9. Try an LDAP test using dnslint.exe (this fails on systems that are
successfully operating under AD! -- M$, are your people on crack?);

DCDiag is almost always a faster way to find such errors.

10. Try joining using joindom.exe (I get error 53);

That there isn't more meaningful info available from Windoze is
frustrating/infuriating.

Can anybody help? Thanks in adavance.

Also run NetDIAG on each client.

NetDIAG and DCDiag are in the SUPPORT TOOLS from the (server) CDROM.

BTW, I once knew how to authenticate to a remote server on command
line (without actually mapping a drive etc.), which might make the
difference.

No, because you are having trouble finding the DNS entries for the
Kerberos service probably.

But here it is:

net use \\ServerName\ipc$ * /useromainName\UserName

Won't (likely) help with your COMPUTER and normal user authentication
however.

It used it to authenticate before I needed to map a drive
because the login while mapping a drive is os a darn unreliable
(frequently get the same message: path not found.) Can anybody congure
up that command?

Check those CLIENT DNS settings on the NIC (my bet) and NetDIAG (clients)
as well as DCDIAG (every DC).


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

-Jaz
[please excuse the burp when replying]

 

[m0rk]

That there isn't more meaningful info available from Windoze is

frustrating/infuriating.

Can anybody help? Thanks in adavance.

BTW, I once knew how to authenticate to a remote server on command
line (without actually mapping a drive etc.), which might make the
difference. It used it to authenticate before I needed to map a drive
because the login while mapping a drive is os a darn unreliable
(frequently get the same message: path not found.) Can anybody congure
up that command?

-Jaz
[please excuse the burp when replying]

Try setting the time to within 5 mins of the correct DC time.

 

[Jaz]

The word "randomly" makes me think the MOST LIKELY reason
is you have (some of) your XP clients NIC->IP->DNS server set
to the ISP or a MIXTURE of ISP and internal.

DNS is set to only the Active Directory server. For example:

C:\>nslookup -q=srv adserver.mydomain.com 10.1.201.162
Server: adserver.mydomain.com
Address: 10.1.201.162

mydomain.com
primary name server = adserver.mydomain.com
responsible mail addr = hostmaster
serial = 149
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)

You must set internal AD clients (and servers for that matter)
to STRICTLY use the INTERNAL DNS server (set.)


So what is the DNS setup on the client?

Client uses the AD server, which is setup exactly the same as on
clinets that don't fail to join the domain. I was referring to the DNS
server. That is, that it responds to the _ldap query neccessary for
the Windows client to join the AD database via LDAP.

This is mostly for browsing and some odds and ends features.


Right. It's a problem finding or reaching the DCs.


Use DCDiag on EVERY DC instead.

Must more comprehensive testing. Fix all indicated problems or post the
results here.

What I'm seeing is that some clients join the doamin fine. Others
wont, no matter how many times I try.... if I come back to them a week
later, same deal. To me, this seems like a client-specific problem.

BTW, DCDiag passes all tests. I have not run NeDiag (I would have run
it and reported here, but the current problematic system is locked and
the user out of town)

DCDiag is almost always a faster way to find such errors.

Alas, DCDiag passes all tests.

Also run NetDIAG on each client.

Ok, will do when I get the chance. (I'll try to post back here in a
few days)

NetDIAG and DCDiag are in the SUPPORT TOOLS from the (server) CDROM.


No, because you are having trouble finding the DNS entries for the
Kerberos service probably.

Ahhh. Can anyone muster up a way for me to check that?

But here it is:

net use \\ServerName\ipc$ * /useromainName\UserName

Won't (likely) help with your COMPUTER and normal user authentication
however.

But very handy for various situations -- thank a lot!

Check those CLIENT DNS settings on the NIC (my bet) and NetDIAG (clients)
as well as DCDIAG (every DC).

[please excuse the burp when replying]

 

[Jaz]

That there isn't more meaningful info available from Windoze is
frustrating/infuriating.

Can anybody help? Thanks in adavance.

BTW, I once knew how to authenticate to a remote server on command
line (without actually mapping a drive etc.), which might make the
difference. It used it to authenticate before I needed to map a drive
because the login while mapping a drive is os a darn unreliable
(frequently get the same message: path not found.) Can anybody congure
up that command?

-Jaz
[please excuse the burp when replying]

Try setting the time to within 5 mins of the correct DC time.

It allready is.
[please excuse the burp when replying]

 

[Herb Martin]

DNS is set to only the Active Directory server.

Good. Double check any of the XP clients that exhibit the random
problem.

For example:
C:\>nslookup -q=srv adserver.mydomain.com 10.1.201.162
Server: adserver.mydomain.com
Address: 10.1.201.162

This doesn't prove the client is set ONLY (or STRICTLY) to
internal DNS server though -- double check the problem machines.

(IPConfig /all and NetDiag)

Client uses the AD server, which is setup exactly the same as on
clinets that don't fail to join the domain. I was referring to the DNS
server. That is, that it responds to the _ldap query neccessary for
the Windows client to join the AD database via LDAP.

Well the Kerberos SRV record is important too.

Run DCDiag on each DC to double check.

What I'm seeing is that some clients join the doamin fine. Others
wont, no matter how many times I try.... if I come back to them a week
later, same deal. To me, this seems like a client-specific problem.

Double checking (IPConfig /all) and using NetDiag (on every trouble
client) is a good thing to check.

After that, it has been known to happen with a bad Hub or Switch
but that is less common. Also watch out for any routing problems
on the clients. So when you have the (intermittant) problem check
name resolution and routing then (NsLookup and Ping etc.)

BTW, DCDiag passes all tests. I have not run NeDiag (I would have run
it and reported here, but the current problematic system is locked and
the user out of town)

Ok. That is where you must focus attention during the problem
(i.e., when it occurs.)

Alas, DCDiag passes all tests.

This does though push the problem towards the clients.

Ok, will do when I get the chance. (I'll try to post back here in a
few days)

Ahhh. Can anyone muster up a way for me to check that?

NetDiag, Nslookup, etc.

But very handy for various situations -- thank a lot!

Sure. (I am not big on saying "that won't help" without giving you
the answer if it is short enough not to disctract from your current
problem.)

You're welcome.

 

[Guest]

On the PDC, please check for the following registry key :
HKLM->system->CCS->services->netlogon->parameters->NT4Emulator dword value.
If it is there, please delete it and restart the DC.

Can you ping the DC from the client box using FQDN of DC?
Taking a netmon trace while joining machines to the domain will help.

That there isn't more meaningful info available from Windoze is
frustrating/infuriating.

Can anybody help? Thanks in adavance.

BTW, I once knew how to authenticate to a remote server on command
line (without actually mapping a drive etc.), which might make the
difference. It used it to authenticate before I needed to map a drive
because the login while mapping a drive is os a darn unreliable
(frequently get the same message: path not found.) Can anybody congure
up that command?

-Jaz
[please excuse the burp when replying]

Try setting the time to within 5 mins of the correct DC time.

It allready is.
[please excuse the burp when replying]

 

[Herb Martin]

On the PDC, please check for the following registry key :
HKLM->system->CCS->services->netlogon->parameters->NT4Emulator dword
value.
If it is there, please delete it and restart the DC.

What is the background or purpose in doing this?

Can you ping the DC from the client box using FQDN of DC?
Taking a netmon trace while joining machines to the domain will help.

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

That there isn't more meaningful info available from Windoze is
frustrating/infuriating.

Can anybody help? Thanks in adavance.

BTW, I once knew how to authenticate to a remote server on command
line (without actually mapping a drive etc.), which might make the
difference. It used it to authenticate before I needed to map a drive
because the login while mapping a drive is os a darn unreliable
(frequently get the same message: path not found.) Can anybody congure
up that command?

-Jaz
[please excuse the burp when replying]


Try setting the time to within 5 mins of the correct DC time.

It allready is.
[please excuse the burp when replying]