A customer recently reported the desire to use Windows Scripting Files as the “installer” for Application Streaming profiles.  The report was that the installation could not be done under the Streaming Profiler because the profiler refused to trigger the execution of the script.

A quick reproduction confirmed the report.  Solution follows, I hope positing it here can help other folks who hit the same issue.

Experiment installer:  HelloWorld.wsf

<job id=”HelloWorld”>

‘** Hello world in VB as a Windows Script File

<script language=”VBScript”>

WScript.echo “Hello!  Fantastic, it worked.”

</script>

</job>

First – Confirm the failing behavior.

In the Streaming Profiler, tell it to use this file as the installer and the result is

“This is not a valid Win32 application”.  HUM.


Meanwhile, “Double Clicking” on this file is known to work to trigger installations when the Streaming Profiler is not involved.  What’s up with .WSF?

How to solve:

Open a command prompt and peek inside .WSF.  Two commands to get the answer

C:\>assoc .wsf

.wsf=WSFFile

C:\>ftype WSFFile

WSFFile=%SystemRoot%\System32\WScript.exe “%1” %*

Okay, the Windows application for installer really WScript.exe, not HelloWorld.wsf.

To get this installer to run under the Streaming Profiler, two steps are required.

1)      The “installer” is wscript.exe

2)      The “parameter” to the installer is HelloWorld.wsf

Click on Next,

Click on Launch Installer

Disclaimer:  This *SHOULD* work for triggering the installers that are commanded via the script.  In writing this blog entry, I have not taken it to the next step of actually installing (profiling) something.

OKAY – How’s this work?

When launching installation programs, the Streaming Profiler takes the “installer” parameter and the “parameters” and feeds them to the Win32 CreateProcessEx API, run under the context of isolation.    It would appear that .WSF is not a known extension for CreateProcessEx.

The solution is to feed CreateProcessEx the WScript.EXE file (which CreateProcessEx knows how to launch) and to give that EXE file a parameter of the script that should be executed.

This same process should be possible for other extensions that provide similar results, possibly perl, rexx and a variety of other scripting languages.

Out of the box, .EXE, .MSI, .VBS, .BAT, .CMD work when launched.   The full list is variable, but this is the general idea.

Joe Nord

Product Architect Application Streaming, Citrix Systems, Fort Lauderdale, FL