App-V ABORTRESULT, SUCCESSRESULT and new free tool to make it better

Somewhere along the line, Microsoft (or was it even Softricity?) added two new attributes into OSD scripting, called ABORTRESULT and SUCCESSRESULT. The intention of these attributes is to provide some additional control for deciding if virtual application that the OSD represents should be launched, like discussed in my OSD scripting primer blog post.

I was recently testing the usage of these two attributes and started to pay attention on how the App-V Client actually handles the case when the returned value from the script does not match intended one in SCRIPT element; effectively triggering stop for virtual application launch. (These tests were done with 4.6 RTM and not SP1, but I suspect that the behaviour has not changed in-between)

Here’s how App-V Client tells our users that not everything was in order (using SUCCESSRESULT here):

Or in case of using ABORTRESULT, nothing is showed at all but launch is silently aborted, which is interesting behaviour difference in itself. The App-V Client log file shows no mention of my script (cmd.exe) at all:

But if ABORTRESULT is set to something else than what the script returns, we do get all appropriate lines in the log:

Compare this to log file when SUCCESSRESULT is used, and the return value is not matching (causing the error dialog above). While we don’t get any lines about script being run, at least we get the “end result” of our launch which is the launch failed event:

Setting aside the fact that there’s a clear behavioural difference, and that the log file cannot be trusted for in this case either, my biggest concern is that the error message is so “hostile” of sorts, if looking from the end-user’s perspective. It’s a frigging error (because it says so in the title) after all! Just like all other abnormal conditions of virtual application launches in App-V. And of course, with ABORTRESULT there’s not even any indication to the user why his or her application did not start even after franticly double-clicking the shortcut…

Since we cannot change the way how App-V works, not at least until Microsoft does something to it, I decided that we need something little bit better for improving any pre-launch, script –based, launch control. And because we cannot change the App-V implementation of SUCCESSRESULT and ABORTRESULT, there needs to be another way for bubbling up the information from OSD scripts to the actual application launch process.

Introducing the LaunchGate, a free tool to control App-V virtual application launch

For toolmaker, the answer to the problem is quite obvious: build a software tool to intercept virtual application launch and make a decision inside that tool if the actual virtual application should be allowed to launch or not. Now, remember that we cannot hook into end of any of the scripts and prevent App-V Client from continuing from there directly, because the only facility for that is the very thing we like to improve, so the only possible point we could integrate with is the process that App-V Client calls as a thing to launch when executing OSD file.

What I have thus implemented is a small executable (native Win32 one, so you don’t have any dependencies for any runtimes) that you use both for flagging launch process as needing to be stopped and also for stopping the launch. Like Tim’s LaunchIt tool – which is designed to handle issues with closing of child- and grandchild processes and more – this tool called LaunchGate needs to be added as the actual program that App-V Client calls (in FILENAME) and move the things you normally have in FILENAME and PARAMETERS attributes into PARAMETERS only:

(Just remember to change path to actual executable into absolute form by adding %SFT_MNT%\ on front of the path if such is needed, because Sequencer sets relative paths from the root of virtual drive for all executables that you start from package’s internal directory structure)

When App-V Client calls the LaunchGate, it will check if that particular virtual application (or package to be more precise) is flagged or not, and either prompts the user or executes the original application that we intended to start, with possible parameters. If the launch is stopped, the tool also clears the flag again so that future launches would be evaluated freshly.

Main issue with doing this whole operation with a separate tool is that we do explicitly need to have a line in script which calls the tool in order to flag the launch as needing to be stopped, as we cannot use ERRORLEVEL value or any other environmental value for that purpose (those change after every program executed and would not be passed on to the actual program in FILENAME). But that’s a small price to pay for having better mechanism for launch control and, more importantly, having more descript information to the end user why the application is not being launched:

The tool can also be called multiple times, if you have more complex script or several scripts, since there are parameters for it to both set the flag (“LaunchGate.exe SET”) and clear the flag (“LaunchGate.exe UNSET”). This could come in handy if your script evaluates conditions on the system and first flags because of something, but later another script unflags the process as condition is remedied. Or something to that effect. The normal case however would set the flag once and that would tell to the launch event that actual virtual application should not be started and user be informed about it.

Please note that LaunchGate requires App-V 4.6 or newer client, because it relies on a new client-based environment variable APPV_VAPPNAME that is set for all processes by App-V Client when it starts scripts or the main executable. This variable does not exist in App-V 4.5 Client or older, so sadly the tool cannot be used over there.

You can download LaunchGate from our free tools page at http://www.gridmetric.com/community/free.html and it is available as 32-bit and 64-bit builds. If you find any obvious issues in its working, please drop us a note.

—

Happy scripting and have a nice weekend!