We're having the same problem here - We have mapped the U: drive to user home
folders using the tool provided in the Profile tab, in Active Directory Users
and Computers, and periodically the mapping resets for no apparent reason to
the root of the DFS share that the user folders are hosted on. Resetting the
entry in the Profile tab manually for each user as they report it (if they
report it), seems to work... but this is hardly an enterprise level solution.
It would take decades to sort through hundreds of profiles and reset each
one. Also, there's no way to tell who is experiencing the problem unless they
log in and find that they can't access their home folder.
It is interesting to note that for users affected by the problem, the U:
drive mapping points to the DFS root where we have stored the user home
folders, but when using cmd the home folder that immediately appears is the
U: drive, pointing to the folder there as though the U: drive were mapped
directly to the share. That is to say, instead of seeing U:> (which points to
the user's home folder), we see U:\users\username\> as though U: were mapped
to our DFS root.
The question is why it's 'resetting' to begin with. When we initially mapped
each home folder, we used the %username% variable
(\\ourdomain\DFSshare\Userfolders\%username%) and it generated a folder
structure for us with the appropriate permissions for each user, and
everything was fine. Then users began to report the problem, and I initially
thought it was a permissions issue, but that seems not to be the case, as the
permissions are fine. They all have the appropriate user mapped to them, and
inherit permissions from the previous folder in the structure which allows
administrators to access all user folders.
I can't find any other mentions of this problem anywhere on the internet,
except one which seemed to suggest that it had something to do with the
%username% variable not returning a value and as a result the drive not being
mapped.
Another solution indicated that using "fast logons", or the policy object
which requires PCs to wait for the network before logging in, can cause this
problem, but this policy was already set to wait for the network to resolve
another issue we were having with other drive mappings not appearing. That
turned out to be resolved through a hotfix (XP machines don't get Server 2008
group policy preferences without a hotfix). So it doesn't seem to affect the
problem either way.
Anyway, this problem is very frustrating as there seems to be no avenue to
take to track down what is actually causing it. In a test environment, it
continues to occur intermittently, so we know it's not an issue with our own
software interfering with the mapping. It must have something to do with the
way the client machines are interfacing with the server. We have 2000, XP,
and Vista machines which are all experiencing this problem. HELP!
