Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisez des scripts de session pour gérer l'expérience de streaming de vos utilisateurs d'Amazon WorkSpaces Applications
WorkSpaces Les applications fournissent des scripts de session sur instance. Vous pouvez les utiliser pour exécuter vos propres scripts personnalisés lorsque des événements spécifiques surviennent au cours des sessions de streaming des utilisateurs. Par exemple, vous pouvez utiliser des scripts personnalisés pour préparer l'environnement de vos WorkSpaces applications avant le début des sessions de streaming de vos utilisateurs. Vous pouvez également utiliser les scripts personnalisés pour nettoyer les instances de streaming après que les utilisateurs ont terminé leur session.
Les scripts de session sont spécifiés dans une image d' WorkSpaces applications. Ces scripts sont exécutés au sein du contexte de l'utilisateur ou du contexte du système. Si vos scripts de session utilisent la sortie standard pour écrire des messages d’information, d’erreur ou de débogage, ils peuvent éventuellement être enregistrés dans un compartiment Amazon S3 de votre compte Amazon Web Services.
**Topics**
+ [Exécution de scripts avant le début des sessions de streaming](run-scripts-before-streaming-sessions-begin.md)
+ [Exécution de scripts une fois les sessions de streaming terminées](run-scripts-after-streaming-sessions-end.md)
+ [Création et spécification de scripts de session](create-specify-session-scripts.md)
+ [Fichier de configuration des scripts de session](session-script-configuration-file.md)
+ [Utilisation de PowerShell fichiers Windows](using-powershell-files-with-session-scripts.md)
+ [Journalisation de la sortie du script de session](logging-session-output.md)
+ [Utilisation des connecteurs de stockage avec les scripts de session](use-storage-connectors-with-session-scripts.md)
+ [Activation du stockage des journaux de script de session dans un compartiment Amazon S3](enable-S3-bucket-storage-session-script-logs.md)
+ [Utiliser des scripts de session sur des flottes multisessions](session-scripts-multi-session-fleets.md)
# Exécution de scripts avant le début des sessions de streaming
Vous pouvez configurer vos scripts pour qu'ils s'exécutent pendant 60 secondes maximum avant que les applications de vos utilisateurs se lancent et que leurs sessions de streaming commencent. Cela vous permet de personnaliser l'environnement des WorkSpaces applications avant que les utilisateurs ne commencent à diffuser leurs applications. Pendant que les scripts de session s'exécutent, une icône de chargement s'affiche sur l'écran de vos utilisateurs. Lorsque l'exécution des scripts est terminée ou que le temps d'attente maximum s'est écoulé, la session de streaming de vos utilisateurs commence. Si vos scripts ne parviennent pas à s'exécuter complètement, un message d'erreur s'affiche sur l'écran de vos utilisateurs. Toutefois, cette erreur ne les empêche pas d'accéder à leur session de streaming.
Lorsque vous spécifiez un nom de fichier sur une instance Windows, vous devez utiliser une double barre oblique inverse. Par exemple :
C:\$1\$1Scripts\$1\$1Myscript.bat
Si vous n'utilisez pas une une double barre oblique inverse, un message d'erreur s'affiche pour vous avertir que le fichier .json n'est pas correctement formaté.
**Note**
Si l'exécution de vos scripts réussit complètement, une valeur de 0 devrait vous être renvoyée. Si vos scripts renvoient une valeur autre que 0, WorkSpaces Applications affiche le message d'erreur à l'attention de l'utilisateur.
Lorsque vous exécutez des scripts avant le début des sessions de streaming et que le framework d' WorkSpaces applications dynamiques des applications n'est pas activé, le processus suivant se produit :
![\[WorkSpaces Applications workflow diagram showing connection, application selection, and session launch steps.\]](http://docs.aws.amazon.com/fr_fr/appstream2/latest/developerguide/images/session-scripts-without-DAF-non-domain-joined2.png)
1. Vos utilisateurs se connectent à une instance de parc d' WorkSpaces applications qui n'est pas jointe à un domaine. Ils se connectent à l'aide d'une des méthodes d'accès suivantes :
+ WorkSpaces Groupe d'utilisateurs d'applications
+ SAML 2.0
+ WorkSpaces API d'applications
1. Le catalogue d'applications s'affiche dans le portail WorkSpaces Applications, et vos utilisateurs choisissent l'application à lancer.
1. L'un des scénarios suivants survient :
+ Si la persistance des paramètres d'application est activée pour vos utilisateurs, le fichier de paramètres d'application VHD (Virtual Hard Disk), qui stocke les personnalisations et les paramètres Windows de vos utilisateurs, est téléchargé et monté. Dans ce cas, la connexion utilisateur à Windows est requise.
Pour en savoir plus sur la persistance des paramètres d'application, consultez [Activer la persistance des paramètres d'application pour les utilisateurs de vos WorkSpaces applications](app-settings-persistence.md).
+ Si la persistance des paramètres d'application n'est pas activée, l'utilisateur Windows est déjà connecté.
1. Vos scripts de session démarrent. Si le stockage persistant est activé pour vos utilisateurs, le montage du connecteur de stockage se lance également. Pour en savoir plus sur le stockage persistant, consultez [Activez et gérez le stockage permanent pour les utilisateurs de vos WorkSpaces applications](persistent-storage.md).
**Note**
Le montage du connecteur de stockage n’a pas besoin d’être terminé pour que la session de streaming démarre. Si l’exécution des scripts de session est terminée avant que le connecteur de stockage ne soit monté, la session de streaming commence.
Pour savoir comment surveiller l’état de montage des connecteurs de stockage, consultez [Utilisation des connecteurs de stockage avec les scripts de session](use-storage-connectors-with-session-scripts.md).
1. L’exécution de vos scripts de session est terminée ou expire.
1. La session de streaming des utilisateurs démarre.
1. L’application que vos utilisateurs ont sélectionnée se lance.
Pour plus d'informations sur le framework d' WorkSpaces applications dynamiques Applications, consultez[Utiliser le framework d' WorkSpaces applications dynamiques pour créer un fournisseur d'applications dynamiques](build-dynamic-app-provider.md).
Lorsque vous exécutez des scripts avant le début des sessions de streaming et que le framework d' WorkSpaces applications dynamiques des applications est activé, le processus suivant se produit :
![\[WorkSpaces Applications workflow from user login to application launch, including SAML authentication and session scripts.\]](http://docs.aws.amazon.com/fr_fr/appstream2/latest/developerguide/images/session-scripts-with-DAF-domain-joined2.png)
1. Vos utilisateurs consultent le portail d'applications SAML 2.0 de votre organisation et choisissent la pile WorkSpaces Applications.
1. Ils se connectent à une instance de parc d' WorkSpaces applications jointe à un domaine.
1. Si la persistance des paramètres d'application est activée pour vos utilisateurs, le fichier de paramètres d'application VHD, qui stocke les personnalisations et les paramètres Windows de vos utilisateurs, est téléchargé et monté.
1. L'utilisateur Windows est connecté.
1. Le catalogue d'applications s'affiche dans le portail WorkSpaces Applications et vos utilisateurs choisissent l'application à lancer.
1. Vos scripts de session démarrent. Si le stockage persistant est activé pour vos utilisateurs, le montage du connecteur de stockage se lance également.
**Note**
Le montage du connecteur de stockage n’a pas besoin d’être terminé pour que la session de streaming démarre. Si l’exécution des scripts de session est terminée avant que le connecteur de stockage ne soit monté, la session de streaming commence.
Pour savoir comment surveiller l’état de montage des connecteurs de stockage, consultez [Utilisation des connecteurs de stockage avec les scripts de session](use-storage-connectors-with-session-scripts.md).
1. L’exécution de vos scripts de session est terminée ou expire.
1. La session de streaming des utilisateurs démarre.
1. L’application que vos utilisateurs ont sélectionnée se lance.
# Exécution de scripts une fois les sessions de streaming terminées
Vous pouvez également configurer vos scripts de manière à ce qu'ils s'exécutent après les sessions de streaming. Par exemple, vous pouvez exécuter un script lorsque les utilisateurs sélectionnent **Fin de session** dans la barre d'outils des WorkSpaces applications ou lorsqu'ils atteignent la durée maximale autorisée pour la session. Vous pouvez également utiliser ces scripts de session pour nettoyer l'environnement de vos WorkSpaces applications avant de mettre fin à une instance de streaming. Par exemple, vous pouvez utiliser les scripts pour libérer des verrouillages de fichiers ou pour charger des fichiers journaux. Si vous exécutez des scripts une fois les sessions de streaming terminées, le scénario suivant se produit :
![\[Flowchart showing WorkSpaces Applications session termination process with scripts and storage actions.\]](http://docs.aws.amazon.com/fr_fr/appstream2/latest/developerguide/images/session-scripts-termination.png)
1. La session de streaming des WorkSpaces applications de vos utilisateurs se termine.
1. Vos scripts d'arrêt de session démarrent.
1. L'exécution des scripts d'arrêt de session se termine ou expire.
1. L'utilisateur Windows est déconnecté.
1. Un des scénarios suivants, ou les deux, se produi(sen)t, le cas échéant :
+ Si la persistance des paramètres d’application est activée pour vos utilisateurs, le fichier VHD de paramètres d’application, qui stocke les personnalisations et les paramètres Windows de vos utilisateurs, est démonté et chargé dans un compartiment Amazon S3 de votre compte.
+ Si le stockage persistant est activé pour vos utilisateurs, le connecteur de stockage effectue une synchronisation finale et est démonté.
1. L'instance de flotte est arrêtée.
# Création et spécification de scripts de session
Vous pouvez configurer et spécifier des scripts de session pour les flottes toujours actives, à la demande et Elastic.
**Pour configurer et spécifier des scripts de session pour les flottes toujours actives et à la demande**
1. Ouvrez la console WorkSpaces Applications à l'adresse [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. Dans le panneau de navigation, choisissez **Images**, puis **Image Builder**.
1. Choisissez un Image Builder dont l'état correspond à **Running (En cours d'exécution)**, puis sélectionnez **Connect (Se connecter)**.
1. Lorsque vous y êtes invité, sélectionnez **Administrateur**.
1. Accédez à `C:\AppStream\SessionScripts` et ouvrez le fichier de configuration `config.json`.
Pour en savoir plus sur les paramètres des scripts de session, consultez [Fichier de configuration des scripts de session](session-script-configuration-file.md).
1. Une fois que vous avez terminé d’effectuer vos modifications, enregistrez puis fermez le fichier `config.json`.
1. Sur le bureau de l’instance Image Builder, ouvrez l’application **Image Assistant**.
1. (Facultatif) Spécifiez les autres applications que vous souhaitez inclure dans l’image.
1. Effectuez les étapes nécessaires dans Image Assistant pour finaliser la création de votre image.
Si la configuration des scripts de session ne peut pas être validée (par exemple, si le fichier .json n'est pas correctement formaté), vous en êtes averti lorsque vous choisissez **Disconnect and create image (Se déconnecter et créer une image)**.
**Note**
Pour localiser le fichier de configuration des scripts de session pour les instances Image Builder Linux, accédez à `/opt/appstream/SessionScripts/config.json`.
**Pour configurer et spécifier des scripts de session pour les flottes Elastic**
1. Créez un fichier zip contenant les scripts de session et le fichier config.json. Les fichiers de script seront copiés aux emplacements suivants. Vous devez utiliser ces emplacements pour votre fichier config.json.
+ Pour Windows, utilisez `C:\AppStream\SessionScripts\SessionScript`.
+ Pour Linux, utilisez `/opt/appstream/SessionScripts/SessionScript`.
**Note**
Pour exécuter les fichiers de script de session, assurez-vous que le fichier .zip inclut uniquement les scripts de session et les fichiers `config.json`, et non le dossier qui les contient. Pour plus d’informations, consultez [Fichier de configuration des scripts de session](session-script-configuration-file.md).
1. Chargez le fichier zip dans un compartiment Amazon S3 de votre compte.
**Note**
Votre VPC doit fournir l’accès au compartiment Amazon S3. Pour de plus amples informations, veuillez consulter [Fonctionnalités d'utilisation des points de terminaison VPC Amazon S3 pour les applications WorkSpaces](managing-network-vpce-iam-policy.md).
Vous devez avoir votre compartiment S3 et votre parc WorkSpaces d'applications au même endroit Région AWS.
Vous devez disposer des autorisations IAM pour effectuer l’action `S3:GetObject` sur l’objet scripts de session dans le compartiment Amazon S3. Pour en savoir plus sur le stockage des scripts de session dans un compartiment Amazon S3, consultez [Stockage de l’icône de l’application, du script de configuration, du script de session et du VHD dans un compartiment S3](store-s3-bucket.md).
1. Ouvrez la console WorkSpaces Applications à l'adresse [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. Dans le volet de navigation, sélectionnez **Flottes**.
1. Choisissez une flotte Elastic à mettre à jour, puis sélectionnez **Afficher les détails**.
1. Dans l’onglet **Paramètres des scripts de session**, choisissez **Modifier**.
1. Pour **Objet scripts de session dans S3**, entrez l’URI S3 qui représente l’objet scripts de session ou choisissez **Parcourir S3** pour accéder à vos compartiments S3 et trouver l’objet scripts de session.
1. Une fois les modifications terminées, choisissez **Enregistrer les modifications**.
1. À ce stade, les scripts de session sont disponibles pour toutes les instances de flotte lancées.
**Note**
Vous pouvez également configurer les scripts de session lorsque vous créez une nouvelle flotte Elastic.
# Fichier de configuration des scripts de session
Pour localiser le fichier de configuration des scripts de session dans une instance Windows, accédez à C : \$1 \$1 AppStream SessionScripts \$1 config.json. Sur une instance Linux, accédez à/opt/appstream/SessionScripts/config.json. Le format du fichier est le suivant.
**Note**
Le fichier de configuration est au format .json. Vérifiez que tout le texte que vous saisissez dans ce fichier est au format .json valide.
```
{
"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
}
}
```
Vous pouvez utiliser les paramètres suivants dans le fichier de configuration des scripts de session.
***SessionStart/SessionTermination ***
Les scripts de session s'exécutent dans l'événement de session approprié, en fonction du nom de l'objet.
**Type** : chaîne
**Obligatoire** : non
**Valeurs autorisées :** **SessionStart**, **SessionTermination**
***WaitingTime***
Durée maximale en secondes des scripts de session.
**Type** : entier
**Obligatoire** : non
**Contraintes :** la durée maximale ne peut pas dépasser 60 secondes. Si l'exécution des scripts de session n'est pas terminée au terme de ce délai, elle s’arrête. Si vous avez besoin d'un script pour continuer l’exécution, lancez-le comme un processus distinct.
***Executables***
Détails sur les scripts de session à exécuter.
**Type** : chaîne
**Obligatoire** : oui
**Contraintes :** le nombre maximum de scripts qui peuvent s'exécuter par événement de session est de 2 (un pour le contexte de l'utilisateur et l'autre pour le contexte du système).
***Context***
Le contexte dans lequel le script de session doit être exécuté.
**Type** : chaîne
**Obligatoire** : oui
**Valeurs autorisées :** **user**, **system**
***Filename***
Le chemin d'accès complet au script de session qui doit être exécuter. Si ce paramètre n'est pas spécifié, le script de session n'est pas exécuté.
**Type** : chaîne
**Obligatoire** : non
**Contraintes :** la longueur maximale du nom de fichier et du chemin d'accès complet est de 1 000 caractères.
**Valeurs autorisées :****.bat**,**.exe**, **.sh**
Vous pouvez également utiliser des PowerShell fichiers Windows. Pour de plus amples informations, veuillez consulter [Utilisation de PowerShell fichiers Windows](using-powershell-files-with-session-scripts.md).
***Arguments***
Les arguments pour votre script de session ou votre fichier exécutable.
**Type** : chaîne
**Obligatoire** : non
**Contraintes de longueur :** la longueur maximale est de 1 000 caractères.
***S3LogEnabled***
Lorsque la valeur de ce paramètre est définie sur **True**, un compartiment S3 est créé dans votre compte Amazon Web Services pour stocker les journaux créés par le script de session. Par défaut, cette valeur indique **True**. Pour en savoir plus, consultez la section *Journalisation de la sortie du script de session* plus loin dans cette rubrique.
**Type** : valeur booléenne
**Obligatoire** : non
**Valeurs autorisées :** **True**, **False**
# Utilisation de PowerShell fichiers Windows
Pour utiliser PowerShell des fichiers Windows, spécifiez le chemin complet du PowerShell fichier dans le **filename** paramètre :
```
"filename":
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
```
Ensuite, spécifiez votre script de session dans le paramètre **arguments** :
```
"arguments": "-File \"C:\\path\\to\\session\\script.ps1\"",
```
Enfin, vérifiez que la politique PowerShell d'exécution autorise l'exécution de votre PowerShell fichier.
# Journalisation de la sortie du script de session
Lorsque cette option est activée dans le fichier de configuration, WorkSpaces Applications capture automatiquement le résultat du script de session écrit sur la sortie standard. Cette sortie est chargée dans un compartiment Amazon S3 de votre compte. Vous pouvez consulter les fichiers journaux à des fins de dépannage ou de débogage.
**Note**
Les fichiers journaux sont chargés lorsque le script de session renvoie une valeur, ou lorsque la valeur définit dans **WaitingTime** s'est écoulée, en fonction de l'événement qui se produit en premier.
# Utilisation des connecteurs de stockage avec les scripts de session
Lorsque WorkSpaces les connecteurs de stockage des applications sont activés, leur montage commence lorsque les scripts de démarrage de session s'exécutent. Si votre script repose sur le montage des connecteurs de stockage, vous pouvez attendre qu'ils soient disponibles. WorkSpaces Les applications conservent l'état de montage des connecteurs de stockage dans le registre Windows sur les instances Windows, à l'aide de la clé suivante :
HKEY\$1LOCAL\$1MACHINE \$1 SOFTWARE \$1 Amazon \$1 \$1 Storage \$1 \$1 AppStream
Les valeurs de la clé de registre sont les suivantes :
+ Nom d’utilisateur fourni : ID utilisateur fourni via le mode d’accès. Les modes d'accès et la valeur pour chaque mode sont les suivants :
+ Groupe d’utilisateurs : adresse e-mail de l’utilisateur
+ URL de streaming : ID utilisateur (UserID)
+ SAML : ID du nom (NameID). Si le nom d'utilisateur inclut une barre oblique (par exemple, le SAMAccount nom d'utilisateur d'un domaine), la barre oblique est remplacée par un caractère « - ».
+ Connecteur de stockage : connecteur pour l’option de stockage persistant qui a été activée pour l’utilisateur. Les valeurs du connecteur de stockage sont les suivantes :
+ HomeFolder
+ GoogleDrive
+ OneDrive
Chaque clé de registre du connecteur de stockage contient une valeur **MountStatus**DWORD. Le tableau suivant répertorie les valeurs possibles pour **MountStatus**.
**Note**
Pour afficher ces clés de registre, vous devez avoir installé Microsoft .NET Framework version 4.7.2 ou ultérieure sur votre image.
| Value | Description |
| --- | --- |
| 0 | Connecteur de stockage non activé pour cet utilisateur |
| 1 | Montage du connecteur de stockage en cours |
| 2 | Montage du connecteur de stockage terminé |
| 3 | Échec du montage du connecteur de stockage |
| 4 | Le montage du connecteur de stockage est activé, mais pas encore monté |
Sur les instances Linux, vous pouvez vérifier l'état de montage du dossier de base en consultant la valeur de appstream\$1home\$1folder\$1mount\$1status dans le fichier \$1/. config/appstream-home-folder/appstream-home-folder-mount-status.
| Value | Description |
| --- | --- |
| True | Le dossier de base est monté avec succès |
| False | Le dossier de base n’est pas encore monté |
# Activation du stockage des journaux de script de session dans un compartiment Amazon S3
Lorsque vous activez la connexion Amazon S3 dans la configuration de votre script de session, WorkSpaces Applications capture le résultat standard de votre script de session. La sortie est régulièrement chargée dans un compartiment S3 au sein de votre compte Amazon Web Services. Pour chaque AWS région, WorkSpaces Applications crée un compartiment dans votre compte qui est propre à votre compte et à la région.
Vous n'avez à effectuer aucune tâche de configuration pour gérer ces compartiments S3. Ils sont entièrement gérés par le service WorkSpaces Applications. Les fichiers journaux qui sont stockés dans chaque compartiment sont chiffrés en transit à l’aide des points de terminaison SSL d’Amazon S3 et au repos à l’aide des clés de chiffrement gérées par Amazon S3. Les compartiments sont nommés dans un format spécifique comme suit :
```
appstream-logs-region-code-account-id-without-hyphens-random-identifier
```
***region-code***
Il s'agit du code de AWS région dans lequel la pile est créée avec le stockage par compartiment Amazon S3 activé pour les journaux de script de session.
***account-id-without-hyphens***
Identifiant de votre compte Amazon Web Services. L'identifiant aléatoire permet de garantir qu'aucun conflit ne sera déclenché avec les autres compartiments de la région. La première partie du nom du compartiment, `appstream-logs`, ne change pas quel que soit le compte ou la région.
Par exemple, si vous spécifiez des scripts de session dans une image de la région USA Ouest (Oregon) (us-west-2) sous le numéro de compte 123456789012 WorkSpaces , Applications crée un compartiment Amazon S3 au sein de votre compte dans cette région avec le nom indiqué. Seul un administrateur disposant d’autorisations suffisantes peut supprimer ce compartiment.
```
appstream-logs-us-west-2-1234567890123-abcdefg
```
La désactivation des scripts de session ne supprime aucun fichier journal stocké dans le compartiment S3. Pour supprimer définitivement les fichiers journaux, vous ou un autre administrateur disposant des autorisations appropriées devez le faire à l'aide de la console ou de l'API Amazon S3. WorkSpaces Applications ajoute une politique de compartiment qui empêche la suppression accidentelle du compartiment. Pour plus d’informations, consultez *Stratégies IAM et compartiment Amazon S3 pour la persistance des paramètres d’application* dans [Identity and Access Management pour les WorkSpaces applications Amazon](controlling-access.md).
Lorsque les scripts de session sont activés, un dossier unique est créé pour chaque session de streaming démarrée.
Le chemin d’accès au dossier dans lequel les fichiers journaux sont stockés dans le compartiment S3 de votre compte est structuré comme suit :
```
bucket-name/stack-name/fleet-name/access-mode/user-id-SHA-256-hash/session-id/SessionScriptsLogs/session-event
```
***bucket-name***
Le nom du compartiment S3 dans lequel les scripts de session sont stockés. Le format du nom est décrit plus haut dans cette section.
***stack-name***
Le nom de la pile d'où est issue la session.
***fleet-name***
Le nom de la flotte sur laquelle le script de session s'exécute.
***access-mode***
La méthode d'identification de l'utilisateur : `custom` pour l'API ou la CLI des WorkSpaces applications, `federated` pour le SAML et `userpool` pour les utilisateurs du groupe d'utilisateurs.
***user-id-SHA-256-hash***
Nom du dossier spécifique à l’utilisateur. Ce nom est créé à l'aide d'une chaîne hexadécimale de hachage SHA-256 en minuscules, générée à partir de l'identifiant utilisateur.
***session-id***
L'identifiant de la session de streaming de l'utilisateur. Chaque session de streaming utilisateur génère un ID unique.
***session-event***
L'événement qui a généré le journal du script de session. Les valeurs des événements sont `SessionStart` et `SessionTermination`.
L'exemple de structure de dossier suivant correspond à une session de streaming démarrée à partir de test-stack (pile-test) et test-fleet (flotte-test). La session utilise l'API de l'ID utilisateur`testuser@mydomain.com`, à partir d'un Compte AWS ID de`123456789012`, et le groupe `test-stack` de paramètres de la région USA Ouest (Oregon) (us-west-2) :
```
appstream-logs-us-west-2-1234567890123-abcdefg/test-stack/test-fleet/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/05yd1391-4805-3da6-f498-76f5x6746016/SessionScriptsLogs/SessionStart/
```
L'exemple de structure de dossier contient un fichier journal pour le script de démarrage de session du contexte utilisateur, et un autre fichier journal pour le script de démarrage de session du contexte système, le cas échéant.
# Utiliser des scripts de session sur des flottes multisessions
Lorsque vous utilisez des scripts de session sur des flottes multisessions, des exigences et des considérations supplémentaires doivent être prises en compte pour garantir des performances et une sécurité optimales.
## Exigences
Sur une flotte à session unique, pour une instance donnée, il est garanti que les **SessionTermination**hooks **SessionStart**et ne fonctionneront qu'une seule fois. Cela est dû au fait qu'il existe un mappage 1:1 des sessions aux instances. Lorsque vous utilisez des flottes multisessions, il existe un mappage N:M des sessions aux instances, où chaque session exécute sa propre session et se connecte. **SessionStart**SessionTermination**** Cela signifie que les **SessionTermination**hooks **SessionStart**and peuvent être exécutés plusieurs fois sur une instance donnée, et dans de nombreux ordres différents. Pour une expérience optimale, les règles suivantes doivent s'appliquer à vos scripts de session lorsqu'ils sont utilisés sur des flottes multisessions :
+ Les scripts sont idempotents.
Lorsqu'une action a déjà été exécutée, les scripts doivent gérer plusieurs exécutions sur la même instance avec une gestion harmonieuse.
+ Les scripts sont indépendants.
Comme les scripts s'exécutent par session, si une session est **SessionTermination**en cours d'exécution pendant qu'une autre est en cours d'exécution **SessionStart**, ils ne doivent pas interférer les uns avec les autres ni avec l'expérience des autres sessions.
+ Les scripts sont performants.
Sur les instances multisessions, plusieurs sessions peuvent être mises en service simultanément. Cela signifie qu'il peut y avoir plusieurs exécutions simultanées des scripts de session. Les scripts doivent être efficaces, ne pas consommer trop de ressources et ne pas affecter l'expérience des autres utilisateurs sur l'instance ni la stabilité des sessions.
La plupart de ces exigences peuvent être satisfaites en gardant la logique du script de session centrée sur la session utilisateur spécifique pour laquelle le script est exécuté.
## Considérations de sécurité
WorkSpaces Les images des applications ne doivent pas être configurées pour autoriser les utilisateurs à accéder en écriture aux fichiers de script de session. Cela introduit un vecteur d'attaque critique pour les utilisateurs malveillants, qui peuvent modifier les fichiers de script. Ces fichiers peuvent ensuite être exécutés en tant que SYSTEM ou sous un autre nom d'utilisateur, en fonction de votre configuration.
**Important**
Il est de votre responsabilité de vous assurer que les images de vos WorkSpaces applications sont configurées de manière sécurisée. Cela est particulièrement important pour les instances multi-sessions, où plusieurs utilisateurs utilisent la même instance. Si les images ne sont pas configurées de manière sécurisée, il existe un risque de sécurité pour tous les utilisateurs de cette instance.
Ce qui suit doit être vrai pour vos images et vos fichiers de scripts de session :
+ Les utilisateurs ne sont pas autorisés à modifier les fichiers de script de session.
+ Les utilisateurs ne sont pas autorisés à modifier le script de session config.json. Le comportement par défaut de l'image restreint l'accès aux administrateurs.
Les exécutables des scripts de session doivent être stockés dans un emplacement sécurisé où ils ne peuvent pas être modifiés lors de l'exécution.
Si le service détecte qu'un exécutable de script de session a été modifié, il échouera à toute exécution ultérieure de ce hook sur cette instance, téléchargera les fichiers journaux sur Amazon S3 (si la journalisation Amazon S3 est activée) et le message suivant s'affichera :
**Le script de session n'a pas été exécuté car l'exécutable a été modifié après le provisionnement de l'instance. L'exécution a été ignorée pour des raisons de sécurité.**
Si votre cas d'utilisation nécessite de modifier le script de session exécutable au moment de l'exécution (par exemple, si vous pointez sur un fichier EXE modifié par un processus de mise à jour automatique lors de l'exécution), les vérifications ci-dessus échoueront. Dans ce cas, utilisez un script pour rediriger l'exécution vers votre exécutable modifié. Ne modifiez pas le script au moment de l'exécution lorsque le service effectue des contrôles de sécurité.
Si les fichiers de script de session sont trop volumineux (plus de 100 Mo), cela peut entraîner des retards dans le provisionnement des instances et des sessions, et les contrôles de sécurité peuvent prendre plus de temps (en fonction du type d'instance et des ressources disponibles). Si votre cas d'utilisation nécessite des scripts de session volumineux, pensez à utiliser des scripts plus petits pour rediriger l'exécution. Cela améliorera les expériences de provisionnement des instances et des sessions.
Notez que le service ne vérifie que l'exécutable défini dans les scripts de session config.json, et qu'il ne s'agit que d'un mécanisme d' fallback/best effort. Il est de votre responsabilité de vous assurer que tous les chemins de code des exécutables des scripts de session sont sécurisés et ne peuvent pas être modifiés par les utilisateurs finaux.