About Scripts in App-V 5.0

Scripting has changed in App-V 5.0.

[Editing Note: The graphic below was updated due to an editing error in the original post.  Thanks Mark C!  Tim 3/2015]

The scripts move from the OSD to the new “Dynamic Configuration Files”, and very different options are now available to us to customize actions at the client.

Microsoft’s Aurung wrote a blogpost that describes much of the detail, but there are a few things to clarify and point out. Still, it is a great start, so go read that first and then come back. I’ll wait!

OK. You are back.

First, let’s replace the table in that post with this one:

Most important is that, depending on the script, these scripts can run in the system or user context. This allows you to do great new things like install a dependent device driver on behalf of the user. But there are some things that you need to know:

1. The “script” must started as an EXE optionally with parameters. So you might need to specify the script engine (cmd.exe, cscript.exe, etc) for some of the things you want to do.
2. Only scripts starting the virtual environment, or starting the application, can run inside the virtual environment. Everything else, including terminate application and terminate virtual environment, must be run outside the virtual environment. When a script is run outside the virtual environment, it cannot access anything inside the environment, so you’ll probably need to utilize a file share. So the idea of placing the scripts in a script folder inside the VE is cool, but how often can I really use that?
3. You will want to ensure that scripts that run don’t produce UI elements. Just try to use “C:\Windows\System32\Notepad.exe” as your script that runs under the system context to see the results. You don’t see the UI and a timeout happens. If the rollback option was specified, you become an unhappy camper.
4. You will want to ensure that script that run in the user context don’t cause UAC elevation prompts. Have a script try to create a file at the root of C:\ and if the script is running in the user context it will fail on default permission systems.
5. Don’t forget about that column about only running once. They should have given us an option on the script definition for that feature. Most of the time you are probably going to remove the package before adding again, so you will rarely have an issue, but not if you are adding a package update. This probably forces you to use a Publishing script at the Machine level with logic to figure out if it is updating the pervious or starting new.