Strange AD and DNS Error

[Chris-n-Jordan]

Greetings All!

I wonder if you could help me with an irritating problem. I have a lab
of 31 XP Pro computers logging in to a domain (Win2003 Server- AD
Domain Controller and main DNS server) using a profile I have named
"Student." The student profile is pretty locked down but has access to
a network share on the server where it pulls some app files and gets
its desktop background.

Everything was great...the students would log in using the profile and
connect and there were no problems. Then I decided to save myself the
headache of loggin in 31 computers and did the registry modifications
to have the computer auto-login. These mods were four keys in the
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon section of the
registry. I modified:
Default User- Student; Default Password- Student; Default Domain - AMP;
AutoLogin = 1

When I did this all heck broke loose. All of the sudden, the computers
that logged in beautifully when I did it manually, DID NOT MAP THE
NETWORK DRIVE (Z:- It was set in the User Profile). I checked the
event log and found Event 1054- Windows cannot obtain the domain
controller name for your computer network. (The Specified domain either
does not exist or could not be contacted.) Group Policy processing
aborted.

I remove the autologin and the problem goes away. It is the same for
all of my computers. There are no anomolies in the DNS Events...it is
up and working fine as far as I can tell. The DHCP server has the
domain controller listed in the Options. When I log on manually, I get
DNS, Default Gateway...a full lease.

I can't figure it out. The only thing I could guess is that the speed
of the login causes something to be missed from the DHCP Server. Any
thoughts?

 

[Herb Martin]

Everything was great...the students would log in using the profile and
connect and there were no problems. Then I decided to save myself the
headache of loggin in 31 computers and did the registry modifications
to have the computer auto-login. These mods were four keys in the
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon section of the
registry. I modified:
Default User- Student; Default Password- Student; Default Domain - AMP;
AutoLogin = 1

When I did this all heck broke loose. All of the sudden, the computers
that logged in beautifully when I did it manually, DID NOT MAP THE
NETWORK DRIVE (Z:- It was set in the User Profile). I checked the
event log and found Event 1054- Windows cannot obtain the domain
controller name for your computer network. (The Specified domain either
does not exist or could not be contacted.) Group Policy processing
aborted.

I remove the autologin and the problem goes away. It is the same for
all of my computers. There are no anomolies in the DNS Events...it is
up and working fine as far as I can tell. The DHCP server has the
domain controller listed in the Options. When I log on manually, I get
DNS, Default Gateway...a full lease.

DHCP server has the DOMAIN CONTROLLER listed?

In what way? What does this mean?

(DHCP servers don't do that as far as I can understand what you are
claiming.)

I can't figure it out. The only thing I could guess is that the speed
of the login causes something to be missed from the DHCP Server. Any
thoughts?

What makes you suspect DHCP? It's easy to eliminate: Do the following
under both situations:

ipconfig /all >auto.txt
ipconfig /all >manual.txt

Then compare the two files -- ignoring any difference in IP address
IF that changes (probably isn't the source of the problem) UNLESS
you can see some discrepancy this might cause.

What type of Profile is this? (It sounds like a Roaming profile but
you seem to be using it as a Mandatory profile...)

What happens under both situations (logons) when you run NetDiag
on the client machine (and search the output for FAIL, WARN, ERROR)?

What about running DCDiag on each DC?

Most such odd problems turn out to be DNS related, but there
COULD be a bug in this logon method (it's not heavily used by
many people) although that seems to be unlikely -- basically its
the same logon except the location of the password.

ONE DIFFERENCE is that with autologon the logon occurs
immediately so you could have a timing problem where the
machine is not properly authenticating....

Maybe something silly like a (bogus) Computer STARTUP
script that wastes a few seconds/minutes might help if this is
the case.

 

[Seahawk60B]

Try using the FQDN instead of the NetBIOS name

 

[Chris-n-Jordan]

Thanks for the reply....

First, the DHCP has the DNS listed which should give the PDC IP address
in response to the request for Default Domain- AMP

As for DHCP- I don't really suspect DHCP...I was just noting that it
was one player in the game... It really passes off the issue to DNS
immediately. The problem is that when the login goes through so
quickly, the DNS resolution is not happening and the DC is not
contacted and the GP is not applied.

This is a regulary user profile on the domain, but I have put it in its
own OU and set up a special set of policies that apply to it. Not only
is it heavily locked down in terms of NTFS permissions, it can't do
much of anything...see my computer, execute an exe, no command
prompt...etc.

I will run the NetDiag and DCDiag tests tomorrow. I will also
experiment with some kind of script to increase the logon timout time.

Thanks in advance!

 

[Chris-n-Jordan]

I did try this up front. The FQDN, the NetBIOS, and the IP address all
provide failed results.

Thanks for the suggstions!

 

[Herb Martin]

I did try this up front. The FQDN, the NetBIOS, and the IP address all
provide failed results.

Well, in general when the IP fails you do NOT have a
DNS nor a NetBIOS name error.

If IP fails you have a routing/firewall/hardware etc issue.

But none of that seems relavant - in fact HOW did you use
the IP address for your failing profile?

 

[Herb Martin]

Thanks for the reply....

First, the DHCP has the DNS listed which should give the PDC IP address
in response to the request for Default Domain- AMP

Huh? Ok, but in neither this explanation or you original is it
giving the "DC" but rather it appears the default DOMAIN.

That should NOT be an IP but rather the machines domain name.

Every machine should ALSO have the correct name set in the SYSTEM
control panel.

As to the IP, the DHCP should provide the IP of the DNS server
which may also be the DC but that portion is irrelevant to making
it work -- just an accident of the way we run our systems with
multiple service roles.

As for DHCP- I don't really suspect DHCP...I was just noting that it
was one player in the game... It really passes off the issue to DNS
immediately. The problem is that when the login goes through so
quickly, the DNS resolution is not happening and the DC is not
contacted and the GP is not applied.

Well we know that DHCP completes BEFORE the computer
logs (itself) on, before it obtains its GPOs (if any), before it
logs on any user (even autologon).

All of these must happen after DHCP and DNS are working
since they are required for any network IP access.

This is a regulary user profile on the domain, but I have put it in its
own OU and set up a special set of policies that apply to it.

Profiles are not assigned through or by OUs unless you have
figured out something that I don't know....

Do you mean GPO or do you mean Profile? Group Policies
are something entirely different from profiles....

Not only
is it heavily locked down in terms of NTFS permissions, it can't do
much of anything...see my computer, execute an exe, no command
prompt...etc.

I will run the NetDiag and DCDiag tests tomorrow. I will also
experiment with some kind of script to increase the logon timout time.

If that works, then the answer is a (semi)bug and this solution (of
mine) is pretty cheesy. But hey, it if works it works.