Scripts dans Exchange Management Shell

 

Sapplique à :Exchange Server 2013

Pour la plupart des tâches générales, l’exécution de cmdlets l’une après l’autre ou ensemble à travers les pipelines suffit. Cependant, il peut arriver que vous deviez automatiser certaines tâches. L’environnement de ligne de commande Exchange Management Shell prend en charge un langage de script riche, basé sur Microsoft .NET Framework, qui ressemble au langage de script d’autres interfaces de commandes interactives. L’environnement de ligne de commande permet de créer des scripts, de simples à complexes. Les constructions de langage pour l’affectation de boucle, de condition, de contrôle de flux et de variable sont toutes prises en charge.

Chaque organisation a des tâches qui lui sont en quelque sorte propres. Avec une bibliothèque de fichiers de script pour exécuter ces tâches, vous pouvez économiser du temps en exécutant ces scripts sur tout ordinateur sur lequel l’environnement de ligne de commande Exchange Management Shell est installé.

Pour plus d’informations sur l’utilisation des scripts, consultez la page relative à la génération de scripts avec Windows PowerShell. Étant donné que l’environnement Shell s’appuie sur la technologie MicrosoftWindows PowerShell, les recommandations en matière de script applicables à Windows PowerShell s’appliquent à l’environnement de ligne de commande Exchange Management Shell.

Contenu de cette rubrique

Exécution d’un script dans l’environnement de ligne de commande Shell

Exécution d’un script à partir de Cmd.exe

Test de Scripts

Dépannage de scripts

Les utilisateurs habitués à utiliser l’environnement Cmd.exe savent comment exécuter des scripts d’interfaces de commande interactives. Il s’agit simplement de fichiers texte qui ont l’extension de nom de fichier .bat. Comme pour les fichiers de commandes, vous pouvez créer les fichiers de script de l’environnement de ligne de commande Exchange Management Shell en utilisant un éditeur de texte tel que le Bloc-notes. Vous pouvez aussi utiliser l’environnement d’écriture de scripts intégré (ISE) Windows PowerShell pour écrire des scripts. Windows PowerShell ISE offre une expérience riche en matière d’édition avec une prise en charge du débogage, des couleurs de syntaxe, une exécution sélective, etc. Les fichiers de script de l’environnement Shell utilisent l’extension de nom de fichier .ps1.

L’environnement de ligne de commande Exchange Management Shell utilise un répertoire racine pour les fichiers de script lors de leur appel. Par défaut, le répertoire racine est <lecteur racine>:\Program Files\Microsoft\Exchange Server\V15\bin. Vous pouvez aussi vérifier que le répertoire PSHome actuel d’un ordinateur quelconque exécute l’environnement de ligne de commande Exchange Management Shell en exécutant $PSHome depuis une invite de commandes. Les deux répertoires se trouvent dans la variable de l’environnement PATH.

Si un fichier de script est enregistré dans le répertoire racine, vous pouvez l’appeler en utilisant le nom du script. Si le fichier de script se trouve dans un endroit autre que l’emplacement actuel, vous devez utiliser le chemin d’accès et le nom du script. Si le fichier de script se trouve dans l’emplacement actuel, le nom du script doit avoir pour préfixe les caractères point barre oblique inverse (.\).

Ces exemples montrent les caractéristiques de syntaxe de commande requises pour appeler trois scripts différents. Ces exemples utilisent tous la cmdlet Get-Date, à partir de trois emplacements différents.

[PS] C:\>Get-Date-Script-A.ps1
Friday, January 20, 2006 3:13:01 PM

Le fichier de script Get-Date-Script-A.ps1 se trouve dans le répertoire spécifié par $PSHhome et ne requiert que le nom du script à exécuter.

[PS] C:\>c:\workingfolder\Get-Date-Script-B.ps1
Friday, January 20, 2006 3:13:25 PM

Le fichier de script Get-Date-Script-B.ps1 se trouve dans le répertoire C:\dossierdetravail, de sorte que vous devez fournir le chemin d’accès complet pour exécution.

[PS] C:\>.\Get-Date-Script-C.ps1
Friday, January 20, 2006 3:13:40 PM

Le fichier de script Get-Date-script-C.ps1 se trouve dans l’emplacement actuel, C:\. C’est pourquoi, le préfixe .\ est nécessaire à son exécution.

[PS] C:\>Get-Date-Script-C.ps1
The term 'Get-Date-Script-C.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling
of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:22
+ Get-Date-Script-C.ps1 <<<<
    + CategoryInfo          : ObjectNotFound: (Get-Date-Script-C.ps1:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Dans le dernier exemple, lorsque le même script, Get-Date-Script-C.ps1, est appelé sans le préfixe .\, les résultats attendus sont affichés.

La meilleure pratique consiste à toujours attribuer aux fichiers de script un nom descriptif et inclure des commentaires dans le script afin de décrire son but et d’identifier chaque point d’intérêt. Certaines informations concernant l’auteur doivent également être incluses au cas où quelqu’un exécutant le script se poserait des questions sur son utilisation. Utilisez le symbole dièse (#) au début des lignes de commentaire à l’intérieur du corps d’un script.

Pour qu’un script soit exécuté de façon planifiée par le service Windows Task Scheduler, vous pouvez appeler l’environnement Shell et inclure le script à exécuter comme paramètre. Pour utiliser des cmdlets Exchange avec votre script, vous devez faire en sorte que Windows PowerShell se connecte à un serveur qui exécute Exchange et charge les cmdlets Exchange auxquels vous avez accès. Le raccourci que vous utilisez pour ouvrir l’environnement de ligne de commande Exchange Management Shell effectue cela automatiquement. Pour réaliser cette action lorsque vous désirez exécuter un script contenant des cmdlets Exchange, vous devez ordonner à Windows PowerShell d’exécuter les scripts établissant cette connexion. Cette syntaxe est requise pour ouvrir Windows PowerShell, vous connecter à un serveur Exchange et exécuter votre script depuis la commande Cmd.exe.

PowerShell.exe -command ". 'D:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; <path to your script>"

Cet exemple montre comment exécuter le script RetrieveMailboxes.ps1 à partir de C:\My Scripts.

PowerShell.exe -command ". 'D:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\My Scripts\RetrieveMailboxes.ps1"

Pour accéder à des options supplémentaires à utiliser lorsque vous appelez l’environnement de ligne de commande Exchange Management Shell depuis l’environnement Cmd.exe, tapez PowerShell.exe /?

Lorsque vous créez des scripts, vous devez toujours les tester dans un environnement de test avant de les appliquer dans votre environnement de production. Lorsque vous testez vos scripts dans votre environnement de test et lorsque vous les déployez dans votre environnement de production, vous pouvez utiliser le paramètre WhatIf disponible dans de nombreuses cmdlets incluses dans l’environnement de ligne de commande Exchange Management Shell pour vérifier que votre script s’exécute comme prévu. Le paramètre WhatIf donne pour instruction à la commande à laquelle il est appliqué d’exécuter, mais également d’afficher les objets qui seront affectés par l’exécution de la commande et les modifications qui seront apportées à ces objets, sans réellement en modifier aucun.

Pour plus d’informations sur le paramètre WhatIf, consultez la rubrique Commutateurs WhatIf, Confirm et ValidateOnly.

Les scripts risquent de ne pas fonctionner comme prévu pour de nombreuses raisons. Il peut être difficile de déterminer à quel niveau se situe le problème et ce qui fonctionne mal. L’environnement de ligne de commande Exchange Management Shell peut vous aider à localiser des erreurs de syntaxe générales en reportant la ligne et le caractère au point de défaillance. Lorsque la syntaxe d’un script est correcte mais que son comportement est inattendu, il peut être beaucoup plus difficile de diagnostiquer le problème. L’environnement de ligne de commande Exchange Management Shell inclut une fonctionnalité de débogage pour dépanner les fichiers de script par l’analyse de chaque étape exécute par le script pendant son exécution. Cette fonctionnalité est appelée suivi.

Pour activer le suivi et analyser chaque étape de commande dans un script, utilisez la cmdlet Set-PSDebug avec le paramètre Trace défini sur une valeur de 1. Pour analyser chaque étape et chaque attribution de variable telles qu’elles sont faites, définissez le paramètre Trace sur la valeur 2. Pour désactiver le suivi, définissez la valeur du paramètre Trace sur 0 (zéro).

Pour analyser les commandes d’un script ligne par ligne, utilisez la cmdlet Set-PSDebug avec le paramètre Step. À chaque étape, vous être invité à continuer l’opération. Les choix disponibles en mode d’étape sont les suivants.

[Y] Yes (continue to the next step)
[A] Yes to All (continue to the end of the script)
[N] No (stop this step)
[L] No to All (stop all remaining steps)
[S] Suspend (suspend at this point and drop to a prompt)

Suspend permet de quitter le programme pour accéder à une invite dans laquelle vous pouvez exécuter toute commande, par exemple, pour vérifier ou définir des valeurs sur un objet que le script y accède. Lorsque vous êtes prêt à reprendre l’exécution du script, tapez Exit et contrôlez immédiatement les retours au point auquel le script s’est arrêté.

 
Afficher: