Application Environment Inheritance
Understanding how applications inherit environment settings from one another can shed light on some otherwise puzzling situations.
Applications in Windows run within an "environment" that gets passed down to each process that the application creates.
The following items are environment-specific:
- Environment variables
- UAC Account Elevation status
- User
- Network-only user
This behavior opens up some powerful possibilities, but it can also lead to confusing situations.
Taking Advantage of Environment Inheritance
One of the simplest, but most useful, things I do to take advantage of this behavior is to launch a PowerShell or CMD console as an Administrator.
I enter my admin password one time. From within that console, I can then laucnh multiple applications running with admin credentials without having to re-enter my admin password each time. This is handy if I'm running multiple installers, multiple system tools (such as regedit.exe, services.exe, etc.), or if I'm repeatedly running a short-lived process (such as a script) that requires admin credentials.
This is a great time saver, especially if your normal login does not have administrative rights (which it should not).
Taking Advantage of Environment Isolation
A phenomenon related to environment inheritance in Windows is environment isolation.
To create isolated Windows environments, you can use the Runas command to launch multiple CMD or PowerShell consoles. I do this on a daily basis to facilitate network connections to domain assets from non-domain-joined devices.
I might have one CMD console window where I use the /netonly flag to connect to another domain and map an X:\ drive so that I have access to the production environment:
In a different CMD console, I'll set up a development environment where I substitute a local folder using the same drive letter, X:\, as shown below:
To help me keep all these windows straight, I use the Title function to set the window caption. The first part of the Window title is based on the name of the Access application I've set up the environment for. The second part is the network user account that is active for the current environment (this is the value I passed to the /u flag in the call to runas).
I use a dummy account, xxx\xxx, as a network username when I want to create an isolated CMD environment that does not need to actually connect to any network resources.
I've automated the tedious parts of this approach into an AutoHotkey script.
The Surprising Side Effects
If you are going to use this approach, there are some interesting side effects of which you should be aware.
On a daily basis, I have multiple CMD sessions open running different applications. Each CMD session has its own set of mapped or SUBSTed drive letters. One reason I do this, is because it’s the only way to connect to SQL Server using domain credentials from a non-domain-joined computer.
Here's an example of an issue I run into regularly with this approach:
- Open a CMD prompt
- Map an X:\ drive
- Open an Access application
- Open a PDF file from the X:\ drive in the default system viewer from within Access
At this point, one of two things happens:
- If the PDF viewer is not already open, then the PDF file opens without a hitch (a new instance of the PDF viewer is opened that inherits the X: drive mapping from Access, which inherited it from the CMD window)
- If the PDF viewer is already open, then I get an error message that the file X:\Path\To\My\File.pdf cannot be found
For a long time, I was baffled by the second situation. The reason for the error message is that the PDF viewer was opened from an environment that did not have an X: drive mapping, and so it cannot see the file.
I’ve now run into this issue enough times that I recognize it immediately and can deal with it. But it is definitely counter-intuitive the first few times you run into it.
Referenced articles
Mike Wolfe
Image by Hannah Alkadi from Pixabay
