If your company is like most organisation i have come across you all users to have a home drive (typically H: ) that is give to the users that allows them to store private information that only they have access. Ever since the days of at least NT4 (or possibly earlier) administrators have had the option to configure their users home drives via a setting in their AD account (see image below below).
Even today with Windows Server 2012 this is this is still an option for administrators to configured users home drives via their users accounts (see image below).
When the home drive is set on a user account via Active Directory Users and Computers the tool actually goes out and creates the home drive in ready for the user to map the next time the log onto a computer.
The main problem with configuring users home drive this way is that it is configured on a one by one basis which means that it is difficult to configure these setting and it is another step in the user creation process that can be forgotten to be done. Certainly this is a lot easier with the advent of Windows Server 2003 admin tools that allowed you to select multiple users and configured the home drive on mass.
However the idea of setting the home drive as an individual attribute in todays policy driven, economy of scale management style is just not ideal. Such as a user account is moved from one location to another in AD the users home drive setting is not automatically updated as its a static configuration on the users account.
If you have read my blog post Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization) you might have realised that you can already create the users home drive automatically using folder redirection (specifically Documents) and then you can simply use the Group Policy Preferences Drive Mapping Extension to map the user home drive to the same location as the folder is redirected. This method does allow for the users account to moved around and have policy automatically update their home drive. But in reality it is just a workaround to the lack of any other way of setting the users home drive automatically via policy… until now..
With the introduction of Windows 8 and Windows Server 2012 there is now a new group policy setting called “Set user home folder†and is found under Computer Configuration > Policies > Administrative Templates > System > User Profiles.
One the policy is applied to a computer anyone logos onto this computer will get a home drive mapped to the path above…
Warning: As this policy can only be applied to the computer object this will apply to everyone who logs on the computer that have this setting applied… including Domain admins and alike so be carefully how you apply it…
TIP: If you have your workstations segmented in your OU structure by site you may want to apply this policy setting at each site to the nearest file server you want to use for storing your home drives. This means that users will not have home drive re-map if they travel for a short time to other locations… Alternately you MIGHT want to apply this setting to your AD site however if you do this make sure you put a WMI filter on the policy so it does not apply to Windows Servers in the same site.. .
Blog Post: How to “Set users home folder†via group policy in Windows 8 http://t.co/VGcgYOcw
How to set users home folder via group policy in Windows 8: http://t.co/AyNGNCwf
But Alan, correct me if I’m wrong but this doesn’t move the content of the user’s home folder around, so using this in the way described above means that they could have home folders sprinkled all over a network? Not sure I get how this is helpful? What is missing?
Darren
Good point, I must admit I struggled trying to find a good use case for this policy setting seeing it only applies to the computer and not user. The post is more of an FYI for those who might have been looking for this functionality…
In some scenarios I could see having the home drive isolate to regions would be useful, and in other having them roam would be very good. I suppose you could replicate them on the back end
using DFSR…
With this setting in mind you can use UE-V and this would achieve a consistent user experience wherever they are.
UE-V would also be good for that…
Yea, DFSR already gives you site-based affinity so you wouldn’t need this. Just refer to the DFS link and away you go. However, after thinking about it, I think it could be useful in VDI/RDS scenarios where you might want the user’s home directory to be near the VM/RDS farm for performance reasons, but only when they are on that farm. You still have the issue of sychronizing with their “normal” home folder though, so not sure.
Yes, VDI did cross my mind…. But I do wish that this policy could be applied to the user… that would be very handy…
The use case you are searching for are enterprises which don’t have a single IT authority/shop, and where users aren’t “owned/supported” by just one IT group but by several. In those scenarios, the home directory for any given user changes based on which computer they are using, because in contrast computers do have a single IT group supporting them. This scenario is rampant in the Higher Education sector, and is why HiEd leverages loopback processing more heavily than any other sector. There are workarounds, but as you’ve said this new setting means you don’t have to use those other workarounds. Thanks for posting this!
That’s exactly our environment at the university where I work. This makes it easier for me to provide our school’s students with a home directory whle still letting them use their acounts from the Central Forest. Looking forward to kicking the tires on this one.
Hi Alan
This is exactly what I was searching for. However it didn’t work for me 🙁 I need to redirect the the users’ home folders to a Samba share WITHOUT Active Directory. So what I tried to do is setting the property in the local group policy of a Windows 8.1 client. As it didn’t work I decided to try a local folder but even this failed. Here is what I do:
1. set the property to a local folder (C:\Userhomes)
2. Then I add a local user
3. Logout admin and login with the new user
After logging in I see that Windows has created an empty subfolder C:\Userhomes\test1.compaq (where compaq is the computer name) but has still put all skeleton user data under C:\Users\test1.
Do you have any idea what am I doing wrong?
Hi, is there a way to accomplish this in a Windows 2008R2 AD environment?
thanks!
This works for older clients too with the correct permissions (tested with W7). The Comp config Policy (above) will create the folder. However you still need to use a User GPP to map the drive.
Any tips for someone who’s set this up, but finds that the folders aren’t getting created? I have the same permissions set up as my roaming profile folder (ntfs and share), but it’s just not working
I work in a school and use this in a loop back policy for pupils who are in exam mode so they have a new clean home directory for their exams.
Is there a way to rename this map drive from GPO?
I create a Powershell script, a .bat.. I can’t make it work.
We have discovered a problem with this. It’s a Windows thing. Our environment has both Windows 7 and Windows 10 clients. Windows 7 appends the username as “username”. Windows 10 appends the username as “username.DOMAIN”. In our environment, a user can find themselves on a Windows 7 computers one week and Windows 10 the next. This will create different mappings and users panicking that their files are missing.
I have recently discovered the same issue of Windows 10 appending .DOMAIN onto the end of the home directory name. I spent several hours trying to figure out why it was happening, only to find the above comment which seems to say it is standard behavior. Boy, is that dumb. Might look into whether symbolic links could point them both to the same place. Aggravating!