AppV5 – System Environment Variables Gotcha’s

AppV5 – System Environment Variables Gotcha’s

/ /
in Blog

We had an application that has its environment configured via ‘system environment variables’.  System environment variables differ from ‘user’ environment variables in that they are global so all users see them, and in a native Windows environment, they are stored in a different location; but still in the registry.  So it seemed, like everything else App-V, these values would be captured (they are just registry values).  Imagine our surprise when they were *not* captured.

The tech who was working on this thought this must be a mistake, exported the registry keys he needed into a file and imported them into the package:




He created a startup script that would modify the environment variables to whatever environment the user wanted to launch (Test, Prod, Dev, etc.).

BUT, no matter what was set the application always launched with the parameters it was sequenced with.  In this case it was always PROD.  We would put a ‘SET’ or ECHO ‘%TT_SYS1%’ or some such into the batch file, after the ‘SET/SETX’ commands we could see the variables were different.  They were what we expected them to be.  But launching a new process with these changed variables resulted with the new process inheriting the original environment variables.  So it was always PROD.  Now, these are SYSTEM environment variables and Microsoft released a utility, setx, which you can use to manipulate them.  This utility still did not work as expected, the variables were not being retained by a child process.

“By default, a child process inherits the environment variables of its parent process.”

When this was brought to my attention I suggested we explore ‘Exporting the manifest and seeing what was stored there’. Changing the registry entries in the package did NOTHING.  So I suspected they weren’t being used at all…

What we found is when we extracted the manifest file:

We saw where the environment variables where being stored.  By deleting this section and reimporting the manifest file we found that we could set environment variables and they would correctly inherit from the parent process from then on.  But if you do NOT delete this section of the Manifest file, then whatever is set for that AppV session will be reset for any new processes created in the bubble.


Final Analysis:

AppV5 treats Environment Variables differently then one would expect from a native system.  My expectation when I enter the bubble is an environment that I could manipulate and then have those changes persist for the duration of that session.  Instead, AppV environment variables are reset for EVERY process in the bubble.  Although you can manipulate them in the current process, creating a new process (cmd.exe/powershell.exe/whatever.exe) results in those changes being reset for variables specified in the manifest file.

One Comment

  1. The Kahuna 2017-06-05 3:25 pm

    Trent – let me add some tidbits that might help, or just outright confuse!

    I use a purpose built test app that creates both a system and user environment variable, and the sequencer does indeed properly detect the variables and at runtime the client sees them. So the initial problem detected was either mis-diagnosed OR the method used to create them in the tech’s package was “different” causing them not to be captured (like somehow it managed to be created by an existing process or something).

    Another idea for a possible cause comes from the 7-zip affect with FTAs. 7-Zip creates the FTA entries upon first launch of the app and not upon installation. The capture of shortcuts and ftas is known to happen during that transition from installation to the screwy “configure the app” screen. So if you launch 7-zip there to configure the FTAs end up in the virtual registry, but not in the manifest.xml file. Possibly the capture of Environment Variable information occurs at the same time, and perhaps your friend created the environment variables in that configure app phase of the wizard.

    The App-V client doesn’t care if the environment variable change is system or global; this is seen in the internal manifest.xml file where they are just listed as environment variables. The concept there is not unlike shortcuts of FTAs where the value might be in the HKLM or HKCU branch but the XML representation of the shortcut doesn’t care (and actual implementation in that case is based on how the package is published).

    The App-V client uses that XML information to inject those environment variables into the environment block of the process (this is a portion of kernel memory for the process) when the process becomes virtualized. As such, all such injected environment variables are effectively more like “per user” (technically they would be per virtual environment). Once the environment variable is in the environment block, nobody looks at what was in the registry, and this is why just changing the registry after that capture doesn’t affect anything.

    The way that environment variables get injected carries over to a secondary effect that I have noticed. If at the client you run the app and it changes environment variable values further, those are captured and visible in the redirected registry for the package, but don’t get used when you launch the app next time. Again, here the virtualization is only looking at that internal manifest file and ignores the redirected registry values. Very few programs modify environment variables at runtime (mostly developer tools I think) so we don’t really run into this very often.

    Maybe this helps?


Post a Comment

Your email address will not be published. Required fields are marked *