Can system Environment Variables be set via Windows Logon Scripts?

Question

I have an MSI-packaged application that is being deployed via Group Policy Objects (GPO) from a Windows 2003 Domain Server to all the XP client machines in the network.

This application reads two environment variables for its configuration (which server IPs to talk to) and it seems like we'd also want to push this configuration via a GPO style setting or Login script to all the desktops.

What is the best approach for setting environment variables across a network of desktops?

Lackey

Answer 1

Why can't you embed this configuration into the Property table of the MSI (post-build, using a transform) and then read from there? This would make much more sense... fire up Orca, add a couple of properties, save a transform and deploy via GPO with transform applied.

Edit: Just re-read this question... then deploy settings to the registry and have the application read from there, rather than setting environment variables. Setting global environment variables for one application doesn't make sense for an administrators point of view.

Disfigurement

I've done just as you said to expose yet another way to set these env vars. In InstallShield, I built entries for these three vars so that they can be "addressed" via an MST (Transform). Good idea. – Lackey

The reason we can't use the registry is the app has to be cross platform. Thus, I can't/don't want to put registry reading libs into the app's 3p JARs. The environment variable makes it cross platform. Just sharing the motivations. The MST/Transform worked well for us. Thanks for the inspiration! – Lackey

Answer 2

My research says there are four ways to do this. I started at the Microsoft Logon Script documentation pages and fanned out from there.

Login Script Batch File

Windows Server 2000, 2003, 2008

Login batch file (.BAT) scripts are just a temporary instance of a CMD window, and the environment variables set in there go away as soon as the login window closes.

set MYVAR=MyValue

Won't work for the aforementioned reason.

So, alternatively, I can try to set the variable via directly writing to the registry like so for a System Environment Variable:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v MYVAR /t REG_EXPAND_SZ /d MyValue

or to the User Environment Variables like so:

reg add HKCU\Environment /v MYVAR /t REG_EXPAND_SZ /d MyValue 

The drawback here is that the variables, though written to registry, are not read until the next login for all I can see. A new CMD window shows no trace of them until the user re-logs-in.

Login Script WSH VBS File

Windows Server 2000, 2003, 2008

With a Visual Basic Script (VBS) login script, you can use a more programmatic method to access the environment variables. This is looking like my most viable approach. This example would append to the end of PATH.

Set WSHShell = WScript.CreateObject("WScript.Shell")
Set WshEnv = WshShell.Environment("SYSTEM")
WshEnv("Path") = WshEnv("Path") & ";M:\DB\whatever\"

This example would just set the variable.

Set WSHShell = WScript.CreateObject("WScript.Shell")
Set WshEnv = WshShell.Environment("SYSTEM")
WshEnv("MYVAR") = "MyNewValue"

This approach yields variables that are immediately available via a CMD window. No reboot is required like the batch file registry writes.

ADM File

Windows Server 2000, 2003, 2008

ADM files are a way to expose custom functionality of settings to the Group Policy Editor. It seems tricky to get them installed and visible on the domain controller so I'm jumping over this option.

Microsoft Support TechNet Reference on ADM File Locations.
Another article about ADM files and using them to set Registry settings.
Tom's Hardware on ADM Files.

---- set.adm ---- 
CLASS MACHINE 
CATEGORY "Environment" 
POLICY "Self dfined variables" 
KEYNAME "SYSTEM\CurrentControlSet\Control\Session Manager\Environment" 
PART "Set MyVar1 =" EDITTEXT 
DEFAULT "MyValue1" 
VALUENAME MyVar1 ; EXPANDABLETEXT 
; add expandabletext if it can contain Variables itself 
END PART 
END POLICY 
END CATEGORY 
---- set.adm ----

Group Policy Preferences (GPP)

Windows Server 2008

Windows Server 2008 has a new feature called the Environment Extensions for the Group Policy Preferences. It allows you to conveniently set what otherwise required complex batch scripts. The new items exposed include registry values, environment variables, and more. A quick how-to guide is available here.

I can't use this option because my clients don't have Windows Server 2008.

Summary

Please tell me based on your experiences as Windows Administrators which of these works best and why. I'm just a desktop developer, and need an admin's insight.

Lackey

Actually, GPP Works in a windows 2003 domain as well if all the clients are at least xp sp2 with gpp client installed. You must use Vista, Windows 7 or Windows 2008 to administer it. – Linkage

In Windows 7, one can use setx MYVAR MyValue – Namely

I haven't tested this myself, but assuming that environment variables are only reset when you sign-out and -in again, I think you can use a different REG command to retrieve it. Yeah, it's ugly as can be, but if it's your only option, take a look at this answer which explains how to get a specific value in an arbitrary registry key, and getting an environment variable should be easier. – Doriadorian

I wanted to explain why a reboot is required when you change the Registry entries used by the Shell with REG. The VBScript snippet has a significant advantage because it can request from Windows an API that understands the Shell. When you change a variable using that API, Windows is aware of the change and can refresh itself immediately. REG is concerned with the registry and nothing else, so it changes the Registry values that it should, but Windows is never notified that it needs to reload the environment variables because REG is just at too low of a level. – Doriadorian

Answer 3

You can always set environment variable through your login script. Of course!

That's how we do it:

Don't use "set" as it is not taken over into the user-environment. Variables set with "set" are just valid during the login-script-running-time.

Use "setx".

So, to set a variable within the users envrionment

setx MYSPECIALVAR THIS_IS_THE_VALUE

setx Softwaresource  \\\this\is\the\value\of\the\variable

(Note: There is no = sign as it would be the case with set MYSPECIALVAR=THIS_IS_THE_VALUE)

If the user has administration-rights on the PC you could also set the variables within the global-system-envrionment with

setx MYSPECIALVAR THIS_IS_THE_VALUE /m

(Thats the way we deploy variables throughout the PCs with installationscripts and administrative-rights)

Radioactive