IIS

Informations sur l'hébergement de PowerShell Universal dans IIS.

Hébergement dans IIS

PowerShell Universal prend en charge l'hébergement dans IIS (Internet Information Services (IIS) pour Windows® Server). Veuillez noter qu'une série de prérequis et d'étapes de configuration spécifiques sont nécessaires pour exécuter PowerShell Universal sur IIS. Veuillez lire attentivement chaque section, car IIS requiert de nombreux paramètres de configuration spécifiques pour fonctionner avec les applications .NET Core modernes telles que PowerShell Universal.

Étape 1 : Préparation de l'hôte IIS

Les composants suivants sont requis pour héberger PowerShell Universal sur IIS.

Internet Information Services (IIS) Version 10.0
- Incluant : le protocole WebSocket
ASP.NET Core Hosting Bundle 10.0

Les fonctionnalités IIS de Windows Server suivantes doivent également être activées sur l'hôte IIS :

Nom d'affichage de la fonctionnalité

Exigence

Script d'installation

WebSocket Protocol

Requis pour exécuter PowerShell Universal

Install-WindowsFeature Web-WebSockets

Windows Authentication

Requis pour utiliser l'authentification Windows

Install-WindowsFeature Web-Windows-Auth

Commencez par activer la fonctionnalité IIS sur Windows Server, puis installez le bundle d'hébergement ASP.NET Core.

REMARQUE : IIS nécessite souvent un redémarrage de l'hôte après l'installation du bundle d'hébergement .NET Core ! Il est fortement recommandé de REDÉMARRER l'hôte IIS après l'installation du bundle d'hébergement .NET Core.

Une fois ces prérequis satisfaits, vous êtes prêt à commencer la configuration de PowerShell Universal sur IIS.

L'activation de la fonctionnalité IIS WebDav Publishing peut causer des problèmes avec Universal. WebDav Publishing filtre les requêtes HTTP et bloque par défaut les verbes PUT et DELETE. Si vous avez activé WebDav Publishing, assurez-vous de l'avoir configuré correctement pour autoriser ces verbes.

Étape 2 : Téléchargement de PowerShell Universal

Téléchargez la dernière version de PowerShell Universal. Vous devrez télécharger la version ZIP archive de PowerShell Universal. Cette archive est spécifiquement conçue pour ceux qui souhaitent configurer PowerShell Universal pour IIS ou d'autres serveurs web tiers. Extrayez le contenu du fichier Zip dans le dossier d'hébergement web souhaité sur votre hôte IIS.

Vous devez vous assurer que les fichiers de l'application PowerShell Universal sont débloqués après leur extraction. Vous pouvez les débloquer avec le cmdlet Unblock-File.

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

Cet emplacement est très important et sera référencé tout au long de ce document. Plus important encore, cet emplacement doit être accessible par l'identité utilisée par le pool d'applications IIS.

Étape 3 : Configuration du pool d'applications IIS

Maintenant que notre hôte est prêt et que nous avons téléchargé PowerShell Universal, nous pouvons commencer la configuration d'IIS.

La première étape du processus de configuration IIS consiste à créer un nouveau pool d'applications dans IIS. Avant de commencer la configuration, nous devons sélectionner une identité valide pour le pool d'applications IIS.

3.1 : Choix de l'identité du pool d'applications

L'identité du pool d'applications est cruciale pour PowerShell Universal, car il s'agira de l'« utilisateur par défaut » sous lequel les tâches et les applications (anciennement appelées tableaux de bord) s'exécuteront. Ce sera également l'utilisateur qui effectuera les opérations de lecture/écriture sur la base de données Universal Automation et qui sera utilisé par IIS pour lire le répertoire de contenu web et exécuter l'application.

Il est conseillé d'utiliser "LocalSystem" ou un compte de service de votre choix.

En raison des limitations d'IIS, les paramètres d'identité du pool d'applications ont des conséquences MAJEURES sur le comportement des options "Exécuter en tant que" lors de l'utilisation d'Universal Automation.

Limitations d'IIS avec Universal Automation

Service d'application configuré en tant que Local System — Les scripts s'exécutent par défaut sous le compte Système et un compte Exécuter en tant que PEUT être spécifié lors de l'exécution d'un script dans Universal Automation
Service d'application configuré en tant que compte de service — Les scripts peuvent UNIQUEMENT être exécutés avec le compte de service et un **compte Exécuter en tant que _**_NE PEUT PAS** être spécifié lors de l'exécution de scripts.

Exigences relatives à l'identité du compte de service

Accès complet en lecture/écriture au dossier de l'application PowerShell Universal que nous avons extrait à l'étape 2
Accès complet en lecture/écriture à la base de données PowerShell Universal : Par défaut : C:\ProgramData\Universal Automation
Droits d'ouverture de session en tant que tâche (par exemple, via secpol.msc > Stratégies locales > Attribution des droits utilisateur)

L'emplacement par défaut de la base de données peut être personnalisé via le fichier appsettings.json de PowerShell Universal si vous le souhaitez.

Une fois que nous avons sélectionné une identité valide, nous sommes prêts à créer le pool d'applications dans IIS.

3.2 : Création du nouveau pool d'applications IIS

Maintenant que nous avons choisi une identité de pool d'applications disposant d'un accès en lecture/écriture aux dossiers de l'application et de la base de données PowerShell Universal, nous pouvons créer le pool d'applications dans IIS.

Dans le Gestionnaire IIS, choisissez l'option Ajouter un pool d'applications...
- Nom : Utilisez le nom de votre choix pour le pool d'applications
- Version du CLR .NET : Aucun code managé
- Cliquez sur OK pour créer le pool d'applications.

3.3 : Configuration des « paramètres avancés » du pool d'applications IIS

Maintenant que le pool d'applications a été créé, nous devons configurer les Paramètres avancés.

Ouvrez les "Paramètres avancés" du pool d'applications et appliquez les configurations suivantes :
- Général / Activer les applications 32 bits : Faux
- Modèle de processus / Identité : Utilisez l'identité que nous avons sélectionnée pour notre pool d'applications dans la section « Choix de l'identité du pool d'applications » ci-dessus.
- Modèle de processus / Charger le profil utilisateur : Vrai

Une fois les paramètres avancés appliqués, notre pool d'applications est prêt. L'étape suivante consiste à configurer le site web IIS qui utilisera ce pool d'applications.

Étape 4 : Configuration du site web IIS

4.1 : Préparation du fichier web.config pour notre site web

Maintenant que nous disposons d'un pool d'applications valide, nous devons créer un site web IIS pour exposer l'application. Avant de procéder, nous souhaitons examiner le fichier web.config de PowerShell Universal pour notre site web. Dans le dossier de l'application PowerShell Universal extrait, nous trouverons un fichier web.config. Ce fichier de configuration a été spécifiquement conçu pour IIS et contient un certain nombre de configurations à examiner avant de créer le site web IIS.

Le plus important est de mettre à jour la valeur de l'argument "processPath" de ce fichier de configuration. Cette valeur fournit à IIS le chemin exact du binaire de l'application afin qu'il puisse démarrer correctement l'application.

Ouvrez le fichier web.config dans le dossier de l'application PowerShell Universal
- Localisez la section <aspNetCore processPath du fichier de configuration
- Remplacez l'argument processPath ".\Universal.Server.exe" par l'emplacement exact du chemin Universal.Server.exe (voir la figure ci-dessous pour un exemple)
- Enregistrez le fichier pour appliquer la configuration

<?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>

Ce fichier contient diverses configurations supplémentaires. Nous les examinerons plus en détail dans la section « Configuration avancée », mais vous pouvez consulter les « Configurations supplémentaires de web.config » sur cette page pour plus de détails.

4.2 : Création du site web IIS

Maintenant qu'un pool d'applications a été créé pour PowerShell Universal avec une identité valide et que nous avons configuré le fichier web.config, nous sommes enfin prêts à créer le site web IIS. Le composant Site web d'IIS charge les artefacts de l'application et expose l'application sur le point de terminaison web configuré.

Dans le Gestionnaire IIS : cliquez sur « Ajouter un site web... »
Configurez les options du nouveau site web :
- Nom du site : Utilisez le nom de votre choix, par exemple : PowerShell Universal.
- Pool d'applications : N'utilisez PAS le DefaultAppPool — Sélectionnez le pool d'applications que nous avons créé à l'étape précédente.
- Chemin d'accès physique : Il doit s'agir du chemin physique vers le contenu PowerShell Universal que nous avons extrait de notre fichier .zip téléchargé. REMARQUE : L'identité du pool d'applications doit avoir accès à cet emplacement.
- Paramètres de liaison : Pour la configuration initiale, il est conseillé d'utiliser les valeurs par défaut de base ; nous les mettrons à jour ultérieurement dans notre configuration avancée.
  - Type http — Pour la configuration initiale
  - Adresse IP : Toutes non assignées
  - Port : 80
  - Nom d'hôte : Nom de l'hôte

Étape 5 : Démarrage du site web

À ce stade, toutes les configurations requises devraient être en place et le site web IIS hébergeant PowerShell Universal devrait être opérationnel. À l'aide d'un navigateur web, accédez à l'emplacement du site web configuré pour valider que PowerShell Universal a démarré. À partir de là, vous pouvez suivre le guide « Prise en main » pour valider les fonctionnalités de base. Une fois que vous êtes certain que l'application fonctionne correctement avec une configuration IIS de base, vous pouvez passer à la « Configuration avancée » pour sécuriser et finaliser votre configuration IIS souhaitée.

Si vous rencontrez toujours des problèmes avec la configuration IIS de base, essayez de vérifier le chemin « Journaux » spécifié dans le fichier web.config pour les problèmes courants. Si vous rencontrez toujours des problèmes, contactez les forums ou le support pour obtenir de l'aide.

Applications IIS imbriquées

Il est possible d'imbriquer plusieurs instances de PowerShell Universal sous un seul pool d'applications et site web, mais cela nécessite une configuration supplémentaire.

Vous devrez disposer de deux dossiers pour vos fichiers d'application : un pour chaque application. Vous devrez également configurer deux dossiers de données : un pour chaque application.

Une fois votre structure de dossiers configurée, vous devrez créer deux fichiers appsettings.json et mettre à jour vos fichiers web.config pour chaque application.

Dans les fichiers appsettings.json, vous devrez définir les chemins corrects vers les fichiers de données pour chaque instance. Vous devrez également configurer la bonne URL de base pour le site imbriqué.

{
  "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",
  }
}

Ensuite, vous devrez mettre à jour les fichiers web.config pour chaque site afin d'utiliser le fichier appsettings.json approprié et l'hébergement OutOfProcess.

<?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-->

Maintenant, dans le Gestionnaire IIS, faites un clic droit sur les dossiers psu1 et psu2 pour les convertir en applications.

Vous devriez maintenant pouvoir accéder à la console d'administration de PowerShell Universal aux deux URL suivantes.

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

Configuration pour les tâches

Des paramètres de pool d'applications mal configurés peuvent entraîner l'échec de l'exécution des tâches. La cause principale est le recyclage du pool d'applications ou l'échec du démarrage de l'application web au démarrage du serveur. Cela ne pose pas de problème pour les fonctionnalités telles que les API ou les applications (anciennement appelées tableaux de bord), mais en raison du traitement en arrière-plan des tâches, vous devez vous assurer que le serveur démarre le site web et le maintient en fonctionnement. Vous pouvez en savoir plus ici.

Si vous prévoyez d'exécuter des tâches planifiées dans votre instance de PowerShell Universal hébergée dans IIS, vous devez vous assurer de configurer IIS de manière appropriée. Plusieurs paramètres sont à valider lors de la configuration de votre pool d'applications.

Initialisation de l'application

Installez la fonctionnalité d'initialisation des applications du rôle Serveur web.

Paramètres du pool d'applications

Vous devez configurer les paramètres suivants :

Général : Version du CLR .NET = Aucun code managé.
Général : Mode de démarrage = AlwaysRunning
Modèle de processus : Paramètre de délai d'inactivité = 0 (désactivé)
Recyclage : Intervalle de temps régulier = 0.

Paramètres du site web

Dans le site IIS qui héberge Universal, vous devez vous assurer que le préchargement est activé.

Variables d'environnement

Bien que nous tentions de détecter que PSU s'exécute dans IIS, vous pourriez rencontrer des problèmes avec le gestionnaire d'authentification negotiate activé alors qu'il n'est pas pris en charge dans IIS. Pour vous assurer que ce n'est pas un problème, vous pouvez le désactiver complètement en créant la variable d'environnement ci-dessous sur votre machine IIS.

$Env:PSU_DISABLE_WIN_AUTH = true

Débogage des problèmes avec IIS et les tâches

Si vous rencontrez toujours des problèmes avec IIS et les tâches, vous devriez envisager d'activer la journalisation des recyclages IIS pour vous assurer qu'IIS maintient votre site en fonctionnement.

À partir de PowerShell Universal 3.3, vous pouvez (via la durée de fonctionnement du système sur la page d'accueil de la console d'administration) obtenir un bon indicateur de la dernière fois que le service a été démarré.

Avant la version 3.3, vous pouvez afficher la durée de fonctionnement du serveur en visitant le tableau de bord Hangfire et en cliquant sur l'onglet Serveurs.

Authentification

PowerShell Universal peut utiliser l'authentification anonyme et l'authentification Windows dans IIS.

Authentification Windows

Pour activer l'authentification Windows, vous devez d'abord l'activer pour votre serveur web, puis pour votre site web. Vous pouvez trouver les paramètres d'authentification dans la section Authentification du Gestionnaire IIS.

Pour le site web, appliquez les mêmes paramètres.

Une fois l'authentification activée dans IIS, vous devez vous assurer que l'authentification Windows est activée pour PowerShell Universal.

Tout d'abord, modifiez le fichier web.config pour transférer le jeton d'authentification Windows.

<?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-->

Ensuite, activez l'authentification Windows dans le fichier appsettings.json pour PowerShell Universal.

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

Redémarrez votre pool d'applications et vous devriez maintenant pouvoir vous connecter avec des identifiants Windows.

Lorsque vous activez l'authentification Windows sans activer l'authentification anonyme, vous ne pourrez plus utiliser les jetons d'application PowerShell Universal. Vous devrez activer les deux méthodes d'authentification pour prendre en charge à la fois les identifiants Windows et les jetons d'application.

Authentification anonyme

L'authentification anonyme peut être activée pour permettre aux jetons d'application et aux autres requêtes d'être transmis via le proxy IIS. Vous devrez activer l'authentification anonyme au niveau du serveur et du site web. Aucune configuration supplémentaire n'est requise dans PowerShell Universal.

Configurations supplémentaires de web.config

Les paramètres du fichier web.config Universal peuvent être ajustés selon vos besoins. Vous trouverez ci-dessous une description de chaque paramètre.

ForwardWindowsAuthToken

Ce paramètre est utilisé pour l'authentification Windows. Si vous souhaitez utiliser l'authentification Windows avec IIS, assurez-vous de désactiver l'authentification anonyme et d'activer l'authentification Windows dans votre site IIS, puis définissez ce paramètre sur true.

StdoutLogEnabled et StdoutLogFile

Ce paramètre est utilisé pour déboguer les problèmes de démarrage de votre configuration Universal. Il est recommandé de l'activer lors de la première configuration de l'intégration IIS. Vous pouvez le désactiver une fois que tout est configuré. Vous devez vous assurer que l'identité de votre pool d'applications dispose d'un accès en écriture à l'emplacement du fichier StdOutLogFile.

HostingModel

Le modèle d'hébergement définit la façon dont le serveur Universal s'exécutera. Lorsqu'il est défini sur InProcess, le serveur Universal s'exécutera au sein de l'agent IIS. Cela offre de meilleures performances que l'hébergement OutOfProcess. L'hébergement InProcess ne fonctionne pas avec StdOutLogEnabled. Il est recommandé d'utiliser l'hébergement OutOfProcess uniquement lors de la configuration d'Universal et InProcess une fois vos étapes de configuration terminées.

Mise à niveau

Lors de la mise à niveau, assurez-vous de ne pas copier (écraser) les fichiers par-dessus votre installation existante. Au lieu de cela (à l'exception des fichiers web.config et *.json), supprimez tous les fichiers d'application actuels et copiez les nouveaux dans le répertoire. Copier les fichiers d'application par-dessus les existants peut entraîner la présence de binaires dans le répertoire d'installation qui ne sont pas attendus et peut causer des problèmes avec PowerShell Universal.

PrécédentHaute disponibilité SuivantProxy inverse

Mis à jour il y a 1 mois

Ce contenu vous a-t-il été utile ?