CODEWITHSUNDEEP
windowscmdenvironment-variables
Fantastic Mr Fox
Fantastic Mr Fox

Reputation: 33944

Permanently Change Environment Variables in Windows

I found a way to change the default home directory of a user but I am having trouble with it.

enter image description here

enter image description here

enter image description here

Doing this will change the home drive to C:

But then when I check the environment variable:

enter image description here

It is still H:, with a system restart the Enviroment variables in windows settings will also return to H:/

I have also tried changing it like this:

enter image description here

Which appears to work but if i open a new cmd it will have reverted back to H:/

Now I am trying to do this so that OpenSSH will recognise C as my home directory instead of H: which is a network drive, forcing OpenSSH not to work unless I cam connected to my university network via VPN.

What can I do to set this permanently and in the eyes of OpenSSH?

Upvotes: 22

Views: 66186

Answers (7)

absentmindeduk
absentmindeduk

Reputation: 136

Sounds like the AD profile on the domain is overwriting the user defined variables. I see your screenshot says you are connected to the eait.org.edu.au domain. That will be the root of your issue. Just to include some details here that I spotted elsewhere, that may be of help to you:

HOMEDRIVE, HOMEPATH & HOMESHARE are set and updated via Active Directory. HOMEDRIVE & HOMEPATH are set even without a home drive set on the account; however they will be overridden by any user account properties set in AD.

Also see these KB articles:

http://support.microsoft.com/kb/841343 (archived)
http://support.microsoft.com/kb/237566
http://support.microsoft.com/kb/101507 (archived)

On a side-note for another way around the issue:

-I have in the past created a new instance of the windows command-line shell executable that automatically runs a custom script, so everytime you launch the shell, the environment variable could be overriden.

-To do that you could just put the code you posted to change the environment variable into a batch script, stored wherever you like, then edit the shortcut(s) used to launch the shell by going to properties > then alter the Target box: %SystemRoot%\system32\cmd.exe /K "C:\Documents and Settings\Administrator\My Documents\customshellscript.cmd" (Obviously the part of the path after /K is the location of your custom script)

This way, if you are using openSSH over the console anyway, it will always have the homedrive set correctly.

Upvotes: 7

Richard Humphrey
Richard Humphrey

Reputation: 1

I had a similar issue, the HOMEDRIVE variable was set to U: which was a drive we no longer used. This was just for one particular user. I went to that user's profile in AD and clicked the Attribute Editor tab. There was an attribute for HOMEDRIVE which I changed from U: to C: - when the user logged in again, it was set correctly. I also updated the HomeDirectory attribute here.

Upvotes: 0

Richard
Richard

Reputation: 1

This issue had been really frustrating me trying to find a solution, but I have found what I think is the definitive answer and posted it at:

https://stackoverflow.com/a/60235759/12903197

You need to run 'net user USERNAME /homedir:PATH' where USERNAME is the name of the user you are trying to change and PATH is the drive letter and full path to the desired home folder, which must already exist.

Upvotes: -1

Adolfo Macias
Adolfo Macias

Reputation: 1

On windows 8:

  1. Hit "windows key".
  2. type "system environment variables".
  3. Allow "Advance system settings" to make changes.
  4. Select "Advance" tab.
  5. Click on "Enviroment Variables...".
  6. Double click on "Path" from "User variable for XXXXXXXX"

  7. Add at the end the variable the new path that you want separated by semicolon.

    e.g. C:\Program Files\;C:\Python27\ shareeditdelete (1)flag

Upvotes: -3

joocer
joocer

Reputation: 1121

Nowhere does it mention a dependency between the HOMEDRIVE value and the HOMEDIRECTORY value, what was happening (I think) is that it was failing to map the home directory to the HOMEDRIVE and therefore defaulting back to a safe value (C:)

I wrote a script to update the local AD, replace the values in [] with your values. Copy and paste into a .vbs file and double click on it to run it.

Set objUser = GetObject("WinNT://[COMPUTERNAME]/[USERNAME],user")
objUser.homeDirDrive = "H:"
objUser.HomeDirectory = "[URNPATH]"
objUser.SetInfo

e.g.

Set objUser = GetObject("WinNT://UQBDART-2328/BEN,user")
objUser.homeDirDrive = "H:"
objUser.HomeDirectory = "\\SERVER\SHARE"
objUser.SetInfo

run this, reboot and test. It worked for me.

Upvotes: 12

joocer
joocer

Reputation: 1121

Back in the days of DOS the environment variables were part of the Program Segement which meant that you basically got a local snapshop of the variables limited to the scope of that program.

I'm guessing Windows hasn't changed this and the environment variables available to the CMD window only have the scope of that window and any further windows it spawns. This is supported by this little experiment:

in a CMD window type

set homedrive=h:\

and then test it's updated by typing

set h

from this same window type

start cmd

and in this new window type

set h

when I've done this I get HOMEDRIVE=H:\

if I then just open a new CMD window from the start menu and do the same SET H I get HOMEDRIVE=C:\

I don't know anything about OpenSSH but I suspect like the START CMD got the updated HOMEDRIVE environment variable, if you write a batch to update the environment variable and then execute OpenSSH that'll work.

Upvotes: 0

Christian.K
Christian.K

Reputation: 49310

Changing those environment variable's values is not "supported", at least it will not work as you expect because Windows changes them back.

According to this Microsoft knowledge base article (KB841343), you should use policies, if you need to change these settings. The article also contains links for how to do that (but personally, I never tried). Note that the article was originally written for Windows 2000, but I would strongly suspect, that it is still valid for current Windows versions.

Upvotes: 2

Related Questions