iis 7.5 - Can't run exe from classic ASP script on IIS 7.5

Question

I am attempting to upgrade an existing system from Windows XP Professional / IIS 5.1 to Windows 7 Ultimate (32-bit) / IIS 7.5. The original system ran a classic ASP website (only available to the localhost) that used 'ASPExec' to launch desktop applications on the local machine (.bat, .cmd, .exe, etc). Under Windows 7 Ultimate / IIS 7.5, the applications fail to launch from the ASP page.

As tests (The end goal is not to launch notepad), I have tried:

<% 
Set Executor = Server.CreateObject("ASPExec.Execute")
Executor.Application = "notepad.exe"
Executor.ShowWindow = True
strResult = Executor.ExecuteWinApp
%>

I have also tried:

<%
Set wshell = CreateObject("WScript.Shell")
wshell.run "notepad.exe"
Set wshell = Nothing
%>

Both methods will cause notepad.exe to show in the Windows Process list, but fail to launch the application on the desktop. This is true for any .exe I try to run, and .bat or .cmd files simply fail to do anything.

With IIS 5.1, the original author of the ASP application used the "Allow Service to Interact with the Desktop" option on the "IIS Admin" service and "World Wide Web Publishing" service to make this work. All issues aside with allowing desktop interactive services, IIS 7 no longer uses the "IIS Admin" service, so this is not an option.

I am looking for either a workaround from the Windows/IIS side or another option in ASP that might acheive the same desired end result.

Answer 1

You won't be able to do this with Windows 7/IIS 7.5. The reason this worked was because you were running IIS5.1. Back in the days of IIS5.0/5.1 you had three different process models:

• In Process (or Low Isolation mode) - where every site ran inside the inetinfo.exe process
• Pooled Process - sites ran in an external surrogate process inside COM+
• Out of Process (or High Isolation mode) - where each site runs inside it's own COM+ process

Most likely your IIS5.1 instance is configured to run in "In Process" mode and under the SYSTEM account. Because you can configure the IIS service to interact with the desktop, and because your Classic ASP script is being executed inside this process it is able to launch executables and they appear on the desktop.

In IIS7 life is different. Your code will run inside an application pool process which is spun up on demand. There is no way to configure pool processes (w3wp.exe) and allow them to interact with the desktop, even if running under the local system account.

Also unlike IIS6 you can't configure IIS7 to behave as if it's IIS5; IIS7 is a bottom up rewrite with a new architecture.

A possible workaround would be to write a simple WCF service with a HTTP endpoint that starts when the user logs on (hosted in a Windows app that hides or minimises itself to the notification area). You could then make calls to this service from your Classic ASP code using something like MSXML2.ServerXMLHttp and get the WCF service to launch these processes on your behalf.

This archived copy of chapter 29 of Keith Brown's "The .NET Developers Guide to Windows Security" explains the machinations involved in getting a service application to interact with the desktop:

The .NET Developers Guide to Windows Security - chapter 29 - How to Display a User Interface from a Daemon (source: archive.org)

Quote:

Option one is to get yourself into the interactive window station, and option two is to have a process already in the interactive window station display a UI for you.

An easy way to put a daemon in the interactive window station (WinSta0) so it can have its own user interface is to package it as a service that runs as SYSTEM and check the box that says, "Allow service to interact with the desktop." This tells the SCM to launch your service process in the SYSTEM logon session (WhatIsALogonSession) and to attach your process to WinSta0 instead of the noninteractive window station in which the SYSTEM daemons normally run, Service-0x0-0x3e7$.

This is what you probably have already on your XP box. But as I explained, there is no way to configure worker processes to do this because you can't configure the "Allow service to interact with the desktop." flag, even though you can configure a pool to run as the local SYSTEM account. When the book was written this applied to Windows 2000/2003. With the advent of Windows Vista/2008 and onwards you have the added complication of UAC and getting past that as well.

What you should consider instead is option two: Use two processes instead of just one. One process must be launched in the interactive user's logon session and WinSta0. It should contain all the user interface elements you need, and it can connect to your daemon process using any secure form of interprocess communication you're comfortable with

This is essentially what I've suggested.