Home folder mapping randomly not working

We have assigned home folders (P to our users in AD. They are in the form
\\server\share\username.

More often than not, it works fine, but randomly, when a user logs on, the
home folder ends up as "share" rather than "share\username". You can
disconnect and reconnect to the correct folder and it's fine. This issue is
not specific to any particular user.

Any ideas why this is happening?

Hi John,

How are you mapping the users, through login script, AD or right in the
profile. Are you seeing any errors in the eventlog.

Bob

"John" <> wrote in message
news:%...
> We have assigned home folders (P to our users in AD. They are in the
> form \\server\share\username.
>
> More often than not, it works fine, but randomly, when a user logs on, the
> home folder ends up as "share" rather than "share\username". You can
> disconnect and reconnect to the correct folder and it's fine. This issue
> is not specific to any particular user.
>
> Any ideas why this is happening?
>

I have also seen this problem with the domain i look after (and it certainly
has been posted MANY time on this newgroup.) I could never find a solution to
it, so my workaround was to add a line into our logon to map a drive to
H:\server1name\sharename\%username
I also created a security group that i would add users into, which tied in
with this log on script (ie ifmember HomeFolders, then call LoginScript.cmd)
etc etc.
Its very annoying that there is a feature to be used, but it does not work
properly.
Grant.

"Bob Smith" wrote:

> Hi John,
>
> How are you mapping the users, through login script, AD or right in the
> profile. Are you seeing any errors in the eventlog.
>
> Bob
>
> "John" <> wrote in message
> news:%...
> > We have assigned home folders (P to our users in AD. They are in the
> > form \\server\share\username.
> >
> > More often than not, it works fine, but randomly, when a user logs on, the
> > home folder ends up as "share" rather than "share\username". You can
> > disconnect and reconnect to the correct folder and it's fine. This issue
> > is not specific to any particular user.
> >
> > Any ideas why this is happening?
> >
>

"John" wrote:

> We have assigned home folders (P to our users in AD. They are in the form
> \\server\share\username.
>
> More often than not, it works fine, but randomly, when a user logs on, the
> home folder ends up as "share" rather than "share\username". You can
> disconnect and reconnect to the correct folder and it's fine. This issue is
> not specific to any particular user.
>
> Any ideas why this is happening?
>
> Has anyone found anything on this subject of home drives yet. I am also experiencing this issue.
>

"John" wrote:

> We have assigned home folders (P to our users in AD. They are in the form
> \\server\share\username.
>
> More often than not, it works fine, but randomly, when a user logs on, the
> home folder ends up as "share" rather than "share\username". You can
> disconnect and reconnect to the correct folder and it's fine. This issue is
> not specific to any particular user.
>
> Any ideas why this is happening?
>
>
>

I am getting this same problem too.

We map the drive letter U for our users using the AD Profile tab in the form
\\server\users\%username%. Then upon saving it renames the %username%
wildcard to the user's username.

For some people it works fine, for some people it occasionally doesn't map
and a restart will solve it and for a few unlucky users (including me) it
happens every time without fail. A lot of people on this forum give the
off-hand answer that it's a permission problem which may be true of other
problems but in this case the permissions are set up so that Everyone has
full control on the share permissions and the NTFS permissions are set so
that Domain Admins and SYSTEM have full control, Authenticated Users have
read access and then each user has full control of their own home folder. I
am a domain admin and as such I have full control over almost everything and
so I can't see it being a permissions problem.

I've been reading the threads people have posted up about this problem and
the only way to solve it for certain seems to be to ditch the AD mapping and
use a logon script. I was thinking though could a slow domain controller or
network be the cause of it? Or even a misconfiguration within GP?

Can anyone shed any light on the ACTUAL workings of the home folder mapping
through AD?

"John" wrote:

> We have assigned home folders (P to our users in AD. They are in the form
> \\server\share\username.
>
> More often than not, it works fine, but randomly, when a user logs on, the
> home folder ends up as "share" rather than "share\username". You can
> disconnect and reconnect to the correct folder and it's fine. This issue is
> not specific to any particular user.
>
> Any ideas why this is happening?
>
>
>

This is a very common problem. Group policy is your answer.
http://support.microsoft.com/kb/q305293/ explains it best.
Basically, you need to tell your XP and later clients to wait for the network before allowing logon.
Simple solution.



CharlesSempl wrote:

I am getting this same problem too.
31-Aug-07

I am getting this same problem too.

We map the drive letter U for our users using the AD Profile tab in the form
\\server\users\%username%. Then upon saving it renames the %username%
wildcard to the user's username.

For some people it works fine, for some people it occasionally doesn't map
and a restart will solve it and for a few unlucky users (including me) it
happens every time without fail. A lot of people on this forum give the
off-hand answer that it's a permission problem which may be true of other
problems but in this case the permissions are set up so that Everyone has
full control on the share permissions and the NTFS permissions are set so
that Domain Admins and SYSTEM have full control, Authenticated Users have
read access and then each user has full control of their own home folder. I
am a domain admin and as such I have full control over almost everything and
so I can't see it being a permissions problem.

I've been reading the threads people have posted up about this problem and
the only way to solve it for certain seems to be to ditch the AD mapping and
use a logon script. I was thinking though could a slow domain controller or
network be the cause of it? Or even a misconfiguration within GP?

Can anyone shed any light on the ACTUAL workings of the home folder mapping
through AD?

"John" wrote:

Previous Posts In This Thread:

On Saturday, July 28, 2007 9:26 AM
John wrote:

Home folder mapping randomly not working
We have assigned home folders (P to our users in AD. They are in the form
\\server\share\username.

More often than not, it works fine, but randomly, when a user logs on, the
home folder ends up as "share" rather than "share\username". You can
disconnect and reconnect to the correct folder and it's fine. This issue is
not specific to any particular user.

Any ideas why this is happening?

On Saturday, July 28, 2007 2:05 PM
Bob Smith wrote:

Hi John,How are you mapping the users, through login script, AD or right in
Hi John,

How are you mapping the users, through login script, AD or right in the
profile. Are you seeing any errors in the eventlog.

Bob

On Sunday, July 29, 2007 11:16 PM
gbu wrote:

I have also seen this problem with the domain i look after (and it certainly
I have also seen this problem with the domain i look after (and it certainly
has been posted MANY time on this newgroup.) I could never find a solution to
it, so my workaround was to add a line into our logon to map a drive to
H:\server1name\sharename\%username
I also created a security group that i would add users into, which tied in
with this log on script (ie ifmember HomeFolders, then call LoginScript.cmd)
etc etc.
Its very annoying that there is a feature to be used, but it does not work
properly.
Grant.

"Bob Smith" wrote:

On Friday, August 17, 2007 5:53 PM
Larlor4 wrote:

RE: Home folder mapping randomly not working
"John" wrote:

On Friday, August 17, 2007 5:54 PM
Larlor4 wrote:

RE: Home folder mapping randomly not working
"John" wrote:

On Friday, August 31, 2007 5:36 AM
CharlesSempl wrote:

I am getting this same problem too.
I am getting this same problem too.

We map the drive letter U for our users using the AD Profile tab in the form
\\server\users\%username%. Then upon saving it renames the %username%
wildcard to the user's username.

For some people it works fine, for some people it occasionally doesn't map
and a restart will solve it and for a few unlucky users (including me) it
happens every time without fail. A lot of people on this forum give the
off-hand answer that it's a permission problem which may be true of other
problems but in this case the permissions are set up so that Everyone has
full control on the share permissions and the NTFS permissions are set so
that Domain Admins and SYSTEM have full control, Authenticated Users have
read access and then each user has full control of their own home folder. I
am a domain admin and as such I have full control over almost everything and
so I can't see it being a permissions problem.

I've been reading the threads people have posted up about this problem and
the only way to solve it for certain seems to be to ditch the AD mapping and
use a logon script. I was thinking though could a slow domain controller or
network be the cause of it? Or even a misconfiguration within GP?

Can anyone shed any light on the ACTUAL workings of the home folder mapping
through AD?

"John" wrote:

EggHeadCafe - Software Developer Portal of Choice
Custom configuration Data from DataSets: Less is More
http://www.eggheadcafe.com/tutorials...tion-data.aspx

http://support.microsoft.com/kb/q305293/ solves this issue.



CharlesSempl wrote:

I am getting this same problem too.
31-Aug-07

I am getting this same problem too

We map the drive letter U for our users using the AD Profile tab in the form
\\server\users\%username%. Then upon saving it renames the %username%
wildcard to the user's username

For some people it works fine, for some people it occasionally doesn't map
and a restart will solve it and for a few unlucky users (including me) it
happens every time without fail. A lot of people on this forum give the
off-hand answer that it's a permission problem which may be true of other
problems but in this case the permissions are set up so that Everyone has
full control on the share permissions and the NTFS permissions are set so
that Domain Admins and SYSTEM have full control, Authenticated Users have
read access and then each user has full control of their own home folder. I
am a domain admin and as such I have full control over almost everything and
so I can't see it being a permissions problem

I've been reading the threads people have posted up about this problem and
the only way to solve it for certain seems to be to ditch the AD mapping and
use a logon script. I was thinking though could a slow domain controller or
network be the cause of it? Or even a misconfiguration within GP

Can anyone shed any light on the ACTUAL workings of the home folder mapping
through AD

"John" wrote:

Previous Posts In This Thread:

On Saturday, July 28, 2007 9:26 AM
John wrote:

Home folder mapping randomly not working
We have assigned home folders (P to our users in AD. They are in the form
\\server\share\username

More often than not, it works fine, but randomly, when a user logs on, the
home folder ends up as "share" rather than "share\username". You can
disconnect and reconnect to the correct folder and it's fine. This issue is
not specific to any particular user

Any ideas why this is happening?

On Saturday, July 28, 2007 2:05 PM
Bob Smith wrote:

Hi John,How are you mapping the users, through login script, AD or right in
Hi John

How are you mapping the users, through login script, AD or right in th
profile. Are you seeing any errors in the eventlog

Bob

On Sunday, July 29, 2007 11:16 PM
gbu wrote:

I have also seen this problem with the domain i look after (and it certainly
I have also seen this problem with the domain i look after (and it certainly
has been posted MANY time on this newgroup.) I could never find a solution to
it, so my workaround was to add a line into our logon to map a drive to
H:\server1name\sharename\%usernam
I also created a security group that i would add users into, which tied in
with this log on script (ie ifmember HomeFolders, then call LoginScript.cmd)
etc etc
Its very annoying that there is a feature to be used, but it does not work
properly
Grant

"Bob Smith" wrote:

On Friday, August 17, 2007 5:53 PM
Larlor4 wrote:

RE: Home folder mapping randomly not working
"John" wrote:

On Friday, August 17, 2007 5:54 PM
Larlor4 wrote:

RE: Home folder mapping randomly not working
"John" wrote:

On Friday, August 31, 2007 5:36 AM
CharlesSempl wrote:

I am getting this same problem too.
I am getting this same problem too

We map the drive letter U for our users using the AD Profile tab in the form
\\server\users\%username%. Then upon saving it renames the %username%
wildcard to the user's username

For some people it works fine, for some people it occasionally doesn't map
and a restart will solve it and for a few unlucky users (including me) it
happens every time without fail. A lot of people on this forum give the
off-hand answer that it's a permission problem which may be true of other
problems but in this case the permissions are set up so that Everyone has
full control on the share permissions and the NTFS permissions are set so
that Domain Admins and SYSTEM have full control, Authenticated Users have
read access and then each user has full control of their own home folder. I
am a domain admin and as such I have full control over almost everything and
so I can't see it being a permissions problem.

I've been reading the threads people have posted up about this problem and
the only way to solve it for certain seems to be to ditch the AD mapping and
use a logon script. I was thinking though could a slow domain controller or
network be the cause of it? Or even a misconfiguration within GP?

Can anyone shed any light on the ACTUAL workings of the home folder mapping
through AD?

"John" wrote:

On Wednesday, November 11, 2009 12:00 PM
Chad Taylor wrote:

GPO to Solve this Issue
This is a very common problem. Group policy is your answer.
http://support.microsoft.com/kb/q305293/ explains it best.
Basically, you need to tell your XP and later clients to wait for the network before allowing logon.
Simple solution.

EggHeadCafe - Software Developer Portal of Choice
Efficient XML: Some basics for Windows developers
http://www.eggheadcafe.com/tutorials...ome-basic.aspx

I have the same issue of random home drives not mapping. I have the gpo "Always wait for the network at computer startup and logon" enabled and it has not made a difference. any other suggestions? I have two servers at the site and both are global cat so server availability should not be an issue.



Chad Taylor wrote:

GPO for Resolution
11-Nov-09

http://support.microsoft.com/kb/q305293/ solves this issue.

Previous Posts In This Thread:

On Saturday, July 28, 2007 9:26 AM
John wrote:

Home folder mapping randomly not working
We have assigned home folders (P to our users in AD. They are in the form
\\server\share\username

More often than not, it works fine, but randomly, when a user logs on, the
home folder ends up as "share" rather than "share\username". You can
disconnect and reconnect to the correct folder and it's fine. This issue is
not specific to any particular user

Any ideas why this is happening?

On Saturday, July 28, 2007 2:05 PM
Bob Smith wrote:

Hi John,How are you mapping the users, through login script, AD or right in
Hi John

How are you mapping the users, through login script, AD or right in th
profile. Are you seeing any errors in the eventlog

Bob

On Sunday, July 29, 2007 11:16 PM
gbu wrote:

I have also seen this problem with the domain i look after (and it certainly
I have also seen this problem with the domain i look after (and it certainly
has been posted MANY time on this newgroup.) I could never find a solution to
it, so my workaround was to add a line into our logon to map a drive to
H:\server1name\sharename\%usernam
I also created a security group that i would add users into, which tied in
with this log on script (ie ifmember HomeFolders, then call LoginScript.cmd)
etc etc
Its very annoying that there is a feature to be used, but it does not work
properly
Grant

"Bob Smith" wrote:

On Friday, August 17, 2007 5:53 PM
Larlor4 wrote:

RE: Home folder mapping randomly not working
"John" wrote:

On Friday, August 17, 2007 5:54 PM
Larlor4 wrote:

RE: Home folder mapping randomly not working
"John" wrote:

On Friday, August 31, 2007 5:36 AM
CharlesSempl wrote:

I am getting this same problem too.
I am getting this same problem too

We map the drive letter U for our users using the AD Profile tab in the form
\\server\users\%username%. Then upon saving it renames the %username%
wildcard to the user's username

For some people it works fine, for some people it occasionally doesn't map
and a restart will solve it and for a few unlucky users (including me) it
happens every time without fail. A lot of people on this forum give the
off-hand answer that it's a permission problem which may be true of other
problems but in this case the permissions are set up so that Everyone has
full control on the share permissions and the NTFS permissions are set so
that Domain Admins and SYSTEM have full control, Authenticated Users have
read access and then each user has full control of their own home folder. I
am a domain admin and as such I have full control over almost everything and
so I can't see it being a permissions problem

I've been reading the threads people have posted up about this problem and
the only way to solve it for certain seems to be to ditch the AD mapping and
use a logon script. I was thinking though could a slow domain controller or
network be the cause of it? Or even a misconfiguration within GP

Can anyone shed any light on the ACTUAL workings of the home folder mapping
through AD

"John" wrote:

On Wednesday, November 11, 2009 12:00 PM
Chad Taylor wrote:

GPO to Solve this Issue
This is a very common problem. Group policy is your answer.
http://support.microsoft.com/kb/q305293/ explains it best.
Basically, you need to tell your XP and later clients to wait for the network before allowing logon.
Simple solution.

On Wednesday, November 11, 2009 12:02 PM
Chad Taylor wrote:

GPO for Resolution
http://support.microsoft.com/kb/q305293/ solves this issue.


Submitted via EggHeadCafe - Software Developer Portal of Choice
Dr. Dotnetsky's Cool .NET Tips and Tricks # 5
http://www.eggheadcafe.com/tutorials...-cool-net.aspx