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.
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.
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 :
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 ».
É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.
Il existe deux cas dans lesquels le nouveau comportement de la configuration de la connexion peut causer des problèmes :
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 …
… soit d’ouvrir la console PowerShell locale et de charger les Snap-Ins Exchange manuellement :
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 |
Kommentar