Actions Personnalisé et Exécuter

Dans cette section :

Action personnalisée

Vous pouvez créer des actions personnalisées dans PowerShell, Visual Basic ou JavaScript pour permettre un traitement qui n'est pas disponible avec les autres actions Environment Manager. Les scripts sont stockés dans le fichier XML de configuration, copiés sur disque lors de l'exécution, exécutés, puis supprimés lorsqu'ils ont terminé.

Les actions avec des scripts non valides renvoient Échec et aucune action enfant n'est exécutée. Avant Environment Manager 8.1, les actions personnalisées étaient transmises, que le script soit valide ou non.

Des événements d'audit séparés sont créés pour les actions qui réussissent et celles qui échouent. Vous les affichez à l'aide du bouton Audit du ruban Gérer.

' ==========================================================

' Le système vérifie si un processus (EMCoreService.exe) est en cours d'exécution

' =========================================================

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set objShell = CreateObject("Wscript.Shell")

Set colProcesses = objWMIService.ExecQuery _

("Select * from Win32_Process Where Name = 'EMCoreService.exe'")

If colProcesses.Count =0 Then

 Wscript.Echo "Aucune instance d'EMCoreService.exe n'est en cours d'exécution"

 Wscript.Quit 0

Else

 Wscript.Echo "EMCoreService.exe est en cours d'exécution"

 Wscript.Quit 1

End If

Des événements d'audit séparés sont créés pour les actions qui réussissent et celles qui échouent. Vous les affichez à l'aide du bouton Audit du ruban Gérer.

Sélectionnez le type de script requis (PowerShell, Visual Basic ou JavaScript) et entrez le script directement dans la boîte de dialogue. Vous pouvez également ajouter des scripts par copier-coller ou en importer avec le bouton Importer.

Vous pouvez appliquer les paramètres suivants, qui affectent le comportement de l'action :

  • Temporisation - Définissez un délai de temporisation pour l'achèvement du script. Si le délai s'écoule, l'action échoue. Le délai maximal pouvant être défini est de 60 secondes. Avec la valeur 0, il est infini. Les délais définis sous Actions personnalisées écrasent les paramètres de nœud par défaut.

    Il est recommandé de configurer une valeur de temporisation spécifique (30 secondes ou plus) pour les actions personnalisées et les conditions personnalisées. Si vous définissez la temporisation sur 0 (infini), cela peut provoquer un gel de la connexion/déconnexion si le script échoue.

    Pour en savoir plus, reportez-vous à « Configuration de nœuds » et à « Paramètres de délai par défaut ».

  • Interdire au script de s'exécuter en mode interactif - Cette option est sélectionnée par défaut. Les scripts s'exécutent sans popups nécessitant l'intervention de l'utilisateur.
  • Appliquer des variables d'environnement à la configuration - Si cette option est sélectionnée, toutes les variables d'environnement définies dans le script sont également définies dans le registre et dans le client EM, ce qui permet de les utiliser hors du script.
  • Insérer - Sélectionnez la variable de session à ajouter au script. La liste inclut les variables prédéfinies suivantes :
    • SessionID - ID de session actuel
    • UserSID - ID de sécurité (SID) de l'utilisateur
    • UserTemp - Emplacement du dossier Temp (temporaire) de l'utilisateur

Dans les déclencheurs Réseau disponible, Réseau connecté et Réseau déconnecté, vous pouvez ajouter d'autres variables de session prédéfinies au script pour déterminer les attributs de connexion.

Codes de sortie (exit)

Tous les scripts personnalisés doivent spécifier un code de sortie (exit) qui, lorsqu'il est renvoyé, permet à l'agent Environment Manager de déterminer si le script a réussi ou a échoué. Pour les scripts sans code de sortie, l'agent considère que l'opération est un succès (valeur 0).

Chaque type de script doit utiliser une instruction exit spécifique :

  • VBScript : WScript.Quit [valeur]
  • JScript : WScript.Quit([valeur])
  • PowerShell : exit ([valeur])

Remplacez [valeur] par le code de sortie du script : 0 pour un succès, 1 pour un échec. Par exemple : WScript.Quit 0, WScript.Quit(0), exit (0)

Scripts PowerShell

Les scripts Windows PowerShell utilisent diverses stratégies d'exécution qui peuvent empêcher l'exécution des scripts ou autoriser uniquement ceux qui sont signés par des éditeurs de confiance. Environment Manager passe outre aux stratégies d'exécution et contourne toutes les restrictions afin d'autoriser l'exécution des scripts PowerShell.

Vous pouvez également ajouter des stratégies d'exécution pour des utilisateurs ou des ordinateurs via une stratégie de groupe, qui écrase toutes les stratégies d'exécution PowerShell. Une stratégie Utilisateur qui interdit les scripts ou autorise uniquement ceux portant une signature n'affecte pas l'exécution des actions personnalisées PowerShell si vous l'exécutez en tant que Système. Cependant, si vous l'exécutez en tant qu'utilisateur actuel, la stratégie Utilisateur interdit les scripts et l'action personnalisée échoue. Une stratégie Ordinateur qui interdit les scripts ou autorise uniquement ceux portant une signature empêche l'exécution de toutes les actions personnalisées PowerShell.

Par conséquent, pour exécuter avec succès des actions personnalisées qui utilisent PowerShell, votre stratégie de groupe doit être configurée pour autoriser l'exécution de ces scripts pour les utilisateurs et les ordinateurs.

Environment Manager est compatible avec PowerShell 1.0, 2.0 et 3.0.

Action Exécuter

Ce type d'action exécute une application ou un processus lorsqu'elle se déclenche. Naviguez jusqu'à l'application à partir du champ Nom de fichier. Le système ajoute automatiquement le répertoire de travail quand vous sélectionnez l'application. Vous pouvez ajouter des paramètres à transmettre au programme.

Pour autoriser le processus à s'exécuter avec d'autres références d'authentification utilisateur, sélectionnez l'onglet Exécuter comme et choisissez l'utilisateur voulu.

Si vous avez coché la case Ne pas créer de fenêtre (applications basées sur la console), toutes les fenêtres de commande associées à une application ou à un processus sont masquées pour l'utilisateur.

Évitez d'inclure des actions Exécuter à la connexion dans des nœuds définis pour s'exécuter l'un après l'autre pour des fichiers nécessitant l'intervention de l'utilisateur pour fonctionner, comme les fichiers de programme. Sinon, le processus de connexion est suspendu indéfiniment, car le script de connexion attend que le script d'exécution s'achève. Par exemple, si l'action Exécuter lance notepad.exe, le script de connexion attend que le Bloc-notes prenne fin avant de continuer le processus de connexion.

Si vous ne sélectionnez pas l'option Ne pas exécuter les enfants de cette action jusqu'à ce que le processus se ferme, l'opération n'est pas suspendue car l'interaction de l'utilisateur est désactivée.

Rubriques connexes

Gestion des actions