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
Opening an elevated command-prompt always starts in %systemroot%\System32
, the rationale being that if you are doing something requiring elevated privileges, you are likely to be working on system files as opposed to just the user’s own files which you can do without elevated privileges.
You can work around it:
- Open a registry editor (e.g.,
regedit
)
- Navigate to
HKEY_CURRENT_USER\Software\Microsoft\Command Processor
- Edit the
Autorun
value to read cd /d %userprofile%
Now whenever you open a command-prompt, it will either start in or switch to, as the case may be, the user profile directory. Also, instead of HKCU
, you can set the value in the HKLM
branch to do it for all users on the system.
Best Answer
It looks like you're trying to modify the system path so it's dynamic per-user.
You can set environment variables on a per-user basis, so this isn't necessary.
via the registry;
via the ui;
Admittedly such an approach falls down once you add more users, but on a home system this probably isn't a frequent occurrence.