I would like to add an Environment variable to a Windows machine (desktop or server) and be able to use it without rebooting that machine.
Say you have a production server which hosts a variety of apps and a new app needs a particular Environment variable to run. You do not want to reboot it while users are connected to your other apps. What choices do you have? I don't like the wait-until-a-good-time-to-reboot option. There must be a better way. What am I missing?
Changes to environment variables should take effect immediately, if you make the change via the main Properties dialog for the computer in question (go to My Computer | Properties | Advanced | Environment Variables). After the changes are saved, Explorer broadcasts a
WM_SETTINGCHANGE
message to all windows to inform them of the change. Any programs spawned via Explorer after this should get the updated environment, although already-running programs will not, unless they handle the setting change message.I'm not able to tell from your problem description what specific problem you're having with this. Can you tell us more about the specific scenario that isn't working?
This KB article may also be of use: How to propagate environment variables to the system
runas /user:yourusername@yourdomain cmd
taskkill /f /im explorer.exe
explorer.exe
Now after closing all command prompts, you will see that the
PATH
variable has been truly updated.All command prompts must be closed. Reopen a new command prompt, type path and you will see the new data.
One thing to keep in mind is that many programs obtain the environmental variables when they're first started, so while windows may not need a restart, some programs might before they'll be able to use the new variables. Good example of this is having to open a new command prompt window after adding a PATH (yes, I've been tripped up by this).
Whilst I don't have enough of a reputation to comment on the highest voted answer to this question, I would like to state that it is not exactly correct. I know this because no matter which workaround I tried in this post, nothing actually worked.
The kb article linked to in that answer actually states that:
The part about the environment variables resetting to the previous values after reloading the command prompt is exactly what I experienced in Windows Server 2008.
The article goes on to say:
That does not imply that Explorer broadcasts a WM_SETTINGCHANGE message once you have changed the system environment variables, or that it actually works. I'm not sure how you would do what is suggested in the KB article (to propagate the changes immediately) from the command prompt.
Make the env. variable available straight away:
Depending on the environment variable you want to change do the following: (supose that you want to add a new PATH for a recently installed application) So, at the shell prompt, type the following:
check that your new path has been added to the environment variable
Done.
Make the variable available on reboot
Tested and working on Windows 7/10
Since people haven't added this answer yet, I wanted to mention that you can set permanent system variables that survive reboot with the
SETX
command.e.g.
Please note that the above will not work in the current command window and will require you to open a new command window before it takes effect. As a result, depending on the use case; you may need to combine this with one of the other techniques above.
A possible solution for services is to run them temporarily as another user (other than LocalSystem, LocalService, NetworkService). For example for Apache service this works without any problems. To change service account open services.msc console, select service, click service properties and on second tab enter logon credentials for a user. Restart the service and it's environment variables should be up to date.
If this is a user which has been logged of than this should work without problems. If you are using current user account, then restarting explorer.exe might be necessary too. Also note that running services as normal user account might create security risks.