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 Sitzungsskripten, um das Streaming-Erlebnis Ihrer Amazon WorkSpaces Applications-Benutzer zu verwalten WorkSpaces Applications stellt auf der Instanz installierte Sitzungsskripte 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 Skripts verwenden, um Ihre WorkSpaces Anwendungsumgebung 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 WorkSpaces Anwendungs-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. **Topics** + [Ausführen von Skripten vor dem Beginn von Streaming-Sitzungen](run-scripts-before-streaming-sessions-begin.md) + [Ausführen von Skripten nach dem Ende von Streaming-Sitzungen](run-scripts-after-streaming-sessions-end.md) + [Erstellen und Angeben von Sitzungsskripten](create-specify-session-scripts.md) + [Sitzungsskript-Konfigurationsdatei](session-script-configuration-file.md) + [PowerShell Windows-Dateien verwenden](using-powershell-files-with-session-scripts.md) + [Protokollieren der Ausgaben von Sitzungsskripten](logging-session-output.md) + [Verwenden von Speicher-Connectors mit Sitzungsskripten](use-storage-connectors-with-session-scripts.md) + [Aktivieren der Speicherung von Sitzungsskriptprotokollen in Amazon-S3-Buckets](enable-S3-bucket-storage-session-script-logs.md) + [Verwenden Sie Sitzungsskripten auf Flotten mit mehreren Sitzungen](session-scripts-multi-session-fleets.md) # 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 WorkSpaces Anwendungsumgebung anpassen, bevor Benutzer mit dem Streaming 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. Beispiel: C:\$1\$1Scripts\$1\$1Myscript.bat Wenn Sie keinen doppelten umgekehrten Schrägstrich verwenden, werden Sie in einer Fehlermeldung darauf hingewiesen, dass die JSON-Datei falsch formatiert ist. **Anmerkung** Wenn die Skripte erfolgreich ausgeführt wurden, müssen sie den Wert 0 zurückgeben. Wenn Ihre Skripts einen anderen Wert als 0 zurückgeben, zeigt WorkSpaces Applications dem Benutzer die Fehlermeldung an. Wenn Sie Skripts ausführen, bevor Streaming-Sitzungen beginnen und das dynamische Anwendungsframework für WorkSpaces Anwendungen nicht aktiviert ist, läuft der folgende Vorgang ab: ![\[WorkSpaces Applications workflow diagram showing connection, application selection, and session launch steps.\]](http://docs.aws.amazon.com/de_de/appstream2/latest/developerguide/images/session-scripts-without-DAF-non-domain-joined2.png) 1. Ihre Benutzer stellen eine Verbindung zu einer WorkSpaces Applications-Flotteninstanz her, die nicht in eine Domäne eingebunden ist. Die Verbindung wird unter Verwendung einer der folgenden Zugriffsmethoden hergestellt: + WorkSpaces Benutzerpool für Anwendungen + SAML 2.0 + WorkSpaces Anwendungs-API 1. Der Anwendungskatalog wird im WorkSpaces Anwendungsportal angezeigt, und Ihre Benutzer wählen eine Anwendung zum Starten aus. 1. Nun erfolgt einer dieser Schritte: + Wenn die Persistenz von Anwendungseinstellungen für die Benutzer aktiviert ist, wird die Virtual Hard Disk (VHD)-Datei mit den Anwendungseinstellungen – Anpassungen sowie Windows-Einstellungen für die Benutzer – heruntergeladen und bereitgestellt. In diesem Fall ist eine Windows-Benutzeranmeldung erforderlich. Weitere Informationen zur Persistenz von Anwendungseinstellungen siehe [Aktivieren Sie die Persistenz der Anwendungseinstellungen für Ihre WorkSpaces Anwendungsbenutzer](app-settings-persistence.md). + Wenn die Persistenz von Anwendungseinstellungen nicht aktiviert ist, ist der Windows-Benutzer bereits angemeldet. 1. Das Sitzungsskript startet. Wenn für die Benutzer persistenter Speicher aktiviert ist, beginnt auch die Bereitstellung des Speicher-Connectors. Informationen zu persistentem Speicher siehe [Aktivieren und verwalten Sie persistenten Speicher für Ihre WorkSpaces Anwendungsbenutzer](persistent-storage.md). **Anmerkung** Die Bereitstellung des Speicher-Connectors muss nicht abgeschlossen sein, damit die Streaming-Sitzung startet. Wenn die Sitzungsskripte abgeschlossen werden, bevor die Bereitstellung des Speicher-Connectors abgeschlossen ist, wird die Streaming-Sitzung gestartet. Informationen zum Überwachen des Bereitstellungsstatus von Speicher-Connectors siehe [Verwenden von Speicher-Connectors mit Sitzungsskripten](use-storage-connectors-with-session-scripts.md). 1. Die Sitzungsskripte werden abgeschlossen oder überschreiten das Zeitlimit. 1. Die Streaming-Sitzung des Benutzers startet. 1. Die vom Benutzer gewählte Anwendung startet. Informationen zum Dynamic Application Framework für WorkSpaces Anwendungen finden Sie unter[Verwenden Sie das WorkSpaces Applications Dynamic Application Framework, um einen dynamischen Anwendungsanbieter zu erstellen](build-dynamic-app-provider.md). Wenn Sie Skripts ausführen, bevor Streaming-Sitzungen beginnen und das Framework für dynamische WorkSpaces Anwendungen für Anwendungen aktiviert ist, läuft der folgende Vorgang ab: ![\[WorkSpaces Applications workflow from user login to application launch, including SAML authentication and session scripts.\]](http://docs.aws.amazon.com/de_de/appstream2/latest/developerguide/images/session-scripts-with-DAF-domain-joined2.png) 1. Ihre Benutzer besuchen das SAML 2.0-Anwendungsportal für Ihr Unternehmen und wählen den WorkSpaces Anwendungsstapel aus. 1. Sie stellen eine Verbindung zu einer WorkSpaces Applications-Flotteninstanz her, die mit einer Domäne verknüpft ist. 1. Wenn die Persistenz von Anwendungseinstellungen für die Benutzer aktiviert ist, wird die VHD-Datei mit den Anwendungseinstellungen – Anpassungen sowie Windows-Einstellungen für die Benutzer – heruntergeladen und bereitgestellt. 1. Die Windows-Benutzeranmeldung erfolgt. 1. Der Anwendungskatalog wird im Anwendungsportal angezeigt, und Ihre Benutzer wählen eine Anwendung zum Starten aus. WorkSpaces 1. Das Sitzungsskript startet. Wenn für die Benutzer persistenter Speicher aktiviert ist, beginnt auch die Bereitstellung des Speicher-Connectors. **Anmerkung** Die Bereitstellung des Speicher-Connectors muss nicht abgeschlossen sein, damit die Streaming-Sitzung startet. Wenn die Sitzungsskripte abgeschlossen werden, bevor die Bereitstellung des Speicher-Connectors abgeschlossen ist, wird die Streaming-Sitzung gestartet. Informationen zum Überwachen des Bereitstellungsstatus von Speicher-Connectors siehe [Verwenden von Speicher-Connectors mit Sitzungsskripten](use-storage-connectors-with-session-scripts.md). 1. Die Sitzungsskripte werden abgeschlossen oder überschreiten das Zeitlimit. 1. Die Streaming-Sitzung des Benutzers startet. 1. Die vom Benutzer gewählte Anwendung startet. # 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 in der WorkSpaces Anwendungs-Symbolleiste die Option **Sitzung beenden** auswählen oder wenn sie die maximal zulässige Sitzungsdauer erreicht haben. Sie können diese Sitzungsskripts auch verwenden, um Ihre WorkSpaces Anwendungsumgebung 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: ![\[Flowchart showing WorkSpaces Applications session termination process with scripts and storage actions.\]](http://docs.aws.amazon.com/de_de/appstream2/latest/developerguide/images/session-scripts-termination.png) 1. Die WorkSpaces Anwendungs-Streaming-Sitzung Ihrer Benutzer wird beendet. 1. Die Skripte zur Sitzungsbeendigung werden gestartet. 1. Die Skripte zur Sitzungsbeendigung werden abgeschlossen oder überschreiten das Zeitlimit. 1. Die Windows-Benutzerabmeldung erfolgt. 1. Eine der folgenden Operationen wird ausgeführt (bzw. beide gleichzeitig, falls relevant): + Wenn die Persistenz von Anwendungseinstellungen für die Benutzer aktiviert ist, wird die Bereitstellung der VHD-Datei mit den Anwendungseinstellungen – Anpassungen sowie Windows-Einstellungen für die Benutzer – aufgehoben und die Datei in einen Amazon-S3-Bucket Ihres Kontos hochgeladen. + Wenn für die Benutzer persistenter Speicher aktiviert ist, führt der Speicher-Connector eine abschließende Synchronisierung durch, bevor seine Bereitstellung aufgehoben wird. 1. Die Flotten-Instance wird beendet. # Erstellen und Angeben von Sitzungsskripten Sie können Sitzungsskripts für Always-On-, On-Demand- und Elastic-Flotten konfigurieren und angeben. **So konfigurieren und spezifizieren Sie Sitzungsskripts für Always-On- und On-Demand-Flotten** 1. Öffnen Sie die WorkSpaces Anwendungskonsole unter [https://console.aws.amazon.com/appstream2.](https://console.aws.amazon.com/appstream2) 1. Wählen Sie im Navigationsbereich **Images (Abbilder)**, **Image Builder** aus. 1. Wählen Sie einen Image Builder mit dem Status **Running (Wird ausgeführt)** und dann **Connect (Verbinden)** aus. 1. Wählen Sie nach Aufforderung **Administrator**. 1. Navigieren Sie zu `C:\AppStream\SessionScripts` und öffnen Sie die Konfigurationsdatei `config.json`. Informationen zum Ändern von Sitzungsskriptparametern siehe [Sitzungsskript-Konfigurationsdatei](session-script-configuration-file.md). 1. Speichern und schließen Sie die Datei `config.json`, nachdem Sie die gewünschten Änderungen vorgenommen haben. 1. Öffnen Sie auf dem Image-Builder-Desktop den **Image Assistant**. 1. (Optional) Geben Sie optional alle anderen Anwendungen an, die in das Abbild eingeschlossen werden sollen. 1. Führen Sie die erforderlichen Schritte im Image Assistant aus, um Ihr Abbild fertigzustellen. Wenn die Konfiguration der Sitzungsskripts nicht validiert werden kann (weil beispielsweise die JSON-Datei nicht richtig formatiert ist), werden Sie benachrichtigt, sobald Sie **Verbindung trennen und Abbild erstellen** auswählen. **Anmerkung** Navigieren Sie zu `/opt/appstream/SessionScripts/config.json`, um die Konfigurationsdatei für Sitzungsskripts für Linux-basierte Image Builder zu finden. **So konfigurieren und spezifizieren Sie Sitzungsskripts für Elastic-Flotten** 1. Erstellen Sie eine ZIP-Datei mit den Sitzungsskripts und der config.json-Datei. Die Skriptdateien werden an die folgenden Speicherorte kopiert. Sie müssen diese Speicherorte für Ihre config.json-Datei verwenden. + Für Windows, verwenden Sie `C:\AppStream\SessionScripts\SessionScript`. + Für Linux, verwenden Sie `/opt/appstream/SessionScripts/SessionScript`. **Anmerkung** Überprüfen Sie zur Ausführung der Sitzungsskriptdateien, dass die Zip-Datei nur die Sitzungsskripts und `config.json`-Dateien enthält und nicht den enthaltenen Ordner. Weitere Informationen finden Sie unter [Sitzungsskript-Konfigurationsdatei](session-script-configuration-file.md). 1. Laden Sie die Zip-Datei in einen Amazon-S3-Bucket in Ihrem Konto hoch. **Anmerkung** Ihre VPC muss den Zugriff auf den Amazon-S3-Bucket ermöglichen. Weitere Informationen finden Sie unter [Verwendung von Amazon S3 S3-VPC-Endpunkten für Anwendungsfunktionen WorkSpaces](managing-network-vpce-iam-policy.md). Ihr S3-Bucket und Ihre WorkSpaces Anwendungsflotte müssen identisch sein. AWS-Region Sie benötigen IAM-Berechtigungen, um die Aktion `S3:GetObject` für das Sitzungsskriptobjekt im Amazon-S3-Bucket auszuführen. Weitere Informationen zum Speichern der Sitzungsskripts in einem Amazon-S3-Bucket finden Sie unter [Speichern der Anwendungssymbole, Setup-Skripts, Sitzungsskripts und VHDs in einem S3-Bucket](store-s3-bucket.md). 1. Öffnen Sie die WorkSpaces Anwendungskonsole unter [https://console.aws.amazon.com/appstream2.](https://console.aws.amazon.com/appstream2) 1. Klicken Sie im Navigationsbereich auf **Fleets (Flotten)**. 1. Wählen Sie eine Elastic-Flotte aus, die Sie aktualisieren möchten, und klicken Sie dann auf **Details anzeigen**. 1. Wählen Sie auf der Registerkarte **Einstellungen für Sitzungsskripts** die Option **Bearbeiten** aus. 1. Geben Sie unter **Sitzungsskriptobjekt in S3** entweder die S3 URI ein, die das Sitzungsskriptobjekt darstellt, oder wählen Sie **S3 durchsuchen** aus, um zu Ihren S3-Buckets zu navigieren und das Sitzungsskriptobjekt zu finden. 1. Wenn Sie die gewünschten Änderungen vorgenommen haben, wählen Sie **Änderungen speichern** aus. 1. Zu diesem Zeitpunkt sind die Sitzungsskripts für alle gestarteten Flotten-Instances verfügbar. **Anmerkung** Sie können die Sitzungsskripts auch konfigurieren, wenn Sie eine neue Elastic-Flotte erstellen. # Sitzungsskript-Konfigurationsdatei Um die Konfigurationsdatei für Sitzungsskripten in einer Windows-Instanz zu finden, navigieren Sie zu C:\$1\$1AppStream\$1 SessionScripts config.json. Navigieren Sie auf einer Linux-Instanz zu/opt/appstream/SessionScripts/config.json. Die Datei ist wie folgt formatiert: **Anmerkung** Die Konfigurationsdatei liegt im JSON-Format vor. Verifizieren Sie, dass der gesamte eingegebene Text ein gültiges JSON-Format hat. ``` { "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. ***SessionStart/SessionTermination *** Welche Sitzungsskripte bei Auftreten eines Sitzungsereignisses ausgeführt werden, hängt vom Namen des Objekts ab. **Typ:** Zeichenfolge **Required**: No **Zulässige Werte:** **SessionStart**, **SessionTermination** ***WaitingTime*** Maximale Dauer der Sitzungsskripte in Sekunden. **Typ**: Ganzzahl **Required**: No **Einschränkungen:** Die maximale Dauer beträgt 60 Sekunden. Wenn die Sitzungsskripte nicht innerhalb dieser Zeit abgeschlossen werden, werden sie beendet. Wenn ein Skript weiter ausgeführt werden soll, starten Sie es als einen separaten Prozess. ***Executables*** Die Details für die auszuführenden Sitzungsskripte. **Typ:** Zeichenfolge **Erforderlich**: Ja **Einschränkungen:** Pro Sitzungsereignis können maximal 2 Skripte ausgeführt werden (eines für den Benutzerkontext, eines für den Systemkontext). ***Context*** Der Kontext, in dem das Sitzungsskript ausgeführt werden soll. **Typ:** Zeichenfolge **Erforderlich**: Ja **Zulässige Werte:** **user**, **system** ***Filename*** Der vollständige Pfad des auszuführenden Sitzungsskripts. Wenn dieser Parameter nicht angegeben wird, wird das Sitzungsskript nicht ausgeführt. **Typ:** Zeichenfolge **Required**: No **Einschränkungen:** Die maximale Länge für Dateiname und vollständigen Pfad beträgt 1000 Zeichen. **Zulässige Werte:****.bat**,, **.exe** **.sh** Sie können auch PowerShell Windows-Dateien verwenden. Weitere Informationen finden Sie unter [PowerShell Windows-Dateien verwenden](using-powershell-files-with-session-scripts.md). ***Arguments*** Die Argumente für das Sitzungsskript oder die ausführbare Datei. **Typ:** Zeichenfolge **Required**: No **Längenbeschränkungen:** Die maximale Länge beträgt 1000 Zeichen. ***S3LogEnabled*** Wenn der Wert für diesen Parameter auf **True** gesetzt ist, wird im Amazon-Web-Services-Konto ein S3-Bucket zum Speichern der vom Sitzungsskript generierten Protokolle erstellt. Standardmäßig ist dieser Wert auf **True** festgelegt. Weitere Informationen finden Sie im Abschnitt *Protokollieren der Ausgaben von Sitzungsskripten* unten in diesem Thema. **Typ**: Boolesch **Required**: No **Zulässige Werte:** **True**, **False** # PowerShell Windows-Dateien verwenden Um PowerShell Windows-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\"", ``` Stellen Sie abschließend sicher, dass 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 WorkSpaces Applications automatisch die Ausgabe des Sitzungsskripts, die in die Standardausgabe 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. **Anmerkung** Die Protokolldateien werden hochgeladen, wenn das Sitzungsskript einen Wert zurückgibt oder die in **WaitingTime** festgelegte Zeit abgelaufen ist (je nachdem, welches Ereignis zuerst eintritt). # Verwenden von Speicher-Connectors mit Sitzungsskripten Wenn die Speicherconnectors für WorkSpaces Anwendungen aktiviert sind, beginnen sie mit dem Mounten, sobald die Sitzungsstartskripts ausgeführt werden. Wenn Ihr Skript darauf angewiesen ist, dass die Speicherconnectors bereitgestellt werden, können Sie warten, bis die Konnektoren verfügbar sind. WorkSpaces Applications behält den Bereitstellungsstatus der Speicherconnectors in der Windows-Registrierung auf Windows-Instances unter dem folgenden Schlüssel bei: HKEY\$1LOCAL\$1MACHINE\$1 SOFTWARE\$1 Amazon\$1\$1 Speicher\$1\$1 AppStream Die Werte des Registrierungsschlüssels lauten wie folgt: + Bereitgestellter Benutzername – die über den Zugriffsmodus bereitgestellte Benutzer-ID. Die verfügbaren Zugriffsmodi und die jeweils zugehörigen Werte lauten: + Benutzerpool – die E-Mail-Adresse des Benutzers + Streaming-URL – die UserID + SAML – die NameID. Wenn der Benutzername einen Schrägstrich enthält (z. B. der Name eines Domänenbenutzers SAMAccount), wird der Schrägstrich durch ein „-“ -Zeichen ersetzt. + Speicher-Connector – der Connector für die persistente Speicheroption, die für den Benutzer aktiviert ist. Mögliche Werte für den Speicher-Connector: + HomeFolder + GoogleDrive + OneDrive Jeder Storage Connector-Registrierungsschlüssel enthält einen **MountStatus**DWORD-Wert. In der folgenden Tabelle sind die möglichen Werte für **MountStatus**aufgeführt. **Anmerkung** Um diese Registrierungsschlüssel anzuzeigen, müssen Sie Microsoft.NET Framework Version 4.7.2 oder höher auf Ihrem Abbild installiert haben. | Wert | Description | | --- | --- | | 0 | Der Speicher-Connector wurde für diesen Benutzer nicht aktiviert. | | 1 | Die Bereitstellung des Speicher-Connectors läuft. | | 2 | Der Speicher-Connector wurde bereitgestellt. | | 3 | Der Speicher-Connector konnte nicht bereitgestellt werden. | | 4 | Mounting des Speicher-Connectors ist aktiviert, aber noch nicht gemountet | Auf Linux-Instances können Sie den Bereitstellungsstatus des Home-Ordners überprüfen, indem Sie sich den Wert von appstream\$1home\$1folder\$1mount\$1status in der Datei \$1/ ansehen. config/appstream-home-folder/appstreamhome-folder-mount-status-. | Wert | Description | | --- | --- | | Wahr | Der Basisordner wurde erfolgreich bereitgestellt. | | Falsch | Der Basisordner ist noch nicht bereitgestellt. | # Aktivieren der Speicherung von Sitzungsskriptprotokollen in Amazon-S3-Buckets Wenn Sie die Amazon S3 S3-Protokollierung in Ihrer Sitzungsskriptkonfiguration aktivieren, erfasst WorkSpaces Applications die Standardausgabe Ihres Sitzungsskripts. Die Ausgabe wird regelmäßig in einen S3-Bucket im Amazon-Web-Services-Konto hochgeladen. WorkSpaces Applications erstellt für jede AWS Region einen Bucket in Ihrem Konto, der für Ihr Konto und die Region einzigartig ist. Konfigurationsschritte zum Verwalten dieser S3-Buckets sind nicht erforderlich. Sie werden vollständig vom WorkSpaces Applications 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 ``` ***region-code*** Dies ist der AWS Regionalcode, in dem der Stack erstellt wird, wobei der Amazon S3 S3-Bucket-Speicher für Sitzungsskriptprotokolle aktiviert ist. ***account-id-without-hyphens*** Ihre Konto-ID für Amazon Web Services. Die zufällige ID stellt sicher, dass keine Konflikte mit anderen Buckets in dieser Region auftreten. Der erste Teil des Bucket-Namens, `appstream-logs`, ändert sich konto- oder regionsübergreifend nicht. Wenn Sie beispielsweise Sitzungsskripte in einem Bild in der Region USA West (Oregon) (us-west-2) unter der Kontonummer 123456789012 angeben, erstellt WorkSpaces Applications innerhalb Ihres Kontos in dieser Region einen Amazon S3 S3-Bucket mit dem angezeigten Namen. 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 entsprechenden Berechtigungen die Amazon S3 S3-Konsole oder API verwenden. WorkSpaces Applications fügt eine Bucket-Richtlinie hinzu, 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 WorkSpaces Amazon-Anwendungen](controlling-access.md). 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 ``` ***bucket-name*** Name des S3-Buckets, in dem die Sitzungsskripte gespeichert werden. Auf das Format des Namens wird weiter oben in diesem Abschnitt eingegangen. ***stack-name*** Name des Stacks, aus dem die Sitzung stammt. ***fleet-name*** Name der Flotte, für die das Sitzungsskript ausgeführt wird. ***access-mode*** Die Identitätsmethode des Benutzers: `custom` für die WorkSpaces Anwendungs-API oder CLI, `federated` für SAML und `userpool` für Benutzer im Benutzerpool. ***user-id-SHA-256-hash*** Der benutzerspezifische Ordnername. Der Name wird aus einer aus der Benutzer-ID generierten hexadezimalen SHA-256-Hash-Zeichenfolge in Kleinbuchstaben gebildet. ***session-id*** ID der Streaming-Sitzung des Benutzers. Für jede Streaming-Sitzung eines Benutzers wird eine eindeutige ID generiert. ***session-event*** Ereignis, das zum Generieren des Sitzungsprotokolls geführt hat. Die Ereigniswerte lauten `SessionStart` und `SessionTermination`. 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` aus einer AWS-Konto ID von `123456789012` und 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 Sie Sitzungsskripten auf Flotten mit mehreren Sitzungen Bei der Verwendung von Sitzungsskripten für Flotten mit mehreren Sitzungen gelten zusätzliche Anforderungen und Überlegungen, um optimale Leistung und Sicherheit zu gewährleisten. ## Voraussetzungen Bei einer Flotte mit nur einer Sitzung werden die **SessionStart**SessionTermination****And-Hooks für eine bestimmte Instanz garantiert nur einmal ausgeführt. Das liegt daran, dass es eine 1:1 -Zuordnung von Sitzungen zu Instanzen gibt. Bei der Verwendung von Multi-Session-Flotten gibt es eine N:M-Zuordnung von Sessions zu Instances, wobei jede Session ihren eigenen und einen eigenen Hook ausführt. **SessionStart**SessionTermination**** Das bedeutet, dass die **SessionTermination**Hooks **SessionStart**und die Hooks auf einer bestimmten Instanz viele Male und in vielen verschiedenen Reihenfolgen ausgeführt werden können. Für eine optimale Benutzererfahrung sollte Folgendes für Ihre Session-Skripte gelten, wenn Sie sie auf Multi-Session-Flotten verwenden: + Skripte sind idempotent. Wenn eine Aktion bereits ausgeführt wurde, sollten Skripte mehr als eine Ausführung auf derselben Instanz problemlos verarbeiten. + Skripten sind unabhängig. Da Skripten pro Sitzung ausgeführt werden, sollten sie, wenn eine Sitzung ausgeführt wird **SessionStart**, **SessionTermination**während eine andere läuft, sich gegenseitig oder die Erfahrung anderer Sitzungen nicht beeinträchtigen. + Skripts sind performant. Auf Instanzen mit mehreren Sitzungen können mehrere Sitzungen gleichzeitig bereitgestellt werden. Das bedeutet, dass die Sitzungsskripten mehrfach gleichzeitig ausgeführt werden können. Skripts sollten effizient sein, keine übermäßigen Ressourcen verbrauchen und die Erfahrung anderer Benutzer auf der Instanz oder die Stabilität der Sitzungen nicht beeinträchtigen. Viele dieser Anforderungen können erfüllt werden, indem die Logik des Sitzungsskripts auf die spezifische Benutzersitzung ausgerichtet wird, für die das Skript ausgeführt wird. ## Sicherheitsüberlegungen WorkSpaces Anwendungs-Images sollten nicht so konfiguriert werden, dass Benutzern Schreibberechtigungen für Sitzungsskriptdateien gewährt werden. Dadurch entsteht ein kritischer Angriffsvektor für böswillige Benutzer, bei dem sie Skriptdateien ändern könnten. Diese Dateien können dann je nach Konfiguration als SYSTEM oder als anderer Benutzer ausgeführt werden. **Wichtig** Es liegt in Ihrer Verantwortung, sicherzustellen, dass Ihre WorkSpaces Anwendungs-Images sicher konfiguriert sind. Dies ist besonders wichtig für Instanzen mit mehreren Sitzungen, bei denen mehrere Benutzer dieselbe Instanz verwenden. Wenn Images nicht sicher konfiguriert sind, besteht ein Sicherheitsrisiko für alle Benutzer dieser Instanz. Folgendes sollte für Ihre Bilder und Sitzungsskriptdateien gelten: + Benutzer sind nicht berechtigt, Sitzungsskriptdateien zu ändern. + Benutzer sind nicht berechtigt, das Sitzungsskript config.json zu ändern. Das Standardverhalten des Images schränkt den Zugriff auf Administratoren ein. Die ausführbaren Dateien von Sitzungsskripten sollten an einem sicheren Ort gespeichert werden, an dem sie während der Laufzeit vor Änderungen geschützt sind. Wenn der Service feststellt, dass eine ausführbare Datei eines Sitzungsskripts geändert wurde, schlägt er alle nachfolgenden Ausführungen dieses Hooks auf dieser Instance fehl, lädt Protokolldateien auf Amazon S3 hoch (falls die Amazon S3 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 eine Änderung der ausführbaren Datei des Sitzungsskripts zur Laufzeit erfordert (wenn Sie beispielsweise auf eine EXE-Datei verweisen, die zur Laufzeit durch einen automatischen Aktualisierungsprozess geändert wurde), werden die obigen Prüfungen nicht bestanden. Verwenden Sie in diesem Fall ein Skript, um die Ausführung an Ihre geänderte ausführbare Datei weiterzuleiten. Lassen Sie das Skript zur Laufzeit unverändert, wenn der Dienst Sicherheitsüberprüfungen durchführt. Wenn Ihre Sitzungsskriptdateien zu groß sind (mehr als 100 MB), kann dies zu Verzögerungen bei der Instanz- und Sitzungsbereitstellung führen, und die Sicherheitsprüfungen nehmen zusätzliche Zeit in Anspruch (abhängig vom Instanztyp und den verfügbaren Ressourcen). Wenn Ihr Anwendungsfall umfangreiche Sitzungsskripten erfordert, sollten Sie die Verwendung kleinerer Skripts in Betracht ziehen, um die Ausführung umzuleiten. Dies wird die Erfahrung bei der Bereitstellung von Instanzen und Sitzungen verbessern. Beachten Sie, dass der Dienst nur die in den Sitzungsskripten config.json definierte ausführbare Datei überprüft, und dies ist nur ein fallback/best Aufwandsmechanismus. Es liegt in Ihrer Verantwortung sicherzustellen, dass alle Codepfade in den ausführbaren Dateien von Sitzungsskripten sicher sind und nicht von Endbenutzern geändert werden können.