Help me understand strange behavior with users and their documentsfolder

[Rafael Block]

This is sort of a follow up to a question I posted here a few days ago with the
subject users unable to delete/destroy files/folders in /users/%username% directory.

I can't help feeling that I am missing something big big big while I am distracted
by the small small small, so here is my problem, and if anyone can shed some light
on what I am doing wrong, and where my assumptions vary from the MS way [I am
trying to do all this intuitively, so I guess this is a usability lab microcosm].

I have set up a server. I have created a shared folder on the d:\ drive called users.

I set up a user [at first] by creating a new user in AD, then going back into the
user properties, accessing the profile tab, and add \\server\users\%username% and
in the home folder, local path box I put the same thing \\server\users\$username%.

The user logs onto the network for the first time, and windows creates the
'username' folder on the 'users' share.

When this user tried to move his/her MyDocs folder by right-clicking on it and
selecting 'move' they can move their docs to \\server\users\username. So far so good.

But when they try to delete files or move files, they re-appear in their old
location.

I figured out that under this scenario, the MyDocs properties target shows the
network share \\server\users\username, but this appears from the users perspective
to be a read only folder, and if they look on their own c:\ drive under 'documents
and settings,' there is a folder with their username present which has copies of
their documents, and THESE documents can be erased/moved/deleted. This local
folder seems to act as some kind of 'ghost' of the server share folder, but
without the delete/copy restrictions. Weird....

Next I set up a user on the server, but leave out the entry for profile path and
home directory.

User logs in, goes to change their MyDocs settings, browses to the network share,
and finds \\server\users\ present, clicks on 'add folder' and is able to create a
folder with their user name which works as I would expect, with the user able to
create/delete/edit/etc. This folder isn't 'ghosted' on their local
c:\documents_and_settings folder.

Somehow I am missing something here. I'm sure that this is an MS 'feature' and not
a bug, and though I can go back and re-create the users without the profile and
home directory entry, I really want to know WHY it doesn't behave as I think it
should.

Or, after checking out Minasi, CUE and SAM's books, none of them really address
just a 'real world' scenario of adding a bunch of users to a domain. They spend
copious space discussing mandatory profiles, etc. but if I'm doing something
wrong, I can't cipher it out by reading these books...help?

 

[Steve Duff [MVP]]

If I understand you, you entered the same path in the
user properties for the profile and the home directory.

While interesting, I have to say this is an extremely unusual
way to configure a user account. The fact that you are getting
strange results doesn't surprise me, what does surprise me is
that anything works much at all.

The profile path is used when you want to have a roaming profile.
When this value is filled in, Windows will automatically sync and save
local user changes to this folder on the server when you
log off (the profile path), so that if you then log on somewhere else
your updated profile can be downloaded from the server.

The profile is pretty much all the non-junk/temp stuff in
c:\documents and settings\<user>, especially including the user
registry file NTUSER.DAT. The server profile path should be
viewed as a server holding area for the roaming copy of that users
profile store.

By default, a user's "my documents" is in the profile tree and not excluded,
so it will roam too. This tends to slow things down unmercifully, so most
admins will move my-documents out of the local profile and map it
to a server share, which is normally what the second box in the
user settings is for (aka net use.../home).

Now what you've done is re-map the user's home folder back in to a
roaming profile where it already is roaming. Interesting, but...

Short story: what you want to do is create one tree for profile stores,
and a completely separate folder tree for home folders/mydocuments,
and list each in the user account separately, and I think that will end your and
your users' confusion.

Steve Duff, MCSE
Ergodic Systems, Inc.

This is sort of a follow up to a question I posted here a few days ago with the
subject users unable to delete/destroy files/folders in /users/%username% directory.

I can't help feeling that I am missing something big big big while I am distracted
by the small small small, so here is my problem, and if anyone can shed some light
on what I am doing wrong, and where my assumptions vary from the MS way [I am
trying to do all this intuitively, so I guess this is a usability lab microcosm].

I have set up a server. I have created a shared folder on the d:\ drive called users.

I set up a user [at first] by creating a new user in AD, then going back into the
user properties, accessing the profile tab, and add \\server\users\%username% and
in the home folder, local path box I put the same thing \\server\users\$username%.

The user logs onto the network for the first time, and windows creates the
'username' folder on the 'users' share.

When this user tried to move his/her MyDocs folder by right-clicking on it and
selecting 'move' they can move their docs to \\server\users\username. So far so good.

But when they try to delete files or move files, they re-appear in their old
location.

I figured out that under this scenario, the MyDocs properties target shows the
network share \\server\users\username, but this appears from the users perspective
to be a read only folder, and if they look on their own c:\ drive under 'documents
and settings,' there is a folder with their username present which has copies of
their documents, and THESE documents can be erased/moved/deleted. This local
folder seems to act as some kind of 'ghost' of the server share folder, but
without the delete/copy restrictions. Weird....

Next I set up a user on the server, but leave out the entry for profile path and
home directory.

User logs in, goes to change their MyDocs settings, browses to the network share,
and finds \\server\users\ present, clicks on 'add folder' and is able to create a
folder with their user name which works as I would expect, with the user able to
create/delete/edit/etc. This folder isn't 'ghosted' on their local
c:\documents_and_settings folder.

Somehow I am missing something here. I'm sure that this is an MS 'feature' and not
a bug, and though I can go back and re-create the users without the profile and
home directory entry, I really want to know WHY it doesn't behave as I think it
should.

Or, after checking out Minasi, CUE and SAM's books, none of them really address
just a 'real world' scenario of adding a bunch of users to a domain. They spend
copious space discussing mandatory profiles, etc. but if I'm doing something
wrong, I can't cipher it out by reading these books...help?