Windows Environment Variables and why devs need to use them!
Windows Environment variables hold all kinds of information for example:
- The path to the user’s My Documents folder
- The path to the user’s Application Data folder
- The path to the local machine’s Windows folder
The list goes on…
In a typical Windows enterprise deployment user folders are redirected to folders on file servers. This helps to minimise the amount of profile traffic moving around the network (if using roaming profiles), allows IT admins to easily backup/restore user files, use the same target folder(s) regardless of whether a user is logging in to a full Windows desktop or logging in via Remote Desktop Services Session Hosts (I include Citrix in this). The list of benefits on this is long and the above is by no means a full list.
So what is the point of this blog post?
Very occasionally it may be necessary to move a user’s data from one server to another, i.e. change the path of the redirected folder… Whilst this can be mitigated, to some degree, by the use of Distributed File System (DFS), there are some applications that really don’t like DFS paths. So if you’ve set a user’s Application Data folder to redirect to \\ServerX\UserData$\<username>\AppData you’ll find numerous entries in the registry for this path – usually stored in an application’s settings to help it find files it may need.
What happens when you need to change the server?
If you need to change the server in the above example from ServerX to ServerY then you would make the appropriate changes in Group Policy (after setting the new share up as it should be) and when the user next logs on their data will move to the appropriate location (there are several other ways of achieving this – but I’ve always found this one to be the most straight forward). Once the user logs on Windows is aware of the changes and the the environment variables are updated, the folder paths in the operating system sections of the registry are updated, etc. What doesn’t get updated is random application Z’s settings paths – consequently when application Z starts, goes to the registry to find its path information, gets the path \\ServerX\UserData$\<username>\AppData\Roaming\ApplicationZ and then goes crazy when it can’t access the path!
Not all applications are the same
I’m an IT Pro not a developer, however I have actually done development in the past so I think I can speak about this (a little bit). Most developers are aware of this issue and code appropriately, it’s not difficult as environment variables can be accessed via standard API calls, or natively in .NET.
A small bit of defensive programming from developers can really help cut down on service desk calls. For example:
- Get path from registry
- Does path exist?
- Yes – carry on as normal
- No – recreate what the normal path would be (for example %APPDATA%\ApplicationZ). Are the files there?
- Yes – update registry and carry on as normal
- No – spit dummy out and tell the user
Small things can help make big changes.