PI Services

Le blog des collaborateurs de PI Services

Exchange Online – Erreur avec les listes de distribution dynamiques et le filtre UsageLocation

Contexte

Dans Exchange Online il est possible de créer des listes de distribution dynamiques en se basant sur l’attribut UsageLocation. Cet attribut est défini par l’administrateur lors de l’attribution d’une licence à un utilisateur.

2017-11-21_151051

Cependant lorsque vous créez une liste de distribution il se peut que le filtre ne fonctionne pas et que l’erreur suivante apparaisse lorsque vous tentez de lister les membres de la liste :

2017-11-21_144233

Explications

Lorsque l’on regarde le filtre via la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que la valeur pour l’attribut UsageLocation est en Français. Ceci est causé par le fait que l’outil Microsoft Sign-In Assistant a été installé en Français.

2017-11-21_143648

Même si l’on créé le filtre à l’aide de la norme ISO 3166 (comme décrit dans la KB suivante https://technet.microsoft.com/en-us/library/bb738157(v=exchg.160).aspx), l’outil remplace le code par le texte en Français avant de l’envoyer au serveur Exchange.

Après avoir contacté le support Microsoft, nous avons eu une confirmation de ce problème et une mise à jour doit être apportée dans le code source de l’outil.

Solution

La solution en attendant le fix est de supprimer la liste de distribution et de la recréer depuis une machine où l’outil est installé en anglais. Pour cela, lancez les commandes suivantes :

Remove-DynamicDistributionGroup “dl_language_it”

2017-11-21_144451

New-DynamicDistributionGroup "dl_language_it" -RecipientFilter {UsageLocation –eq “IT”}

La liste des codes ISO pour l’ensemble des pays sont disponibles au lien suivant : https://www.iso.org/obp/ui/fr/

Si l’on vérifie avec la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que l’attribut UsageLocation est maintenant en Anglais.

2017-11-21_144550

Si l’on utilise la commande suivante pour lister les membres, l’erreur n’apparait pas et les membres du groupes apparaissent.

$group = Get-DynamicDistributionGroup ‘”dl_language_it”
Get-Recipient –RecipientPreviewFilter $group.RecipientFilter

2017-11-21_144739

Office 365 migration tenant-to-tenant – Retour d’expérience 1/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.

Architecture

L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.

Figure 1 – Schéma source de l’architecture

schemaSource

Figure 2 – Schéma cible de l’architecture

schemaCible

Pré-requis

Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.

La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).

Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.

Enfin il est important d'avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).

 

Voilà qui conclut la première partie de mon retour d'expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 2/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la seconde partie qui traitera du plan d’action et de la migration.

Plan d’action

Lors de la migration les noms de domaine des adresses emails étant conservés, une coupure de service est obligatoire. Il est donc primordial de bien préparer la migration et d’effectuer en avance de phase toutes les tâches pouvant être traitées pré-migration.

Le plan d’action sera le suivant :

    1. Avoir un export de l’ensemble des données du tenant A. Pour chaque compte connaître son adresse de messagerie, ses alias, ses droits… Idem pour l’ensemble des objets Exchange (boites partagées, listes de distribution, contacts...)
    2. Créer des utilisateurs cloud uniquement dans le tenant B correspondant aux utilisateurs du tenant A. Exemple : john.doe@domainea.com aura un compte john.doe@domaineb.onmicrosoft.com
    3. Assigner des licences aux utilisateurs dans le tenant B
    4. Créer le reste des objets Exchange (attention certains objets peuvent-être synchronisés avec l’AD et d’autre uniquement dans le cloud) du tenant A dans le tenant B
    5. Commencer les migrations via l’outil de migration. Exemple : l’ensemble des mails plus vieux que les 30 derniers jours
    6. Arrêter la synchronisation de l’ensemble des objets de l’Active Directory A vers le tenant A (supprimer la synchronisation des OU dans Azure AD Connect A). L’ensemble des comptes dans le tenant A sont à présent en Soft-Deleted
    7. Utiliser la commande suivante pour restaurer l’ensemble des comptes en tant que comptes cloud uniquement :
      Get-MsolUser –ReturnDeletedUsers –All | Restore-MsolUser
    8. Supprimer l’ensemble des références aux noms de domaine présent sur le tenant A (alias, adresses SIP,…). Tous les objets doivent avoir uniquement des adresses avec l’adresse par défaut de Microsoft
    9. Supprimer les noms de domaine du tenant A
    10. Ajouter les noms de domaine sur le tenant B
    11. Modifier l’UPN des comptes cloud du tenant B pour qu’ils soient égaux aux UPN des comptes de l’Active Directory A.
    12. Créer un nouveau connecteur sur l’AD Connect B pour synchroniser les comptes de l’Active Directory A. Une fois la synchronisation terminée, les comptes cloud du tenant B ont fusionné avec les comptes de l'Active Directory A.
    13. Finaliser la migration via l’outil (attention, les adresses sources et destinations ont changé, il est peut-être nécessaire de les mettre à jour dans l’outil utilisé pour la migration)
    14. Mettre à jour l’ADFS A via les commandes suivantes :
      Set-MsolDomainFederationSettings –domainname "domainea.com" –ActiveLogOnUri "https://<url ADFS A>/adfs/services/trust/2005/usernamemixed" –issuerUri "http://<domainea.com>/adfs/services/trust/" –logoffuri "https://<url ADFS A>/adfs/ls/" –metadataexchangeuri "https://<url ADFS A>/adfs/services/trust/mex" –PassiveLogOnUri "https://<url ADFS A>/adfs/ls/"
      Update-MsolFederatedDomain –DomainName "domainea.com" –SupportMultipleDomain

 

Migration

La planification

La planification de la migration est importante. En effet lorsque l’on se réfère au plan d’action on remarque que beaucoup d’actions sont à faire pendant l’interruption de service (de l’étape 6 à l’étape 12). Il est donc important de bien planifier la migration sur un weekend et de vérifier qu’aucune autre action est prévue à cette date là (paye, bilan comptable…).

Il est également très important de communiquer avec les utilisateurs tout au long du projet. Expliquer pourquoi une telle migration (intégration de la messagerie dans la messagerie groupe par exemple), bien indiquer les dates de la migration, prévenir de l’interruption de service et informer des éléments qui ne sont pas pris en compte par cette migration (signature…).

Y penser !

Une fois la migration terminée, le support utilisateur peut être amener à avoir une surcharge de travail. Avoir une équipe renforcée lors des premiers jours post-migration aidera grandement à la résolution des problèmes et à la gestion du stress des équipes.

Les actions post-migrations

Une fois la migration terminée, certaines actions sont nécessaires côté utilisateur (création d’un nouveau profil sur Outlook par exemple) mais aussi côté administrateur (donner de nouveaux droits d’administration aux équipes sur le tenant B par exemple).

Mettre en place un fichier de suivi pour les problèmes rencontrés est fortement conseillé. Cela permet de centraliser et donc de faciliter la résolution des problèmes et de ne pas oublier certains points (notamment si c’est un problème mineur).

 

Voilà qui conclut la seconde partie de mon retour d'expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 3/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la dernière partie qui traitera des problèmes rencontrés lors de la migration.

Problèmes rencontrés et solutions

Eléments de calendrier non-migrés

Un point important pour que la migration des calendrier se fasse, la time-zone de la boite aux lettres de destination doit être renseignée. La commande PowerShell suivante permet de mettre à jour cet attribut

Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"

Les valeurs possibles de la time-zone sont indiqués ici : https://support.microsoft.com/en-us/help/973627/microsoft-time-zone-index-values.

Migration OneDrive

Tout comme la migration des éléments de calendrier, la partie OneDrive nécessite une initialisation des comptes cibles pour que la migration s’effectue.

Lors de cette migration j’ai utilisé le script présent à l’adresse suivante pour initialiser l’ensemble des comptes.

https://support.office.com/fr-fr/article/Comment-configurer-des-sites-utilisateur-dans-OneDrive-entreprise-ceef6623-f54f-404d-8ee3-3ce1e338db07

Mauvaise synchronisation des comptes Active Directory

Au moment de la synchronisation de l’Active Directory A vers le tenant B, il est possible que certains comptes ne fusionnent pas avec leur compte cloud correspondant et que des doublons soient présent.

Il peut y avoir diverses raisons à cela :

  • Une erreur dans l’UPN du compte cloud
  • Un contact déjà présent dans le tenant B avec l’adresse email du compte A
  • Un compte invité dans le tenant B avec l’adresse email du compte A

Dans ce cas, il faut tout d’abord supprimer l’objet (le contact ou le compte invité) du tenant B (en le supprimant également de la corbeille O365). Ensuite il faut désynchroniser le compte AD (en déplaçant le compte dans un OU non-synchronisée). Une fois le compte désynchronisé il faut supprimer ce compte de la corbeille O365. Lancer une nouvelle synchronisation pour que la métaverse de l’AD Connect prenne en compte la modification. Enfin resynchroniser le compte AD. Il doit alors fusionner correctement.

Si ce n’est pas le cas, il est possible que le compte cloud ne récupère par l'attribut ImmutableID. Cet attribut est le "lien" entre le compte dans l'Active Directory (et donc celui de la métaverse AD Connect) et le compte cloud O365.

Pour modifier l'attribut il faut de nouveau désynchroniser le compte AD et le supprimer de la corbeille O365 puis il faut utiliser les commandes PowerShell suivantes.

Sur l’Active Directory A :

$adUser = Get-ADUser "<SamAccountName>" –Properties *

$id= $adUser.ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($adUser.ObjectGUID)).tobytearray())}

Sur le tenant B :

Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id

Resynchroniser le compte AD.

Conclusion

Ce billet termine mon retour d'expérience sur cette migration tenant-to-tenant. J'espère qu'il vous a été utile.

Exchange / Powershell : Influence du paramètre DomainController

Introduction

 

Exchange bénéficie d'un grand nombre de cmdlet Powershell très abouties et permettant de configurer et d'administrer l'intégralité d'une infrastructure de messagerie. Aussi, celles-ci sont très utiles dans le cas de scripts de provisionning. J'ai rencontré une erreur lorsque je cherchais à créer et à configurer un grand nombre de boites aux lettres de ressources.

 

Contexte

 

L'environnement dans lequel j'ai découvert ce problème est une forêt mono domaine Active Directory avec une infrastructure Exchange 2010 SP3 dans laquelle il y avait plusieurs contrôleurs de domaine dans le même site Active Directory que la totalité des serveurs de messagerie.

 

Plus globalement, cette erreur pourra être rencontrée dès qu'un serveur Exchange pourra être amené à interroger plus d'un contrôleur de domaine.

 

Erreur rencontrée

 

Dans un script de provisionning de boîtes aux lettres, on cherche à les créer mais aussi à les configurer. Si l'on souhaite configurer une boite aux lettres tout de suite après sa création alors on obtient une erreur similaire à celle ci-dessous (“ObjectNotFoundException”) :



Cela peut se retrouver en exécutant l'exemple suivant :



Une ou plusieurs opérations de modification (de type Set-…) vont échouer avec le message d'erreur cité précédemment.

 

Explication

 

Suite à cette erreur, il est logique de penser que cela est dû à l'interrogation de différents contrôleurs de domaine qui n'ont pas encore répliqué entre eux (Une réplication intra site peut prendre quelques secondes).

 

Aussi, on peut se dire qu'il suffit alors de spécifier le paramètre DomainController pour corriger le problème en l'indiquant sur toutes les commandes et en définissant un contrôleur de domaine unique qui traitera toutes les opérations.

 

Cependant, cela ne corrigera pas le problème. Microsoft en donne l'explication dans les fiches Technet des cmdlets :http://technet.microsoft.com/en-us/library/dd335046.aspx.

 

Le paramètre DomainController ne concerne que le contrôleur de domaine qui va écrire les modifications dans Active Directory. Cependant, un autre contrôleur de domaine  peut être utilisé pour lire l'objet avant d'écrire les changements sur celui spécifié en paramètre.

 

Aussi, pour une cmdlet de type Get-… (lecture), le paramètre DomainController sera bien le contrôleur de domaine sur lequel l'objet sera lu (cela sera utile pour mettre en place l'une des solutions proposées).

 

Solution

 

Pour résoudre ce problème,  il faut donc attendre que la réplication ait eu lieu sur la totalité des contrôleurs de domaine du site Active Directory de l'infrastructure Exchange. Pour cela, nous avons trois solutions.

 

Solution 1 :

 

Il est possible de séparer la création des boîtes aux lettres et leurs configurations. Cette solution oblige donc a réaliser le provisioning en plusieurs phases.

 

Solution 2 :

 

On peut définir un délai entre l'opération de la cmdlet de création et la cmdlet de configuration via un Start-Sleep par exemple. Cependant, cette solution ne garantit pas que les opérations vont toutes se dérouler correctement. Il faudra sans doute que le délai soit important pour que le provisioning ait un taux de réussite élevé et donc augmenter considérablement le temps d'exécution du script.

 

Solution 3 :

 

La dernière solution est une combinaison des deux précédentes puisqu'elle permet de n'avoir qu'une seule phase de provisioning tout en ayant un temps d'exécution relativement rapide.

 

Cette solution consiste à implémenter une boucle de test de l'opération à réaliser sur le même contrôleur de domaine via la cmdlet de lecture (Get-…).

 

Exemple :



Il est possible d'ajouter une courte pause entre chaque test afin de ne pas surcharger le processus sans pour autant trop pénaliser le temps d'exécution du script. Le paramètre ErrorAction permet d'alléger l'affichage car on connait déjà l'erreur que l'on va rencontrer.

Il ne vous reste plus qu'à choisir la solution que vous préférez.

DirSync – Erreur à l’installation de DirSync sur un serveur Windows Server 2012 R2

La problématique

Lors de l’installation de Windows Azure Active Directory Synchronization (aka “DirSync”) sous Windows Server 2012 R2, l’erreur suivante peut apparaitre :

The minimum version of Windows Powershell required is 2,0.
Please install the minimum version required (or higher) and try again.

image

Cela peut sembler étrange d’autant plus que Windows Server 2012 R2 intègre nativement la version 4.0 de PowerShell.

Explication

Il semble que ce problème soit dû à la localisation du système d’exploitation. En effet sur un système d’exploitation installé en langue française, le caractère séparateur entre les entiers et les décimales est la virgule et non le point.

Or on peut remarque que le message d’erreur indique un problème pour détecter la version PowerShell 2,0 et non 2.0.

Solution

La solution consiste tout simplement à modifier les formats de date, d’heure et de nombre et à les passer sur le format anglais.

image

Il suffit ensuite de fermer, puis de relancer l’installeur de DirSync pour que la modification soit prise en compte et que PowerShell soit bien détecté.

image

N.B. : Ne pas oublier de lancer dirsync.exe avec des droits administrateur (clic droit, puis Run As Administrator), sinon une exception .net apparaît

Powershell / Exchange : Erreur 9323 - Certificat expiré sur un objet AD

Introduction

Cet article permet de montrer la gestion des certificats via Powershell au travers d'un problème concret rencontré sur une infrastructure Exchange. Une solution basée sur un script Powershell sera détaillée.

Erreur rencontrée

Contexte : Infrastructure Exchange 2010 avec plusieurs dizaine de milliers de contacts Active Directory importés et mis à jour par un outil tierce.

Dans l’observateur d’événements de nombreux événements 9323 apparaissent.

9323

Ces derniers sont liés à la génération de l'OAB. Exchange détecte un utilisateur dont un certificat est expiré. Ces événements n'apparaissent que sur des objets de type "Contact"  La solution doit contrôler tous les objets Active Directory de ce type.

Solution

La soluton proposée pour purger les certificats invalides des contacts Active Directory se base sur un script Powershell V2. Ce dernier analyse l'attribut UserCertificate (il s'agit d'une liste de certificat).

Avec le type d'objet "System.Security.Cryptography.X509Certificates.X509Certificate2", il est possible d'obtenir des informations sur les certficats contenus dans cet attribut sous forme lisible (et non pas un tableau de bytes ou de valeur hexadécimal comme sur la console Active Directory Users and Computers).

Ci-dessous, un exemple de données récupérées sur les certificats d'un objet Active Directory (ici, il n'y a qu'un seul certificat et la variable $User est un utilisateur Active Directory).

Certificate

On remarque qu'on accède à des renseignements comme l'émetteur ou le sujet. Les informations qui nous interessent (dates de validité du certificat) sont aussi présentes. Il suffit donc de comparer la date d'expiration contenue dans l'attribut "notAfter" avec la date du jour en cours pour détecter les certificats expirés.

Grâce à la cmdlet "Set-ADObject", il sera ensuite possible de supprimer les certificats qui ne sont plus valides.

Script

En amont de ce script, un transcript est lancé afin de loguer toute les opération effectuées. Une vérification de la présence du module ActiveDirectory ainsi que son chargement sont ensuite réalisées.

Le script appelle une fonction créée pour traiter tout objet AD (ou tableau d'objets AD) qui lui est passé. Pour ma part, je transmets en paramètre tous les contacts présents dans Active Directory. Cependant cette fonction peut très bien être utilisée avec des utilisateurs. Voici l'algolrithme mis en place dans la fonction Test-CertExpiration :

  1. Filtrage des objets pour ne conserver que ceux ayant au moins un certificat présent dans l'attribut userCertificate.
  2. Boucle ForEach sur tous les utilisateurs :
    1. Boucle For sur tous les certificats de l'utilisateur (pas de ForEach afin d'être certain de la position du certificat dans l'attribut userCertificate)
    2. Analyse de la date d'expiration
    3. Si le paramètre DeleteExpired est présent alors on supprime le certificat dans Active     Directory s'il n'est plus valide.
    4. Si le paramètre DeleteExpired n'est pas présent alors deux attributs sont ajoutés à l'objet     AD :
      1. CertExpired : contient les index des certificats expirés dans le tableau de l'attribut userCertificate
      2. CertValid : contient les index des certificats valides dans le tableau de l'attribut userCertificate
  3. Si le paramètre Export et ExportPath ont été renseigné alors le tableau d'objet AD est exporté sous format CSV avec la liste des index des certificats valides et expirés.

Ci-dessous, vous trouverez le script intégralement commenté. A noter, que le compte exécutant ce script doit posséder les droit suffisants à la modifications des objets AD concernés (via une délégation par exemple).

Ici, la fonction Test-CertExpiration, est utilisée en mode suppression, cependant il est aussi possible de se servir du mode Export pour n'effectuer qu'un simple audit (logué dans un fichier) des objets concernés via la commande suivante :

$ADObjets est un tableau d'objets Active Directory.

Il est enfin possible de ne donner qu'un tableau d'objets AD à traiter sans spécifier le mode export ou suppression :

Dans ce cas, un tableau d'objets AD est retourné. Pour chaque objet, les attributs CertExpired et CertValid sont ajoutés.

Quelques points clés du fonctionnement de la fonction Test-CertExpiration :

Les paramètres Export et DeleteExpired sont de type switch et ne peuvent apparaître ensemble. Le paramètre ExportPath est dynamique et n'est disponible que si le paramètre Export a été choisi.

Pour information, il n'est pas nécessaire de paralléliser le processus de contrôle du certificat. Après un test effectué sur plus de 90000 contacts Active Directory, il s'avère que ce dernier a duré moins de 5 minutes. Utiliser du multi thread (workflow ou job Powershell) alourdirai le script et ralentirai le processus au lieu de l'accélérer.

Exchange 2013 - Erreur 5203 (source WAS) sur un serveur multi-rôles Exchange 2013 CU2

Symptômes

Ce type d’erreur peut se rencontrer sur un serveur multi-rôles (Client Access et Mailbox) en version Exchange Server 2013 CU1 ou Exchange Server 2013 CU2.

Les symptômes sont les suivants :

  • Les services Web Exchange (OWA, Outlook Anywhere…) dysfonctionnent
  • L’erreur 503 (source WAS) est présente en boucle dans le journal d’évènement Système

    Voici le détail de l’erreur concernée :

    Journal : System
    Source: Microsoft-Windows-WAS
    Event ID : 5203
    Level : Error
    Description: A process serving application pool 'MSExchangeRpcProxyAppPool' reported a failure trying to read configuration during startup. The process id was '27620'.  Please check the Application Event Log for further event messages logged by the worker process on the specific error.  The data field contains the error number.

Explication

Cette erreur est généralement due à la présence d’un fichier de configuration IIS corrompu.

Cela peut être mis en évidence en lançant la console d’administration IIS Manager.

image

Dans notre exemple, la console fait très clairement référence à un fichier de configuration nommé applicationHost.config et stocké dans le répertoire C:\Windows\System32\Inetsrv\Config.

Lorsque l’on tente d’éditer le fichier, ce dernier peut apparaitre remplis d’espace blancs ou bien ma formaté (selon les cas de figure).

image

Résolution

Pour résoudre ce problème il suffit de recopier le fichier sur le serveur applicationHost.config à partir d’un autre serveur Exchange en même version ou bien à partir d’une sauvegarde.

Dès le fichier copié, il devient  possible de démarrer les services IIS et les services Web sont de nouveau opérationnels.

Interaction Powershell - Exchange Web Services

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.

Powershell : Modifier l'affichage d'un compte sous Outlook 2010

Introduction

Dans le cadre d'une migration inter-organization Exchange 2003 vers Exchange 2010, il fallait reconfigurer le profil pour que le nom de compte dans Outlook 2010 soit mis à jour avec la nouvelle adresse email (ainsi que le nom des arborescences des emails et de dossiers publics associées).

Blog1blog2

Afin de répondre à cette problématique en impactant le moins d'utilisateurs possibles, la solution proposée réalisait des modifications via un script déployer en GPO (logon script).
Ci-dessous vous trouverez les informations nécessaires à ce paramétrage via Powershell.

Récupération des informations de comptes

Afin d'effectuer ces modifications il faut aller les chercher dans le registre.
Ainsi, la ruche "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\" liste tout les profiles Outlook enregistré (par défaut le premier profil est appelé Outlook) pour l'utilisateur connecté.
Dans les ruches enfantes, si la clé de registre 001f6620 est présente c'est qu'il s'agit d'un compte Outlook. Cette dernière définit le nom du compte.

De plus, toujours dans les ruches sous-jacentes au nom d'un profile, si la clé 0003660a est positionné alors il s'agit d'une arborescence de emails ou de dossiers publics (ce sont celles qui nous intéressent dans le cas d'un changement de nom).
Si elle a la valeur "0x03,0x00,0x00,0x00" c'est qu'elle représente une arborescence de dossiers publics tandis que "0x01,0x00,0x00,0x00" représente la même chose pour des emails.
Le nom de l'arborescence est contenu dans la clé 001f3001.

Avec ces informations nous pouvons donc facilement retrouver le nom d'un compte et le profile associé pour le modifier. Pour modifier les noms des arborescences, nous avons les clés de registres à changer.

Modification du nom de compte

Pour modifier le nom du compte il n'existe actuellement qu'une seule méthode puisque la propriété du accessible via la librairie Interop (permettant d'interagir avec Outlook) n'est accessible qu'en lecture seule. Un module Powershell a été développé pour gérer les comptes Outlook : Outlook Account Manager. Il est disponible à cette adresse : http://psoutlookmanager.codeplex.com/

Il propose un jeu de commandes permettant de récupérer les profiles (Get-Profile), les comptes (Get-MAPIAccount) et de modifier ces derniers (Set-MAPIAccount).

Voici un exemple permettant le modification du nom d'un compte :

On récupère le compte Outlook que l'on souhaite renommer (Il faut spécifier le profil)
$Account = Get-MAPIAccount -ProfileName "Nom du profil" | Where-Object `   {$_.AccountName -eq "Mon compte à modifier"}
On change l'attribut AccountName avec le nouveau nom que l'on souhaite obtenir.
$Account.AccountName = "Nouveau nom"
On enregistre les changements sur le compte que l'on a mis à jour.
Set-MAPIAccount $Account

Il est à noter que le module Outlook Account Manager ne s'exécute qu'avec Powershell 32 bits. On peut donc lancer le script via la commande ci-dessous :
&"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" $Path
$Path représente ici le chemin du script.

Cette méthode peut être exécuter pendant qu'Outlook est lancé. Le résultat sera visible dès l'exécution du script (sans avoir à redémarrer Outlook).

Modification du nom d'affichage

Pour mettre à jour le nom d'affichage dans l'arborescence Outlook, il existe plusieurs méthodes.

La première, consiste à utiliser les classes Interop Outlook. Cela va lancer un processus Outlook en tâche de fond.
Tout d'abord on invoque une instance d'Outlook
$Outlook = New-Object -comObject Outlook.Application
$Namespace = $Outlook.GetNamespace("MAPI")

Permet d'obtenir tous les comptes.
$Accounts = $Namespace.Accounts

Cette méthode présente l'avantage d'obtenir un résultat visible même si Outlook est lancé (sans avoir à le redémarrer). Cependant, l'utilisateur sera prompté pour lui dire qu'un autre processus souhaite accéder à Outlook, et cela nécessitera donc une intervention manuelle. Il peut aussi être concevable de fermer toutes les instances d'Outlook avant d'exécuter ce script, ce qui peut être déroutant pour l'utilisateur.

Voici un exemple de code permettant la dernière proposition :
$OutlookProcesses = Get-Process | Where-Object {$_.Name -like "Outlook"}
ForEach($Outlook in $OutlookProcesses){
    Stop-Process $Outlook.Id
}

A la fin du script on n'oublie pas de fermer le processus ouvert par la création de l'objet COM :
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($Outlook)

La seconde méthode consiste à modifier directement la clé de registre. Pour mettre en œuvre cette opération il faut changer la valeur de la clé "001f3001" que l'on a identifier au préalable. Attention, le type de cette clé est un tableau de bytes. Bien qu'il soit possible de donner une chaine de caractère classique (String), tout en impactant pas le fonctionnement d'Outlook, cela va modifier le type. Voici donc un exemple pour créer un tableau de bytes à partir d'une chaine de caractère :

Exemple de résultat à obtenir :
blog4

On encode une String  en tableau de bytes
$enc = [system.Text.Encoding]::UTF8
$mystring = "This is a string"
$data = $enc.GetBytes($mystring)

Chaque caractère est séparé par une valeur en byte équivalente à un zéro. Pour que notre tableau soit correct il faut ajouter ce zéro après chaque caractère.
On crée un tableau modifiable (ArrayList)
$ArrayBytes = New-Object System.Collections.ArrayList
Entre chaque byte on ajoute un zéro.
foreach($d in $data){
    $ArrayBytes.Add($d)
    $ArrayBytes.Add(0)
}

Enfin on peut modifier la valeur de la clé de registre :

Set-ItemProperty "$RegistryPath" -Name 001f3001 -Value $ArrayBytes
$RegistryPath représente le chemin vers la clé de registre.

L'avantage de cette méthode est de n'avoir pas à exécuter de processus Outlook et l'utilisateur ne se rend pas compte du changement (pas de prompt ni de fermetures intempestives d'Outlook). Cependant si Outlook est lancé, le résultat ne sera visible qu'au prochain démarrage de celui-ci.