Exchange Server 2007

Prendre le commandement avec Exchange Management Shell

David Strome

Vue d'ensemble:

• Fonctionnement d'Exchange Management Shell
• Utilisation des cmdlets
• Cmdlets vs. commandes

Si vous administrez un environnement Exchange, je suis sûre que vous savez maintenant que le nouveau Exchange Server 2007 inclut une nouvelle interface à ligne de commande appelée Exchange Management Shell. Construite sur la technologie Microsoft Windows PowerShell, Exchange

Management Shell est une interface de gestion puissante que vous pouvez utiliser pour gérer tous les aspects d'Exchange Server 2007 depuis la ligne de commande. À partir de là, vous pouvez interagir directement avec Exchange Management Shell, écrire des scripts pour l'automatisation ou intégrer vos applications avec le moteur sous-jacent. La Figure 1 montre l'interpréteur de commandes en action.

Figure 1** Exchange Management Shell **(Cliquer sur l'image pour l'agrandir)

La console de gestion Exchange ne se contente pas d'utiliser Exchange Management Shell pour effectuer des opérations, les assistants vous montrent quelles sont les commandes qu'ils effectuent. Copiez les commandes que les assistants créent et collez-les directement dans la ligne de commande ou dans un script. Après avoir modifié les paramètres à votre convenance, testez vos scripts ou vos commandes en utilisant le paramètre WhatIf, ce qui vous permet de voir les résultats avant d'effectuer des modifications de votre environnement.

Exchange Management Shell vous fournit une plate-forme de script solide et souple pour intégrer vos solutions de script courantes et vous permet de communiquer en mode natif avec des sources de données telles que COM et Windows Management Instrumentation (WMI). Basée sur .NET Framework, Exchange Management Shell utilise des cmdlets - la plus petite unité de fonctionnalité dans Exchange Management Shell - pour accepter et renvoyer des données structurées au lieu du texte brut. Nous allons nous intéresser de plus près aux cmdlets d'ici peu.

Composant logiciel enfichable Windows PowerShell

La première étape pour comprendre Exchange Management Shell est d'observer la relation qui la lie à Windows PowerShell™, une interface à ligne de commande toute nouvelle, puissante et souple basée sur .NET Framework. Elle associe les meilleures fonctionnalités de plusieurs autres interpréteurs de commandes et en ajoute également un grand nombre de nouvelles. Windows PowerShell est conçu pour héberger d'autres applications, un peu comme Microsoft Management Console (MMC) agit en tant qu'hôte pour les divers composants logiciels enfichables fournis avec les applications. Exchange Management Shell est le premier composant logiciel enfichable Windows PowerShell a être publié.

Les composants logiciels enfichables sont des collections de cmdlets utilisées pour administrer une application ou un composant majeur. Si vous ne les chargez pas en premier, vous ne pouvez pas les utiliser. Heureusement, il est très facile de démarrer le composant logiciel enfichable Exchange Management Shell. Mais avant d'en arriver là, il faut que je vous explique quelques concepts essentiels que vous aurez besoin de comprendre lors de la lecture de cet article et de l'utilisation d'Exchange Management Shell.

Cmdlets Les cmdlets ressemblent aux commandes intégrées d'autres interpréteurs de commandes, comme par exemple la commande dir que l'on trouve dans cmd.exe. Comme ces commandes d'usage courant, les cmdlets peuvent être appelées directement depuis la ligne de commande dans Exchange Management Shell et s'exécuter dans le contexte de l'interpréteur de commandes et non pas en tant que processus séparé. Contrairement aux commandes d'autres interpréteurs, les cmdlets ont des appellations verbe-nom descriptives. Le verbe décrit l'action que fait la cmdlet et le nom décrit le composant ou la fonction sur lequel ou laquelle on agit.

Vous n'avez pas à deviner que ce fait la cmdlet. Lorsque vous voyez la cmdlet Move-Mailbox, vous savez exactement ce pourquoi elle est utilisée.

Pour voir la différence entre les cmdlets et les commandes ordinaires, veuillez vous reporter à la barre latérale « Cmdlets vs. Commandes » extraite de la section .NET Framework 3.0 de Windows® SDK, qui se trouve sur windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx.

Paramètre Identité (Paramètre de Positionnement) Le paramètre Identité peut être utilisé avec la plupart des cmdlets associées à Exchange. Il vous permet d'accéder aux identificateurs uniques qui se réfèrent à un objet particulier dans Exchange Server 2007 afin que vous puissiez effectuer des actions sur un objet Exchange spécifique en utilisant la valeur unique la plus significative pour vous.

Le paramètre Identité est une collection de valeurs d'autres paramètres. Le caractère unique de ces valeurs est garanti dans cet ensemble d'objets. Vous pouvez spécifier les valeurs de ces autres paramètres, telles que Nom et DistinguishedName, qui peuvent également être générées par le système, tel qu'un GUID. Les paramètres supplémentaires utilisés, s'il y en a et la manière dont ils sont alimentés, dépendent de l'objet auquel vous vous référez.

Le paramètre Identité est également considéré comme un paramètre de positionnement - c'est-à-dire un paramètre qui vous permet de spécifier sa valeur sans spécifier son nom. Un paramètre est dit de positionnement si l'attribut Paramètre de positionnement est un nombre entier. Ce nombre entier indique la position de la ligne de commande où la cmdlet peut trouver la valeur du paramètre. Parce qu'Identité est un paramètre de positionnement qui réside à la position 0 qui est la première position, n'importe quelle valeur entrée à cette position sans un nom de paramètre est considérée comme étant une valeur de paramètre Identity. Cela réduit le nombre de frappes de touche lorsque vous tapez des commandes. Par exemple :

Get-Mailbox –Identity "Kim Akers" 

effectue la même action que :

Get-Mailbox "Kim Akers"

Traitement « pipeline » Le traitement « pipeline » dans Exchange Management Shell correspond à l'action d'une cmdlet utilisant la sortie d'une autre cmdlet lorsqu'elle effectue une opération. Le traitement « pipeline » s'effectue en utilisant le symbole « | ». Tous les verbes dans le même ensemble nom-cmdlet peuvent utiliser des informations transmises en provenance d'une autre commande. Certains ensembles nom-cmdlet vous permettent également de transmettre des données par le pipeline à un autre ensemble nom-cmdlet.

L'utilisation du traitement par pipeline pour chaîner ensemble les actions de deux cmdlets ou plus vous permet de choisir des composants plus petits et de les convertir en éléments plus puissants. Par exemple, vous pouvez utiliser une cmdlet pour rassembler des données, transmettre ces données à une deuxième cmdlet pour filtrer les données vers un sous-ensemble, puis transmettre ces données à une troisième cmdlet pour agir sur le sous-ensemble seulement.

Démarrer Exchange Management Shell

La manière la plus simple de charger un interpréteur de commandes est de cliquer sur Démarrer, de cliquer sur Programmes, puis sur Microsoft Exchange Server 2007 et enfin de cliquer sur Exchange Management Shell.

La deuxième manière de charger le composant logiciel enfichable Exchange Management Shell est de le faire manuellement depuis une session Windows PowerShell. Cliquez sur Démarrer, puis sur Programmes et enfin sur Windows PowerShell. Après le démarrage, exécutez la commande suivante pour charger Exchange Management Shell:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

Il existe quelques différences entre le chargement du composant logiciel enfichable Exchange Management Shell à l'aide de l'entrée de menu Programmes et son démarrage manuel à l'aide de la tcmdlet Add-PSSnapin. Lorsque vous utilisez l'entrée de menu Programmes, cela charge non seulement le composant logiciel enfichable Exchange Management Shell mais exécute également un script Windows PowerShell pour configurer un environnement d'administration Exchange personnalisé. Si vous voulez configurer un environnement administratif similaire après avoir chargé Exchange Management Shell manuellement, allez dans votre répertoire \bin Exchange de votre installation - par exemple, C:\Program Files\Microsoft\Exchange Server\Bin. Puis exécutez la commande suivante :

.\Exchange.ps1

Examinez le script Exchange.ps1 pour voir comment personnaliser l'environnement Windows PowerShell et l'adapter à vos besoins. Lorsque vous chargerez Exchange Management Shell, vous verrez quelque chose qui ressemble à la Figure 2.

Figure 2** Bannière de Bienvenue d'Exchange Management Shell **(Cliquer sur l'image pour l'agrandir)

Par où dois-je commencer ?

Le tableau de cmdlets de l'interpréteur de commandes étant si étendu, la cmdlet Get-Help et le fichier d'aide Exchange Server 2007 seront des aides précieuses. La section Opérations dans le fichier d'aide Exchange Server 2007 vous procure des dizaines de modes opératoires pour effectuer la plupart des tâches administratives.

Le fait de taper Get-Help seul affiche des informations d'aide générale sur la manière d'obtenir de l'aide. Pour obtenir de l'aide sur une cmdlet spécifique, tapez Get-Help suivi de la cmdlet sur laquelle vous voulez des informations. Vous pouvez contrôler quelles sont les informations exposées en utilisant les paramètres Détail, Tout et Exemple. Il vous suffit de les ajouter à la fin de la commande. Par exemple, le nom de cmdlet Get-Help (– Tout) renvoie la totalité des sections d'aide disponibles pour une cmdlet.

Si vous voulez récupérer des informations concernant un ou plusieurs paramètres spécifiques sur une cmdlet, vous pouvez utiliser le paramètre Paramètres avec Get-Help. Ainsi, si vous voulez visualiser tous les paramètres et leur description sur la cmdlet Set-Mailbox qui contient le mot « quota », utilisez la commande :

Get-Help Set-Mailbox –Parameter *quota*

Il se peut que vous vouliez visualiser une liste de cmdlets qui gère un rôle de serveur spécifique ou une fonctionnalité de composant ou qui affecte les objets sur un certaine gamme de fonctionnalités. La cmdlet Get-Help vous permet de faire ça avec trois paramètres. Rôle, Composant et Fonctionnalité. Lorsque vous utilisez la cmdlet Get-Help avec ces paramètres, vous devez inclure les valeurs que vous spécifiez avec ces trois paramètres dans des caractères génériques « * ». Ci-dessous des exemples qui montrent comment appeler Get-Help avec chaque paramètre.

Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*

Pour plus d'informations, le sujet « Getting Help » dans le fichier d'aide Exchange Server 2007 répertorie toutes les valeurs de rôle, de composant et de fonctionnalité qui peuvent être utilisées.

Formater la sortie de commande

Par défaut, lorsque la sortie est affichée à l'écran, Exchange Management Shell affiche uniquement un sous-ensemble des propriétés disponibles pour chaque objet. Cependant, vous pouvez facilement accéder à toutes les propriétés en transférant la sortie d'une commande aux trois cmdlets de formatage suivantes : Format-List, Format-Table et Format-Wide. Vous utiliserez probablement Format-List et Format-Table de manière régulière, je vais donc vous en parler plus en détail.

La cmdlet Format-List accepte une entrée du pipeline et génère en sortie une liste en colonnes verticales de toutes les propriétés spécifiées de chaque objet. Vous pouvez spécifier les propriétés que vous voulez afficher en utilisant le paramètre Propriété (bien que le paramètre Propriété soit un paramètre de positionnement, ce qui signifie que vous n'avez à spécifier que les valeurs et non le nom du paramètre). Si la cmdlet Format-List est appelée sans aucun paramètre spécifié, toutes les propriétés sont générées en sortie. Cette cmdlet encapsule les lignes au lieu de les tronquer. L'une des meilleures utilisations de Format-List est de remplacer la sortie par défaut d'une cmdlet afin de pouvoir récupérer des informations supplémentaires ou mieux ciblées. Par exemple :

Get-DistributionGroup | Format-List Name, *OnlyFrom, 
PrimarySmtpAddress, *Size*

La figure 3 illustre la sortie de cette commande.

Figure 3** Exemple de sortie Format-List **(Cliquer sur l'image pour l'agrandir)

La cmdlet Format-Table vous permet d'afficher des éléments dans un format de tableau avec des en-têtes et des colonnes de données de propriété. Par défaut, de nombreuses cmdlets, telles que Get-Mailbox et Get-JournalRule, utilisent le format de tableau en sortie. Les paramètres de la cmdlet Format-Table incluent les paramètres Propriétés et Grouper par. Ceux-ci fonctionnent exactement comme avec la cmdlet Format-List. Pour que de longues lignes d'informations de propriétés s'affichent complètement au lieu d'être tronquées en fin de ligne, utilisez le paramètre Encapsuler, comme suit :

Get-Mailbox –Database Research | Format-Table Name, 
ProhibitSendQuota, Database –Wrap 

Voir la Figure 4 pour visualiser la sortie

Figure 4** Exemple de sortie Format-Table **(Cliquer sur l'image pour l'agrandir)

Si vous incluez un caractère générique, vous pouvez faire correspondre plusieurs propriétés sans avoir à taper chaque nom de propriété individuellement. Par exemple, cela renvoie toutes les propriétés qui commencent par une adresse électronique.

Get-Mailbox | Format-List Email* 

Mise en pratique

Maintenant que vous avez acquis quelques commandes de base, pourquoi ne pas mettre en pratique les exemples suivants. Ils illustreront la puissance et la souplesse d'Exchange Management Shell et vous feront mettre la main à la pâte.

La première commande que vous allez essayer, crée 10 utilisateurs, appelés Utilisateur1 jusqu'à Utilisateur10 :

1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD 
/Domain; Enable-Mailbox "User$_" -Database "Mailbox 
Database" }

Examinons ses différentes parties. La commande 1.0 génère les nombres entiers de 1 à 10 et les transmet par le pipeline à chaque cmdlet ForEach. La cmdlet ForEach agit sur chaque objet à sa réception et exécute les commandes entre accolades { } pour chaque objet. La commande Net User crée un nouvel utilisateur de domaine et la cmdlet Enable-Mailbox crée une nouvelle boîte aux lettres dans la « Base de données de boîte aux lettres » sur le serveur local. Le point-virgule sépare les deux commandes afin qu'elles puissent être placées sur la même ligne de commande. La variable $_ est une variable spéciale qui contient la valeur de l'objet qui se trouve dans le pipeline. Dans cet exemple, la variable $_ contient le nombre entier qui se trouve dans le pipeline.

L'exemple suivant vous permettra de visualiser les boîtes aux lettres qui résident sur le serveur MBX et de renvoyer le Nom, la base de données de boîte aux lettres et les propriétés de quota de chaque boîte aux lettres.

Get-Mailbox –Server MBX | Format-Table 
Name,Database,*quota*

La cmdlet Get-Mailbox renvoie chaque boîte aux lettres spécifiée avec le paramètre Serveur, puis transfère la sortie de chaque objet de boîte aux lettres à la cmdlet Format-Table. Par défaut, la cmdlet Format-Table affiche toutes les propriétés renvoyées par une cmdlet à moins que vous ne spécifiiez les propriétés à afficher. Ici seules les propriétés Nom et Base de données, comme toutes les propriétés qui contiennent la chaîne « quota » sont requises. La Figure 5 montre à quoi pourrait ressembler cette sortie.

Figure 5** Sortie de commande Get-Mailbox **(Cliquer sur l'image pour l'agrandir)

Dans cet exemple, vous définirez la limite de quota d'envoi à 600 Mo pour tous les utilisateurs pouvant utiliser la messagerie dans l'organisation, qui ont le terme de « Manager » (Responsable) dans leur titre.

Get-User –Filter { Title –Like "*Manager*"} 
–RecipientTypeDetails UserMailbox | Set-Mailbox 
–ProhibitSendQuota 600MB

Auto-exécutée, la cmdlet Get-User renvoie tous les objets utilisateurs de Active Directory, y compris les utilisateurs non autorisés à utiliser la messagerie électronique. Afin de récupérer un ensemble d'objets utilisateurs que la cmdlet Set-Mailbox peut utiliser, il vous faut donner l'instruction à la cmdlet Get-User de ne renvoyer que les objets utilisateurs Active Directory qui sont des utilisateurs autorisés à utiliser la messagerie. Le paramètre RecipientTypeDetails vous permet de spécifier le type de destinataire Active Directory, UserMailbox dans le cas présent. Ensuite, il vous faut récupérer un ensemble d'utilisateurs autorisés à utiliser la messagerie qui sont des managers. Dans le présent exemple, la propriété Title de chaque objet utilisateur Active Directory est renseignée. Vous pouvez utiliser cette valeur pour déterminer les utilisateurs qui sont des managers à l'aide du paramètre Filter qui donne l'instruction au serveur de ne renvoyer que les objets Active Directory correspondant à vos critères. Cette opération s'appelle le filtrage côté serveur. Une fois que vous avez défini un ensemble d'objets, celui-ci est transmis à la cmdlet Set-Mailbox, qui définit alors la propriété ProhibitSendQuota de chaque boîte aux lettres à 600 Mo.

Nous testerons ensuite le résultat d'une commande de suppression de toutes les boîtes aux lettres qui sont membres d'un groupe de distribution. Voici la commande :

Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf

La première cmdlet récupère les objets destinataires qui sont membres du groupe de distribution « Fourth Year Students ». Puis seuls les objets destinataires correspondant au RecipientType de « UserMailbox » sont transmis à la cmdlet Remove-Mailbox. Au lieu de supprimer les boîtes aux lettres, la cmdlet Remove-Mailbox affichera l'action qu'elle aurait effectuée et les objets sur lesquels elle aurait agi. La cmdlet Get-DistributionGroupMember récupère une liste de tous les objets destinataires qui sont membres du groupe de distribution « Fourth Year Students ». Cependant, comme la cmdlet peut uniquement fonctionner avec des utilisateurs autorisés à utiliser la messagerie, il vous faut exclure tous les types de destinataires sauf « UserMailbox ». Contrairement à d'autres cmdlets, la cmdlet Get-DistributionGroupMember n'a pas la cmdlet Filter, ce qui signifie qu'elle ne peut pas effectuer le filtrage côté serveur. Pour les cmdlets qui ne peuvent pas effectuer un filtrage côté serveur (parce qu'elles n'y voient aucun avantage en termes de performance), vous pouvez utiliser la cmdlet Where pour effectuer le filtrage côté client, ce qui récupère tous les objets et effectue le filtrage sur la machine cliente locale. La cmdlet Where ne transmet que les objets qui répondent aux critères que vous spécifiez. Les objets qui ont un RecipientType de « UserMailbox » sont envoyés à la cmdlet Remove-Mailbox. Cette cmdlet supprime l'objet utilisateur Active Directory et marque la boîte aux lettres pour élimination.. Lorsque le paramètre WhatIf est utilisé, la cmdlet Remove-Mailbox affiche un texte similaire à ce qui suit :

What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark 
the mailbox in the database for removal.

Si vous êtes persuadé que la commande va effectuer les actions que vous voulez, exécutez la commande à nouveau sans WhatIf. Pour certaines cmdlets, telles que celles qui comportent le verbe Remove, l'interpréteur de commandes demandera automatiquement confirmation avant toute modification. Vous avez le choix d'examiner chaque modification, d'indiquer à l'interpréteur de commandes de ne pas demander confirmation une nouvelle fois ou d'annuler tout traitement ultérieur. Pour les cmdlets qui n'implémentent pas de confirmation automatiquement, vous pouvez forcer la confirmation en utilisant le paramètre Confirm.

Conclusion

Maintenant que vous avez eu un avant-goût de la cmdlet, vous êtes prêt à faire vos expériences par vous-même et à constater à quel point Exchange Management Shell et Microsoft Windows PowerShell vous seront utiles pour vos futures tâches de gestion systèmes. Pour plus d'informations sur ces deux sujets, consultez les ressources suivantes. Concernant Management Shell, veuillez vous reporter au fichier d'aide d'Exchange Server 2007 sur go.microsoft.com/fwlink/?LinkId=69434, au centre de script Windows Powershell sur go.microsoft.com/fwlink/?LinkId=71134 et au blog de l'équipe Exchange sur msexchangeteam.com.

David Strome est rédacteur technique auprès du groupe Exchange User Education chez Microsoft depuis à peine plus d'un an. Avant de rejoindre Microsoft à Redmond dans l'État de Washington, David a passé une dizaine d'années à concevoir, implémenter et administrer des installations Exchange Server dans diverses entreprises basées en Colombie britannique, au Canada.. Vous pouvez le contacter à l'adresse suivante : technet@getwired.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.