I found a way to change the default home directory of a user but I am having trouble with it.
Doing this will change the home drive to C:
But then when I check the environment variable:
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:
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?
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.
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
http://support.microsoft.com/kb/237566
http://support.microsoft.com/kb/101507
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.
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.
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.
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.
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.
On windows 8:
Hit "windows key".
type "system environment variables".
Allow "Advance system settings" to make changes.
Select "Advance" tab.
Click on "Enviroment Variables...".
Double click on "Path" from "User variable for XXXXXXXX"
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
Related
Ahead of time I am a newb at programming/scripting. I mainly research what I want and just edit it to fit my needs when possible.
Environment:
Windows 7
CMD
Usergroup = admin
Occurs when launching as user(admin) or launching cmd as administrator
When I use CMD to change an environment setting, it does not save to the system.
Example:
C:\Users\admin>SET TESTVARIABLE = "This is a test"
C:\Users\admin>SET
TESTVARIABLE = "This is a test"
C:\Users\admin>_
close out cmd, reopen, use SET and the testvariable is no longer there.
Going through System > Advanced System Settings > Environment Variables > System Variables is the only way I can positively make changes to the variables.
This is also affected by any .bat files I make. Mine don't actually get applied when they run but other peoples that I copy(entire .bat file, not just text/context).
This is occuring on my (all at work) desk pc(win10) and 2x Remote Desktop (win7). I am admin and I'm using admin users on these RDP's.
Anyone have any idea what is happening, what i'm missing, how I can research it or fix it?
Variables set using the "set" command are only available in the cmd's instance. To save variables persistently see this: Set a persistent environment variable from cmd.exe
Putting %appdata% into the run window will open up the Appdata folder, but what is the command to open the User's Documents folder, even when someone else logs in? I thought it was something like %userdir%, but I can not find out what it is. Not sure what to search for in Google either so I am at a loss.
There is no environment variable for this. You'll need to set one. Here's a list of all Windows default environment variables:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx?mfr=true
*This is for XP, but should be the same for newer versions of Windows
For a single terminal session, you can just use
set USERDOCS=%USERPROFILE%\Documents
For all terminal sessions, you'll need to set a system environment variable. You can do this using the GUI or using setx -m USERDOCS %USERPROFILE\Documents, as described here.
The command to make this happen would be
explorer %USERDOCS%
But if you wanted to make an alias to that (i.e. a openuserdocs command), I can update and explain.
On my Pc, running Windows XP 5.1.2600, following
"My Computer" > "Properties" > "Advanced" > "Environment Variables" > "Path"
I get a string, but in a batch file, or directly typing from prompt, by means of
echo %path%
I get a different one.
Can someone, please, explain what makes them differ and how to fix the issue, setting the "DOS-path" to the same value of "Windows-PATH" ?
Two things:
As others have mentioned, the full value of PATH is the combination of the user's PATH variable and the system's PATH variable.
If you change environment variables (including PATH), any processes already running (including the Command Prompt) will continue using the old environment variable values. You will need to restart those processes to pick up any changes that you've made.
The value of the PATH environment variable you see on the command line (which has nothing to do with "DOS" btw) is the sum of the system wide PATH variable and the user specific PATH variable.
If you open the dialog with the system variables from within the control panel, the upper part contains the user specific environment variables. The lower part contains the system variables.
If you set a PATH variable for your user to e.g. c:\foo, and the system path is be c:\Windows\System32 then you'd see c:\Windows\System32;c:\foo when you do an ECHO %PATH% on the commandline.
Probably the difference you are seeing is that when a new process is made, its default environment contains a PATH variable that is made by merging the system variable with the user variable.
As for how to "fix the issue", there is nothing to fix. The system behaves as designed.
I was getting the same issue where the System Variable that I get through the
"My Computer" > "Properties" > "Advanced" > "Environment Variables" >
"Path"
was different that the one being displayed through the command line interface via
ECHO %PATH%
The fix for this is basically to wait for the change to take place and this can be made faster by restarting the cmd and explorer. To do that you can simply end task for Explorer and CMD and then start a new task or restart it directly.
The same shall be done for the CMD as well.
The Windows registry can hold path entries that do not show up in the Environment Variables version of PATH you see via the control panel. (Why, I do not know).
The difference means that something (likely an install script) made changes to the registry.
To view or change the local user's path variable, look in the HKEY_CURRENT_USER\Environment key.
To view the system path, look in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
i need to set permanently the %username% variable on windows is that possible?
I mean if I do on command prompt set username=UPPERCASE I can see that the variable is changed, however as expected this does work just in that command prompt, If I open another one the username variable is the original.
I tried to find the correspondent registry value but I did not find it.
I need some automatic way to do it.
Thanks!
When each process starts, the process gets a copy of the parent process' environment variables. So, if you used Windows Explorer to start your command prompt. You get a copy of Explorer.exe's environment variables, but when you edit it in cmd.exe, you don't edit the value for the rest of the system.
That said, Windows provides an event that processes can subscribe to so they can be told that there is a new value for environment variables. If you are interested, I can try to dig it up. I've used it before for the Path environment variable and think it may apply to your problem.
Sounds like you should create a bat file. This will prompt the user for their username and put it in the %USERNAME% environment variable.
SET /p USERNAME=What is your UserName?
putty /user:%username%
I'm writing a dos-batch in which I need to change the PATH.
I'm using the SET command.
The batch is run from the command line (cmd.exe).
The problem : the changes are only available for the cmd window, and I soon as this window is closed, the changes are dismissed.
How can I change the PATH from a batch and make sure the change will affect the whole system ?
There is a tool setx.exe provided in the Windows XP Service Pack 2 Support Tools that can be used to permanently change an environment variable from the command line:
setx path "%PATH%;C:\New Folder"
Source: http://vlaurie.com/computers2/Articles/environment.htm
The above link also gives the location of the registry keys that store the system / user environment variables - if you are feeling adventurous you could also try setting those.
User environment variables:
HKEY_CURRENT_USER\Environment
System environment variables:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment