bnob99
asked on
Drive Mapping Problems
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?
Try adding:
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.
net use s: /delto the beginning of the script. This will remove the prior S: drive connection and hopefully allow you to remap it to the correct place.
ASKER
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?
Is it possible that these computer's are somehow using a cached logon script?
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:
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.
If you are using Group Policy, run the following command on the computer:
gpresult /h c:\gpresult.htmlYou 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.
ASKER
It is being set through AD.
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.
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.
How through AD? Through Login script option on user account? GPO?
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Is there a way to tell which domain controller they are pulling the script from?
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.
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.
ASKER
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.
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.
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.
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\N
Go to other DC and make that Non-authoritative by navigating to same registry location HKLM\System\CCS\Services\N
Restart Ntfrs service on both servers and force replication to see event 13516 in event viewer for FRS.
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\N
Go to other DC and make that Non-authoritative by navigating to same registry location HKLM\System\CCS\Services\N
Restart Ntfrs service on both servers and force replication to see event 13516 in event viewer for FRS.
ASKER
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.
You're right. You will likely see it working tomorrow. Good call on the restore. Good luck!
FRS was most likely causing the problem
ASKER
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?
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
Remove computer from the domain.
Delete the computer account from AD.
Re-add the computer back to the domain
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?
So now it isn't running a script at all?
ASKER
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.
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.
ASKER
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.
Did you use net use S: /delete