PI Services

Introduction

Depuis Exchange 2010, il existe les agents d'extension des Cmdlets. C'est une fonctionalité méconnue (car peu documentée) et pourtant très utile dans beaucoup d'entreprise.

Ces agents permettent d'étendre les fonctionnalités de base d'Exchange. Par exemple lors de la création d'une boîte aux lettres, si une base de données n'est pas renseignée alors un agent se charge d'en choisir une automatiquement. Quelque soit le mode d'administration (Powershell ou via la console graphique EMC), l'agent se lancera. Cela vient entre autre du fait que la console Exchange ne fait qu'exécuter du Powershell en tâche de fond. Il est possible d'obtenir la liste de ces agents en exécutant la Cmdlet suivante dans une session Powershell Exchange :

Voici le résultat obtenu sur une infrastructure sans paramétrage particulier de ces agents :

Il existe de nombreux agents ; notamment pour la gestion de l'OAB ou des boîtes aux lettres. Dans le résultat obtenu, 2 attributs vont nous intéresser : l'activation et la priorité. Le premier permet simplement de savoir si l'agent est actuellement utilisé ou non. Le second concerne l'ordre d'application. En effet, plusieurs agents peuvent agir sur la même chose (par exemple : le choix de la base de données pour une boîte aux lettres). La priorité permet de définir l'agent qui sera utilisé (celui qui a la priorité la plus basse, les autres ne seront pas utilisés). Pour changer la priorité d'un agent, il suffit d'utiliser la commande suivante :

L'agent qui nous intéresse dans cet article est le "Scripting Agent". Nous allons voir comment l'utiliser ainsi que quels exemples d'utilisation.

L'agent de script

A contrario des autres agents, l'agent de scripting est entièrement customisable par les administrateurs Exchange. Typiquement, il va nous permettre par exemple, de réaliser certaines actions au moment de la création d'une boîte aux lettres et donc de l'exécution de la commande New-Mailbox ou Enable-Mailbox (activer/désactiver POP3/Single item recovery etc, création d'une boîte d'archive, envoi d'un mail automatique à l'utilisateur). On peux aussi imaginer un export automatique de la boîte aux lettres au format PST lorsque la commande remove-mailbox sera lancée. D'autres types d'actions sont réalisables. Elles seront détaillées plus loin dans cet article. Tout type de script Powershell peux être intégré.

Par défaut l'agent de scripting n'est pas activé. C'est pourquoi, on utilise la commande :

Cette commande active l'agent de scripting sur tous les serveurs Exchange de l'organisation.

Attention : Le fichier de configuration doit être présent sur tous vos serveurs Exchange. En effet, si l'agent de scripting est activé et que l'un des serveurs ne possède pas le fichier alors des erreurs peuvent survenir lorsque l'on appelle une commande Powershell ou lorsqu’on lance la console Exchange (impossibilité de se connecter au serveur ne possédant pas le fichier de configuration).

L'agent de scripting ne possède aucune configuration par défaut. Il convient aux administrateurs Exchange de la créer. Celle-ci se fait au travers du fichier ScriptingAgentConfig.xml qui doit être positionné dans le dossier C:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents (à moduler suivant le répertoire d'installation d'Exchange). Un exemple existe dans ce même répertoire nommé ScriptingAgentConfig.xml.sample).

Ce fichier contiendra tous nos scripts d'automatisation. Regardons maintenant la hiérarchie de ce fichier XML :

La balise Configuration contient l'ensemble des scripts qui seront utilisés par l'agent de scripting. C'est la balise racine.

Les balises Feature contiennent chaque fonctionnalité que l'on souhaite ajouter. Il peut y en envoir plusieurs au sein d'une balise Configuration. Elle possède chacune 2 attributs :

• Name : pour le nom que l'on souhaite donner à notre fonctionnalité)
• Cmdlets : permet de spécifier les Cmdlets Powershell Exchange qui vont déclencher la fonctionnalité. S'il y en a plusieurs, elles doivent être séparées par des virgules (Exemple : "New-Mailbox,Enable-Mailbox").

La balise API Call précice à quel moment la fonctionnalité se déclenche. Elle contient aussi le script qui sera lancé au déclenchement. Il peux y en envoir plusieurs au sein d'une balise Feature. Elle possède un attribut Name qui peut avoir 4 valeurs possibles :

• OnComplete : Le script fourni sera exécuté lorsque la commande appelé aura déjà été exécuté. Exemple : Après la création d'une boîte aux lettres, on souhaite envoyer un mail de bienvenu à l'utilisateur et activer le Single Item Recovery.
• Validate : Utile lorsque l'on souhaite valider des attributs. Le script se déclenchera avant l'exécution de la commande. Exemple : On souhaite être sur que les attributs Location et Phone ont été renseignés ou qu'ils respectent une certaine nomenclature pendant la création d'une boîte aux lettres. Ainsi l'administrateur recevra une erreur lors de l'exécution de la commande comme si ces attributs étaient obligatoire. Lorsque le retour est $null alors l'étape de validation est un succès.
• ProvisionDefaultProperties : Cela permet de définir des valeurs par défaut pour les propriétés d'un objet. Exemple : Lorsque l'on crée une boîte aux lettres Exchange, on peux imaginer une règle qui choisit automatiquement la base de données en fonction de la première lettre du nom de la personne. Attention, dans cet exemple, il est nécessaire de désactiver l'agent Mailbox Resources Management ou de baisser sa priorité en dessous de celle de l'agent de scripting. En effet, l'agent Mailbox Resources Management est en charge de l'attribution automatique d'une base de données si aucune n'est renseignée.
• UpdateAffectedIConfigurable : Cette API offre la possibilité de définir des propriétés juste avant l'opération de validation.

L'ordre d'exécution des différentes API lorsque l'on exécute une commande Exchange est le suivant  :

ProvisionDefaultProperties - UpdateAffectedIConfigurable - Validate – OnComplete

L'exécution de la commande Powershell Exchange a lieu entre les étapes Validate et OnComplete.

Enfin la balise Common permet de définir des fonctions Powershell pouvant être utilisées dans les scripts des balises ApiCall (A utiliser comme une librairie). On peut aussi charger ses propres scripts Powershell.

La mise en forme du fichier ScriptingAgentConfig.xml est importante. En effet, il apparait que lorsque des espaces inutiles sont présents, Exchange génère une erreur similaire à celle ci-dessous :

De plus, un événement est généré :

Pour ma part, afin d'éviter tout problème, je me suis rendu compte qu’il ne fallait mieux pas commenter les scripts présents dans le fichier xml.

NB : Une fois l'agent de scripting activé, les modifications du fichier ScriptingAgentConfig.xml sont prises en compte automatiquement.

Exemple d'utilisation avec l'événement OnComplete :

Lorsqu'on utilise l'API OnComplete, la variable $succeeded existe si la commande a réussi. Cela permet de gérer les cas d'échecs (il serait impossible d'effectuer un traitement sur une boîte aux lettres qui n'existerait pas).

L’exemple ci-dessous est un fichier ScriptingAgentConfig.xml permettant d’activer la boîte d’archive et le single item recovery lorsqu’une nouvelle boîte aux lettres Exchange est créée (Commande New-Mailbox et Enable-Mailbox). On remarque que l’on accède aux paramètres définis par l’utilisateur via la variable $provisioningHandler qui contient un hastable nommé UserSpecifiedParameters.

Exemple d'utilisation avec l'événement Validate : 

Ce nouvel exemple montre cette fois-ci l'usage de l'API Validate. Ici, lorsqu'une boîte aux lettres de salle est créée, on vérifie que son nom est bien du type : Salle, XX où XX est un nombre. Si le test échoue alors une erreur est retourné avec un message qui sera affiché pour l’administrateur (que l’action soit réalisée via EMS ou l’EMC).

Problématique

Sur certains smartphones (BlackBerry et Windows Phone) lors de la connexion à une boite mail Exchange 2010 (via ActiveSync) le mot de passe est demandé alors qu’il est enregistré.

Une resynchronisation de la BAL sans indiquer le mot de passe suffit au smartphone pour se reconnecter.

Contexte

L’architecture en place lors du problème se compose de plusieurs serveurs Exchange 2010 (plusieurs serveurs CAS/HUB, plusieurs MBX en DAG) et de deux serveurs TMG 2010 pour la publication des flux.

Après avoir fait des traces sur TMG, l’erreur suivante est présente à chaque demande de mot de passe :

• Log Type : Web Proxy (Forward)
• Status : 10054 An existing connection was forcibly closed by the remote host.

Solution

Le problème provient de TMG. En effet ce dernier possède un timeout sur la session ActiveSync entre le Smartphone et Exchange.

Pour résoudre ce problème il faut changer un paramètre dans TMG. Depuis la console TMG faites un clic droit sur le listener qui publie ActiveSync, ensuite dans Properties, Forms tab, Advanced décochez la case “apply session timeout to non-browser client” (http://technet.microsoft.com/en-us/library/cc995246.aspx).

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.

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).

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 :

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).

$ADObjets est un tableau d'objets Active Directory.

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.

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 :

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.

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.

Problème rencontré

Lors d'une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d'une entreprise, il s'est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d'adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d'adresse qui sera affiché par défaut à l'ouverture du carnet d'adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S'agissant d'appliquer une modification du registre à l'ensemble des postes clients d'une filiale, la solution la plus simple était d'implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.
 
Il est à savoir que la vue par défaut du carnet d'adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d'adresse) alors Outlook repositionnera automatiquement le carnet d'adresse sur la liste d'adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

Si l'on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
- Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
- Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
- Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d'un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l'on va appliquer les paramètres que l'on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l'on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.

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).

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 :

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.

En observant les files d’attentes d’un serveur de transport on peut parfois observer une

file en mode “suspended” ne contenant aucun message dont le “delivery type” est

“DnsConnectorDelivery”. La présence de ce type est compréhensible lorsqu’un connecteur

utilise un serveur DNS pour connaitre la passerelle distante, dans mon cas il n’y a que des

connecteurs utilisant une remise vers un “smarthost” !

Quoiqu’il en soit supprimons cette file.

Passez la file en mode “resume”. Elle va passer en “ready”:

Redémarrez le service MS Exchange Transport.

Relancez la console Queue Viewer.

La file a disparue.

Après avoir créé une liste de distribution vous souhaitez l’ajouter sur une autorisation de

partage d’un dossier public:

Vous constatez que la liste ne peut être ajoutée et est marquée du “panneau accès interdit”.

Cela est dû au fait que la liste est du type Mail Universal Distribution group.

On doit donc la convertir via la console ADUC ou par une commande powershell

Active Directory :

Le groupe de distribution est maintenant de type “sécurité”.

Patientons quelques minutes (réplication AD) puis ajoutons l’autorisation

sur le dossier public:

Oups, le problème est toujours présent

Vérifions le RecipientTypeDetails

Celui-ci est bien du type MailUniversalSecuritygroup !!!

Regardons l’attribut msExchRecipientDisplayType. Celui-ci à la valeur 1.

Ce qui correspond à un “mail universal distribution group”.

La modification réalisée dans l’interface graphique n’a donc pas été prise en compte.

Pour corriger le problème il faut utiliser la commande PowerShell Set-DistributionGroup

Vous pouvez rencontrer ce type d’erreur, pas de panique , rajoutez l’option

-MemberDepartRestriction Closed

Regardons de nouveau l’attribut msExchRecipientDisplayType:

La valeur est maintenant 1073741833 ce qui correspond à un “mail universal security group”.

                                                  **************

                                          *********************

Essayons de nouveau d’ajouter ce groupe sur les droits du dossier public:

Et voilà, mon groupe de distribution est disponible.

A ce jour ce disfonctionnement n’est pas considéré comme “bug” chez Microsoft .

L’accès à l’OAB est devenu crucial dans une infrastructure Exchange et plus précisément dans des configurations spécifiques où :

· Outlook est utilisé avec le mode cache activé.

· Outlook est en mode déconnecté.

Dans ces deux cas de figures, Outlook utilisera le carnet en mode hors connexion. Celui-ci sera mis à jour chaque 24 heures via un téléchargement différentiel, à noter que c’est le client Outlook qui initie la connexion.

Avec Exchange 2007, Microsoft a introduit le mécanisme de distribution Web, le client Outlook 2007 & 2010 peuvent télécharger l’OAB en se connectant directement sur les serveurs CAS en utilisant du le protocole http ou https.

L’url de téléchargement de l’OAB est fournie par le service Autodiscover aux clients Outlook.

Quant à la génération de L’OAB, celle-ci est gérée par un serveur Mailbox qui est désigné comme serveur de génération.

Qu’est ce qui a changé avec Exchange 2013?

Sur les versions précédentes Exchange, on pouvait désigner qu’un seul serveur de génération par OAB, ce qui représente un SPOF (Single point of failure).

Imaginer que le serveur Mailbox est en erreur, cela implique la non génération de l’OAB et ainsi que la non distribution de celui-ci aux clients Outlook.

L’impact de ce disfonctionnement peut être important, on peut citer deux phénomènes :

· Messages d’erreurs lors du téléchargement de l’OAB.

· Utilisation d’une version obsolète de l’OAB par les clients Outlook (les nouveaux contacts et les nouveaux utisateurs n’apparaissent pas sur l’OAB)

Avec Exchange 2013, l’OAB est généré par plusieurs serveurs Mailbox Exchange 2013 qui hébergent des boites aux lettres systèmes nommées « Organization Mailbox ».

Dans cette configuration, la génération de l’OAB est effectuée par plusieurs serveurs Mailbox ce qui permet d’assurer une résilience du processus de génération de l’OAB.

Quel Composant génère l’OAB ?

Le processus « Microsoft Exchange Mailbox Assistants/ OABGeneratorAssistant» est responsable de la génération de l’OAB dans Exchange 2013.

Ou sont stockés les fichiers OAB ?

Les fichiers OAB sont stockés en premier dans la Organization Mailbox et sont ensuite copiés dans le dossier %ExchangeInstallPath%\ClientAccess\OAB\

Méthode de distribution OAB :

Dans Exchange 2013, seule la distribution Web est supportée. Plus besoin de dossiers publics ! J

Le processus est le suivant :

1. Outlook reçoit l’URL de téléchargement OAB depuis le service Autodiscover.

2. Outlook s’authentifie auprès du serveur CAS pour télécharger l’OAB.

3. Le serveur CAS interroge un DC/GC pour :

a. Déterminer l’emplacement de l’Organization Mailbox la plus proche.

b. Déterminer quelle est la base de données qui herberge l’Organization Mailbox.

4. Le serveur CAS interroge ensuite l’Active Manager pour déterminer la copie Active de la base de données (Seulement si la base de données fait partie d’un DAG)

5. Le serveur CAS proxie ensuite la demande de téléchargement vers le serveur Mailbox identifié dans les étapes précédentes.

6. Le serveur Mailbox renvoie les fichiers OAB au serveur CAS qui les renvoie à son tour au Client Outllok.

Avec Exchange 2013, il a vraisemblablement une avancée importante du processus OAB,cette avancée permet de garantir une tolérance de panne mais implique aussi un troubleshooting plus compliqué en cas d’anomalie de génération de l’OAB.

Pour plus d’informations :

http://blogs.technet.com/b/exchange/archive/2012/10/26/oab-in-exchange-server-2013.aspx

À Très bientôt

Khalil Ben Zneiguia

La commande “Switchover server” permet de basculer les banques actives

vers un serveur de destination.

Ayant rencontré à de maintes reprises des soucis lors de l’utilisation de cet utilitaire

j’ai préféré utiliser un script.

*********************************************************

######## Move database
######## Ce script permet le déplacement des banques actives d'un serveur "A" vers un serveur "B"
######## Ecrit par Pascal FEDAN
######## Le 05 Novembre 2012
######## Version 1.0
######## Modifié le
######## Version

######## Déclaration des serveurs source et cible

$sourceserver = "serveur2"
$targetserver = "serveur1"

####### Fonction d'envoi d'un message

function sendmail {
         send-mailmessage -from "adm_mail@pub.ad" -to "Franck.Test@pub.ad" -subject "MoveDatabase" -body " Merci de consulter le fichier." -Attachment "C:\Temp\databasecopystatus.txt" -priority High -dno onSuccess, onFailure -smtpServer 10.10.10.10
                  }
####### Statut des bases avant la bascule

get-Date >> c:\Temp\databasecopystatus.txt
Write-output "########## Databasecopystatus avant le déplacement " >> c:\Temp\databasecopystatus.txt
Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $sourceserver >> c:\Temp\databasecopystatus.txt

Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $targetserver >> c:\Temp\databasecopystatus.txt

######### recherche des banques "montées" sur le serveur source

$MountedDB=get-mailboxdatabasecopystatus -Server $sourceserver | where { ($_.Status -eq "Mounted")}

########  si aucune banque "montée", sortie du script

if (!$MountedDB) { Write-Host "PAS DE BANQUE ACTIVE SUR $sourceserver"
                   Write-output " " >> c:\Temp\databasecopystatus.txt
                   Write-output "########## PAS DE BANQUE ACTIVE SUR $sourceserver " >> c:\Temp\databasecopystatus.txt
                   Write-output " " >> c:\Temp\databasecopystatus.txt
                   sendmail
                   exit
                  }
                           
######### bascule des banques

else {
      Foreach ($DB in $MountedDB)
         { Move-ActiveMailboxDatabase -Identity $DB.DatabaseName -ActivateOnServer $targetserver -MountDialOverride:None -confirm:$false >> c:\Temp\databasecopystatus.txt}
      }
     
Start-Sleep -s 30

######### statut des banques après la bascule

Write-output " " >> c:\Temp\databasecopystatus.txt
Write-output "########## Databasecopystatus après le déplacement" >> c:\Temp\databasecopystatus.txt
Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $sourceserver >> c:\Temp\databasecopystatus.txt

Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $targetserver >> c:\Temp\databasecopystatus.txt

######## Appel de la fonction sendmail

sendmail

***********************

Ce script recherche les banques actives et les bascule sur le serveur de destination

mentionné dans la déclaration des variables.

Bien sûr, testez avant de l’utiliser en production.