无法从传统的ASP脚本在IIS 7.5上运行的exe
我试图对现有系统从Windows XP专业版升级/ IIS 5.1到Windows 7旗舰版（32位）/ IIS 7.5。原来的系统运行所用ASPExec到本地机器上启动桌面应用传统的ASP网站（仅适用于本地主机）（.BAT，.CMD，.EXE等）。在Windows 7旗舰版/ IIS 7.5，应用程序无法从ASP页面启动。
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
%>
我也尝试：
<%
Set wshell = CreateObject("WScript.Shell")
wshell.run "notepad.exe"
Set wshell = Nothing
%>
这两种方法都将导致的notepad.exe在Windows进程列表来显示，但无法启动桌面上的应用程序。这是任何.exe文件我尝试运行真，.bat或.cmd文件只是不能做任何事情。
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.
使用IIS 5.1，使用ASP应用程序的原作者允许服务与桌面交互上的IIS管理服务选项和万维网发布的服务，使这项工作。所有的问题放在一边与允许桌面互动服务，IIS 7不再使用IIS管理服务，所以这不是一个选项。
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.
我要找无论从Windows / IIS一侧的解决办法或在ASP中的另一种选择，可能acheive相同的期望的最终结果。
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.
您将无法与Windows 7做到这一点。这个工作的原因是因为你正在运行IIS5.1。早在IIS5.0中/ 5.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:
- 在流程（或低隔离模式） - 在每一个网站的
inetinfo.exe下进程内运行 - 共用的进程 - 网站在外部替代进程内运行的COM +
- 进程外（或高隔离模式） - 在每个站点它自己的COM +的过程中运行
最有可能你的IIS5.1实例配置为在进行中模式和系统帐户下运行。因为你可以配置IIS服务与桌面交互，因为你的经典ASP脚本正在这个过程内执行的是能够发射可执行文件和它们出现在桌面上。
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.
在IIS7的生活是不同的。您code将其纺了按需应用程序池进程中运行。有没有办法来配置池进程（的w3wp.exe ），并让他们与桌面，即使在本地系统帐户下运行交互。
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.
也不像IIS6您不能配置IIS7的行为，如果是IIS5; IIS7是一个自下而上重写一个新的架构。
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.
一个可能的解决办法是写一个简单的WCF服务与启动HTTP端点。然后，您可以从传统的ASP code。使用类似 MSXML2.ServerXMLHttp 对这个服务电话，并得到WCF服务，推出代表你的这些进程。
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.
这存档基思·布朗的第29章的复印件的.NET开发人员指南，Windows安全解释参与得到一个服务应用程序的阴谋与桌面交互：
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开发人员指南，Windows安全 - 第29章 - 如何显示从守护用户界面（来源：archive.org）
The .NET Developers Guide to Windows Security - chapter 29 - How to Display a User Interface from a Daemon (source: archive.org)
报价：
选项之一就是让自己进入交互式窗口站和
选项二是已经有一个进程在交互窗口
站显示的UI给你。
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.
一个简单的方法把一个守护进程在交互式窗口站
（ WinSta0 ），所以它可以有它自己的用户界面是打包为一个
随着运行系统服务，并检查说中，允许
服务与桌面交互。这告诉SCM推出
在系统登录会话的服务进程（WhatIsALogonSession）
和你的流程连接到 WinSta0 代替非交互式
窗口站，其中系统守护程序正常运行，
服务0x0-0x3e7 $ 。
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$.
这是什么，你可能已经在你的XP框。但正如我所解释的，有没有办法来配置工作进程要做到这一点，因为你无法配置的允许服务与桌面交互。的标志，即使你可以配置一个池运行作为本地系统帐户。当本书是写这个应用到Windows 2000/2003。随着Windows Vista / 2008及以后的到来你有UAC的复杂因素，并让过去这一点。
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.
你应该考虑的反而是方案二：使用两个过程
而不是仅仅一个。一过程必须在交互式推出
用户的登录会话和 WinSta0 。它应该包含所有用户
你需要的界面元素，它可以连接到您的守护进程
使用进程间通信的任何安全形式你舒服
以
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
这实际上是我提出的。