Windows – Overriding HOMEDRIVE and HOMEPATH as a Windows 7 user

active-directoryenvironment-variableswindows 7

My employer has an Active Directory group policy which sets my Windows 7 laptop HOMEDRIVE to "M:" (a mapped network drive) and my HOMEPATH to "\". Since I have read-only permissions for the root of that shared drive, I cannot create files or directories in my windows home directory. My attempts to work with the IT department have been unsuccessful.

Is there a way for me to globally change these envars at boot or login time? I need for all applications to use alternate values (such as "C:" and "\Users\myname"). I have some installed utilities (like gvim and others) that store preference files in the user's home directory.

IMPORTANT: Changing these envars under "System Properties > Environment Variables" does not work. I have tried setting these as both User and System Variables (including a reboot). TypingSET HOMEin a DOS window clearly shows that my settings are ignored. Also, using "Start in" in a Windows shortcut will also not solve this, as I need things like Explorer context menu items (like "Edit with Vim") to operate correctly.

I do have admin rights on this company laptop, but I am not a Win7 guru. Back in the day, a boot script would have solved this in a minute. Is it even possible today? Thanks.

Best Answer

Below are some hacks I've developed. They are not elegant, but may be functional in your corporate environment.

HOMEDRIVE Only

It seems that many applications only use HOMEDRIVE / HOMEPATH. In that case, you can create a startup script that remaps the base drive letter to your local user path via the UNC drive admin path:

set HOME
HOMEDRIVE=G:
HOMEPATH=\
HOMESHARE=\\Server\Users\username

net use g: /delete
net use g: \\localhost\C$\Users\username

HOMEDRIVE Local Default

If you do not need to access "Server" by name at all, you can cause the group policy setting to fail and fall back to your local machine. The easiest way to do this is to add an entry to C:\Windows\System32\drivers\etc\hosts like:

127.0.0.1   Server

After rebooting, you should see something like:

set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\username

HOMEDRIVE/SHARE with Hybrid Local/Remote UNC Paths

If you want access to "Server" by name for some UNC paths, but override others with local paths, I have developed the following abomination. Note: direct server connections to "Server" will still resolve to your local machine. I recommend this solution only if "Server" is only a file server:

Modify C:\Windows\System32\drivers\etc\hosts to redirect "Server" to your local machine:
```
127.0.0.1   Server
```
Add the following Multi-String registry value to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 to allow credentials to be passed to the local UNC path:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\
BackConnectionHostNames = Server
```

Create a dummy directory that will serve as the root of Server:

set DUMMY_LOC=C:\Server_Dummy

mkdir %DUMMY_LOC%
cd /D %DUMMY_LOC%

For each UNC path you want to direct to the real Server:

rem Alternatively you can use an IP below, but it is more likely to break if DNS changes
set SERVER_FQDN=Server.network.blah.com

rem Take a look at what's available...
net view \\%SERVER_FQDN%\

mklink /D Remote_Example \\%SERVER_FQDN%\Remote_Example
net share Remote_Example=%DUMMY_LOC%\Remote_Example /grant:everyone,FULL

For each UNC share you want to define locally (such as Users):

rem The link isn't really necessary for the share, I just find it easier to manage when all of these hacks are in the same directory

mklink /D Users C:\Users
net share Users=%DUMMY_LOC%\Users /grant:everyone,FULL

Reboot

For the example, this would allow the following UNC paths to be resolved:

\\Server\Remote_Example => \\Server.network.blah.com\Remote_Example
\\Server\Users          => C:\Users

This path resolution should occur prior to drive mappings. As long as the UNC paths associated with the mappings are valid (be they local or remote), drive letters should behave as expected.

For example, in my setup the following variables are forced by the domain:

set HOME
HOMEDRIVE=G:
HOMEPATH=\
HOMESHARE=\\Server\Users\username

But due to my mappings, the result is:

G: => \\Server\Users\username => C:\Users\username

Related Solutions

Debian – Setting environment variables in Linux for all processes

Processes (including shells) only inherit variables from their parents. There is no way to change them from the outside thereafter.

Set "global variables" as early in the boot (for system processes) or shell invocation (for user processes) as possible, or resign yourself to setting them in multiple places.

This may seem like a pain, but the ability to change another processes environment would be a bug, and would introduce all kinds of nasty race conditions.

What are you trying to do that you want "global" environment variables? There may be way to work around your problem.

Workaround:: Write a minimal script in your favorite shell format that only sets the variable you want and put it in a globally accessible place:

/etc/loglocaltion.sh:

export MY_LOG_DIR=/opt/share/mylog
export MY_DEFAULT_LOG_LEVEL=URGENT

and for everything that you want to use that configuration do one of

launch it from shell which has sourceed loglocation.sh in it's non-interactive login file (the one that gets read for all instances of the shell, i.e. .bash_profile).
write a minimal wrapper script which sources loglocation.sh before launching the real program. launchcorelogger.sh:

 CORELOGGER=/opt/sbin/mycorelogger
 source /etc/loglocation.sh
 exec $CORELOGGER

and have init run the script.

Now edits to the loglocation script will effect all associated processing if your run them from a fresh shell in the first case or restart them using you systems dameon restarted (/etc/init.d/mycorelogger restart or whatever).