App-V 5: On Environment Variables
Environment variables are managed on a per-package basis in App-V 5 just as they have with previous versions. During sequencing, the Environment Variable Virtualization Subsystem (say that 10 ten times fast) will capture snapshots of the user and system variable list before and after the monitoring process. Then lists are compared and any differences are added to the package manifest. This means the package will default to the variable data entered in during sequencing. The variables are then stored in the package manifest using the following format:
<appv:Include>
<appv:Variable Name="TMP" Value="[{LocalAppData}]\Temp" />
</appv:Include>
Where the “Name” is the variable and “Value” is the new, tokenized (if necessary) value of the environment variable. On the client, the named variable will be set to the new value within the virtual environment and properly translated.
The one time there is an exception to this process is when the PATH value is being handled. Applications never “set” the PATH variable – they only append, or add to it therefore if changes to the PATH value are detected during sequencing, the changes will be captured and will appear slightly different in the manifest, with a self-referential value. The PATH variable that is captured in manifest will look similar to:
<appv:Variable Name="PATH" Value="<dirpath1;%PATH%;dirpath2" />
Where dirpath1 would be a prefixed Path segment to the current PATH and dirpath2 is a suffixed path segment to the current PATH.
The sequencer can also detect the deletion of existing variables and will apply those in the manifest using the following format:
<appv:Delete>
<appv:Variable Name="TEMP" />
</appv:Delete>
In this case, the Environment Variable TEMP will be deleted within the virtual environment of the application.
These captured values can be modified and overridden using dynamic configuration. An administrator can modify DeploymentConfig and/or UserConfig to edit Environment Variables. The <Include> element beneath the <EnvironmentVariables> section is where new or modified variables should be placed. The <Delete> element is where values need to be removed. In the example below, the PATH variable is modified, two additional variables are added and one will be deleted (if exists.)
The Virtual Environment Variable Subsystem reads the package manifest and the option deployment and user dynamic configuration files, and produces two lists – variables to add and variables to remove. This is all done when the application launches. As the catalog documents are processed, newly processed values overwrite previously processed values, so last writer wins. It is important to make sure all needed variables from the manifest are transferred over to the dynamic configuration files when leveraging them to change variables post-sequencing.
As with sequencing, there is an exception and it again involves the PATH variable. The PATH variable is injected after a process has completely loaded. This is why it is not a good idea to try to use the PATH value to help a virtual application to find a static binary dependency (even inside the immutable package cache.)
Caveat with Connection Groups
An area that confuses sequencers is how environment variables are handled with Connection Groups. Environment variable lists overwrite each when combining packages into Connection Groups. Like with registry convergence, variable convergence is a last writer win scenario in the case of overlapping variable names. The package with the highest order within the connection group descriptor document wins variable name conflicts.
Exception with Multi-String Values
Be advised though that some variables are treated specially, as they have been identified as having multi-string values. If a multi-string variable is present in multiple packages, the resulting value is the combination of values from all packages, instead of the last writer winning. The list of variable names which are treated as multi-strings is stored in the registry at HKLM\SOFTWARE\Microsoft\AppV\Subsystem\EnvVarMultiStrings
Exception with Cross-Bitness
App-V deploys special additional tokens used to denote information that has to be adjusted depending on the bitness of the sequencing machine and the correlation of the client machine. These tokens apply to environment variables impacted by Wow64 redirection. They enable the proper translation when an application that was sequenced on a 32-bit machine gets deployed on a 64-bit client machine.
The two are:
AppVEnvironmentVariableCommonProgramFiles: Can be %commonprogramfiles% or %CommonProgramFiles(x86)%
AppVEnvironmentVariableProgramFiles: Can be %ProgramFiles% or %ProgramFiles(x86)%
The rules for this are as follows:
If the application is a 32-bit application, sequenced on a 32-bit operating system, deployed on a 32-bit operating system, then these tokens are expanded back to the original values.
If the application is a 32-bit application, sequenced on 32-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to X86 versions of the values.
If the application is a 64-bit application, sequenced on 64-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to the original values.
Verification of Virtual Environment Variables
When testing environment variables within a virtual application package, the environment variables will not be visible outside of the virtual environment. That is why you will see no changes when you list the variables using the internal “set” command:
However, when you open the command prompt inside of the virtual environment, you will see the variables from above:
Comments
- Anonymous
January 01, 2003
Tim, you are correct, as often always! I have passed the feedback of a desire for a dynamic configuration guide on Technet. At least here you get the information along with my entertaining prose! :) - Anonymous
October 27, 2014
Great post; wish it were documentation!
One note: If the application attempts to change a environment variable at the client, the value is saved in the virtual registry, but not applied as it appears the package version trumps the user saved changes. This is different behavior than App-V 4.*. I haven't found a "use case" app that needs this, but I am sure it is out there. And now it is in the "documentation". - Anonymous
October 31, 2014
Tim, what do you mean by "at the client"? Do you mean post-sequencing with dynamic configuration, or do you actually mean that when run in the user environment, user-changes are ignored? - Anonymous
June 30, 2015
~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like - Anonymous
March 31, 2016
I get an error message every time, about not containing well formed appv xml :( - Anonymous
April 19, 2016
Could you be more specific? - Anonymous
May 23, 2016
The comment has been removed- Anonymous
May 23, 2016
Unfortunately it seems that the comments here do not accept my "code" pastes from the xml file. And this comment form doesn't have listed markup on what is allowed. Not sure how to proceed here, but I hope someone from MSFT can point me in the right direction just going off my problem description.
- Anonymous
- Anonymous
June 13, 2017
The comment has been removed