How to automate App-V runvirtual keys:

If you want to automate App-v’s “runvirtual” function in a large Enterprise, Ms has not provided you with any central tools to enable it for you.

Most examples online use the following two methods:

Add the runvirtual keys with a GPO or a Script in every package and deliver it during package deployment.

This is working fairly good, but it’s not very dynamic if you have a large and complex company and you need different runvirtual keys for different locations or computers you need to update GPO’s or roll out new packages if you want to change it.

The way we are doing it is fairly simple, but it does provide us with the ability to set and update all our runvirtual keys at once from a central location.

Our method was inspired by a blogpost by Thamim Karim. But we wanted to make it more dynamic so me and a member of my team scripted our own variant in 2017, and we have been using it ever since in our company.

 

How our script works:

Starting with the basics of our INI file on a machine with all empty runvirtual keys.

This is our sample ini file:

The [Ini] version part.

Just to make it easy for us we normally just put in the date of INI file creation and the last -1 part makes it easier if you have to update it several times that day, if it is different from the version on our server it will be replaced by the newest INI file.

IMPORTANT: You have to create a new INI file with the [Ini] and iniversion part to work on your computer before running the powershell script!

The [Forbidden] part.

 This is the programs we DON’T want added as runvirtual keys (if users or helpdesk has been fiddling around for them self to get stuff on the computer).

This is executed first in our script and will remove all added exe files if they exist from the list.

The [PACKAGE] part.

In the example we are using the App-V package [CLUE]

Here you just insert your package name into the brackets [].

The next part 001 is the path to your exe file.

In the example I showed that it will support wildcards from a folder, so *.exe will add all exe files in the office directory. Or you can add one and one if you like to on a new line starting with 002=windord.exe

003=excel.exe and you get the draft 

You can add as many entry’s as you want.

In this example we place our empty runvirtual ini file at the following location.

“c:\company\appv\” on our testmachine.

The location can be altered in the powershell script if you want to.

Then we run the following powershell commandline from the directory the powershell resides in:

powershell.exe -executionPolicy bypass -file .\runvirtual.ps1 -inifile "RunVirtual_product.ini" -Rule "IngenRule" -Serverini "c:\temp\runvirtual_product.ini"

First you run the powershell script using powershell.exe -executionPolicy bypass -file .\runvirtual.ps1

Then you specify what you want your local ini file to be called: -inifile "RunVirtual_product.ini"  (by default it resides under c:\company\appv, must be changed in powershell file for now)

Then we tattoo our registry with a detectionrule so Altiris would know it has been run when using policys under "HKLM:\Software\company\RunVirtual_Version" -Name 'Version' -Value $Version

The last part is the path to our master ini file: Serverini "c:\temp\runvirtual_product.ini" This could be changed to a share \\server\dfs\runvirtual_product.ini or something else you want.

You could also use the runvirtual.cmd file. It will provide you with errorcodes if  something is missing using: %ERRORLEVEL%

if($inifile -eq ''){exit 16000}

if($serverini -eq ''){exit 16001}

if($Rule -eq ''){exit 16002}

NOTE: If our script can’t access or find the specified server ini file it will try to read runvirtual.ini from the same directory as our powershell script is running from, this could be altered in the powershell scriptfile.

This is the result. As we can see it added all exe files from the “c:\programfiles  (x86)\Microsoft Office\Office15\ folder” and the correct packageguid and version guid

Then we want to test the forbidden part. We now add outlook.exe in that part and run the powershellscript again.

Now we can see that outlook.exe got removed from our runvirtual keys

Now we add a new App-V package Wisc-IV in the INI file.

Then we set chrome.exe as a runvirtual key an it gets added when running the script 

What do you need to use this script?

Well first you have to download it from my Github here.

Then you modify the powershellscript after your own liking.

#Edit the name of your ini file to suit your productname if you want. Scripts could be modified for several ini files for different locations/computers

[string]$inifile = 'RunVirtual_product.ini'

The part over here is the filename of your ini file.
# Edit this part to a share for central managment "\\share\folder\"    

[string]$serverIni = "c:\temp\"

In the example I just use a local file in c:\temp, but in production we use a DFS share where all our clients can read it. Using a central location makes it easy to update and be sure that not everyone can modify it.

The next part you need to modify is:

#Edit this part to suit your companys wanted ini file location we just use c:\company in our example

       if (!(Test-Path -Path "c:\Company\Appv")) { new-item -Path"c:\Company\Appv" -ItemType directory | Out-Null }

       $LocalIni = "c:\Company\Appv\" + $inifile

I guess most of you dont want the ini file in a folder called c:\company\appv

IMPORTANT: As stated before in the ini example, you have to create a new INI file in the scriptdir the first time with the [Ini] and Iniversion= part to work on your computer before running the powershell script!

After that has been done, you need to run it at a schedule on your computers.

We use Altiris and deliver it as a package from there on a schedule, or a task if we want it running instantly.

But you could just put up a scheduled task that’s running with an account with correct execution rights to DFS share and the powershell script running. Or build a Windows service if you want.

If I remember correct it will just use the local INI file copy if it lost connection to the DFS share.

So I hope you will enjoy our script.

Updated 25.07.19:

I apologize there is still some Norwegian parts in examples. Have updated the githubscript with an all English version J