App-V OSD scripting with Application Virtualization Explorer, pt. 2 – additional scripting capabilities

In the previous article of AVE’s scripting capabilities, we discovered how AVE implements the basic App-V scripting capabilities – but in much smarter manner and easiness lacking in any other App-V –related tool there is. In this installment, we will see how to take scripting a bit further, by adding additional execution capabilities for our scripts or programs called as scripts.

As we saw the last time, when adding a VBscript script in to the application, we were able to change the script’s execution settings based on the features that App-V itself supports in OSD scripting like when to run, whether or not to run inside the “bubble” and if the App-V Client will stay and wait for our script’s completion or not. Excluding few additional attributes supported by the App-V, those characteristics are not really much to go with if you start to think about possible real-life scenarios:

• What if I need to do local machine set-up for the newly added package, but need it to be done just once?
• What if I don’t want my users to know/see that the script is executing prior to application launch?
• What if I need to do operations in the script, or invoked program, that my user’s do not have rights for (like, say, modify things in HKLM branch of the physical registry)?

Implementing support for additional scripting features in AVE

For addressing these cases and more, when we added scripting support for AVE in version 2.2, we wanted not only to make it more user-friendly but also to enhance the capabilities over what you are able to do with scripting using Plain Jane App-V Sequencer. The problem here of course is that attributes and elements in the OSD files are already defined and cannot be extended per se, since App-V Client would not be able to make any use of those extended attributes. And we did not want to rely on anything that has to be installed on every client to do some additional tasks for the scripting purposes.

Hence the solution that AVE uses for enhancing script’s execution time capabilities: adding our own script launcher in to the package which takes on the responsibility for doing the actual execution of what we want to execute in scripting, instead of App-V Client doing so.

If in the normal – non-enhanced – model the App-V Client will start whatever HREF tells it to start, with the presence of additional execution parameters the model changes so that the App-V Client only starts our own script launcher (ScriptRunner.exe) which in turn read the enhanced settings parameters and acts upon those, like in the following diagram of executing a VBscript file:

Note that the script launcher executable itself is written in .NET 2.0 so that’s why you will need the framework runtime deployed to all the clients. In the newer Windows versions (Vista+) this is kind of no-brainer requirement as 2.0 is already built-in.

As already mentioned, the script launcher upon launch will be reading only those parameters that are beyond what App-V itself provides; there is no point in duplicating already existing script execution settings as those are needed to trigger to script to begin with and control the process’ placement when it comes to virtual environment. Now, depending on if we are executing the scripting outside the virtual environment or inside it, AVE stores the parameters little bit differently. The reason here is that if we run inside the bubble, most convenient place to put those parameters is the virtual registry as our launcher can read the contents of that. But if we run the scripting outside the virtual environment, our launcher by necessity have to run too so we cannot have access to anything in the virtual registry and must read settings from the parameter file.

Since we carry our launcher executable inside the package’s directory structure, along with the settings, there are all sorts of complicated preparational steps needed to be done before our launcher, parameter file and possibly the script file itself too is ”jail braked” from the virtual environment to the real system; and then cleaned up afterwards. Fortunately, you don’t have to do anything extra to make it happen because scripting support in AVE will handle all of those things automatically based on you just de-selecting that Run inside virtual environment –setting in the script’s execution settings screen.

Your only indication that we do some extra processing for you is that in the script listing screen you will see special pre- and post-scripts that sets up the stage:

Supported enhanced execution mode settings

As you probably already discovered from the screenshot of script execution settings screen in the previous article, enhanced execution mode settings are all under separate section from the basic settings:

Enhanced execution mode features that AVE currently supports are:

• Running script only once, with additional settings for controlling what constitutes a once: once per the machine virtual application is deployed to, once per user account that is executing the application even when Repair –operation is run against the package or package re-deployed or once per so-called life-time of cached virtual environment for that package cleared at package repair. This settings is very useful for running scripts that need to do preparations for the machine, for the user profile etc. without you needing to add re-run logic inside the script itself.
• Hiding scripts execution, if at all possible. What we will do in this case is that we start the target process with a setting that hides any visible windows that the target application may create. It is not 100% water-tight, however, because the target process may modify its own window visibility state (that’s fortunately not usual with normal scripts).
• Starting the target process with alternate credentials. The use case for this is most certainly the need to run scripts in administrative context in order to have it possible to touch parts of the physical system that normal user does not normally has rights to modify.

As a tip, it should be noted that if you utilize these enhanced settings, especially for running processes in alternate context, please experiment first without the “only once” setting set on. This is because if your execution fails for some reason or another (typos in credentials), script launcher would have already set the flag that the script run once and following tries on the same machine only causes script to be skipped silently.

When setting script to be run with alternate credentials, there’s the valid concern of how AVE stores those credentials if they are simply put into virtual registry or parameter file for script launcher to read (and for anyone else to read, which is the concern). To secure the credentials, AVE will encrypt the credentials using standard encryption algorithm (Rijndael symmetric algorithm, which is functionally equivalent to AES) and store credentials only in encrypted form:

When script launcher needs to read the settings, it will decrypt the credentials so that they only ever exist in unencrypted form while in memory.

 —

After getting ourselves set with the standard scripting features, we have now seen in this article that App-V scripting support in AVE also has features that you simply cannot do in one-stop-shop manner with the traditional methods or at all if relying only on the Sequencer and App-V Client itself. Hopefully this gives you good pointers on going forward with implementing your own scripts, and with less effort and trouble that you had to endure up until now.

In the next and final article in the series, we will look at the pre-made scripts provided by AVE so that you don’t have to re-implement the wheel, every time. In the meanwhile, I invite you to try and play with AVE’s enhanced scripting capabilities by downloading the trial version or better yet, by buying your very own license of AVE!

Happy enhanced scripting!