App-V OSD scripting with Application Virtualization Explorer, pt. 3 – we do it for you!

As discussed in parts one and two of this series, we already have seen that doing scripting with AVE Professional instead of Sequencer or manually with text editor offers significant easiness not only due to integrated editing and settings –capabilities, but also because of enhanced scripting capabilities that only AVE offers out-of-the-box. In this final part of the series we take a look at something that we call application configuration scripts, which can be utilized for common tasks needed with virtual applications.

Application (or package –level) configuration scripts are pre-made scripts (in VBscript, so that they can be run silently even without using enhanced scripting options which require that .NET 2.0 runtime on the clients), which makes it even more straightforward to implement certain often-needed tasks that App-V packagers face. Some of the scripts are only applicable to individual virtual applications, some only to package level scripting (which was discussed in the first part of this series) and some can be used in both.

Currently shipping configuration scripts can be used for following (and we’ll visit them each in this post) tasks:

• Setting application compatibility settings
• Establishing drive mappings
• Adding entries to Windows’ HOSTS file
• Installing pre-requisites software
• Adding protocol handlers

Application –level configuration scripts can be added by going into application information in the Package Configuration screen, and clicking on the Add application configuration –link in the Virtual and runtime environment settings –section (the same where you add your normal scripts with AVE):

This will present you a screen where all available configuration scripts are selectable:

By selecting any one of the application configuration item in the screen, and pressing Create –button, you are represented a screen for script parameterization. This screen is of course different for all the different application configuration scripts, and they are presented below when discussing the different configuration scripts available.

After specific script has been configured, AVE will create one or more scripts directly into that application and they are shown as “Application/package set-up script” in the normal script listing window:

A reason for displaying them like this is to visually differentiate AVE originated scripts from your own scripts, so that you don’t accidently remove them away. As application configuration script feature is “one-way” process in AVE (meaning, we ask for parameters and generate scripts accordingly) there isn’t GUI –based post-creation editing for the script parameters (manually tweaking the scripts is of course possible if you know what you are doing), or removal other than selecting the script and removing it manually.

The process for adding package level scripting is the same, but it needs to be done from Package Settings -screen instead of per application –basis.

Okay, so now that we know how to start adding configuration scripts, let’s have a run-down of each of them.

Compatibility settings script

Like we discussed already in an earlier blog post, there is a manual method – and quite easy at that – of adding Windows compatibility settings to a virtual application.

Well, here’s even easier way to do the same: application configuration script that does the things we discussed!

You just select Compatibility settings from the list, and in the configuration screen you enable settings you want to have for compatibility:

After pressing Accept –button, necessary script(s) are created for you and will be executed before application’s launch. It’s literally under one minute job to enable compatibility settings for a virtual application with this configuration script.

Drive mappings script

Like everyone knows, network mappings are something that cannot be directly done using virtual environment configuration in App-V. You just have to script them unless done externally with things like Group Policy Preferences or User Environment Management (UEM) software.

With AVE’s application configuration script, it’s also easy to add network or local mappings to the package by using Drive mappings –selection on the list.

In the configuration screen, you can add any number of drive mappings with Add new… -link:

This will open another screen wherein you can set the drive letter and path to use for that drive letter. If you want to do local mapping (i.e. SUBST), you can enable it with checking the Drive is mapped to a local path instead of network –option:

After creating the mapping, it will show up on the list of drives to be mapped on main configuration screen. Before creating the script for mapping, you can also enable options to do disconnection for the mapped drives (only for ones you define) before the mapping is attempted or/and after virtual application has been shut down. This makes it possible to clean up afterwards so nothing will be left mapped when application itself doesn’t use them anymore:

Hosts file entries script

One specific “shortcoming” or rather a side-effect of how and where Virtual Filesystem (VFS) in App-V is done by the App-V Client is that the hosts file in Windows cannot be virtualized with it. This happens because HOSTS file is read by the network stack underneath, and since it doesn’t operate in the same process as the virtual application has for itself, network stack (or name resolving functionality) does not have any visibility to VFS’ed files. (As a sidenote, it’s interesting that services –file can be virtualized (hello SAP!) but hosts file then is a different story)

Making things even more complex, trying to add entries to this file on behalf of virtual application package with normal OSD scripting just cannot be done, because hosts –file lives in a protected operating system location and thus has ACLs that prevent normal users tampering with it. So if you are looking into writing to hosts file in OSD scripting, the write has to be done under account that has administrative rights.

Fortunately, selecting Hosts file entries from application configuration scripts list does exactly this!

When you configure hosts –file writing script, you first of course need to specify host name(s) that you want to add to the hosts –file. This can be done again (like in network mappings script configuration) with Add new… -link:

When hosts entries are set, you cannot begin script generation before specifying alternative credentials under which the creation script will be executed. This feature directly utilizes AVE’s enhanced scripting capabilities to achieve execution with alternate credentials:

Note that if you use local account (instead of domain one), you should left Domain –field empty. In practice, in most of the organisations, you likely will have a special domain service account just for this purpose so that you don’t need to rely on local accounts being set up in same manner.

If, after creation, we take a quick look at the generated script and its execution settings, we can see that there’s also run once –option set so that hosts –file won’t be repeatedly written to on each application launch. This is yet another thing that would need to be handled if trying to do same thing manually with OSD scripting, but with AVE’s configuration scripts –functionality can be implemented literally in few minutes!

Install pre-requisites software script

As application virtualization cannot handle all the possible technical aspects of Windows applications – like drivers, boot time services etc. – sometimes you need to separate part of the large application suite’s functionality into locally installed piece and the application piece which is done virtually. A good example of a package such as this is having the mobile phone USB cable drivers in Nokia’s Ovi Suite delivered as MSI package, and then delivering the actual application as a sequence.

The problem here is how to synchronize those two: if you are using solely App-V -based solution like Management Server, you need to come up a way to do those MSI installs outside it as normal software package delivery and targeting is not available over there. Using SCCM has its own share of issues, at least in the current official version (2007), as you cannot chain physical application installs to virtual applications (other way around is possible, however) so that SCCM client would first install a MSI package and then add App-V package to the client.

Okay, but what about the scripting using OSD? That’s possible, but you have a number of things to solve before the installation can reliably be done with it: does it run in user’s context (not likely if it installs anything serious), how to prevent it from running over and over again on each launch, etc.

Like with other configuration scripts in the AVE, these are all automatically handled for you when using Install pre-requisites software configuration script. By utilizing enhanced scripting features of AVE, all the problematic dancing around the isolation and user-context execution can solved and pre-requisites software installed as part of the App-V package execution so that during the first launch user will have to wait for local install to happen and then it will be there for the virtual application.

When the script configuration is started, there are few things that we have to set up:

First one is that we have to decide if we want to store our installer directly inside the package or allow our script to access it from the outside (like network share). The most important distinction here is that if you place the installer inside, it can only be one single executable or MSI file, and no other files like external CAB files can be used. But if you access some installer file somewhere else, it can have any kind of structure as its read directly from the location.

Secondly we can add any parameters needed for the MSI or executable installer.  Note that for MSI installs the script will automatically use /qb- parameter so that the end user don’t have to interact with the setup (but will see it’s running, this is to prevent them wondering why virtual application does not start as quickly as they expect) so you only need to set any custom MSI properties you would like to pass to the Windows Installer.

Then we can decide whether the installation should be done once per machine or once per user. Of these, per machine option is the default and most likely the one needed.

Finally, if it’s required, we can set credentials under which the setup (and the OSD script itself) should be started. If using installation package which is not stored to the App-V package, then you must make sure that the user account here (in addition to having sufficient privileges to the local machine) has rights to the whatever network path you might be using. If the installation file is stored directly to our SFT file, then configuration script takes care of first copying it out from the virtual environment so that the setup is run without App-V’s bubble being around it (and preventing access to real registry etc.).

After setting all the necessary options and pressing Accept –button, AVE will create the scripts and copies the installer to the package (if selected).

Should you need to troubleshoot why your installation is not run at the client, despite setting everything seemingly correctly, it’s probably best to go to switch run-once setting off for the script because failed execution too will flag script having been run already.
This can be done by going into script list for application (or package) and locating the installation script and then editing its execution setting. The correct script is the one that is started before virtual application startup (others are for copying installer out from the package and cleaning up afterwards):

Go to enhanced settings and switch Run script only once –option off:

This way the script will be run over and over again, making it easier to experiment with different credentials etc. until you get it to execute correctly.

Protocol handlers script

The last configuration script we take a look at for the current version of AVE is one for setting protocol handlers. This particular thing, once again, is for trying to “fix” yet another missing feature in App-V when it comes to integrating virtual applications with the local system. App-V Client is able to publish shortcuts for our virtual applications, and creating file-type associations for them, but presently it cannot register any protocol handlers that application may have created during sequencing.

It is, in fact, quite rare for an application to use any such, but sometimes we come across virtual application which registers protocol handler(s) to the system so that the user may start it through things like a hyperlink. If then the protocol handler is not there, Windows has no way of knowing that it should execute our virtual application for the purpose.

As protocol handler is not really an application specific setting, but rather applies to the whole App-V package, you need to use package scripting to establish protocol handlers by selecting Protocol handlers from that list.

To make it really easy, we actually added some auto-detecting into AVE for this particular purpose. If, during the packaging of the application, original installer created protocol handlers, those registrations still persist in the virtual registry even though the Sequencer does not use them; therefore it is possible for us to detect existing registrations and pre-populate the script configuration screen with that detected information:

In this case, sequence for Skype already has the skype:// -handler in its virtual registry and so we can take that information and add it to the list! Skype uses the protocol handler for having those call –buttons on webpages, and without proper protocol handlers it is not possible to launch the application from such a link.

By default the configuration screen also has the Do not register if protocol already exists on client –option selected. What this option means is that our configuration script won’t override possible already-existing registration for the same protocol. This is a good thing to keep enabled because if you already have some other application, locally installed, that handles the protocol then the virtual application won’t “steal” it. Unlike file-type associations, you really only can have one application that handles a particular protocol at any given time.

When registering for protocol handlers using AVE’s configuration script, please be aware that there is no way to automatically de-register handler(s) as OSD scripts cannot be triggered when application/package is removed from the client. So if you use this feature, you must manually clean up the (user’s) registry should the package be removed at some later date.

—

This post concludes our series on App-V package scripting with AVE; hopefully these three posts have given good pointers on why using AVE for handling your package scripting instead of relying on regular Sequencer might be a good idea. At least one thing can be promised: it’s much, much faster this way!