PowerShell: Persistent Environment Variables.

This comes up pretty often and if you haven't dealt with env. variables much in scripting (or even batch files) you may be confused as to why your variables don't stick around. For example:

$Env:SFT_SOFTGRIDSERVER = "appserver"

Perfectly valid, but only for that PowerShell session. Not sure why but they make you use .Net to set it permanently, and, while syntactically more complex, it isn't difficult.

[Environment]::SetEnvironmentVariable("SFT_SOFTGRIDSERVER", "appvserver", "Machine")

Likewise you can get EV's:

[Environment]::GetEnvironmentVariable("SFT_SOFTGRIDSERVER", "Machine")

It is important to note that once you set it with .Net you wont see it in $Env until you start a new session, you HAVE to retrieve it via .Net in order to see it in the same session. If you really need some functionality of $Env you can add it both ways, but I honestly can't think of a good reason you would need to do that. But it wont harm anything.

RunAsInvoker

If you have an App-V app that complains about elevation but SHOULDN'T really need it, try adding this:

<ENVIRONMENT VARIABLE="__COMPAT_LAYER">RunAsInvoker</ENVIRONMENT>

 That goes inside the <IMPLEMENTATION><VIRTUALENV><ENVLIST> tag. As always, location inside the tag doesn't matter, just that it's inside the tag. You can also use the same trick to set "process level" environment variables. Say, adding something to the PATH variable.