App-V OSD scripting with Application Virtualization Explorer, pt. 1 – integrated script editing experience

In an earlier blog post, we have saw how App-V supports scripting for added package functionality and how it is configured by using the built-in tools (i.e. Sequencer) or manual methods; let’s now look at how our Application Virtualization Explorer (AVE) can make the process much easier for you regardless of the scenario.

In this first installment we will focus on the basic scripting capabilities – the same set of functionalities that we already have seen used by a “manual method” – and how AVE makes it more intuitive and expands on it.

The first thing to understand about AVE’s scripting support is that it is fully integrated in the package editing experience, that is to say there’s no need to know the syntax of OSD XML schema or anything like that like you would have to do in the Sequencer. The aim was and has been to make it as natural and straightforward as possible without having to manually stage things up.

In many ways, we feel that this is how the Sequencer should have done the scripting in the first place in order to make it more discoverable and on-par with how traditional packaging tools may do scripting support.

Scripts for applications and package

When we have opened a package in AVE, we can go and select individual published application (under Published Applications –node in Package Configuration –screen), and see that there is Add script and Edit scripts –links under Virtual and runtime environment settings section:

By using these methods we can add and modify scripts associated with individual application in the package; similar to how we went and created all those XML elements and attributes manually in the Sequencer’s OSD tab. Only this time over, you just don’t need to have any knowledge of any of that like what goes under which node in the XML tree and so forth.

If you remember, in the beginning of the scripting article, we also briefly touched a “limitation” of the OSD scripting which is that there isn’t a straightforward way of adding scripting to an App-V package that would apply to whole of the package instead of being triggered when one specific application is run. We really wanted to make that scenario possible too without additional manual steps, and so in AVE there’s actually a way to add package specific scripting too!

By going into overall Package Settings, found on the main level of Package Configuration –screen (and indeed a default view you will land into when opening a new package in AVE), there’s similar Add script and Edit scripts –links under the similar section like in individual application:

Like with one single application, using these links you can add package –level scripts to your App-V Package.

So, you may now wonder how exactly did we implement support for package level scripting and how it differs from scripts added to each published application from that package? Since App-V doesn’t support triggering of any scripts or custom commands when package is added to the client (or streamed in, whatever the case may be), we had to be little creative and actually add an additional OSD file into the package, but only when you actually add any package level scripts.

This package level script is wired so that it adds the shortcut only to a user’s Startup –group in Start Menu, which ensures that when the user logs on Windows will run the OSD file (which itself points only a dummy application that does literally nothing but exists after 1 second of execution; this was to try to make sure App-V Client doesn’t think that launch fails if the process exists too quickly), triggering all associated scripts in that OSD file. The idea is that regardless of what actual application user runs from the package this one always will be executed never the less.

Yes, we do recognize the fact that if you deploy the application package to the client on the fly and start using it immediately the trick won’t work, but at least this method is there for you to use if you pre-stage the machines with virtual applications etc. and can be relatively sure user won’t start any actual applications before having at least one logon to the machine before it. And if you have only one application published from the package, then you probably should add scripts normally to that one application as it’s guaranteed it will be the only one user will ever run then.

It is unfortunate but true that there isn’t any mechanism for running package-level scripting after or when the package is removed from the system, but at least you can run scripts for setting up the system (if there’s such need) for applications run from the package!

Adding the script

Like seen above, there’s a shorthand way of quickly adding new script to the package using Add script link, but the same can also be achieved from under the script list screen that is opened using Edit scripts link. Script list screen, when open, lists all scripts associated with the selected application. In this screen you can also click on Add script to run or Add program to run to add new script:

(Note that in the screenshot above, we have not yet added any scripts so the list is obviously an empty one)

You may again wonder what is the difference with a script and a program in context of App-V scripts; as we discussed in the OSD scripting article, OSD itself only knows between HREF and SCRIPTBODY types of scripting, a program invocation and an embedded command interpreter script. To make it more natural for you as a packager, one understanding a conceptual difference between a script (list of instructions in scripting language executed by a script interpreter) and a program (an executable), we wanted to support this distinction in the AVE’s UI and not model things based on more unintuitive way how OSD file underneath expresses things.

In the end, everything will map into HREF and SCRIPTBODY elements when we save out the package, but AVE itself “knows” about a bunch of scripting languages that will get a special handling while you are editing those scripts and settings inside AVE:

• Command interpreter script
• VBScript (both as executed by graphical wscript.exe and command-line based cscript.exe)
• Windows PowerShell

And that is what the distinction between a script and a program is in the script list: if you add script there’s a built-in tagging of your script as being one of the scripting language mentioned above, and if you add a program it’s just something that you call/execute.

When we add a script (and this is also the action taken by using Add script –link in the main interface), we will first have to specify that type of scripting language we tie our script into:

Note that in this screen, there are now two choices for command scripts which will dictate if the resulting OSD scripting block will be implemented using SCRIPTBODY (the first option) or HREF (the second option). While it could have been possible to hide this distinction completely, we wanted to enable the choice because with embedded scripting you are not able to utilize AVE’s enhanced execution options (more about those in a follow-up article for this one).

For VBscript type of scripting, there’s also two choices (graphical and console) which will tell AVE which script interpreter executable to use when scripting block will be constructed for you.

After selecting the script type, we are presented with execution settings –screen, which allows us to change the parameters for the script execution and timing. In this article, we will concentrate on the settings displayed under Basic execution settings section:

As you can see, settings and options in that section map into things we already discussed in the scripting primer article, only that they are now spelled out in more understandable terms (like “Run inside virtual environment” instead of PROTECT=”TRUE”!). You may notice that some of the advanced options are missing, like the ability to prevent virtual application launch based on the return code from the script, but these are already planned for the next minor version release of AVE as you can see from the preview screenshot of the same screen in upcoming version (details still subject to change, of course):

When we are ready with the required parameters, the final step of adding new script is to actually create content for it. For that reason, there’s AVE’s built-in Application script editor –screen which will allow in-place editing of your actual script’s contents.

You can either write out the script contents directly on the text edit area (default) or just tell AVE that your script file is already in existence somewhere else (usually a network drive) by selecting Execute script from outside the package.. – option. You can also add any possible command-line parameters that needs to be passed to the script using script parameters -section:

If you add the script contents directly to the screen, what will happen when you press OK is that AVE will automatically create the actual script file for you and store it in the package’s internal directory structure, except for embedded command script which will go directly into SCRIPTBODY. When compared how the scripting is done using Sequencer, one very clear advantage of this is that you really don’t need to think about scripting at all before post-sequencing phase: in the Sequencer if you wanted to have script in the package itself (sans the obvious embedded SCRIPTBODY script, which is only good for running command-interpreter commands in a forced window visible) you needed to add it during monitoring/wizard phase and then add the script invocation afterwards; now it’s all in the one and same step in AVE.

And you don’t need to worry about escaping rules for embedded scripts either: you just write the script normally as you would into cmd or bat file and AVE will do all the double-backslash quoting and \n line terminations automatically when the script is saved out!

If you happened to select using external script which is actually inside the package (for instance if you already had it from before with the name of your own), but later on come back to the editing screen, AVE will detect that the script is actually inside the package and allow you to do embedded script content editing.

And note that even things like running the script outside the virtual environment, but adding the script file inside to the package’s internal directory structure (so that you have a self-contained App-V package without external network path dependencies), is automatically handled for you: AVE will add some extra scripting around your own script – as a separate scripting elements – which automatically copies the script out from the VE and to the local system, executes it from there, and then cleans up after.

For normal scripts that you want to carry with the package, it just cannot get any easier than this. You don’t need to worry about between implementation details and how OSD wants things to be, you just add the script, set the parameters and everything is handled automatically in the background (and we put in a lot of work to make that happen).

And in case you’re wondering about adding a program instead of script; then the workflow is otherwise the same but without the first script type selection screen. And the actual content editing screen is much simpler as you just have a field for setting program to execute and another one for setting possible parameters for it.

Other script operations

When you have script(s) in the application, either by just having added one or coming from opened package, AVE will parse those scripts and try to detect them so that the added functionality will be available like the integrated editing. Furthermore, AVE will display different scripts in the list with different icons so you can visually see what type of scripts or program executions you have and what is their execution ordering. This makes it easy to visualize what scripts are contained in the application and without the need to scan through a complicated XML tree to do so.

When you select a script from the list, you can go back edit its contents with Edit contents -link, change execution settings with Change execution settings –link or remove it completely from the published application using Remove script or program –link.

Should you need to have a “raw” access to exactly what gets executed when the script is run, you can go in the content editing screen and select Advanced script edit –link from the bottom of that screen:

This will show exactly what will be called in the HREF element and for known script types AVE has automatically added necessary path and parameters to the script interpreter, along with the path to script file itself:

This way, should you need to do manual adjustments to the automatically generated script call you can do so again without resorting to editing OSD files by hand using the text editor.

—

We have now seen that support for App-V scripting in AVE is not only made as easy as possible, but it also does some heavy-lifting for us for scenarios wherein you would need to work additional logic in your script by yourself; like when needing to store script file in the package itself but still have it executed outside the virtual environment.

In the next article in the series, we will look at the enhanced execution options provided by AVE over what is normally available for us by using OSD scripting’s various attributes. In the meanwhile, I invite you to see AVE’s scripting capabilities by your own eyes by downloading the trial version or better yet, by buying your very own license of AVE!

Happy scripting!