PI Services

Le blog des collaborateurs de PI Services

Interaction Powershell - Exchange Web Services

4. septembre 2013 Florian-ALIKOFF PowerShell, Exchange 2010, Exchange 2013, Messagerie (0)

Introduction

Avec Exchange 2010, pour certains besoins bien spécifiques, il se peut que les cmdlets Powershell soit limitées. Cependant, il existe aussi les Exchanges Web Services. Bien entendu, quand on parle des Exchange Web Services, on pense au C# et à un développement complexe. Cependant, on n'oublie souvent que Powershell permet d'exécuter du C#.
Il sera donc question d'accéder aux EWS via Powershell. Il s'agit surtout d'une introduction car les possibilités de scripting sont infinies. L'exemple mis en œuvre dans cet article montrera comment accéder à un dossier bien spécifique pour le purger suivant les dates de réception des emails. Cela permettra entre autres de voir le langage AQS permettant la recherche d'objets dans une boîte aux lettres Exchange.

Prérequis

Avant toute chose, pour manipuler l'API Exchange Web Services, il est nécessaire d'installer le package correspondant sur le poste qui exécutera le script. Il est trouvable en suivant ce lien : http://www.microsoft.com/en-us/download/details.aspx?id=28952

Attention si vous utilisez, Exchange 2013, il faut prendre cette version :
http://www.microsoft.com/en-us/download/details.aspx?id=35371

Il sera ensuite nécessaire d'ajouter dans chacun des scripts qui sera réalisé la dll permettant d'interagir avec les Web Services. Pour rappel, cela se réalise via la commande Powershell Add-Type :

001
002
003
Add-Type -path "C:\Program Files\Microsoft\Exchange\Web Services\1.2\Microsoft.Exchange.WebServices.dll"


AQS ou Advanced Query Syntax:

Le langage AQS permet de réaliser des recherches dans les objets d'une boîte aux lettres Exchange. Il est très simple à prendre en main.

Pour comprendre toutes les possibilités de ce langage voici le lien MSDN dédié :
http://msdn.microsoft.com/en-us/library/ee693615.aspx

Grâce à ce langage il va être possible de rechercher des éléments :
- par type (emails, réunions, notes, contacts, ...)
- par date (réception ou envoi)
- par propriété d'un email (champ from, to, cc, subject, body, ...)

L'exemple suivant permet de rechercher des emails ayant été reçu le 3 Septembre 2013 :
"Kind:email AND Received:03/09/2013"

On remarque l'opérateur AND qui permet de prendre en compte 2 propositions. Il en existe d'autres comme le OU (l'une ou l'autre des propositions) et le NOT (l'inverse d'une proposition).

Script commenté

Il s'agit ici d'un script où l'utilisateur se connecte à une boîte aux lettres sur laquelle il possède des droits et dont les messages du dossier nommé Personnel seront supprimées s'ils datent de plus de 30 jours. Aussi, pour chaque dossier, il affiche la taille de celui-ci en Ko. Cette dernière opération est aussi faisable via la commande EMS Get-MailboxFolderStatistics mais avec cette exemple nous n'aurons pas besoin d'installer ces outils mais seulement l'API EWS beaucoup plus légère.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
#Mailbox à traiter
$MailboxName = 'j.dupont@myenterprise.fr'

# A installer avant : www.microsoft.com/en-us/download/details.aspx?id=28952
try{
    Add-Type -path "C:\Program Files\Microsoft\Exchange\Web Services\1.2\Microsoft.Exchange.WebServices.dll"
}catch{

}

#On spécifie la version des web services
$Version = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($version)

#On utilise les credentials avec lesquels on est connecté
$Service.UseDefaultCredentials = $true

#On récupère la configuration Autodiscover pour se connecter à la BAL
$Service.AutodiscoverUrl($MailboxName,{$true})

#On récupère l'ID du dossier
$RootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)

#On se connecte au dossier via la connexion que l'on a initialisé
$RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service,$RootFolderID)

#On limite le nombre de dossier à analyser à 1000 (sinon problème de throttling)
$FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)

#On définit un ensemble de propriété à récupérer en même temps que nos dossiers
$PropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
#On crée une propriété de type taille de dossier
$SizeObject = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(3592,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long)
#On l'ajouter à notre vue de dossier afin que la taille soit aussi récupérée.
$PropertySet.Add($SizeObject); 
$FolderView.PropertySet = $PropertySet;

#On spécifie qu'on analyse l'intégralité de la hiérarchie
$FolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep

#On calcule la date d'il y a 30 jours et on la met au format dd/MM/yyyy
$DateOld = ((Get-Date).AddDays(-30)).ToString("dd/MM/yyyy")

#On récupère tous les dossiers
$Response = $RootFolder.FindFolders($FolderView)
#Pour chaque dossier
ForEach ($Folder in $Response.Folders) {
   
    $FolderSize = $null
    #Si la taille est disponible alors on l'export dans la variable $FolderSize
    if($Folder.TryGetProperty($SizeObject,[ref] $FolderSize)){
        $FolderSizeValue = ([Int64]$FolderSize)/1000 
        #On affiche la taille du dossier
        $Message = "Le dossier " + $Folder.DisplayName + " a une taille de $FolderSizeValue Ko"
        Write-Host $Message
    }else{
        $Message = "Taille du dossier " + $Folder.DisplayName +" introuvable."
        Write-host $Message
    }

    #On compare le display name avec la valeur recherchée
    if($Folder.DisplayName -eq "Personnel"){
        #Si le dossier est bien Personnel alors on récupère tous les mails selon les critères de date définies
        $Items = $Folder.FindItems("Kind:email AND Received:<$DateOld",$ItemView) 
        #Pour chaque email trouvée
        ForEach($Item in $Items){
            #On le supprime définitivement (à décommenter pour que ce soit effectif)
            #$Item.Delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete)
        }
    }
}

 

On remarque l’opérateur “<” (inférieur à) dans la requête AQS qui permet de spécifier tout ce qui se trouve avant cette date.

On peut accéder aux dossiers publics, modifier, supprimer, créer, tout type d'objet y compris des dossiers. Il est aussi possible de récupérer différentes informations comme la taille d'un dossier. Il est aussi possible d'analyser les pièces jointes pour supprimer celle dont l'extension est d'un certain type. Il est donc possible d'imaginer plein de scripts comme des tâches planifiées effectuant des traitement sur des boîtes aux lettres.

Exchange 2010 SP2 – Erreur MapiExceptionNetworkError lors du déplacement des boîtes aux lettres

18. janvier 2013 Matthieu-MARTINEAU Messagerie (0)

Symptôme

Dans le cadre d’une migration depuis une plateforme Exchange Server 2007 SP3 vers une plateforme Exchange 2010 SP2 RU5v2, l’erreur MapiExceptionNetworkError apparaît de manière régulière dans les logs des requêtes de déplacement de boîtes aux lettres (MoveRequests).

Voici un exemple :

18/01/2013 19:03:15 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:13:54 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:19:31 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:25:48 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:36:51 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:42:58 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:53:52 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:00:00 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:11:11 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:17:22 [SRV] Transient error MapiExceptionNetworkError has occurred

Le code d’erreur détaillé est le suivant :

Error details: MapiExceptionNetworkError: Unable to open entry ID. (hr=0x80040115, ec=0)

Les déplacements de boîtes aux lettres ne se terminent jamais car à chaque occurrence de l’erreur réseau, le transfert des données depuis les serveurs Exchange 2007 vers les serveurs Exchange 2010 repart à zéro.

18/01/2013 20:17:53 [SRV] Restarting the move because checkpoint data doesn't exist or isn't valid in 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)'.
18/01/2013 20:17:53 [SRV] Connected to source mailbox 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)', database 'CLUST01\StorageGroup\DB001', Mailbox server 'CLUST01.domain.local' Version 8.3 (Build 213.0).
18/01/2013 20:17:54 [SRV] Request processing started.
18/01/2013 20:17:54 [SRV] An old copy of the mailbox was removed from the destination database. The operation will try again in 30 seconds.

 

En parallèle, on remarque sur les boîtes aux lettres migrées vers Exchange 2010, l’apparition de nombreux évènements ayant pour source Outlook et pour ID 26 sur les postes clients (équipés d’Outlook 2010).

image

L’évènement émis par Outlook avec ID 26 a pour description “La connexion MAPI a été rétablie”.

Explication

Par défaut les sessions MAPI initiées par les serveurs Exchange 2010 ont une durée de vie de deux heures (7200 secondes).

Il peut arriver qu’un équipement réseau (routeur, pare-feu, HLB…) détecté une connexion MAPI comme étant inactive (idle) et coupe la session. En cas de coupure de session les clients MAPI tentent généralement de se reconnecter.

Dans notre cas c’est ce qui se produisait d’une part avec les clients Outlook (d’où les nombreux évènements au sujet d’une connexion MAPI “rétablie”) et d’autre part lorsque les serveurs CAS déplaçaient des boîtes aux lettres (d’où les erreurs “réseau”, suivies d’une reprise de la copie à son état de départ).

Remarque : Cette problématique de timeout est documentée dans la fiche support KB 2535656 (http://support.microsoft.com/kb/2535656/en-us) mais l’impact possible sur les déplacement de boîtes aux lettres (erreur “MapiExceptionNetworkError: Unable to open entry ID”) n’y est pas référencé.

Résolution

Pour résoudre ce problème, deux approches sont possibles :

A) Identifier l’équipement réseau possédant un timeout trop court et reconfigurer ce timeout sur une valeur cohérente avec celle d’Exchange 2010 (2 heures)

B) Identifier la durée du timeout (dans notre cas 300s) et ajouter la clé de registre KeepAliveTime sur l’ensemble des serveurs Exchange 2010 et 2007 pour que le timeout Exchange soit inférieur au timeout de l’équipement (par exemple positionner la valeur KeepAlive sur 180 secondes)

Dans notre cas de figure l’option la plus simple et la plus pertinente a consisté à augmenter le timeout du “protocol profil” FastL4 sur les boitiers F5 (par défaut le timeout sur ce profil était configuré à 300 secondes et il a été relevé à 7200 secondes).

clip_image001[4]

Cette opération a résolu l’ensemble des problèmes rencontrés sur la plateforme (plus d’erreurs 26 sur les clients ni d’erreur MapiNetworkException lors des transferts de boîtes aux lettres).

A titre informatif, voici un exemple de configuration de la clé KeepAliveTime (attention la valeur à entrer est en millisecondes).

image

Exchange 2010 SP2 – Message d’erreur “invalid canary” sur les serveurs CAS

17. janvier 2013 Matthieu-MARTINEAU Messagerie (0)

Symptôme

Suite à la mise en place de la supervision SCOM sur une plateforme Exchange 2010 SP2 RU5v2, des erreurs se produisent toutes les 5 minutes sur les serveurs jouant le rôle CAS.

image

Ces erreurs ont pour source MSExchange Control Panel et correspondent aux ID 4 et 38. Voici le détail de l’erreur 38 (avec en rouge les éléments intéressants) :

Log Name: Application
Source: MSExchange Control Panel
Date: 15/01/2013 14:40:05
Event ID: 38
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: CAS003.domain.local
Description:
Current User: 'domain.local/IT/Applications/Exchange/Sepcial Accounts/extest_123sd45c00812'

Exchange Control Panel detected an invalid canary from request for URL 'https://mail.domain.local/ECP/RulesEditor/InboxRules.svc/GetList'.

Canary in cookie: 'eLKJ8_Sgdekahjnd4825nduehfrkqzeuYDF_ujrDBHjfznakDF46fhbzp' mismatch with canary in header/form: ', in URL '.


Du côté de IIS, une erreur 500 est déclenchée et visible dans les logs W3C.

Explication

Ces erreurs se produisent à intervalles réguliers (toutes les 5 minutes) lorsque le compte de service utilisé par SCOM (extest_<id>) tente d’exécuter la commande PowerShell Test-EcpConnectivity.

Lorsque l’on effectue des recherches sur ces erreurs ont tombe très rapidement sur une fiche support indiquant qu’il s’agit d’un bug Exchange 2010 résolu dans la mise à jour RU3v3 du SP1 d’Exchange 2010.

Unnecessary events are logged in the Application log when you run the "Test-EcpConnectivity" cmdlet in an Exchange Server 2010 environment
http://support.microsoft.com/kb/2494389/en-us

Néanmoins dans notre cas, l’environnement est déjà mis à jour en version SP2 RU5v2 ce qui rend cette solution caduque.

Après investigation il s’avère que la commande Test-EcpConnectivity ne supporte pas les URL possédant des majuscules.

La solution au problème consiste à modifier les URL internes et externes du service Web ECP (Exchange Control Panel) de manière à remplacer le /ECP par un /ecp.

Ce problème est donc totalement indépendant de la supervision SCOM qui est dans ce cas un simple révélateur du problème (car SCOM exécute régulièrement la cmdlet Test-EcpConnectivity).

Résolution

Dès la correction des URL (via la cmdlet Set-EcpVirtualDirectory), les erreurs ne se produisent plus et il est possible d’exécuter sans erreur la commande Test-EcpConnectivity.

Remarque : La correction prend effet immédiatement. Un petit délai peut être nécessaire dans certains environnements, le temps que la réplication Active Directory ait lieu. Il n’est pas nécessaire de redémarrer IIS.

Cette solution a déjà été testée avec succès sur plusieurs environnement Exchange 2010 SP2.