logon script Issue

[jpollack]

There is one machine in our organization that will not map one of my network drives. This script has worked on dozens of other machines, but not this one. I do have local admin rights. Does anyone know why this is happening?

Thanks,
John

 

[LloydSev]

adding the persistent tag causes that drive letter to always be in use regardless of the person logging on. It also doesn't fix the original issue of why it won't map when the script is originally run.

In my company, we run a seperate script for every employee... so it is possible adding the persistent tag is not even an option.

Computer/Network Technician
CCNA

 

[jpollack]

I added the persistent tag and nothing happened. The script still is successful when ran from other computers.

 

[Serbtastic]

Did you add the error logging to the script, then try logging in again (to let it fail, and capture the resultant error)?

Post results.

 

[jpollack]

I added the error log to the script, but since the script will not run there is not an error log to check. I opened up the command prompt and the script ran and added the log file to C, which stated "The command completed sucessfully".

 

[jpollack]

I checked the event viewer to see if it could give me any clues and event 5719 was listed under netlogon. I did some research and maybe the NIC in machine is on its way out. I did upgrade the drivers, but that did not help the issue.

 

[Serbtastic]

Can you post the entire event for analysis?

 

[jpollack]

Here is the error, but not long after I saw this error I ran gpupdate. The error has not been logged again.

Product: Windows Operating System
ID: 5719
Source: NETLOGON
Version: 5.0
Symbolic Name: NELOG_NetlogonAuthNoDomainController
Message: This computer was not able to set up a secure session with a domain controller in domain %1 due to the following:
%2
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

ADDITIONAL INFO
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

 

[LloydSev]

Go ahead and replace the NIC. After reading that event log, I would definately try that out.

Computer/Network Technician
CCNA

 

[jpollack]

All the NICs here are onboard, which makes things a bit harder. I will search the server room for a PCI NIC.

 

[LloydSev]

yeah just use a PCI NIC, disable the onboard adapter then in BIOS before you boot into windows with the new one.

Computer/Network Technician
CCNA

 

[jpollack]

I figured out what the problem is now, but I am not sure on how to fix it. The problem turns out to be a gpo issue. For some reason a gpo that is applied to a group is not apllied to this one specific machine. I figured this by running gpresult /s and low and behold the policy is applied to other computers, but not this one. Any suggestions?

 

[LloydSev]

you could remove it from the domain (by going to system properties).. then remove the computer from AD.

Re-add the computer name to AD, rejoin the system to the domain, and see if it inherits the GPO.

Computer/Network Technician
CCNA

 

[jpollack]

Yes, I guess I can do that. I hope it works.

 

[jpollack]

Well, I removed the computer from the domain at both places and rejoined. And the same thing is still happening.

 

[LloydSev]

well then replace the NIC and cables, and see if it fixes your problem.

Computer/Network Technician
CCNA

 

[spike0724]

Are there any local policies set? You could run the below text to remove aly local policies...

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

This command line script has helped me clean up an inherited problem network.

S. Mike Harris

"If there we 90 seconds in a minute, I might get everything done in a day" - S. M. Harris

 

[jpollack]

gpresult states that the only filtered out gpos were local group policy.

 

[jpollack]

I fixed the problem by adding the logon script to the default domian policy with a new drive letter. However, even though I deleted the old policy/script the computers that the script worked on sill map the drive to b along with the new letter.

 

[jpollack]

btw I searched the server over for the script that maps to b and nothing was found. Is this a replication issue?