Bizarre Roaming Profile Issue

  • Thread starter Thread starter Gorilla
  • Start date Start date
G

Gorilla

So this could be in contention for wierdest problem I've seen yet.

Environment:
3- Windows 2003 Domain Controllers in Active Directory Native Mode.
Windows 2000 Professional SP4 Clients.

Using DNS, WINS, and DFS.

Profiles and Home Directories are stored on a Netapp Filer.

This problem has not been able to be duplicated and happens in a
sporadic and random order it seems. Upon LOGOUT, at times, a users
Roaming Profile which should write out to
\\Server1\Profiles$\%username%\WINNT fails. Instead, a new USERNAME
folder is created in a whole different location.

This only seems to happen on a log out and happens maybe to one user a
day. The users are in different deparments and their profile never
stays pointed there. When they log in next they are reading from and
writing to the proper path.

The other point of interest is that we have an L: mapping which is the
root of each department folder. So as an example, a member of Finanace
would have their Profile folder temporarily written out to L:\Finance.
There is a separate mapping for this drive as well: X: which is
\\<Server1_Alias>\Dept Share

One additional symptom that may be related is that some users on
occasion have reported that *suddenly* when they click on their
Deparment folder in L: they instead see the contents of their Home
Directory (P:). All other Department folder display correctly off the
root of L:
From a command line during an afflicted session, I tested the following
Click to expand...
resolutions:
\\Server1\Dept$ = Home Directory -WRONG
\\Server1_Alias\Dept$ = Home Directory -WRONG
\\<IP Address>\Dept$ = Dept. Folder -RIGHT

I've gone over DNS, WINS, and DFS with a fine tooth comb. Checked all
the settings on the filer. I can't pinpoint anything that change.
Automatice Updates I've researched don't seem to offer any clues
either.

This is easily the most bizarre issue I've seen in 15+ years. The
inability to duplicate it coupled with the mysterious symptoms have
left me hoping someone, somewhere has an idea.

Thanks for any ideas or suggestions.
 
In
Gorilla said:
So this could be in contention for wierdest problem I've seen yet.

Environment:
3- Windows 2003 Domain Controllers in Active Directory Native Mode.
Windows 2000 Professional SP4 Clients.

Using DNS, WINS, and DFS.

Profiles and Home Directories are stored on a Netapp Filer.

This problem has not been able to be duplicated and happens in a
sporadic and random order it seems. Upon LOGOUT, at times, a users
Roaming Profile which should write out to
\\Server1\Profiles$\%username%\WINNT fails.
Click to expand...

I'm curious about the \WINNT ... is that something you set up as a subfolder
for some reason?
Instead, a new USERNAME
folder is created in a whole different location.
Click to expand...

As in, an *entirely* different path on the server?

Are you using folder redirection via Group Policy? (you should - for My
Documents and perhaps even Desktop - I'd redirect to the user's home
directory)
This only seems to happen on a log out and happens maybe to one user a
day. The users are in different deparments and their profile never
stays pointed there. When they log in next they are reading from and
writing to the proper path.

The other point of interest is that we have an L: mapping which is the
root of each department folder. So as an example, a member of Finanace
would have their Profile folder temporarily written out to L:\Finance.
There is a separate mapping for this drive as well: X: which is
\\<Server1_Alias>\Dept Share

One additional symptom that may be related is that some users on
occasion have reported that *suddenly* when they click on their
Deparment folder in L: they instead see the contents of their Home
Directory (P:). All other Department folder display correctly off the
root of L:

resolutions:
\\Server1\Dept$ = Home Directory -WRONG
\\Server1_Alias\Dept$ = Home Directory -WRONG
\\<IP Address>\Dept$ = Dept. Folder -RIGHT

I've gone over DNS, WINS, and DFS with a fine tooth comb. Checked all
the settings on the filer. I can't pinpoint anything that change.
Automatice Updates I've researched don't seem to offer any clues
either.

This is easily the most bizarre issue I've seen in 15+ years. The
inability to duplicate it coupled with the mysterious symptoms have
left me hoping someone, somewhere has an idea.

Thanks for any ideas or suggestions.
Click to expand...

I'd begin by installing the User Profile Hive Cleanup utility on all the
clients - and check the event logs on a workstation where you've seen this
problem occur.
 
The WINNT folder is a hold over from before I was here. Just a folder
in the profile path. I've done away with it as a part of out XP
migration but I'm in the middle of that project so many users still
have that profile path.

As for the new folder, yes it's a new location. Same Filer but a whole
different share and path. Basically they log out and the locally cached
profile is written out to the network but to the wrong location. Next
time they log on they are connected to the correct profile and the
erroneous folder can be deleted.

We're not using any Folder Redirection...yet. It's planned but we're
getting a new SAN up first.

Event logs show nothing. Haven't tried the Hive Cleanup tool but this
is happening to many different users on seemingly random basis.

Thanks for the response. I'll give the Hive Cleanup tool a look. This
is a real brain teaser. Let me know what information I can provide that
I haven't if it will assist with understanding how this could be
happening.
 
In
Gorilla said:
The WINNT folder is a hold over from before I was here. Just a folder
in the profile path. I've done away with it as a part of out XP
migration but I'm in the middle of that project so many users still
have that profile path.

As for the new folder, yes it's a new location. Same Filer but a
whole different share and path. Basically they log out and the
locally cached profile is written out to the network but to the wrong
location. Next time they log on they are connected to the correct
profile and the erroneous folder can be deleted.

We're not using any Folder Redirection...yet. It's planned but we're
getting a new SAN up first.

Event logs show nothing. Haven't tried the Hive Cleanup tool but this
is happening to many different users on seemingly random basis.

Thanks for the response. I'll give the Hive Cleanup tool a look.
Click to expand...

It's a must!
This
is a real brain teaser. Let me know what information I can provide
that I haven't if it will assist with understanding how this could be
happening.
Click to expand...

How big are the profiles in question? If you don't have folder redirection,
you likely have humumgous profiles, and that can definitely cause problems.
I haven't heard of your specific issue before, but as a test, try with a
small test profile and use the User Profile Hive Cleanup thing (which you
can assign via GPO)...
 
Yeah the profiles here can get very large. We will be implementing
Folder Redirection w/ Offline Files soon.

But I have new information. I got to sit with an affected client and
it's very bizarre indeed.

Basically there's an L: drive mapped to \\<domain dfs>\<share>
The <domin dfs> is point to a file server \\fileserver and there's an
alias \\serveralias

Now there's an X: mapping to \\serveralias\smb$ which is a folder
nested in L: \\<domain dfs>\<share>\smb$

When one 'possible symptom' occurs, here's some of the behavior I
observed.

L:\smb$ drive looks like their P: drive (home directory) which is
mapped to \\fileserver\usersname$
From a command prompt the following did NOT work properly:
Click to expand...
\\filerserver\smb$
However, \\serveralias\smb$ worked fine. Both resolve to the same IP
Address on the client and point to the same smb share.

Also of note, using net use I removed and re-added the L: share. No
difference. BUT...when remapping to a new drive letter it worked fine.
And then when deleting it and creating it with the L: again, it worked
fine.

So it doesn't make sense since the share is showing a completely
different share when it goes wonky. I could see how an incorrect
resolution would replace the netbios or dns name of the server, but the
shares have 2 totally different names and are on different folders. How
they get crossed is really a stumper.

Does this all make any sense? Anyone seen anything like this ever?

-KG
 
In
Gorilla said:
Yeah the profiles here can get very large. We will be implementing
Folder Redirection w/ Offline Files soon.
Click to expand...

I wouldn't use offline files unless they're all laptop users (in fact, I
don't use offline files at all; I like a third party shareware app for file
syncing on laptops). It doesn't make any sense to me to have that on a LAN -
it complicates matters immensely and will likely cause problems down the
road.

Just use folder redirection, for My Documents and, perhaps, Desktop.

But I have new information. I got to sit with an affected client and
it's very bizarre indeed.

Basically there's an L: drive mapped to \\<domain dfs>\<share>
The <domin dfs> is point to a file server \\fileserver and there's an
alias \\serveralias

Now there's an X: mapping to \\serveralias\smb$ which is a folder
nested in L: \\<domain dfs>\<share>\smb$

When one 'possible symptom' occurs, here's some of the behavior I
observed.

L:\smb$ drive looks like their P: drive (home directory) which is
mapped to \\fileserver\usersname$
\\filerserver\smb$
However, \\serveralias\smb$ worked fine. Both resolve to the same IP
Address on the client and point to the same smb share.
Click to expand...

I'm not a DFS expert by any means, sorry.
Also of note, using net use I removed and re-added the L: share. No
difference. BUT...when remapping to a new drive letter it worked fine.
And then when deleting it and creating it with the L: again, it worked
fine.

So it doesn't make sense since the share is showing a completely
different share when it goes wonky. I could see how an incorrect
resolution would replace the netbios or dns name of the server, but
the shares have 2 totally different names and are on different
folders. How they get crossed is really a stumper.

Does this all make any sense? Anyone seen anything like this ever?
Click to expand...

You might try posting that as a new thread in a Win2k server group -
updating the details with what you've found out/fixed/already
-KG
Click to expand...

<snip>
 
Back
Top