Résolution d’incidents de production

ExchangeServer » qui récupère l’ensemble des serveurs Exchange 2007 de notre organisation et « Test- ServiceHealth » qui affiche l’état de nos services sur ces serveurs. Bref, d’un coup d’oeil nous pouvons savoir quel service sur quel serveur n’est pas démarré ! Mais il y a beaucoup mieux… L’une des Cmdlets les plus utiles est « Test-SystemHealth » : la version PowerShell de ExBPA.

Lorsque cette Cmdlet est utilisée, elle essaye de chercher la dernière version des tests sur Internet. Voici quelques paramètres pour vous donner une petite idée de la puissance de cette Cmdlet : voir tableau 1. Un exemple de la sortie de cette Cmdlet dans la figure 2. Bien sûr, nous pouvons tester certaines fonctionnalités de notre organisation comme par exemple l’antispam.

Pour cela, nous n’avons pas moins de trois Cmdlets : 1. « Test-IPAllowListPro vider » : Permet de tester si une adresse IP est déclarée comme source de spam ou non. 2. « Test-IPBlockListProvi der » : Détermine si une adresse IP est dans une liste d’adresse refusée par l’organisation. 3. « Test-SenderID » : Cette Cmdlet est un peu spéciale puisqu’elle permet de tester la bonne configuration d’une organisation et de savoir ainsi si le courrier envoyé part dans le répertoire spam d’une boîte aux lettres ! Chaque rôle serveur va pouvoir ainsi être testé.

Le rôle CAS n’est pas épargné ; nous pouvons faire des tests grâce aux Cmdlets dont les noms sont très explicites : – « Test-OutlookWebServices » : Test l’Autodiscover. Autrement dit, il est indispensable – « Test-ActiveSyncConnectivity » : Tester la synchronisation en utilisant ActiveSync n’a jamais été aussi simple… – « Test-OwaConnectivity »: De même pour l’accès Web… – « Test-WebServicesConnectivity » : et les Web Services ! Concernant le rôle Mailbox, nous avons trois Cmdlets capables de nous donner des informations pertinentes : – « Test-MAPIConnectivity » : Permet de tester l’accès aux groupes de stockage et aux bases de données. – « Test-MailFlow » : Teste l’envoi de mail dans notre forêt ou bien avec l’extérieur. « Test-ExchangeSearch » : Ce test insère un message dans une boîte aux lettres, attend que l’index soit mis à jour et recherche l’index du message inséré. Côté Edge, nous pouvons tester la synchronisation avec la Cmdlet « Test-EdgeSynchronization » et côté messagerie unifiée nous pouvons utiliser « Test-UMConnectivity ».

Il est également possible de trouver des informations sur les éventuels problèmes dans les journaux d’évènements. C’est pourquoi « Get-EventLog » existe (Figure 3) ! Nous pouvons ainsi filtrer, faire des recherches dans les journaux d’évènements en chaînant cette Cmdlet avec « Where », mais ça, vous le savez déjà ! 🙂 C’est très bien de pouvoir s’assurer que nos serveurs Exchange fonctionnent correctement et qu’ils soient performants… mais l’envoi des messages électroniques est le plus important pour un serveur de messagerie !

Comment fait-on pour vérifier s’il y a des messages dans la queue ? Un seul mot en guise de réponse : « Get-Message » ! D’accord comment vérifier qu’un message a été envoyé à une certaine heure ? Serait-ce la limite d’Exchan ge Management Shell… ? Et bien non, nous avons « Get- MessageTrackingLog » ! Voir Figure 4.

Comme vous avez pu le constater, les moyens ne manquent pas pour localiser la source des problèmes ! Exchange 2007 propose également de modifier le niveau d’information à écrire dans les journaux. La Cmdlet « Set-Event LogLevel » permet de configurer ce niveau. Voir Figure 5. Il existe cinq niveaux : Lowest, Low, Medium, High et Expert. Nous pouvons maintenant attendre de pied ferme les prochains incidents qui pourraient survenir… Même si nous serions plus tranquille sans !