Tom's Guide | Tom's Hardware | Tom's Games
![]() |
![]() |
![]() |
I have home folders setup for several hundred users in each of their profiles. A couple of months ago a couple of users started complaining that their "home drive" was showing a list of all users. I confirmed this. Example: Instead of H: mapping to \\fileserver\home\bob it was only mapping to \\fileserver\home. Once they find their folder they can access it with no problems. I have tried removing and adding the mapping in their profile, checked permissions. ANY ideas would be appreciated. Thanks.

Did you make the shares Admin shares? Meaning they are only accessible using the $ after the share name?
Do you have the path set in the user's AD profiles? They shouldn't need to manually map that file. It should come up automatically.
Life's more painless for the brainless.

No the shares are not hidden. I have setup the home folders in each users profile. They are not mapping them manually. But when they click on their home drive many of them are seeing a list of all users folders instead of taking them directly to their own.
Thanks.

That's right. As long as they have list access to the root share, they will be able to see all the share names, though unable to access them.
I would change them all to Admin shares and then nobody can see anyone else's folder. There's no need for them to see what else exists in that root share.
Life's more painless for the brainless.

OK. When you setup a home folder in the users Profile tab in AD (ex \\dc1\home\bob) it automatically sets up appropriate permissions. Then when a user clicks on the drive specified in their profile it takes them directly to their home drive. They should NOT see other users folders. That is how it has always worked in the past until just recently more and more users are reporting this oddity. I'm a windows server specialist at my job so I'm well versed. I really just need to know if anyone else has experienced this problems before.
Thanks for your help.

"Profile tab in AD (ex \\dc1\home\bob) it automatically sets up appropriate permissions". Not in my AD experience. If the share doesn't exist, you should receive a message that it doesn't and that the drive can't currently be mapped. The drive will need to be created manually. That's not the exact error message, but similar.
Life's more painless for the brainless.

Yes, we have the same exact thing happen.
Instead of H: mapping to \\fileserver\users\bob it was only mapping to \\fileserver\users. This use to happen randomnly, then the user would reboot and it would remap correctly. Now, it seems when we replace the user with a new computer or new image,then our of about 1 in 20 user upgrades cannot get there H: mapped to their folder (maps to the users directory, under which there folder is). They can map correctly on their original computer....For one user, it started mapping correctly in a month (not a good solution).

I had the exact same thing happen - only on certain Windows XP PCs (it seemed like only newer, faster boxes). I found that disabling the XP Fast Logon via a GPO did the trick:
http://support.microsoft.com/kb/q30...
Good luck,
Bruce

Thank you. I'll give that a try. I still would like to know why this happened in the first place.
TO JENNIFER SUMN: Please read the original posting in order to understand the issue before replying with anymore "resolutions". And your posting on July 7th could not be more incorrect. I'd be happy to explain more of the home drive mapping procedure to you and how it is designed to work, if you would like.

>I had the exact same thing happen - only on >certain Windows XP PCs (it seemed like only >newer, faster boxes). I found that >disabling the XP Fast Logon via a GPO did >the trick:
>http://support.microsoft.com/kb/q30...
>Good luck,
>BruceHi Bruce - is this solution still working? We have the same issue in our environment. Sometimes it maps to the share, other time it maps correctly to the user's folder. We've had other mapping anomolies in the recent past and I suggested your solution, but my team overrode me. Ammunition, please!

We had the same problem. We found after modifying Group Policy to enable "Run logon script synchronously" solved our problem. In GPO Enable (Computer Configuration->Administrative Templates ->System->Scripts->Run logon script synchronously
That should do the trick!

![]() |
![]() |
![]() |

This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |