IIS

Hosting in IIS

PowerShell Universal unterstützt das Hosting in IIS (Internet Information Services (IIS) für Windows® Server). Bitte beachten Sie, dass eine Reihe von Host-Voraussetzungen und spezifischen Konfigurationsschritten erforderlich sind, um die Ausführung von PowerShell Universal in IIS zu ermöglichen. Bitte lesen Sie jeden Abschnitt sorgfältig durch, da IIS viele spezifische Konfigurationseinstellungen erfordert, um mit modernen .NET Core-Anwendungen wie PowerShell Universal zu funktionieren.

Schritt 1: Vorbereiten des IIS-Hosts

Die folgenden Komponenten sind erforderlich, um PowerShell Universal in IIS zu hosten.

Internet Information Services (IIS) Version 10.0
- Einschließlich: WebSocket-Protokoll
ASP.NET Core Hosting Bundle 10.0

Die folgenden Windows Server IIS-Funktionen müssen ebenfalls auf dem IIS-Host aktiviert werden:

Anzeigename der Funktion

Anforderung

Installationsskript

WebSocket-Protokoll

Erforderlich für die Ausführung von PowerShell Universal

Install-WindowsFeature Web-WebSockets

Windows-Authentifizierung

Erforderlich für die Verwendung der Windows-Authentifizierung

Install-WindowsFeature Web-Windows-Auth

Stellen Sie zunächst sicher, dass die IIS-Funktion auf Windows Server aktiviert ist, und installieren Sie dann das ASP.NET Core Hosting Bundle.

HINWEIS: IIS erfordert nach der Installation des .NET Core Hosting Bundles häufig einen Neustart des Hosts! Es wird dringend empfohlen, den IIS-Host nach der Installation des .NET Core Hosting Bundles NEU ZU STARTEN.

Sobald diese Voraussetzungen erfüllt sind, können Sie mit der Konfiguration von PowerShell Universal in IIS beginnen.

Das Aktivieren der IIS-Funktion WebDav-Veröffentlichung führt zu Problemen mit Universal. Die WebDav-Veröffentlichung filtert HTTP-Anfragen und verhindert standardmäßig die Verben PUT und DELETE. Wenn Sie die WebDav-Veröffentlichung aktiviert haben, stellen Sie sicher, dass sie ordnungsgemäß konfiguriert ist, um diese Verben zuzulassen.

Schritt 2: PowerShell Universal herunterladen

Laden Sie die neueste Version von PowerShell Universal herunter. Sie müssen die ZIP-Archivversion von PowerShell Universal herunterladen. Dieses Archiv wurde speziell für diejenigen erstellt, die PowerShell Universal für IIS oder andere Webserver von Drittanbietern konfigurieren möchten. Extrahieren Sie den Inhalt der ZIP-Datei in den vorgesehenen Webhost-Ordner auf Ihrem IIS-Host.

Sie müssen sicherstellen, dass die Anwendungsdateien von PowerShell Universal nach dem Extrahieren freigegeben (unblocked) werden. Sie können sie mit dem Cmdlet Unblock-File freigeben.

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

Dieser Speicherort ist sehr wichtig und wird in diesem Dokument durchgängig referenziert. Am wichtigsten ist, dass dieser Speicherort für die Identität, die vom IIS-Anwendungspool verwendet wird, zugänglich sein muss.

Schritt 3: Konfiguration des IIS-Anwendungspools

Nachdem unser Host bereit ist und wir PowerShell Universal heruntergeladen haben, können wir mit der Konfiguration von IIS beginnen.

Der erste Schritt im IIS-Konfigurationsprozess besteht darin, einen neuen Anwendungspool in IIS zu erstellen. Bevor wir mit der Konfiguration beginnen, sollten wir sicherstellen, dass wir eine gültige Identität für den IIS-Anwendungspool auswählen.

3.1: Auswahl einer Anwendungspool-Identität

Die Anwendungspool-Identität ist für PowerShell Universal von entscheidender Bedeutung, da dies der "Standardbenutzer" ist, unter dem Jobs und Apps (früher als Dashboards bezeichnet) ausgeführt werden. Es ist außerdem der Benutzer, der Lese-/Schreibvorgänge in der Universal Automation-Datenbank durchführt und von IIS verwendet wird, um das Webinhaltsverzeichnis zu lesen und die Anwendung auszuführen.

Es wird empfohlen, "LocalSystem" oder ein Dienstkonto Ihrer Wahl zu verwenden.

Aufgrund von Einschränkungen in IIS haben die Einstellungen der Anwendungspool-Identität GROSSE Auswirkungen auf das Verhalten der "Ausführen als"-Optionen bei der Verwendung von Universal Automation.

IIS-Einschränkungen mit Universal Automation

App-Dienst als Local System konfiguriert - Skripte werden standardmäßig als Systemkonto ausgeführt und ein Ausführen-als-Konto KANN bei der Ausführung eines Skripts in Universal Automation angegeben werden
App-Dienst als Dienstkonto konfiguriert - Skripte können NUR mit dem Dienstkonto ausgeführt werden und ein **Ausführen-als-Konto _**_KANN NICHT** bei der Ausführung von Skripten angegeben werden.

Anforderungen an die Dienstkonto-Identität

Vollständiger Lese-/Schreibzugriff auf den PowerShell Universal-Anwendungsordner, den wir in Schritt 2 extrahiert haben
Vollständiger Lese-/Schreibzugriff auf die PowerShell Universal-Datenbank: Standard: C:\ProgramData\Universal Automation
Rechte für Anmelden als Batchauftrag (z. B. über secpol.msc > Lokale Richtlinien > Zuweisen von Benutzerrechten

Der Standard-Datenbankspeicherort kann bei Bedarf über die PowerShell Universal-Datei appsettings.json angepasst werden.

Sobald wir eine gültige Identität ausgewählt haben, können wir den Anwendungspool in IIS erstellen.

3.2: Erstellen des neuen IIS-Anwendungspools

Nachdem wir nun eine Anwendungspool-Identität gewählt haben, die Lese-/Schreibzugriff auf die Anwendungs- und Datenbankordner von PowerShell Universal hat, können wir den Anwendungspool in IIS erstellen.

Wählen Sie im IIS-Manager die Option Anwendungspool hinzufügen...
- Name: Verwenden Sie einen beliebigen Namen für den Anwendungspool
- .NET CLR-Version: Kein verwalteter Code
- Klicken Sie auf OK, um den Anwendungspool zu erstellen.

3.3: Konfigurieren der "Erweiterten Einstellungen" des IIS-Anwendungspools

Nachdem der Anwendungspool erstellt wurde, müssen wir die Erweiterten Einstellungen konfigurieren

Öffnen Sie die "Erweiterten Einstellungen" für den Anwendungspool und wenden Sie die folgenden Konfigurationen an:
- Allgemein / 32-Bit-Anwendungen aktivieren: False
- Prozessmodell / Identität: Verwenden Sie die Identität, die wir für unseren Anwendungspool im obigen Abschnitt "Auswahl einer Anwendungspool-Identität" ausgewählt haben.
- Prozessmodell / Benutzerprofil laden: True

Sobald die erweiterten Einstellungen angewendet wurden, ist unser Anwendungspool bereit. Unser nächster Schritt besteht darin, die IIS-Website zu konfigurieren, die diesen Anwendungspool verwendet.

Schritt 4: Konfiguration der IIS-Website

4.1: Vorbereiten der web.config für unsere Website

Nachdem wir einen gültigen Anwendungspool haben, müssen wir eine IIS-Website erstellen, um die Anwendung bereitzustellen. Bevor wir dies tun, sollten wir die PowerShell Universal-Datei web.config für unsere Website überprüfen. Im extrahierten PowerShell Universal-Anwendungsordner finden wir eine web.config-Datei. Diese Konfigurationsdatei wurde speziell für IIS entwickelt und enthält eine Reihe von Konfigurationen, die wir vor dem Erstellen der IIS-Website überprüfen müssen.

Am wichtigsten ist, dass wir den Wert des Arguments "processPath" dieser Konfigurationsdatei aktualisieren müssen. Dieser Wert stellt IIS den exakten Pfad der Anwendungsbinärdatei bereit, damit die Anwendung ordnungsgemäß gestartet werden kann.

Öffnen Sie die Datei web.config im PowerShell Universal-Anwendungsordner
- Suchen Sie den Abschnitt <aspNetCore processPath der Konfigurationsdatei
- Ändern Sie das processPath-Argument von ".\Universal.Server.exe" auf den exakten Pfad von Universal.Server.exe (siehe Abbildung unten als Beispiel)
- Speichern Sie die Datei, um die Konfiguration anzuwenden

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

In dieser Datei gibt es eine Vielzahl zusätzlicher Konfigurationen. Wir werden diese im Abschnitt "Erweiterte Konfiguration" ausführlicher behandeln, aber weitere Details finden Sie unter "Zusätzliche web.config-Konfigurationen" auf dieser Seite

4.2: Erstellen der IIS-Website für IIS

Nachdem nun ein Anwendungspool für PowerShell Universal mit einer gültigen Identität erstellt und die Datei web.config konfiguriert wurde, sind wir endlich bereit, die IIS-Website zu erstellen. Die Website-Komponente von IIS lädt die Anwendungsartefakte und stellt die Anwendung am konfigurierten Web-Endpunkt bereit.

Klicken Sie im IIS-Manager auf "Website hinzufügen.."
Konfigurieren Sie die neuen Website-Optionen:
- Sitename: Verwenden Sie einen beliebigen Namen, z. B.: PowerShell Universal.
- Anwendungspool: Verwenden Sie NICHT den DefaultAppPool - Wählen Sie den Anwendungspool aus, den wir im vorherigen Schritt erstellt haben.
- Physischer Pfad: Dies muss der physische Pfad zum PowerShell Universal-Inhalt sein, den wir aus unserer heruntergeladenen .zip-Datei extrahiert haben. HINWEIS: Die AppPool-Identität muss Zugriff auf diesen Speicherort haben.
- Bindungseinstellungen: Beachten Sie, dass für die Erstkonfiguration die Verwendung der Basisstandardwerte empfohlen wird. Wir werden diese später in unserer erweiterten Konfiguration aktualisieren
  - Typ http - Für die Erstkonfiguration
  - IP-Adresse: Alle nicht zugewiesenen
  - Port: 80
  - Hostname: Name des Hosts

Schritt 5: Website starten

An diesem Punkt sollten alle erforderlichen Konfigurationen vorhanden sein und die IIS-Website, die PowerShell Universal hostet, sollte betriebsbereit sein. Navigieren Sie mit einem Webbrowser zum konfigurierten Website-Speicherort, um zu überprüfen, ob PowerShell Universal gestartet wurde. Von hier aus können Sie der Anleitung "Erste Schritte" folgen, um die Basisfunktionalität zu überprüfen. Sobald Sie sicher sind, dass die Anwendung mit einer einfachen IIS-Konfiguration ordnungsgemäß funktioniert, können Sie zur "Erweiterten Konfiguration" übergehen, um Ihre gewünschte IIS-Konfiguration zu sichern und abzuschließen.

Wenn Sie weiterhin Probleme mit der einfachen IIS-Konfiguration haben, überprüfen Sie den in der web.config angegebenen "Logs"-Pfad auf häufige Probleme. Wenn die Probleme weiterhin bestehen, wenden Sie sich für Unterstützung an die Foren oder den Support.

Verschachtelte IIS-Anwendungen

Es ist möglich, mehrere PowerShell Universal-Instanzen unter einem einzigen Anwendungspool und einer einzigen Website zu verschachteln, dies erfordert jedoch einige zusätzliche Konfigurationen.

Sie benötigen zwei Ordner für Ihre Anwendungsdateien: einen für jede Anwendung. Außerdem müssen Sie zwei Datenordner einrichten: einen für jede Anwendung.

Sobald Ihre Ordnerstruktur konfiguriert ist, müssen Sie zwei appsettings.json-Dateien erstellen und Ihre web.config-Dateien für jede Anwendung aktualisieren.

In den appsettings.json-Dateien müssen Sie die richtigen Pfade zu den Datendateien für jede Instanz festlegen. Außerdem müssen Sie die richtige Basis-URL für die verschachtelte Website konfigurieren.

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

Als Nächstes müssen Sie die web.config-Dateien für jede Website aktualisieren, damit sie die richtige appsettings.json-Datei und OutOfProcess-Hosting verwenden.

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

Klicken Sie nun im IIS-Manager mit der rechten Maustaste auf die Ordner psu1 und psu2, um sie in Anwendungen zu konvertieren.

Sie sollten nun über beide der folgenden URLs auf die PowerShell Universal-Administrationskonsole zugreifen können.

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

Konfiguration für Jobs

Falsch konfigurierte Anwendungspool-Einstellungen können dazu führen, dass Jobs nicht ausgeführt werden. Die Hauptursache ist das Recycling des Anwendungspools oder ein Fehler beim Starten der Web-App beim Starten des Servers. Dies ist kein Problem für Funktionen wie APIs oder Apps (früher als Dashboards bezeichnet), aber aufgrund der Hintergrundverarbeitung von Jobs müssen Sie sicherstellen, dass der Server die Website startet und ausgeführt hält. Sie können hier mehr erfahren.

Wenn Sie geplante Jobs in Ihrer in IIS gehosteten PowerShell Universal-Instanz ausführen möchten, müssen Sie sicherstellen, dass IIS entsprechend konfiguriert ist. Bei der Konfiguration Ihres Anwendungspools sind mehrere Einstellungen zu überprüfen.

Anwendungsinitialisierung

Installieren Sie die Funktion Anwendungsinitialisierung der Webserver-Rolle.

Anwendungspool-Einstellungen

Sie sollten die folgenden Einstellungen konfigurieren:

Allgemein: .NET CLR-Version = Kein verwalteter Code.
Allgemein: Startmodus = AlwaysRunning
Prozessmodell: Einstellung Leerlaufzeitüberschreitung = 0 (deaktiviert)
Recycling: Regelmäßiges Zeitintervall = 0.

Website-Einstellungen

Innerhalb der IIS-Website, die Universal hostet, müssen Sie sicherstellen, dass Preload aktiviert ist.

Umgebungsvariablen

Obwohl wir versuchen zu erkennen, dass PSU innerhalb von IIS ausgeführt wird, können Probleme auftreten, wenn der Negotiate-Authentifizierungshandler aktiviert ist, obwohl er in IIS nicht unterstützt wird. Um sicherzustellen, dass dies kein Problem darstellt, können Sie ihn vollständig deaktivieren, indem Sie die folgende Umgebungsvariable auf Ihrem IIS-Computer erstellen.

$Env:PSU_DISABLE_WIN_AUTH = true

Debuggen von Problemen mit IIS und Jobs

Wenn Sie weiterhin Probleme mit IIS und Jobs haben, sollten Sie erwägen, die IIS-Recycling-Protokollierung zu aktivieren, um sicherzustellen, dass IIS Ihre Website ausgeführt hält.

Ab PowerShell Universal 3.3 erhalten Sie (über die Betriebszeit des Systems auf der Startseite der Administrationskonsole) einen guten Hinweis darauf, wann der Dienst zuletzt gestartet wurde.

Vor Version 3.3 können Sie die Server-Betriebszeit anzeigen, indem Sie das Hangfire-Dashboard aufrufen und auf die Registerkarte Servers klicken.

Authentifizierung

PowerShell Universal kann in IIS anonyme Authentifizierung und Windows-Authentifizierung verwenden.

Windows-Authentifizierung

Um die Windows-Authentifizierung zu aktivieren, müssen Sie sie zunächst für Ihren Webserver und dann für Ihre Website aktivieren. Sie finden die Authentifizierungseinstellungen im Abschnitt Authentifizierung im IIS-Manager.

Legen Sie für die Website dieselben Einstellungen fest.

Sobald die Authentifizierung in IIS aktiviert ist, müssen Sie sicherstellen, dass die Windows-Authentifizierung für PowerShell Universal aktiviert ist.

Passen Sie zunächst die Datei web.config an, um das Windows-Authentifizierungstoken weiterzuleiten.

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

Aktivieren Sie anschließend die Windows-Authentifizierung in der Datei appsettings.json für PowerShell Universal.

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

Starten Sie Ihren Anwendungspool neu, und Sie sollten sich nun mit Windows-Anmeldeinformationen anmelden können.

Wenn Sie die Windows-Authentifizierung, aber nicht die anonyme Authentifizierung aktivieren, können Sie PowerShell Universal AppTokens nicht mehr verwenden. Sie müssen beide Authentifizierungsmethoden aktivieren, um sowohl Windows-Anmeldeinformationen als auch App-Tokens zu unterstützen.

Anonyme Authentifizierung

Die anonyme Authentifizierung kann aktiviert werden, damit App-Tokens und andere Anfragen über den IIS-Proxy übertragen werden können. Sie müssen die anonyme Authentifizierung sowohl auf Server- als auch auf Website-Ebene aktivieren. Innerhalb von PowerShell Universal ist keine zusätzliche Konfiguration erforderlich.

Zusätzliche web.config-Konfigurationen

Die Einstellungen innerhalb der Universal web.config können nach Belieben angepasst werden. Nachfolgend finden Sie eine Beschreibung jeder Einstellung.

ForwardWindowsAuthToken

Diese Einstellung wird für die Windows-Authentifizierung verwendet. Wenn Sie die Windows-Authentifizierung mit IIS verwenden möchten, stellen Sie sicher, dass Sie die anonyme Authentifizierung deaktivieren und die Windows-Authentifizierung innerhalb Ihrer IIS-Site aktivieren, und setzen Sie diese Einstellung dann auf true.

StdoutLogEnabled und StdoutLogFile

Diese Einstellung wird zum Debuggen von Startproblemen bei Ihrem Universal-Setup verwendet. Es wird empfohlen, dies bei der ersten Konfiguration der IIS-Integration zu aktivieren. Sie können es deaktivieren, sobald alles konfiguriert ist. Sie müssen sicherstellen, dass Ihre AppPool-Identität Schreibzugriff auf den Speicherort der StdOutLogFile hat.

HostingModel

Das Hosting-Modell legt fest, wie der Universal-Server ausgeführt wird. Bei der Einstellung InProcess wird der Universal-Server innerhalb des IIS-Agenten ausgeführt. Dies bietet eine bessere Leistung als das OutOfProcess-Hosting. InProcess-Hosting funktioniert nicht mit StdOutLogEnabled. Es wird empfohlen, OutOfProcess-Hosting nur während der Konfiguration von Universal zu verwenden und InProcess, wenn Ihre Konfigurationsschritte abgeschlossen sind.

Aktualisieren

Stellen Sie beim Aktualisieren sicher, dass Sie Dateien nicht über Ihre bestehende Installation kopieren (überschreiben). Löschen Sie stattdessen (mit Ausnahme von web.config und *.json-Dateien) alle aktuellen Anwendungsdateien und kopieren Sie die neuen in das Verzeichnis. Das Überschreiben der Anwendungsdateien kann dazu führen, dass sich unerwartete Binärdateien im Installationsverzeichnis befinden, was Probleme mit PowerShell Universal verursachen kann.

VorherigeHochverfügbarkeit

NächsteReverse-Proxy

Zuletzt aktualisiert vor 12 Tagen

War das hilfreich?