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?
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\"
# 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
