Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden Sie Sitzungsskripte, um das Streaming-Erlebnis Ihrer AppStream 2.0-Benutzer zu verwalten

AppStream 2.0 stellt Sitzungsskripts auf der Instance bereit. Sie können diese Skripte verwenden, um benutzerdefinierte Skripte auszuführen, wenn in den Streaming-Sitzungen der Benutzer bestimmte Ereignisse auftreten. Sie können beispielsweise benutzerdefinierte Skripte verwenden, um Ihre AppStream 2.0-Umgebung vorzubereiten, bevor die Streaming-Sitzungen Ihrer Benutzer beginnen. Sie können benutzerdefinierte Skripte auch einsetzen, um Streaming-Instances zu bereinigen, nachdem die Benutzer ihre Streaming-Sitzungen beendet haben.

Sitzungsskripts werden in einem AppStream 2.0-Image angegeben. Diese Skripte werden im Benutzer- oder Systemkontext ausgeführt. Wenn die Sitzungsskripts den Standardausgang verwenden, um Informationen, Fehler- oder Debugging-Meldungen zu schreiben, können diese optional in einem Amazon-S3-Bucket im Amazon-Web-Services-Konto gespeichert werden.

Ausführen von Skripten vor dem Beginn von Streaming-Sitzungen

Sie können die Skripte so konfigurieren, dass sie maximal 60 Sekunden vor dem Start der Anwendungen der Benutzer und dem Beginn der Streaming-Sitzungen ausgeführt werden. Auf diese Weise können Sie die AppStream 2.0-Umgebung anpassen, bevor Benutzer mit dem Streamen ihrer Anwendungen beginnen. Wenn die Sitzungsskripte ausgeführt werden, wird den Benutzern ein Ladekreisel anzeigt. Nach erfolgreicher Ausführung der Skripte oder nach Ablauf der maximalen Wartezeit beginnen die Streaming-Sitzungen der Benutzer. Können die Skripts nicht abgeschlossen werden, wird den Benutzern eine Fehlermeldung angezeigt. Die Benutzer werden jedoch nicht daran gehindert, ihre Streaming-Sitzung zu nutzen.

Bei der Angabe eines Dateinamens auf einer Windows Instance müssen Sie einen doppelten umgekehrten Schrägstrich verwenden. Beispielsweise:

C:\\Scripts\\Myscript.bat

Wenn Sie keinen doppelten umgekehrten Schrägstrich verwenden, werden Sie in einer Fehlermeldung darauf hingewiesen, dass die JSON-Datei falsch formatiert ist.

Wenn Sie Skripts ausführen, bevor Streaming-Sitzungen beginnen und das Framework für dynamische AppStream 2.0-Anwendungen nicht aktiviert ist, erfolgt der folgende Prozess:

Informationen zum Framework für dynamische AppStream 2.0-Anwendungen finden Sie unter Verwenden des AppStream 2.0 Dynamic Application Framework zum Erstellen eines Anbieters für dynamische Apps.

Wenn Sie Skripts ausführen, bevor Streaming-Sitzungen beginnen und das Framework für dynamische AppStream 2.0-Anwendungen aktiviert ist, erfolgt der folgende Prozess:

Ausführen von Skripten nach dem Ende von Streaming-Sitzungen

Sie können Skripte auch so konfigurieren, dass sie nach Beendigung der Streaming-Sitzungen von Benutzern ausgeführt werden. Sie können beispielsweise ein Skript ausführen, wenn Benutzer Sitzung beenden aus der Symbolleiste AppStream 2.0 auswählen oder wenn sie die maximal zulässige Dauer für die Sitzung erreichen. Sie können diese Sitzungsskripts auch verwenden, um Ihre AppStream 2.0-Umgebung zu bereinigen, bevor eine Streaming-Instance beendet wird. Sie können beispielsweise Skripte einsetzen, um Dateisperren aufzuheben oder Protokolldateien hochzuladen. Wenn Sie nach Beendigung von Streaming-Sitzungen Skripte ausführen lassen, geschieht Folgendes:

Erstellen und Angeben von Sitzungsskripten

Sie können Sitzungsskripts für Always-On-, On-Demand- und Elastic-Flotten konfigurieren und angeben.

Sitzungsskript-Konfigurationsdatei

Navigieren Sie zu C:\AppStream\SessionScripts\config.json, um die Konfigurationsdatei der Sitzungsskripts in einer Windows-Instance zu finden. Navigieren Sie auf einer Linux-Instance zu /opt/appstream/SessionScripts/config.json. Die Datei ist wie folgt formatiert:

{
  "SessionStart": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  },
  "SessionTermination": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  }
}

Sie können die folgenden Parameter in der Sitzungsskript-Konfigurationsdatei verwenden.

Verwenden von Windows- PowerShell Dateien

Um Windows- PowerShell Dateien zu verwenden, geben Sie den vollständigen Pfad zur PowerShell Datei im filename Parameter an:

"filename": 
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",

Geben Sie das Sitzungsskript im Parameter arguments an:

"arguments": "-File \"C:\\path\\to\\session\\script.ps1\"",

Überprüfen Sie abschließend, ob die PowerShell Ausführungsrichtlinie die Ausführung Ihrer PowerShell Datei zulässt.

Protokollieren der Ausgaben von Sitzungsskripten

Wenn diese Option in der Konfigurationsdatei aktiviert ist, erfasst AppStream 2.0 automatisch die Ausgabe des Sitzungsskripts, das in den Standardausgang geschrieben wird. Diese Ausgabe wird in einen Amazon S3-Bucket im Konto hochgeladen. Sie können die Protokolldateien im Rahmen der Fehlerbehebung und des Debuggings heranziehen.

Verwenden von Speicher-Connectors mit Sitzungsskripten

Wenn AppStream 2.0-Speicher-Connectors aktiviert sind, beginnen sie mit dem Mounten, wenn die Sitzungsstartskripts ausgeführt werden. Wenn Ihr Skript von den gemounteten Speicher-Connectors abhängt, können Sie warten, bis die Connectors verfügbar sind. AppStream 2.0 behält den Mount-Status der Speicher-Connectors in der Windows-Registrierung auf Windows-Instances bei, und zwar mit dem folgenden Schlüssel:

HKEY_LOCAL_MACHINE\ microSDT microSD\Amazon\AppStream\Storage\<provided user name>\<Storage Connector>

Die Werte des Registrierungsschlüssels lauten wie folgt:

Jeder Speicher-Connector-Registrierungsschlüssel enthält einen MountStatus DWORD-Wert. In der folgenden Tabelle sind die möglichen Werte für aufgeführtMountStatus.

Auf Linux-Instances können Sie den Mountingstatus des Basisordners überprüfen, indem Sie sich den Wert von appstream_home_folder_mount_status in der Datei ~/.config/appstream-home-folder//appstream-home-folder-mount-status ansehen.

Aktivieren der Speicherung von Sitzungsskriptprotokollen in Amazon-S3-Buckets

Wenn Sie die Amazon S3-Protokollierung in Ihrer Sitzungsskriptkonfiguration aktivieren, erfasst AppStream 2.0 die Standardausgabe Ihres Sitzungsskripts. Die Ausgabe wird regelmäßig in einen S3-Bucket im Amazon-Web-Services-Konto hochgeladen. Für jede AWS Region erstellt AppStream 2.0 einen Bucket in Ihrem Konto, der für Ihr Konto und die Region eindeutig ist.

Konfigurationsschritte zum Verwalten dieser S3-Buckets sind nicht erforderlich. Sie werden vollständig vom AppStream 2.0-Service verwaltet. Die in einem Bucket gespeicherten Protokolldateien werden während der Übertragung mit Amazon-S3-SSL-Endpunkten und im Ruhezustand mit Amazon-S3-verwalteten Verschlüsselungsschlüsseln verschlüsselt. Die Benennung der Buckets erfolgt wie folgt in einem bestimmten Format:

appstream-logs-region-code-account-id-without-hyphens-random-identifier

Wenn Sie beispielsweise Sitzungsskripts in einem Bild in der Region USA West (Oregon) (us-west-2) unter der Kontonummer 123456789012, AppStream 2.0 angeben, wird in Ihrem Konto in dieser Region ein Amazon S3-Bucket mit dem angezeigten Namen erstellt. Nur ein Administrator mit ausreichenden Berechtigungen kann diesen Bucket löschen.

appstream-logs-us-west-2-1234567890123-abcdefg

Durch das Deaktivieren von Sitzungsskripten werden die im S3-Bucket gespeicherten Protokolldateien nicht gelöscht. Um Protokolldateien dauerhaft zu löschen, müssen Sie oder ein anderer Administrator mit ausreichenden Berechtigungen dies über die Amazon S3-Konsole oder API. AppStream 2.0 tun, indem Sie eine Bucket-Richtlinie hinzufügen, die ein versehentliches Löschen des Buckets verhindert. Weitere Informationen finden Sie unter IAM-Richtlinien und der Amazon-S3-Bucket für Basisordner und Persistenz von Anwendungseinstellungen in Identity and Access Management für Amazon AppStream 2.0.

Wenn Sitzungsskripte aktiviert sind, wird für jede gestartete Streaming-Sitzung ein eindeutiger Ordner erstellt.

Der Pfad für den Ordner, in dem die Protokolldateien im S3-Bucket in Ihrem Konto gespeichert werden, hat die folgende Struktur:

bucket-name/stack-name/fleet-name/access-mode/user-id-SHA-256-hash/session-id/SessionScriptsLogs/session-event

Das folgende Beispiel für eine Ordnerstruktur gilt für eine Streaming-Sitzung, die von test-stack und test-fleet gestartet wurde. Die Sitzung verwendet die API der Benutzer-ID testuser@mydomain.com, von einer AWS-Konto ID von 123456789012und die Einstellungsgruppe test-stack in der Region USA West (Oregon) (us-west-2):

appstream-logs-us-west-2-1234567890123-abcdefg/test-stack/test-fleet/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/05yd1391-4805-3da6-f498-76f5x6746016/SessionScriptsLogs/SessionStart/

Dieses Beispiel für eine Ordnerstruktur enthält eine Protokolldatei eines Startskripts für eine Benutzerkontextsitzung sowie eine Protokolldatei eines Startskripts für eine Systemkontextsitzung (sofern relevant).

Verwenden von Sitzungsskripten für Flotten mit mehreren Sitzungen

Bei der Verwendung von Sitzungsskripten auf Flotten mit mehreren Sitzungen gibt es zusätzliche Anforderungen und Überlegungen, um eine optimale Leistung und Sicherheit zu gewährleisten.

Voraussetzungen

Auf einer Single-Session-Flotte werden die SessionTermination Hooks SessionStart und für eine bestimmte Instance garantiert nur einmal ausgeführt. Dies liegt daran, dass es eine 1:1-Zuweisung von Sitzungen zu Instances gibt. Bei der Verwendung von Flotten mit mehreren Sitzungen gibt es eine N:M-Zuweisung von Sitzungen zu Instances, in der jede Sitzung ihre eigenen SessionStart und SessionTermination Hooks ausführt. Das bedeutet, dass die SessionTermination Hooks SessionStart und auf einer bestimmten Instance und in vielen verschiedenen Reihenfolgen mehrmals ausgeführt werden können. Für ein optimales Erlebnis sollte Folgendes für Ihre Sitzungsskripte gelten, wenn sie auf Flotten mit mehreren Sitzungen verwendet werden:

Viele dieser Anforderungen können erfüllt werden, indem die Logik des Sitzungsskripts auf die spezifische Benutzersitzung ausgerichtet bleibt, für die das Skript ausgeführt wird.

Sicherheitsüberlegungen

AppStream 2.0-Images sollten nicht so konfiguriert werden, dass sie Schreibberechtigungen für Sitzungsskriptdateien von Benutzern erlauben. Dies führt einen kritischen Angriffsvektor für böswillige Benutzer ein, bei dem sie Skriptdateien ändern können. Diese Dateien können dann je nach Konfiguration als SYSTEM oder als ein anderer Benutzer ausgeführt werden.

Folgendes sollte für Ihre Abbilder und Sitzungsskriptdateien zutreffen:

Ausführliche Sitzungsskripte sollten an einem sicheren Ort gespeichert werden, an dem sie zur Laufzeit vor Änderungen geschützt sind.

Wenn der Service erkennt, dass eine ausführbare Sitzungsskriptdatei geändert wurde, schlägt er alle nachfolgenden Ausführungen dieses Hooks auf dieser Instance fehl, Protokolldateien werden in Amazon S3 hochgeladen (wenn die Amazon S3-Protokollierung aktiviert ist) und Sie erhalten die folgende Meldung:

Das Sitzungsskript wurde nicht ausgeführt, da die ausführbare Datei nach der Instance-Bereitstellung geändert wurde. Die Ausführung wurde aus Sicherheitsgründen übersprungen.

Wenn Ihr Anwendungsfall erfordert, dass die ausführbare Sitzungsskriptdatei zur Laufzeit geändert wird (wenn Sie beispielsweise auf eine EXE-Datei verweisen, die zur Laufzeit durch einen automatischen Aktualisierungsprozess geändert wird), schlagen die oben genannten Prüfungen fehl. Verwenden Sie in diesem Fall ein Skript, um die Ausführung an Ihre geänderte ausführbare Datei umzuleiten. Lassen Sie das Skript zur Laufzeit unverändert, wenn der Service Sicherheitsprüfungen durchführt.

Wenn Ihre Sitzungsskriptdateien übermäßig groß sind (mehr als 100 MB), kann dies zu Verzögerungen bei der Instance- und Sitzungsbereitstellung führen, und die Sicherheitsprüfungen dauern zusätzliche Zeit (je nach Instance-Typ und verfügbaren Ressourcen). Wenn Ihr Anwendungsfall große Sitzungsskripts erfordert, sollten Sie erwägen, kleinere Skripts zu verwenden, um die Ausführung umzuleiten. Dies verbessert die Bereitstellung von Instances und Sitzungen.

Beachten Sie, dass der Service nur die ausführbare Datei überprüft, die in den Sitzungsskripten config.json definiert ist, und dies ist nur ein Fallback-/Best-Effort-Mechanismus. Es liegt in Ihrer Verantwortung sicherzustellen, dass alle Codepfade in ausführbaren Sitzungsskripten sicher sind und nicht von Endbenutzern geändert werden können.