asp classic - No se puede ejecutar el exe de la secuencia de comandos ASP clásica en IIS 7.5

asp-classic iis-7.5

Question

Estoy intentando actualizar un sistema existente de Windows XP Professional / IIS 5.1 a Windows 7 Ultimate (32 bits) / IIS 7.5. El sistema original ejecutaba un sitio web ASP clásico (solo disponible para el servidor local) que usaba ''ASPExec'' para iniciar aplicaciones de escritorio en el equipo local (.bat, .cmd, .exe, etc.). En Windows 7 Ultimate / IIS 7.5, las aplicaciones no se inician desde la página ASP.

Como pruebas (El objetivo final no es abrir el bloc de notas), he intentado:

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

También he intentado:

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

Ambos métodos harán que notespad.exe se muestre en la lista de procesos de Windows, pero no se iniciará la aplicación en el escritorio. Esto es cierto para cualquier .exe que intento ejecutar, y los archivos .bat o .cmd simplemente no hacen nada.

Con IIS 5.1, el autor original de la aplicación ASP utilizó la opción "Permitir que el servicio interactúe con el escritorio" en el servicio "Administrador IIS" y el servicio "Publicación en la World Wide Web" para que esto funcione. Aparte de todas las cuestiones relacionadas con los servicios interactivos de escritorio, IIS 7 ya no utiliza el servicio "Administrador de IIS", por lo que esta no es una opción.

Estoy buscando ya sea una solución del lado de Windows / IIS u otra opción en ASP que pueda lograr el mismo resultado final deseado.

Answer 1

No podrá hacer esto con Windows 7 / IIS 7.5. La razón por la que esto funcionó fue porque estaba ejecutando IIS5.1. Ya en los días de IIS5.0 / 5.1, tenías tres modelos de procesos diferentes:

• En proceso (o modo de aislamiento bajo): donde cada sitio se ejecutó dentro del proceso inetinfo.exe
• Proceso agrupado: los sitios se ejecutan en un proceso sustituto externo dentro de COM +
• Fuera de proceso (o modo de aislamiento alto): donde cada sitio se ejecuta dentro de su propio proceso COM +

Lo más probable es que su instancia de IIS5.1 esté configurada para ejecutarse en modo "En proceso" y bajo la cuenta de SYSTEM . Debido a que puede configurar el servicio IIS para que interactúe con el escritorio, y dado que su script ASP clásico se está ejecutando dentro de este proceso, puede ejecutar ejecutables y aparecer en el escritorio.

En IIS7 la vida es diferente. Su código se ejecutará dentro de un proceso de grupo de aplicaciones que se activa según demanda. No hay forma de configurar los procesos de grupo ( w3wp.exe ) y permitirles interactuar con el escritorio, incluso si se ejecuta bajo la cuenta del sistema local.

Además, a diferencia de IIS6, no puede configurar IIS7 para que se comporte como si fuera IIS5; IIS7 es una reescritura de abajo hacia arriba con una nueva arquitectura.

Una solución posible sería escribir un servicio WCF simple con un punto final HTTP que se inicia cuando el usuario inicia sesión (alojado en una aplicación de Windows que se oculta o se minimiza en el área de notificación). A continuación, puede realizar llamadas a este servicio desde su código ASP clásico utilizando algo como MSXML2.ServerXMLHttp y obtener el servicio WCF para iniciar estos procesos en su nombre.

Esta copia archivada del capítulo 29 de " The .NET Developers Guide to Windows Security " de Keith Brown explica las maquinaciones involucradas en hacer que una aplicación de servicio interactúe con el escritorio:

The .NET Developers Guide to Windows Security - capítulo 29 - Cómo mostrar una interfaz de usuario desde un demonio (fuente: archive.org)

Citar:

La primera opción es ingresar a la estación de ventana interactiva, y la opción dos es tener un proceso que ya esté en la estación de ventana interactiva y mostrar una IU para usted.

Una manera fácil de colocar un daemon en la estación de ventana interactiva ( WinSta0 ) para que pueda tener su propia interfaz de usuario es empaquetarlo como un servicio que se ejecuta como SYSTEM y marcar la casilla que dice "Permitir que el servicio interactúe con el escritorio". " Esto le indica al SCM que inicie su proceso de servicio en la sesión de inicio de sesión del SYSTEM (WhatIsALogonSession) y que adjunte su proceso a WinSta0 lugar de la estación de ventana no interactiva en la que normalmente se ejecutan los daemons SYSTEM , Service-0x0-0x3e7$ .

Esto es lo que probablemente ya tengas en tu caja de XP. Pero como expliqué, no hay forma de configurar procesos de trabajo para hacer esto porque no puede configurar el indicador " Permitir que el servicio interactúe con el escritorio ", aunque puede configurar un grupo para que se ejecute como la cuenta de SYSTEM local. Cuando se escribió el libro, esto se aplica a Windows 2000/2003. Con el advenimiento de Windows Vista / 2008 en adelante, usted tiene la complicación adicional de UAC y también superar eso.

Lo que debes considerar es la opción dos: utiliza dos procesos en lugar de uno solo. Se debe iniciar un proceso en la sesión de inicio de sesión del usuario interactivo y en WinSta0 . Debe contener todos los elementos de la interfaz de usuario que necesita, y se puede conectar a su proceso daemon utilizando cualquier forma segura de comunicación entre procesos con la que se sienta cómodo.

Esto es esencialmente lo que he sugerido.