Network users getting previous user's network drives?

D

dleifelohcs

Limp Gawd
Joined
Jan 7, 2006
Messages
374
To put a long story short, here's what happens:

Windows XP SP2, all up to date
1) turn on computers in morning
2) class logs into lab fine, no issue
3) class logs out
4) New class logs in, finds that their network volumes are either:
* P and N drives are disconnected, P drive points to the previous user's home folder, or drives E through Z all appear as disconnected volumes. Right clicking on any drive to disconnect produces an error message that the drive does not exist.

Rebooting does NOT take care of this.

I have tried installing User Profile Hive cleaner, I have tried removing the computers from the domain and re-adding, which seemed to work for a short period of time (one day) but then the problem persists.

This seems to only happen on one computer lab in the building (all computers are the same model, using the same image, etc.)

ANY ideas what is going on here? Any thoughts to what I can try? Running out of options here, and of course this happens near the semester's end!

Thanks

(PS - my apologies if this is in the wrong subforum, made the most sense to me to put it here)
 
Are the drives mapping through a login script or group policy?

If they are being mapped by a log in script make sure the script also deletes the mappings before creating them.

Your batch file should look like this


net use x: /delete
net use u: /delete
net use s: /delete
net use q: /delete
net use u: \\servername\users
net use s: \\servername\shared
net use q: \\servername\acctg
net use x: \\servername\hr

This helps to keep the mapping clean
 
Make sure when the drives are mapped they are not persistent. And for sure use login scripts.
 
We use login scripts, but apparently they're VBScript.

Code: 
Set oNetwork = CreateObject("WScript.Network")
	oNetwork.MapNetworkDrive "N:", "\\gandalf\Public"

Their actual user drive, P: is handled by AD.
 
dleifelohcs said:
We use login scripts, but apparently they're VBScript.

Code: 
Set oNetwork = CreateObject("WScript.Network")
	oNetwork.MapNetworkDrive "N:", "\\gandalf\Public"

Their actual user drive, P: is handled by AD.
Click to expand...



Code: 
Set oNetwork = CreateObject("WScript.Network")
	oNetwork.MapNetworkDrive "N:", "\\gandalf\Public", true

http://msdn2.microsoft.com/en-us/library/8kst88h6.aspx

I think that'll work.
Or just disconnect the drives on logout / before you map them - http://www.ss64.com/wsh/drivemap.html
 
wouldn't I want it to be "false" instead of "true"? Many people have said to make sure the connections are not persistent...
 
dleifelohcs said:
wouldn't I want it to be "false" instead of "true"? Many people have said to make sure the connections are not persistent...
Click to expand...

It's false by default according to the msdn link. I'm guessing it stores it in the user profile as opposed to all user profile.
 
I don't have a domain to test the true of fasle bit, but I would suspect you want it set to false. I wouldn't think setting it to false updates the all users profile, as it's not a machine login script. There is something you can do for sure though. Forcefully disconnect the drives. Do it before the mapping starts in the login script, and setup a logout script. Here's some simple code from MS:

Set objNetwork = WScript.CreateObject("Wscript.Network")
objNetwork.RemoveNetworkDrive "G:"
 
SpaceHonkey said:
I don't have a domain to test the true of fasle bit, but I would suspect you want it set to false. I wouldn't think setting it to false updates the all users profile, as it's not a machine login script. There is something you can do for sure though. Forcefully disconnect the drives. Do it before the mapping starts in the login script, and setup a logout script. Here's some simple code from MS:

Set objNetwork = WScript.CreateObject("Wscript.Network")
objNetwork.RemoveNetworkDrive "G:"
Click to expand...

From the link

" bUpdateProfile

Optional. Boolean value indicating whether the mapping information is stored in the current user's profile. If bUpdateProfile is supplied and has a value of true, the mapping is stored in the user profile (the default is false)."

Therefore, explicitly setting it to false effects no change with his current script.
 
Question:

You mentioned that they all use the same image. How do you deploy said image? Specifically, are the images Syspreped and are you allowing sysprep to generate a new SID on the workstation?

Drive mappings are stored in the users profile. One user should NEVER see another users profile or drive mapping unless they are sharing profiles. Even if you flag the mapping as persistent, this mapping is only for this user. Could you verify that your users are not sharing a profile when logging on to that machine? If you specified a roaming profile in the policy of that machine, and pointed all users to that profile, then you would experience the results you are seeing.
 
Demon10000 said:
Question:
Drive mappings are stored in the users profile. One user should NEVER see another users profile or drive mapping unless they are sharing profiles. Even if you flag the mapping as persistent, this mapping is only for this user.
Click to expand...

Drive mappings shouldn't be stored in the profile. If you do, while logging in sans domain, the drives will still attempt to map. That is not desirable. There are very few circumstances that persistent mapping should be used for, and this isn't one of them.

dleifelohcs - where is said login script called from? User login script, machine policy, registry? Are you mapping drives from several different sources? Do you use Novell or any other client/gina? Give us some more info on how things work.
 
No, we do not use sysprep. It is something we are looking into for the future (check my post in the Operating Systems forum). We build an image for each model of computer we have. This particular problem is on a Dell Optiplex GX270 (and seems to be spreading to Optiplex GX520s, a different image). We use Ghost to deploy/capture the images.

If I try to write a script that will disconnect a network drive, I get a script error saying that it failed, Windows doesn't seem to think the drive is actually mapped. They show up in My Computer as Disconnected Drives.

Users P drives are mapped through AD. The script I posted above is run at login, to map a Public drive.

This is NOT consistent. One thing I am seeing is some users will login, and have drives E through Z all showing as disconnected (they should only have a P and N drive). When I click on the drives, the P drive generally is the previous user's drive, the N drive shows disconnected, but will connect to Public (though as who I don't know) and the various other drives in the E through Z range can be anything from additional mappings to Public, or other previous users home directories.

Very, very strange. Please also note that this setup, this exact image, has worked fine in this very lab for at least 2 years.
 
Script is applied through domain policy, sits on our AD server in C:\WINDOWS\SYSVOL\[something]\student.vbs - it gets replicated out to all of our AD Masters - Domain policy calls this script, and like I said above, this has worked well for many years.
 
In the script try to delete and rebuild the mappings like I showed above and see if this fixes the issue.
 
Deleting mappings from the script apparently doesn't seem to work. Two more things I can think of to run down.

1. Idenify with certainty that nothing changed at the time period that it started ocurring.

2. What happens with a fresh load? And does the problem follow the users back to their normal machines?
 
So far the culprit seems to be Symantec Corporate 10 - if I uninstall it from a machine (so far) I have no issues.

However, this problem was mostly isolated to one lab in one building. As of yesterday, it has spread over to the High School. Symantec have an update recently?
 
I'm having the exact same problem. A lab with 25+ PCs with users logging in finding that their S:\ drive is showing disconnected. However, clicking on those disconnected drives take them to the previous user mapping to the same drive letter.

In my case, a restart fixes the issue until one user logs off, and the next user logs in again. Also, it is not guaranteed that this happens everytime, a very sporadic problem. I tried to login to a PC 15-20 times without problems. I have also tried the User Profile Hives Cleanup with no success.

This whole problem started sometime around 11/20/2007. I have found a lot of similar problems out there, but none of them has the same solution. A lot of them are pointing to Symantec however.

dleifelohcs - what version of symantec do you have? We are running on 10.1.4, and I have not tried uninstalling it yet.

Help please!
 
Looks like you're finally on the right trail, good find! Hope it works out, let us know what happens.
 
ee: Symantec Corporate 10, but we have the update to the new one (named something new) but it's essentially version 11.

I uninstalled Symantec Client on 5 of our 25 lab machines, and those 5 showed NO symptoms during the test period. We are beginning to migrate our Symantec servers to Symantec 11 so that we can also upgrade the clients, and hopefully resolve this issue.

I also saw in Google searches that Symantec has caused similar problems in the past, however we've been running an updated version that supposedly does not have that problem. Interesting that it would pop back up again.

In any case, give it a try - uninstall Symantec from a few of them and see what happens!

Also noting that around 11/15-11/20 is when we started noticing this problem as well. My first thought was a Windows Update that was applied on 11/14 being the culprit however uninstalling it from a few lab machines did nothing to solve the problem.
 
Thanks dleifelohcs! Uninstalled on 5 PCs, and that fixed the problem! What a strange problem ... I am calling Symantec to get to the bottom of this.
 
Does that Symantec software have some sort of firewall or another network security feature that might be blocking the script from running or blocking Group Policy from being applied at logon? This could cause the drive to not be mapped (because the script didn't run to map it correctly), which would then show the remembered connection in a disconnected state.

Drive mappings shouldn't be stored in the profile. If you do, while logging in sans domain, the drives will still attempt to map. That is not desirable. There are very few circumstances that persistent mapping should be used for, and this isn't one of them.
Click to expand...

Whether it's best practice or not, drive mappings are stored in the users profile. When the users are logging in, the drive mapping is being remembered which is why it is being shown in a disconnected state.

If you build your workstations, add them to the domain, then image them with ghost, you are asking for trouble. You need to sysprep them before you image them. If you were to call Microsoft with this problem, they would flat out refuse to help you because you didn't sysprep, and there is a good reason for that. I recommend that you use the application Newsid from Sysinternals. You can get it here for free. It can't hurt to run it on the machine having a problem.
 
Oh absolutely. We build, clone, deploy, THEN name and bind to domain. It adds a few steps after the fact, but we find _everything_ to be smoother via this method.

Someday we'll check out sysprep, but after this 2-week battle, I'm ready for a vacation!
 
dleifelohcs said:
Oh absolutely. We build, clone, deploy, THEN name and bind to domain. It adds a few steps after the fact, but we find _everything_ to be smoother via this method.

Someday we'll check out sysprep, but after this 2-week battle, I'm ready for a vacation!
Click to expand...
Sysprep is cake and makes delploying computers so much easier and faster. Boot up the computer with the new image. Agree to terms, enter CD key, enter computer name, login as admin, add to domain, reboot, ready for user. (This is of course how we have the sysprep call file setup)

We have a simular issue with mapped drives. We dont use a login script for what ever reason, but the users drive sometimes maps to our main network share. The user has to disconnect the user share, logout, and log back in. We usea managed Symantec 10.1.5.x. I hear issues with SEP 11 anyway... so I am not upgrading for until its been out for some more time.
 
You must log in or register to reply here.
Back
Top