> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/es/config/hosting/hosting-iis.md).

# IIS

Aloje PowerShell Universal en IIS configurando el grupo de aplicaciones, los enlaces del sitio web, los ajustes de web.config y la autenticación de Windows para los trabajos.

## Alojamiento en IIS

PowerShell Universal admite ser alojado en IIS (Internet Information Services (IIS) para Windows® Server). Tenga en cuenta que se requieren una serie de prerrequisitos del host y pasos de configuración específicos para facilitar la ejecución de PowerShell Universal en IIS. Revise cada sección detenidamente, ya que IIS requiere muchos ajustes de configuración específicos para funcionar con aplicaciones modernas de .NET Core como PowerShell Universal.

## Paso 1: preparar el host de IIS

Se requieren los siguientes componentes para alojar PowerShell Universal en IIS.

* [Internet Information Services (IIS) versión 10.0](https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/new-features-introduced-in-iis-10-1709)
  * Incluido: protocolo WebSocket
* [ASP.NET Core Hosting Bundle 10.0](https://dotnet.microsoft.com/en-us/download/dotnet/9.0)

También es necesario habilitar las siguientes funciones de IIS de Windows Server en el host de IIS:

| Nombre para mostrar de la función | Requisito                                       | Script de instalación                     |
| --------------------------------- | ----------------------------------------------- | ----------------------------------------- |
| Protocolo WebSocket               | Necesario para ejecutar PowerShell Universal    | `Install-WindowsFeature Web-WebSockets`   |
| Autenticación de Windows          | Necesario para usar la autenticación de Windows | `Install-WindowsFeature Web-Windows-Auth` |

Primero, asegúrese de habilitar la función de IIS en Windows Server y, a continuación, instale el paquete de hospedaje de ASP.NET Core.

**NOTA**: IIS suele requerir un reinicio del host después de instalar el paquete de hospedaje de .NET Core. Se recomienda encarecidamente REINICIAR el host de IIS después de instalar el paquete de hospedaje de .NET Core.

Una vez cumplidos estos prerrequisitos, ya está listo para comenzar la configuración de PowerShell Universal en IIS.

{% hint style="warning" %}
Habilitar la función Publicación WebDav de IIS causará problemas con Universal. La publicación WebDav filtra las solicitudes HTTP e impide los verbos PUT y DELETE de forma predeterminada. Si tiene habilitada la publicación WebDav, asegúrese de haberla configurado correctamente para permitir estos verbos.
{% endhint %}

## Paso 2: descargar PowerShell Universal

Descargue la última copia de PowerShell Universal. Deberá descargar la versión de archivo **ZIP** de PowerShell Universal. Este archivo está creado específicamente para quienes desean configurar PowerShell Universal para IIS u otros servidores web de terceros. Extraiga el contenido del Zip en la ubicación de la carpeta de host web prevista en su host de IIS.

Debe asegurarse de que los ficheros de la aplicación PowerShell Universal se desbloqueen después de extraerlos. Puede desbloquearlos con el cmdlet `Unblock-File`.

```
Get-ChildItem C:\inetpub\wwwroot -Recurse | Unblock-File
```

{% hint style="warning" %}
Esta ubicación es muy importante y se hará referencia a ella a lo largo de este documento. Lo más importante es que esta ubicación debe ser accesible por la identidad utilizada por el grupo de aplicaciones de IIS.
{% endhint %}

## Paso 3: configuración del grupo de aplicaciones de IIS

Ahora que nuestro host está listo y hemos descargado PowerShell Universal, podemos comenzar a configurar IIS.

El primer paso en el proceso de configuración de IIS es crear un nuevo grupo de aplicaciones en IIS. Antes de comenzar la configuración, debemos asegurarnos de seleccionar una identidad válida para el grupo de aplicaciones de IIS.

### 3.1: elegir una identidad de grupo de aplicaciones

La identidad del grupo de aplicaciones es crucial para PowerShell Universal, ya que este será el «usuario predeterminado» con el que se ejecutarán los trabajos y las apps (antes conocidas como dashboards). También será el usuario que realizará las operaciones de lectura/escritura en la base de datos de Universal Automation y el que IIS utilizará para leer el directorio de contenido web y ejecutar la aplicación.

Se sugiere usar «**LocalSystem**» o una **cuenta de servicio** de su elección.

Debido a las limitaciones de IIS, los ajustes de la identidad del grupo de aplicaciones tienen consecuencias **IMPORTANTES** en el comportamiento de las opciones «**Run As**» al usar Universal Automation.

{% hint style="danger" %}
**Limitaciones de IIS con Universal Automation**

* **App Service configurado como Local System** - Los scripts se ejecutarán como la cuenta System de forma predeterminada y ***SE PUEDEN** especificar cuentas Run as* al ejecutar un script en Universal Automation
* **App Service configurado como una cuenta de servicio** - Los scripts **SOLO** se pueden ejecutar con la cuenta de servicio y **\*\******Run as Account*** \_\*\*\_NO\*\* se puede especificar al ejecutar scripts.
  {% endhint %}

**Requisitos de identidad de la cuenta de servicio**

* [ ] Acceso completo de lectura/escritura a la carpeta de la aplicación PowerShell Universal que extrajimos en el **Paso 2**
* [ ] Acceso completo de lectura/escritura a la base de datos de PowerShell Universal: predeterminada: *C:\ProgramData\Universal Automation*
* [ ] Derechos de *Iniciar sesión como trabajo por lotes* (p. ej., desde secpol.msc > Directivas locales > Asignación de derechos de usuario

{% hint style="info" %}
La ubicación predeterminada de la base de datos se puede personalizar mediante el fichero `appsettings.json` de PowerShell Universal si así se desea.
{% endhint %}

Una vez que hayamos seleccionado una identidad válida, estaremos listos para crear el grupo de aplicaciones en IIS.

### 3.2: crear el nuevo grupo de aplicaciones de IIS

Ahora que hemos elegido una identidad de grupo de aplicaciones que tiene acceso de lectura/escritura a las carpetas de la aplicación y de la base de datos de PowerShell Universal, podemos crear el grupo de aplicaciones en IIS.

* En el Administrador de IIS, elija la opción **Agregar grupo de aplicaciones...**
  * **Nombre:** use cualquier nombre que desee para el grupo de aplicaciones
  * **Versión de .NET CLR**: No managed code
  * Haga clic en **Aceptar** para crear el grupo de aplicaciones.

### 3.3: configurar la «Configuración avanzada» del grupo de aplicaciones de IIS

Ahora que se ha creado el grupo de aplicaciones, tendremos que configurar la **Configuración avanzada**

* Abra la «**Configuración avanzada**» del grupo de aplicaciones y aplique las siguientes configuraciones:
  * **General / Habilitar aplicaciones de 32 bits**: False
  * **Modelo de proceso / Identidad**: use la identidad que seleccionamos para nuestro grupo de aplicaciones en la sección «Elegir una identidad de grupo de aplicaciones» anterior.
  * **Modelo de proceso / Cargar perfil de usuario**: True

Una vez aplicada la configuración avanzada, nuestro grupo de aplicaciones estará listo; nuestro siguiente paso será configurar el sitio web de IIS que utilizará este grupo de aplicaciones.

## Paso 4: configuración del sitio web de IIS

### 4.1: preparar el web.config para nuestro sitio web

Ahora que tenemos un grupo de aplicaciones válido, necesitamos crear un sitio web de IIS para exponer la aplicación. Antes de hacerlo, conviene revisar el fichero `web.config` de PowerShell Universal para nuestro sitio web. Dentro de la carpeta extraída de la aplicación PowerShell Universal, encontraremos un fichero web.config. Este fichero de configuración ha sido diseñado específicamente para IIS y contiene una serie de configuraciones que debemos revisar antes de crear el sitio web de IIS.

Lo más importante es que tendremos que actualizar el valor del argumento «**processPath**» de este fichero de configuración. Este valor proporcionará a IIS la ruta exacta del binario de la aplicación para que pueda iniciarla correctamente.

* Abra el fichero web.config en la carpeta de la aplicación PowerShell Universal
  * Localice la sección **\<aspNetCore** **processPath** del fichero de configuración
  * Cambie el argumento processPath de «.\Universal.Server.exe» a la ubicación exacta de la ruta de Universal.Server.exe (vea la figura siguiente como ejemplo)
  * Guarde el fichero para aplicar la configuración

```markup
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="C:\Program Files (x86)\Universal\Universal.Server.exe" arguments="" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="InProcess"/>
  </system.webServer>
</configuration>
```

{% hint style="info" %}
Hay diversas configuraciones adicionales en este fichero. Las revisaremos con más detalle en la sección «Configuración avanzada», pero puede consultar «**Configuraciones adicionales de web.config**» en esta página para obtener más detalles
{% endhint %}

### 4.2: crear el sitio web de IIS

Ahora que se ha creado un grupo de aplicaciones para PowerShell Universal con una identidad válida y hemos configurado el fichero web.config, por fin estamos listos para crear el sitio web de IIS. El componente de sitio web de IIS carga los artefactos de la aplicación y expone la aplicación en el punto de conexión web configurado.

1. En el Administrador de IIS: haga clic en «Agregar sitio web..»
2. Configure las opciones del nuevo sitio web:
   * **Nombre del sitio**: use cualquier nombre que desee, p. ej.: `PowerShell Universal.`
   * **Grupo de aplicaciones**: **NO** use el *DefaultAppPool* - **Seleccione** el grupo de aplicaciones que creamos en el paso anterior.
   * **Ruta de acceso física**: debe ser la ruta física al contenido de PowerShell Universal que extrajimos de nuestro fichero .zip descargado. **NOTA**: la identidad del AppPool debe tener acceso a la ubicación.
   * **Configuración de enlace**: tenga en cuenta que, para la configuración inicial, se sugiere usar los valores predeterminados básicos; los actualizaremos más adelante en nuestra configuración avanzada
     * Tipo http - Para la configuración inicial
     * Dirección IP: Todas las no asignadas
     * Puerto: 80
     * Nombre de host: nombre del host

## Paso 5: iniciar el sitio web

En este punto, todas las configuraciones necesarias deberían estar en su lugar y el sitio web de IIS que aloja PowerShell Universal debería estar en funcionamiento. Con un navegador web, vaya a la ubicación del sitio web configurado para validar que PowerShell Universal se ha iniciado. Desde aquí puede seguir la guía «Primeros pasos» para validar la funcionalidad básica. Una vez que esté seguro de que la aplicación funciona correctamente con una configuración básica de IIS, puede continuar con la «Configuración avanzada» para proteger y finalizar la configuración de IIS que desee.

{% hint style="info" %}
Si sigue experimentando problemas con la configuración básica de IIS, pruebe a comprobar la ruta «Logs» especificada en el web.config para detectar problemas comunes. Si sigue teniendo problemas, póngase en contacto con los foros o con el soporte para obtener ayuda.
{% endhint %}

## Aplicaciones de IIS anidadas

Es posible anidar varias instancias de PowerShell Universal en un único grupo de aplicaciones y sitio web, pero requiere cierta configuración adicional.

Necesitará tener dos carpetas para los ficheros de su aplicación: una para cada aplicación. También deberá configurar dos carpetas de datos: una para cada aplicación.

Una vez que haya configurado su estructura de carpetas, deberá crear dos ficheros appsettings.json y actualizar los ficheros web.config de cada aplicación.

Dentro de los ficheros appsettings.json, deberá establecer las rutas correctas a los ficheros de datos de cada instancia. También deberá configurar la URL base correcta para el sitio anidado.

```json
{
  "Kestrel": {
    "BasePath": "/psu1"
  },
  "Logging": {
    "Path": "C:\\src\\psu\\data1\\log.txt",
  },
  "Data": {
    "RepositoryPath": "C:\\src\\psu\\data1\\Repository",
    "ConnectionString": "filename=C:\\src\\psu\\data1\\database.db;upgrade=true",
  }
}
```

A continuación, deberá actualizar los ficheros web.config de cada sitio para que usen el fichero appsettings.json adecuado y utilicen el hospedaje OutOfProcess.

```markup
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\Universal.Server.exe" arguments="--appsettings C:\src\psu\appsettings.psu1.json" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="OutOfProcess" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 588ACF2E-9AE5-4DF1-BC42-BCE16A4C4EDE-->
```

Ahora, dentro del Administrador de IIS, haga clic con el botón derecho en las carpetas psu1 y psu2 para convertirlas en aplicaciones.

Ahora debería poder acceder a la consola de administración de PowerShell Universal en las dos URL siguientes.

```
http://localhost/psu1/admin
http://localhost/psu2/admin
```

## Configuración para trabajos

{% hint style="warning" %}
Una configuración incorrecta del grupo de aplicaciones puede provocar que los trabajos no se ejecuten. La causa principal es el reciclaje del grupo de aplicaciones o un fallo al iniciar la aplicación web cuando se inicia el servidor. Esto no supone un problema para funciones como las APIs o las apps (antes conocidas como dashboards), pero debido al procesamiento en segundo plano de los trabajos, deberá asegurarse de que el servidor inicie el sitio web y lo mantenga en ejecución. Puede [obtener más información aquí](https://docs.hangfire.io/en/latest/deployment-to-production/making-aspnet-app-always-running.html#making-asp-net-core-application-always-running-on-iis).
{% endhint %}

Si va a ejecutar trabajos programados en su instancia de PowerShell Universal alojada en IIS, debe asegurarse de configurar IIS adecuadamente. Hay varios ajustes que validar al configurar su grupo de aplicaciones.

### Inicialización de aplicaciones

Instale la función Inicialización de aplicaciones del rol de servidor web.

### Configuración del grupo de aplicaciones

Querrá configurar los siguientes ajustes:

* **General**: versión de .NET CLR = [No Managed Code](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/advanced?view=aspnetcore-7.0#sub-applications).
* **General**: modo de inicio = AlwaysRunning
* **Modelo de proceso**: ajuste de tiempo de espera de inactividad = 0 (deshabilitado)
* **Reciclaje**: intervalo de tiempo regular = 0.

### Configuración del sitio web

Dentro del sitio de IIS que aloja Universal, deberá asegurarse de que Preload esté habilitado.

### Variables de entorno

Aunque intentamos detectar que PSU se está ejecutando en IIS, es posible que encuentre problemas con el controlador de autenticación negotiate habilitado cuando no está soportado en IIS. Para asegurarse de que esto no sea un problema, puede deshabilitarlo por completo creando la siguiente variable de entorno en su máquina de IIS.

```powershell
$Env:PSU_DISABLE_WIN_AUTH = true
```

### Depuración de problemas con IIS y los trabajos

Si sigue teniendo problemas con IIS y los trabajos, debería considerar activar el[ registro de reciclaje de IIS](https://blogs.iis.net/ganekar/iis-7-0-application-pool-recycles-log-a-event-in-windows-event-log) para asegurarse de que IIS mantiene su sitio en ejecución.

A partir de PowerShell Universal 3.3, puede obtener (a través del tiempo de actividad del sistema en la página de inicio de la consola de administración) un buen indicador de la última vez que se inició el servicio.

Antes de la versión 3.3, puede ver el tiempo de actividad del servidor visitando el panel de [Hangfire](/powershell-universal/es/desarrollo/hangfire.md) y haciendo clic en la pestaña Servidores.

## Autenticación

PowerShell Universal puede usar autenticación anónima y autenticación de Windows en IIS.

### Autenticación de Windows

Para habilitar la autenticación de Windows, primero deberá habilitarla para su servidor web y después para su sitio web. Puede encontrar los ajustes de autenticación en la sección Autenticación del Administrador de IIS.

Para el sitio web, establezca los mismos ajustes.

Una vez habilitada la autenticación en IIS, deberá asegurarse de que la autenticación de Windows esté habilitada para PowerShell Universal.

Primero, ajuste el fichero `web.config` para reenviar el token de autenticación de Windows.

```markup
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\Universal.Server.exe" arguments="" forwardWindowsAuthToken="true" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="OutOfProcess" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 588ACF2E-9AE5-4DF1-BC42-BCE16A4C4EDE-->
```

A continuación, habilite la autenticación de Windows en el fichero `appsettings.json` de PowerShell Universal.

```javascript
    "Authentication" : {
    "Windows": {
      "Enabled": "true"
    },
  }
```

Reinicie su grupo de aplicaciones y ahora debería poder iniciar sesión con credenciales de Windows.

{% hint style="warning" %}
Al habilitar la autenticación de Windows pero no la autenticación anónima, ya no podrá usar los AppTokens de PowerShell Universal. Deberá habilitar ambos métodos de autenticación para admitir tanto las credenciales de Windows como los tokens de aplicación.
{% endhint %}

### Autenticación anónima

La autenticación anónima se puede habilitar para permitir que los tokens de aplicación y otras solicitudes se transmitan a través del proxy de IIS. Deberá habilitar la autenticación anónima tanto en el nivel de servidor como en el de sitio web. No hay ninguna configuración adicional que hacer en PowerShell Universal.

## Configuraciones adicionales de web.config

Los ajustes dentro del web.config de Universal se pueden modificar según considere oportuno. A continuación encontrará una descripción de cada ajuste.

### ForwardWindowsAuthToken

Este ajuste se utiliza para la autenticación de Windows. Si desea utilizar la autenticación de Windows con IIS, asegúrese de desactivar la autenticación anónima y activar la autenticación de Windows en su sitio de IIS y, a continuación, establezca este ajuste en true.

### StdoutLogEnabled y StdoutLogFile

Este ajuste se utiliza para depurar problemas de inicio con su configuración de Universal. Se recomienda activarlo al configurar por primera vez la integración con IIS. Puede desactivarlo una vez que todo esté configurado. Debe asegurarse de que la identidad de su AppPool tenga acceso de escritura a la ubicación de StdOutLogFile.

### HostingModel

El modelo de hospedaje establece cómo se ejecutará el servidor Universal. Cuando se establece en InProcess, el servidor Universal se ejecutará desde dentro del agente de IIS. Esto ofrece un mejor rendimiento que utilizar el hospedaje OutOfProcess. El hospedaje InProcess no funciona con StdOutLogEnabled. Se recomienda utilizar el hospedaje OutOfProcess solo mientras se configura Universal y, InProcess cuando se hayan completado los pasos de configuración.

## Actualización

Al actualizar, asegúrese de no copiar (sobrescribir) ficheros sobre su instalación existente. En su lugar, (con la excepción de web.config y los ficheros \*.json) elimine todos los ficheros actuales de la aplicación y copie los nuevos en el directorio. **Copiar sobre los ficheros de la aplicación puede provocar que haya binarios en el directorio de instalación que no se esperan y puede causar problemas con PowerShell Universal.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.devolutions.net/powershell-universal/es/config/hosting/hosting-iis.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
