Accrochage possible lors des migrations vers Échange 2013 CU1120

Mi-décembre 2015, Microsoft a publié la mise à jour cumulative 11 (CU11) pour Exchange 2013. Ce qui a changé, entre autres, est le type de connexion d’Exchange Management Shell (EMS) avec les serveurs en gestion. Quels sont les problèmes qui peuvent se produire et comment ceux-ci sont résolubles, Markus Hengstler le montre dans sa contribution.

Auteur Markus Hengstler
Date 20.01.2016
Temps de lecture 6 Minutes

Le 10/12/2015 Microsoft a publié la mise à jour cumulative 11 (CU11) pour Exchange 2013. Celui qui prend la peine de lire les notes de versions apprendra comment les connexions de l’Exchange Management Shell (EMS) a changé avec les serveurs à gérer. La migration à partir d’Exchange 2007 et 2010 à 2013 est problématique alors je l’explique dans cet article ainsi que l’impact et les solutions possibles.

Qu’est-ce qui a changé ?

Dans Exchange 2007 jusqu’à 2013 avec CU10, l’Exchange Management Shell se connecte via un répertoire virtuel sur le serveur Web du serveur local. Si cela s’avère impossible, la logique s’orientera vers un autre Client Access Server disponible.

Voici un exemple d’un serveur Exchange 2010 :

exchange-2013-migration-cu11-1

Le changement de CU11 (et plus tard aussi dans Exchange 2016 CU1) est que la connexion sera acheminée vers le serveur sur lequel se trouve la copie active de la base de données avec la Mailbox de l’utilisateur administratif. Si ce dernier n’a pas de boîte aux lettres configurée, la boîte aux lettres d’arbitrage SystemMailbox {bb558c35-97f1-4cb9-8ff7-d53741dc928c} sera utilisée à la place ou si celle-ci n’est pas disponible, ce sera l’une des autres boîtes aux lettres système. Cette procédure est appelée ancrage de boîte aux lettres « Mailbox Anchoring ».

Pourquoi ce changement a été introduit ?

Étant donné que les demandes sont transmises au répertoire PowerShell dans IIS , généralement via un équilibreur de charge qui les distribue ensuite au serveur, il peut arriver en particulier dans une combinaison d’Exchange serveurs 2013 et 2016 que le serveur le plus récent ne soit pas utilisé pour la gestion empêchant ainsi les Cmdlets les plus récents de fonctionner. L’ancrage de Boîte aux lettres pour EMS « Mailbox Anchoring » résout ce problème spécifique. Je suppose que cela a été introduit en particulier pour l’environnement Microsoft Office 365.

Quels sont les problèmes possibles ?

Il existe deux cas dans lesquels le nouveau comportement de la configuration de la connexion peut causer des problèmes :

  1. Au cours d’une migration à partir d’Exchange 2007 ou 2010
    Si je veux gérer l’Exchange server 2013 CU11 ou 2016 CU1 et appeler l’EMS, il semble en effet que je sois connecté localement toutefois ceci n’est pas le cas. Cela conduit à une mauvaise interprétation des commandes dans le Shell ou elles ne seront tout simplement pas exécutées. Voici un exemple :
    exchange-2013-migration-cu11-2
    Bien qu’apparemment connecté localement, le Shell ne peut afficher que Exchange 2010 ; 2013 est affiché seulement si le caractère générique « * » est utilisé dans la requête :
    exchange-2013-migration-cu11-3
    Le même problème se produit avec les bases de données :
    exchange-2013-migration-cu11-4
    Ici, nous voyons aussi que le chemin d’accès de base de données (alors même que nous sommes censés être connecté à Exchange 2013) ne peut pas être changé parce que nous sommes considérés comme étant distants, selon le message d’erreur.
  2. Si toutes les bases de données avec des boîtes aux lettres soit ‘admin’ soit ‘système’ sont démontées, l’EMS ne peut même pas se connecter
    exchange-2013-migration-cu11-5

Comment les problèmes peuvent être contournés ?

Tout d’abord, les boîtes aux lettres du système et des administrateurs doivent être déplacées dès que possible vers des bases de données de la dernière version d’Exchange. Mais cela doit également être initialisé sur un nouveau serveur. Cependant, l’EMS se connecte automatiquement au serveur ancien comme nous l’avons vu. Est-ce un problème de la poule et de l’œuf ?
La solution est soit d’utiliser l’EAC …

exchange-2013-migration-cu11-6

… soit d’ouvrir la console PowerShell locale et de charger les Snap-Ins Exchange manuellement :

exchange-2013-migration-cu11-7

Avertissement : ceci est vraiment pris en charge uniquement pour ce cas particulier étant donné que le « Role Based Access Control » (RBAC) ne fonctionne pas correctement et des problèmes d’autorisation sont susceptibles d’arriver lorsque le Shell ne se connecte pas via les répertoires virtuels PowerShell.
Des comptes administratifs supplémentaires avec des boîtes aux lettres dans des environnements multi-sites permettent d’accéder à l’EMS même si des liens WAN échouent ou lorsque des bases de données individuelles ne peuvent plus être montées.


Plus sur les accrochages de la migration vers Exchange 2013 2016

Pour plus de détails sur Microsoft Exchage Server


A propos de l'auteur

Markus Hengstler

Markus Hengstler travaille chez UMB AG en tant que Senior Systems Engineer dans les domaines Exchange, Windows et Citrix. Grâce à son expérience dans ces domaines, il est certifié «MCSE: Server Infrastructure». Il fait également partie des trois «MCSM: Messaging» en Suisse. Il enseigne depuis 2001 en tant que Microsoft Certified Trainer, et depuis 2010 en tant que Citrix Certified Instructor chez Digicomp.