Users map entire home folder during logon

Hi there! I'm experiencing a problem with users during the logon process.
They should map their home directory during this process, which you all know
happens automatically in W2K3 Server. In the properties fane of the user
objects, we've set the users to connect X: to \\servername\home\username. We
use a W2K domain controller, W2K3 file server, and WinXP SP2 clients, by the
way.

However, sometimes the users don't map their personal home directory, but
instead get a mapping of the entire home folder on the server.

That is to say, instead of getting mapped drive X:\ as "username on
servername", they get "home on servername", that is the entire home folder
for all users. What gives? Of course they only have permissions to view their
own personal home folder, and can navigate to their own folder, but still it
can be somewhat confusing to the users. This does cause a problem for some
users, due to the fact that they use applications that specify a path to
their home directory, and when the mapping fails, the application fails.

I've looked through the Event Viewer, on both the client and the server, and
can't find anything to explain this behavior. It seems to appear at random
intervals. Usually logging out and back in solves the problem, but not
always. I'm at a loss here. Anyone experienced the same thing? Any
suggenstions on how to solve this problem?


-Dnort -

Are you doing this via batch file or policies?
Are permissions properly set for all folders and sub folders?
Are you share there is policy around that dictated connecting to the root of
the share rather then the share itself?

--
Amnon Feiner
http://www.woodcontour.com
Solid Wood & Stone PC Peripherals.
"Dnort" <> wrote in message
news:3142B9D1-0673-45DA-A427-...
> Hi there! I'm experiencing a problem with users during the logon process.
> They should map their home directory during this process, which you all
> know
> happens automatically in W2K3 Server. In the properties fane of the user
> objects, we've set the users to connect X: to \\servername\home\username.
> We
> use a W2K domain controller, W2K3 file server, and WinXP SP2 clients, by
> the
> way.
>
> However, sometimes the users don't map their personal home directory, but
> instead get a mapping of the entire home folder on the server.
>
> That is to say, instead of getting mapped drive X:\ as "username on
> servername", they get "home on servername", that is the entire home folder
> for all users. What gives? Of course they only have permissions to view
> their
> own personal home folder, and can navigate to their own folder, but still
> it
> can be somewhat confusing to the users. This does cause a problem for some
> users, due to the fact that they use applications that specify a path to
> their home directory, and when the mapping fails, the application fails.
>
> I've looked through the Event Viewer, on both the client and the server,
> and
> can't find anything to explain this behavior. It seems to appear at random
> intervals. Usually logging out and back in solves the problem, but not
> always. I'm at a loss here. Anyone experienced the same thing? Any
> suggenstions on how to solve this problem?
>
>
> -Dnort -

A. Feiner wrote:
> Are you doing this via batch file or policies?
> Are permissions properly set for all folders and sub folders?
> Are you share there is policy around that dictated connecting to the root of
> the share rather then the share itself?
>

Dnort wrote:
> Hi there! I'm experiencing a problem with users during the logon process.
> They should map their home directory during this process, which you all know
> happens automatically in W2K3 Server. In the properties fane of the user
> objects, we've set the users to connect X: to \\servername\home\username. We
> use a W2K domain controller, W2K3 file server, and WinXP SP2 clients, by the
> way.
>
> However, sometimes the users don't map their personal home directory, but
> instead get a mapping of the entire home folder on the server.
>
> That is to say, instead of getting mapped drive X:\ as "username on
> servername", they get "home on servername", that is the entire home folder
> for all users. What gives? Of course they only have permissions to view their
> own personal home folder, and can navigate to their own folder, but still it
> can be somewhat confusing to the users. This does cause a problem for some
> users, due to the fact that they use applications that specify a path to
> their home directory, and when the mapping fails, the application fails.
>
> I've looked through the Event Viewer, on both the client and the server, and
> can't find anything to explain this behavior. It seems to appear at random
> intervals. Usually logging out and back in solves the problem, but not
> always. I'm at a loss here. Anyone experienced the same thing? Any
> suggenstions on how to solve this problem?
>
>
> -Dnort -
Are you setting this via a variable in the User Account? - Is the entry
for the variable valid? (%username%) or Does the homedir path match the
actual path (is the account name the same as the home dir name?)

Did windows create the home directories for you? Do the users have the
necessary permissions?


Ian

"Are you doing this via batch file or policies?
Are permissions properly set for all folders and sub folders?
Are you share there is policy around that dictated connecting to the root of
the share rather then the share itself?"

This is done via the variable in the User Account in AD, that is in the
properties fane of the user objects, we've set the users to connect X: to
\\SERVERNAME\home\USERNAME (where username is the actual username).

Permissions are indeed correct, the shares are only accessible by the group
which the users belong to. They have full control on the share permission for
the home folder, and "list folder contents" on the home folder. Each user has
all rights except modify on their own personal home folder, and administrator
and domain admins has full control. The permissions seem to be in order. As
I've stated, this is a freak behavior happening maybe 1% of the time.


"Are you setting this via a variable in the User Account? - Is the entry
for the variable valid? (%username%) or Does the homedir path match the
actual path (is the account name the same as the home dir name?)

The homedir path does indeed match the actual path, that is
\\SERVERNAME\home\USERNAME, where USERNAME is the actual username

"Did windows create the home directories for you? Do the users have the
necessary permissions?"

We created the homedirs ourselves, when we migrated from NetWare servers to
Windows. The folders were created using a simple batch script. As stated
above, only the user has permissions to their personal home folder, along
with administrators and domain admins.

I found another thread on the same subject on another newsgroup (which I'm
sad to say I don't have a bookmark on), but no solution in sight, at least
not one that won't require lots of work. The best advice was to not use the
in-built mechanism of assigning home folders in the user objects in AD, but
rather script them. This would mean quite a lot of work, so I'll be looking
for other solutions in the meantime.

Thanks for for replys.

We are experiencing the exact same issue. This issue started popping up at
my previous employer when we upgraded desktops to WinXP SP2. One of my
co-workers also experienced this issue at her previous employer. I am
suprised that there is not more discussion on this topic. I haven't found a
hint of others with this issue via "googling" and there doesn't seem to be a
MS knowledge base article...yet.

From our testing so far it seems to be a timing issue (ever wonder how WinXP
starts up so fast???). My hunch is that some service is not able to start up
in time to map the home folder. I have noticed the issue mostly when logging
on to a system after a cold boot. It also seems to be more prevalent on new
machines. If you wait 30 seconds or so after the logon screen is displayed
you have a better chance of getting the home folder mapped correctly.

We have found 2 work arounds and 1 possible solution. The work arounds
include 1) when cold booting a machine, wait 30 seconds or so after the logon
sceen has been dislayed to actually logon. 2) disable hyper-threading.

A possible true fix that we haven't tested fully is using the fully
qualified domain name in your home folder path (i.e.
\\fileserver.domain.com\home\username instead of \\fileserver\home\username).
Initial testing seems to show that this fixes the problem, but we haven't
applied this to all users yet so it is hard to know for sure.

I would be very interested to hear if using fully qualified domain names
works as a fix in your environmnet.

-Ryan



"Dnort" wrote:

> "Are you doing this via batch file or policies?
> Are permissions properly set for all folders and sub folders?
> Are you share there is policy around that dictated connecting to the root of
> the share rather then the share itself?"
>
> This is done via the variable in the User Account in AD, that is in the
> properties fane of the user objects, we've set the users to connect X: to
> \\SERVERNAME\home\USERNAME (where username is the actual username).
>
> Permissions are indeed correct, the shares are only accessible by the group
> which the users belong to. They have full control on the share permission for
> the home folder, and "list folder contents" on the home folder. Each user has
> all rights except modify on their own personal home folder, and administrator
> and domain admins has full control. The permissions seem to be in order. As
> I've stated, this is a freak behavior happening maybe 1% of the time.
>
>
> "Are you setting this via a variable in the User Account? - Is the entry
> for the variable valid? (%username%) or Does the homedir path match the
> actual path (is the account name the same as the home dir name?)
>
> The homedir path does indeed match the actual path, that is
> \\SERVERNAME\home\USERNAME, where USERNAME is the actual username
>
> "Did windows create the home directories for you? Do the users have the
> necessary permissions?"
>
> We created the homedirs ourselves, when we migrated from NetWare servers to
> Windows. The folders were created using a simple batch script. As stated
> above, only the user has permissions to their personal home folder, along
> with administrators and domain admins.
>
> I found another thread on the same subject on another newsgroup (which I'm
> sad to say I don't have a bookmark on), but no solution in sight, at least
> not one that won't require lots of work. The best advice was to not use the
> in-built mechanism of assigning home folders in the user objects in AD, but
> rather script them. This would mean quite a lot of work, so I'll be looking
> for other solutions in the meantime.
>
> Thanks for for replys.
>

This is quite possibly due to the 'Fast Logon Optimization' that WINXP
does.....Have you seen the article for it? It is a GPO.....

--
Cary W. Shultz
Roanoke, VA 24012

http://www.activedirectory-win2000.com
(soon to be updated!!!)
http://www.grouppolicy-win2000.com
(soon to be updated!!!)



"Ryan" <> wrote in message
news:E0337DD7-7EC1-4E48-B029-...
> We are experiencing the exact same issue. This issue started popping up
> at
> my previous employer when we upgraded desktops to WinXP SP2. One of my
> co-workers also experienced this issue at her previous employer. I am
> suprised that there is not more discussion on this topic. I haven't found
> a
> hint of others with this issue via "googling" and there doesn't seem to be
> a
> MS knowledge base article...yet.
>
> From our testing so far it seems to be a timing issue (ever wonder how
> WinXP
> starts up so fast???). My hunch is that some service is not able to start
> up
> in time to map the home folder. I have noticed the issue mostly when
> logging
> on to a system after a cold boot. It also seems to be more prevalent on
> new
> machines. If you wait 30 seconds or so after the logon screen is
> displayed
> you have a better chance of getting the home folder mapped correctly.
>
> We have found 2 work arounds and 1 possible solution. The work arounds
> include 1) when cold booting a machine, wait 30 seconds or so after the
> logon
> sceen has been dislayed to actually logon. 2) disable hyper-threading.
>
> A possible true fix that we haven't tested fully is using the fully
> qualified domain name in your home folder path (i.e.
> \\fileserver.domain.com\home\username instead of
> \\fileserver\home\username).
> Initial testing seems to show that this fixes the problem, but we haven't
> applied this to all users yet so it is hard to know for sure.
>
> I would be very interested to hear if using fully qualified domain names
> works as a fix in your environmnet.
>
> -Ryan
>
>
>
> "Dnort" wrote:
>
>> "Are you doing this via batch file or policies?
>> Are permissions properly set for all folders and sub folders?
>> Are you share there is policy around that dictated connecting to the root
>> of
>> the share rather then the share itself?"
>>
>> This is done via the variable in the User Account in AD, that is in the
>> properties fane of the user objects, we've set the users to connect X:
>> to
>> \\SERVERNAME\home\USERNAME (where username is the actual username).
>>
>> Permissions are indeed correct, the shares are only accessible by the
>> group
>> which the users belong to. They have full control on the share permission
>> for
>> the home folder, and "list folder contents" on the home folder. Each user
>> has
>> all rights except modify on their own personal home folder, and
>> administrator
>> and domain admins has full control. The permissions seem to be in order.
>> As
>> I've stated, this is a freak behavior happening maybe 1% of the time.
>>
>>
>> "Are you setting this via a variable in the User Account? - Is the entry
>> for the variable valid? (%username%) or Does the homedir path match the
>> actual path (is the account name the same as the home dir name?)
>>
>> The homedir path does indeed match the actual path, that is
>> \\SERVERNAME\home\USERNAME, where USERNAME is the actual username
>>
>> "Did windows create the home directories for you? Do the users have the
>> necessary permissions?"
>>
>> We created the homedirs ourselves, when we migrated from NetWare servers
>> to
>> Windows. The folders were created using a simple batch script. As stated
>> above, only the user has permissions to their personal home folder, along
>> with administrators and domain admins.
>>
>> I found another thread on the same subject on another newsgroup (which
>> I'm
>> sad to say I don't have a bookmark on), but no solution in sight, at
>> least
>> not one that won't require lots of work. The best advice was to not use
>> the
>> in-built mechanism of assigning home folders in the user objects in AD,
>> but
>> rather script them. This would mean quite a lot of work, so I'll be
>> looking
>> for other solutions in the meantime.
>>
>> Thanks for for replys.
>>

Thanks Cary, that is a great lead. I will test enabling the "Always wait for
the network at computer startup and logon" GPO setting (disables fast logon
optimization).

Interestingly enough, according to two Microsoft articles this option is
disabled automatically when users have a home directory. Here are the
articles I found:

http://msdn.microsoft.com/library/de...timization.asp

http://www.microsoft.com/technet/pro...848df2ab9.mspx

Maybe the policy is not actually being disabled when users have a home
folder specified? I will test this theory and post my results.

-Ryan


"Cary Shultz" wrote:

> This is quite possibly due to the 'Fast Logon Optimization' that WINXP
> does.....Have you seen the article for it? It is a GPO.....
>
> --
> Cary W. Shultz
> Roanoke, VA 24012
>
> http://www.activedirectory-win2000.com
> (soon to be updated!!!)
> http://www.grouppolicy-win2000.com
> (soon to be updated!!!)
>
>
>
> "Ryan" <> wrote in message
> news:E0337DD7-7EC1-4E48-B029-...
> > We are experiencing the exact same issue. This issue started popping up
> > at
> > my previous employer when we upgraded desktops to WinXP SP2. One of my
> > co-workers also experienced this issue at her previous employer. I am
> > suprised that there is not more discussion on this topic. I haven't found
> > a
> > hint of others with this issue via "googling" and there doesn't seem to be
> > a
> > MS knowledge base article...yet.
> >
> > From our testing so far it seems to be a timing issue (ever wonder how
> > WinXP
> > starts up so fast???). My hunch is that some service is not able to start
> > up
> > in time to map the home folder. I have noticed the issue mostly when
> > logging
> > on to a system after a cold boot. It also seems to be more prevalent on
> > new
> > machines. If you wait 30 seconds or so after the logon screen is
> > displayed
> > you have a better chance of getting the home folder mapped correctly.
> >
> > We have found 2 work arounds and 1 possible solution. The work arounds
> > include 1) when cold booting a machine, wait 30 seconds or so after the
> > logon
> > sceen has been dislayed to actually logon. 2) disable hyper-threading.
> >
> > A possible true fix that we haven't tested fully is using the fully
> > qualified domain name in your home folder path (i.e.
> > \\fileserver.domain.com\home\username instead of
> > \\fileserver\home\username).
> > Initial testing seems to show that this fixes the problem, but we haven't
> > applied this to all users yet so it is hard to know for sure.
> >
> > I would be very interested to hear if using fully qualified domain names
> > works as a fix in your environmnet.
> >
> > -Ryan
> >
> >
> >
> > "Dnort" wrote:
> >
> >> "Are you doing this via batch file or policies?
> >> Are permissions properly set for all folders and sub folders?
> >> Are you share there is policy around that dictated connecting to the root
> >> of
> >> the share rather then the share itself?"
> >>
> >> This is done via the variable in the User Account in AD, that is in the
> >> properties fane of the user objects, we've set the users to connect X:
> >> to
> >> \\SERVERNAME\home\USERNAME (where username is the actual username).
> >>
> >> Permissions are indeed correct, the shares are only accessible by the
> >> group
> >> which the users belong to. They have full control on the share permission
> >> for
> >> the home folder, and "list folder contents" on the home folder. Each user
> >> has
> >> all rights except modify on their own personal home folder, and
> >> administrator
> >> and domain admins has full control. The permissions seem to be in order.
> >> As
> >> I've stated, this is a freak behavior happening maybe 1% of the time.
> >>
> >>
> >> "Are you setting this via a variable in the User Account? - Is the entry
> >> for the variable valid? (%username%) or Does the homedir path match the
> >> actual path (is the account name the same as the home dir name?)
> >>
> >> The homedir path does indeed match the actual path, that is
> >> \\SERVERNAME\home\USERNAME, where USERNAME is the actual username
> >>
> >> "Did windows create the home directories for you? Do the users have the
> >> necessary permissions?"
> >>
> >> We created the homedirs ourselves, when we migrated from NetWare servers
> >> to
> >> Windows. The folders were created using a simple batch script. As stated
> >> above, only the user has permissions to their personal home folder, along
> >> with administrators and domain admins.
> >>
> >> I found another thread on the same subject on another newsgroup (which
> >> I'm
> >> sad to say I don't have a bookmark on), but no solution in sight, at
> >> least
> >> not one that won't require lots of work. The best advice was to not use
> >> the
> >> in-built mechanism of assigning home folders in the user objects in AD,
> >> but
> >> rather script them. This would mean quite a lot of work, so I'll be
> >> looking
> >> for other solutions in the meantime.
> >>
> >> Thanks for for replys.
> >>
>
>
>

I just wanted to report back to anyone who sees this thread that disabling
fast logon optimization does in fact fix this issue.

"Ryan" wrote:

> Thanks Cary, that is a great lead. I will test enabling the "Always wait for
> the network at computer startup and logon" GPO setting (disables fast logon
> optimization).
>
> Interestingly enough, according to two Microsoft articles this option is
> disabled automatically when users have a home directory. Here are the
> articles I found:
>
> http://msdn.microsoft.com/library/de...timization.asp
>
> http://www.microsoft.com/technet/pro...848df2ab9.mspx
>
> Maybe the policy is not actually being disabled when users have a home
> folder specified? I will test this theory and post my results.
>
> -Ryan
>
>
> "Cary Shultz" wrote:
>
> > This is quite possibly due to the 'Fast Logon Optimization' that WINXP
> > does.....Have you seen the article for it? It is a GPO.....
> >
> > --
> > Cary W. Shultz
> > Roanoke, VA 24012
> >
> > http://www.activedirectory-win2000.com
> > (soon to be updated!!!)
> > http://www.grouppolicy-win2000.com
> > (soon to be updated!!!)
> >
> >
> >
> > "Ryan" <> wrote in message
> > news:E0337DD7-7EC1-4E48-B029-...
> > > We are experiencing the exact same issue. This issue started popping up
> > > at
> > > my previous employer when we upgraded desktops to WinXP SP2. One of my
> > > co-workers also experienced this issue at her previous employer. I am
> > > suprised that there is not more discussion on this topic. I haven't found
> > > a
> > > hint of others with this issue via "googling" and there doesn't seem to be
> > > a
> > > MS knowledge base article...yet.
> > >
> > > From our testing so far it seems to be a timing issue (ever wonder how
> > > WinXP
> > > starts up so fast???). My hunch is that some service is not able to start
> > > up
> > > in time to map the home folder. I have noticed the issue mostly when
> > > logging
> > > on to a system after a cold boot. It also seems to be more prevalent on
> > > new
> > > machines. If you wait 30 seconds or so after the logon screen is
> > > displayed
> > > you have a better chance of getting the home folder mapped correctly.
> > >
> > > We have found 2 work arounds and 1 possible solution. The work arounds
> > > include 1) when cold booting a machine, wait 30 seconds or so after the
> > > logon
> > > sceen has been dislayed to actually logon. 2) disable hyper-threading.
> > >
> > > A possible true fix that we haven't tested fully is using the fully
> > > qualified domain name in your home folder path (i.e.
> > > \\fileserver.domain.com\home\username instead of
> > > \\fileserver\home\username).
> > > Initial testing seems to show that this fixes the problem, but we haven't
> > > applied this to all users yet so it is hard to know for sure.
> > >
> > > I would be very interested to hear if using fully qualified domain names
> > > works as a fix in your environmnet.
> > >
> > > -Ryan
> > >
> > >
> > >
> > > "Dnort" wrote:
> > >
> > >> "Are you doing this via batch file or policies?
> > >> Are permissions properly set for all folders and sub folders?
> > >> Are you share there is policy around that dictated connecting to the root
> > >> of
> > >> the share rather then the share itself?"
> > >>
> > >> This is done via the variable in the User Account in AD, that is in the
> > >> properties fane of the user objects, we've set the users to connect X:
> > >> to
> > >> \\SERVERNAME\home\USERNAME (where username is the actual username).
> > >>
> > >> Permissions are indeed correct, the shares are only accessible by the
> > >> group
> > >> which the users belong to. They have full control on the share permission
> > >> for
> > >> the home folder, and "list folder contents" on the home folder. Each user
> > >> has
> > >> all rights except modify on their own personal home folder, and
> > >> administrator
> > >> and domain admins has full control. The permissions seem to be in order.
> > >> As
> > >> I've stated, this is a freak behavior happening maybe 1% of the time.
> > >>
> > >>
> > >> "Are you setting this via a variable in the User Account? - Is the entry
> > >> for the variable valid? (%username%) or Does the homedir path match the
> > >> actual path (is the account name the same as the home dir name?)
> > >>
> > >> The homedir path does indeed match the actual path, that is
> > >> \\SERVERNAME\home\USERNAME, where USERNAME is the actual username
> > >>
> > >> "Did windows create the home directories for you? Do the users have the
> > >> necessary permissions?"
> > >>
> > >> We created the homedirs ourselves, when we migrated from NetWare servers
> > >> to
> > >> Windows. The folders were created using a simple batch script. As stated
> > >> above, only the user has permissions to their personal home folder, along
> > >> with administrators and domain admins.
> > >>
> > >> I found another thread on the same subject on another newsgroup (which
> > >> I'm
> > >> sad to say I don't have a bookmark on), but no solution in sight, at
> > >> least
> > >> not one that won't require lots of work. The best advice was to not use
> > >> the
> > >> in-built mechanism of assigning home folders in the user objects in AD,
> > >> but
> > >> rather script them. This would mean quite a lot of work, so I'll be
> > >> looking
> > >> for other solutions in the meantime.
> > >>
> > >> Thanks for for replys.
> > >>
> >
> >
> >