Best practice for defining user "HOMEDRIVE" "HOMEPATH" "HOMESHARE"
Is it considered a best practice to map domain users' "HOME" environment variables to a network path? If so, why?
By "HOME" variables, I am referring to:
- %HOMEDRIVE%
- %HOMEPATH%
- %HOMESHARE%
This question arises because some applications - such as Git - store critical configuration files in the user's %HOMEPATH%. If a user is working remotely, or the server or network is down, these applications no longer function correctly because their core files are not accessible from the remote HOMEPATH.
It seems to make more sense to always use the default local Windows user directories for the HOMEPATH, but I could not find any documented best practices arguing for or against this. In my office, the standard practice is to map the user HOMEPATH to a network folder...
In most cases, I would answer with a resounding NO. The Windows architecture provides the ability to redirect user data in a domain/networked environment through Folder Redirection, Offline Files, and Roaming User Profiles, collectively known as User State Virtualization.
To complement this functionality, applications are provided with the ability to choose whether their data is stored locally, AppData\Local
, or migrated with the user profile, AppData\Roaming
, or some mix of the two. This allows items such as preferences to be stored centrally and move with the user, while keeping machine-specific files or cached data locally.
Configuring these items automatically takes care of adjusting all the relevant environmental variables. For example, when redirecting the Roaming AppData Folder, %AppData%
will automatically point to the networked location.
About the only time you should be adjusting these variables by hand is if you have a specific use case that requires it, such as a legacy application that is unaware of the proper data storage location. Adjusting variables like %HomeDrive%
can actually do more harm than good - occasionally breaking applications that expect them to point to a local disk, or are incapable of handling the nuances of working with a file on a remote system.