Drive Mapping Problems

bnob99
bnob99 used Ask the Experts™
on
We are running 2003 server and have logon scripts for users so that the drives they need will be mapped.  Users are on Windows 7.  We recently changed the script so that their "S:" drive would map to a different location than what it was originally set.  Everyone has been able to connect to the new drive, but occasionally we have users who will log in and instead of the S: drive mapping to the new location, it will map to the old location.  Nothing has changed with the login script that was run.  I had a user today send me a screenshot of the batch file running and when it tried to map the S: drive, it was mapping to the old location again and there was a message that the S: drive had a remembered connection (which was the correct location) and it wanted to know whether it should overwrite or not.  Why would it try to map to the old location since that isn't part of the batch file it should be running?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2012

Commented:
Make sure the change to the logon script replicated to all DCs.

Did you use net use S: /delete

Commented:
Try adding:

net use s: /del

Open in new window


to the beginning of the script. This will remove the prior S: drive connection and hopefully allow you to remap it to the correct place.

Author

Commented:
I've checked all of our domain controllers and the correct information has replicated to all of them.  I did have the net use del command in the batch file at first, but even with that command, we were still seeing these issues.  

Is it possible that these computer's are somehow using a cached logon script?
Acronis in Gartner 2019 MQ for datacenter backup

It is an honor to be featured in Gartner 2019 Magic Quadrant for Datacenter Backup and Recovery Solutions. Gartner’s MQ sets a high standard and earning a place on their grid is a great affirmation that Acronis is delivering on our mission to protect all data, apps, and systems.

Commented:
How are you apply the logon script? Are you setting it in AD, or using Group Policy?

If you are using Group Policy, run the following command on the computer:

gpresult /h c:\gpresult.html

Open in new window


You can then open that file and see what policies are being applied. If it shows the correct policies, you can even drill down and see the name of the script being run. If you are using the same name for the script, consider changing it so you can ensure that the newest script is running.

Author

Commented:
It is being set through AD.

Commented:
Obviously the users with the issue are still running the old script. I'm not sure, if you say that everything has replicated, why they would still see the old one. I know I had issues with something similar in the past, which is why I moved to applying logon scripts through Group Policy. It seems much more reliable.

I would suggest adding some troubleshooting lines to the script for a particular user that is having issues. Maybe turn echo back on and add a pause? Then apply the script just to that user, run a gpupdate /force on their machine and have them log out and back in. See if the new script runs.
Top Expert 2012

Commented:
How through AD? Through Login script option on user account? GPO?

Author

Commented:
Dariusg- Yes, through the logon script option in AD.

Oharvey- I would agree that you would think they are running the wrong script, but this doesn't happen all the time.  Some mornings when they log in, they have no issues and the correct drive maps.  I will try your suggestions on one of the users and let you know what happens.
Commented:
Where do you have the script stored? Is it possible you've updated it in one location, and it seems to have replicated, but really hasn't? Maybe they are running a script from a different location from time to time.

Author

Commented:
Is there a way to tell which domain controller they are pulling the script from?

Commented:
You can add and echo %LOGONSERVER% in the script that should show you.

Or, you could just go to the computer in question and run the same command, or run SET in cmd and check the Logon server there.

Author

Commented:
I did find a DC that isn't replicating the logon scripts that are under C:\windows\sysvol.  It is replicating AD users correctly though.  Why wouldn't the scripts be replicating when it appears that other things are?  We will probably end up demoting this DC anyway, but is there a way to force it to replicate the scripts?  I've gone into AD sites and services and replicated from there, but it didn't do anything for the scripts.

Commented:
You could use the repadmin utility to force replication. It will then show you the results and any errors that might be occurring.

For the time being, you could manually copy the script to the other server to see if that helps. In the long run, however, you should sort out that replication issue.
Top Expert 2012

Commented:
There is a way to force the FRS replication. If you want to do that below are the steps


Take backup of the policies and script folders from both the servers from c:\Windows\Sysvol\domain

Stop NTFRS service on both DCs.
Make one of the DC authoritative server by modifying registry setting : Navigate to registry HKLM\System\CCS\Services\NTFRS\Parameters\CumlativeReplicaSets and Set the Burflags value to D4. This should be done with server which has the Updated information available or correct data.

Go to other DC and make that Non-authoritative by navigating to same registry location HKLM\System\CCS\Services\NTFRS\Parameters\CumlativeReplicaSets and Set the Burflags value to D2.

Restart Ntfrs service on both servers and force replication to see event 13516 in event viewer for FRS.

Author

Commented:
I did a non-authoritative restore on the DC that wasn't replicating the sysvol information.  It did replicate after doing that so the scripts are now the same at each DC.  I'll check tomorrow morning and see if anyone has issues with mapping their drives.  I would imaging this was the problem all along.  I'll update this tomorrow.  Thanks for all the help so far.

Commented:
You're right. You will likely see it working tomorrow. Good call on the restore. Good luck!
Top Expert 2012

Commented:
FRS was most likely causing the problem

Author

Commented:
The person that had issues yesterday with it trying to map to the old drive, had issues this morning.  It didn't try mapping to an old drive, it just didn't map the S: drive at all.  I checked the logon server that he was using and confirmed that the logon script on that server is correct, so I'm not sure what is causing this now.  The S: drive was mapped to his computer yesterday, so shouldn't it remember the mapped drive even if it couldn't map to it this morning?
Top Expert 2012

Commented:
Could have an issue with the login script. Or the computer has a bad secure channel password.

Remove computer from the domain.
Delete the computer account from AD.
Re-add the computer back to the domain

Commented:
If you are not using the /persistent flag in your drive mapping command, it wouldn't have stuck this morning after being mapped yesterday.

So now it isn't running a script at all?

Author

Commented:
I don't know for sure if the script ran this morning, but there are a couple of other drives that we map and they are still on the computer.  I'm not using the persistent flag for any of the mapped drives, so I'm not sure why this one drive won't stay mapped while the others are fine.

Commented:
You should remove the other drives and log out and back in to see what happens. If they come back, obviously the script must be running. I'm thinking it isn't, though.

Author

Commented:
We are still seeing the issue happen occasionally, but only with a select few users.  I have turned their logon scrips off for the time being and the mapped drives they should have remain.  This did make us aware that our servers weren't replicating correctly, which has been resolved.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial