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.

  • 2
    Your IT department have set these policies for a reason. If you have tried to work it out with them and they have refused to change it there's probably a good reason. If you then continue to ignore their advice and go against what they've asked prepare for disciplinary action if you're caught.
    – Joe Taylor
    Mar 10, 2011 at 15:16
  • 35
    After over 30 years in this industry, I've learned that IT policy for the average PC user is often inadequate (or even obstructive) for developers and power users. IT often has had to accommodate the needs of developers differently, and if this is another such learning experience for them here, then I'm glad to help. I'd love to hear a valid business reason for making a user's home directory unusuable.
    – MykennaC
    Mar 10, 2011 at 15:32
  • 2
    The why not escelate the problem, show it is unworkable for certain users and propose a separate GPO for such users. Moving in this constructive way is far more likely to work than trying to bypass the domain policies with hacks.
    – Joe Taylor
    Mar 10, 2011 at 16:17
  • 8
    IT finally got back to me. They aren't going to change anything. Yes, official company policy is to provide a user home directory where I am not allowed to create files. Windows applications that attempt to use the default user home directory for things like preference files will fail. Is there no wizard here who can offer me some workaround to this?
    – MykennaC
    Apr 5, 2011 at 16:49
  • 3
    yes @D0rf, he should roll over and just take it. If IT makes your job impossible, you need to fight and raise a fuss until it is changed. If you're a passive developer, then you deserve your lot in life at a terrible company that doesn't give you the tools you need for your job.
    – Scott
    May 2, 2013 at 17:10

6 Answers 6


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


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

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:   Server

After rebooting, you should see something like:

set HOME

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:

  1. Modify C:\Windows\System32\drivers\etc\hosts to redirect "Server" to your local machine:   Server
  2. 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:

    BackConnectionHostNames = Server
  3. 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%
  4. 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
  5. 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
  6. 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

But due to my mappings, the result is:

G: => \\Server\Users\username => C:\Users\username
  • These suggestions seem like they might help IF I was working at the command line. To affect an app (like gvim) I would probably need to create a wrapper. Iterating over all affected apps sounds like a lot of work, not to mention changing file associations, etc. Remapping my M: drive at boot time is a fine suggestion, but how to do that globally when Windows starts up (in order to affect all apps/shells)? I hope these suggestions will help others, but I don't think they solve my O.P.
    – MykennaC
    Apr 4, 2014 at 19:34
  • 4
    I haven't needed these methods in a while, but I recall developing them specifically for gvim, which I believe was using HOMEDRIVE and HOMEPATH. These methods do not require that you execute from the command line; any applications using the variables or drive letter will all be affected. Method #2 and #3 are "permanent", and only need to be executed once for the changes to stick. Method #1 can be automatically executed at startup by placing a shortcut in C:\Users\<You>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, or setting up a task in Task Scheduler. I hope this helps!
    – Terrance
    Apr 4, 2014 at 20:51
  • @terrance Ahhh, the beauty of well-crafted abominations. LMAO. Thanks for info here - and there is TONS here... Sep 15, 2017 at 20:36

Best solution I found was to set variables during login and before userinit.exe.

This is what I did. First created a batch file at C:\Windows\System32\userinit.cmd containing

SET HOMESHARE=\\localhost\C$\Users\%USERNAME%
@START C:\Windows\system32\userinit.exe

and then changed value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit to C:\Windows\System32\userinit.cmd in the registry.

More information at: https://technet.microsoft.com/en-us/library/cc939862.aspx

  • Worked in Win7, but not in Win10.
    – Ants
    Mar 22, 2019 at 1:35

I used SETX in a startup script and that worked for me. See my answer.


I think these paths are automatically set to the place where your user profile is. The home drive you're referring to is the place where your ntuser.dat and application data and other user profile folders are, correct? Back with NT3.x, the "user profile" was just your user registry hive with settings and you could set a separate home path for each user. Those got unified together in NT4 as a user profile with a desktop, my documents, start menu, etc.

The locations of all the profiles are stored in registry keys under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

You will find some values for the special profiles, and subkeys: one for each active profile on the system. They are set up by the SID of the user account they belong to. The easiest way to find yours would be to scroll through each one looking for the right path (under the ProfileImagePath value). You should be able to just change that value to whatever path you want; it'll take effect the next time you log on. Be sure to copy your files to the new path first.

If you have to move the profile from the account you are logged in as (i.e. logged in as MikeC and you are trying to copy the profile for MikeC) the ntuser.dat file (the registry hive containing HKEY_CURRENT_USER) will be locked by the kernel. You can still copy the hive: go into regedit, right click on HKEY_CURRENT_USER, select export, change the type to registry hive files, and save as ntuser.dat at your new location.

In my experience if winlogon has a problem loading a profile because something is set up wrong, it'll either create a new copy from the default profile or give you a temporary copy to use for that session and you'll still be able to log in. However, I would recommend you have a different admin login to use on the system in case something goes wrong.

  • Well, the only item in my ProfileList that seems relevant is ProfileImagePath, which shows as C:\Users\mcepek. That matches what SET USERPROFILE shows me, but that's not my focus here. I need to affect HOMEPATH and HOMEDRIVE. Just for fun I searched my registry for items with values or data set to "M:" (match whole string only = checked) and came up only with a Computer/HKEY_USERS/xxxx/Volatile Environment/HOMEDRIVE. Changing it to C: didn't seem to have any affect in my current login session. After a reboot the value was back to M: (not a surprise).
    – MykennaC
    Jul 13, 2012 at 18:34

I am posting this in case anyone else comes to this question via google. Instead of changing my home directory and getting the IS guys mad at me, I setup and ran my development on a virtual machine. Microsoft offers Widows XP in virtual mode. http://www.microsoft.com/windows/virtual-pc/download.aspx


A somewhat easier alternative would be to run the script below (env-reset.vbs) as a scheduled task at logon, unlock and maybe every a few minutes too.

Set shell = WScript.CreateObject("WScript.Shell")  
Set venv = shell.Environment("Volatile")  

scriptingHost = LCase(Right(Wscript.FullName,Len("cscript.exe")))
interactive = Wscript.Interactive And (scriptingHost = "cscript.exe")

If interactive Then 
  Wscript.Echo "WSCRIPT"
  Wscript.Echo "  ScriptingHost = " & scriptingHost
  Wscript.Echo "  FullName = " & Wscript.FullName
  Wscript.Echo "  ScriptFullName = " & Wscript.ScriptFullName
End If  

If interactive Then Call showVolatile()

homedrive = Left(venv("USERPROFILE"),2)
homepath = Mid(venv("USERPROFILE"),3)
If interactive Then 
  Wscript.Echo "COMPUTED"
  Wscript.Echo "  homedrive = " & homedrive
  Wscript.Echo "  homepath = " & homepath
End If  
venv("HOMEDRIVE") = homedrive
venv("HOMEPATH")  = homepath

If interactive Then Call showVolatile()


Sub showVolatile()
  Wscript.Echo "VOLATILE"
  Wscript.Echo "  USERPROFILE = " & venv("USERPROFILE")  
  Wscript.Echo "  HOMEDRIVE = " & venv("HOMEDRIVE")  
  Wscript.Echo "  HOMEPATH = " & venv("HOMEPATH")  
  Wscript.Echo "  HOMESHARE = " & venv("HOMESHARE")  
End Sub

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .