Recently we had an issue with a particular Windows terminal server running on Windows 2003.
When users logon to it, a default logon script runs which maps specific and standard drives for the user. One of the standard drive is our S drive. This maps the users to the root of our DFS group data tree.
During logon, all users had an error prompt from our logon script that the S drive cannot be mapped. Upon logged on and if we view My Computer, we could see the S drive there marked as “disconnected network drive”. Users could continue to browse their S drive despite this error. What was strange is that I get the drive even when I was logging on as an admin (which doesn’t run the logon script).
You see this occurs when somehow the server remembers a drive mapping at logon, and as a result when your logon script tries to map the same drive, it fails and Windows marks the drive as disconnected.
Anyway, this caused some frustrated users and they would immediately assumed that S drive was not available because of that.
I tried some recommendations off the Net but they did not work:
- removing mountpoints from the registry
- tried to disconnect it, but there was an error
- tried to reboot the server, but this did not work
However, one of the recommendation sounds mostly likely the cause of our problem. That is an issue caused by Symantec AV version 10.x. A quick check on our current version and confirmed that indeed SAV as below 10.1.4. We did an emergency change, had the SAV upgraded to 10.1.5, rebooted the server and the persistent drive issue dissappear.
- Roaming profiles are not saved on shutdown with Symantec AntiVirus 10.x installed’