Décommissionnement du mode Exchange Hybride : les points d’attention
Update 16/03/2017 : Cet article est toujours d’actualité, et s’applique également à Exchange 2016.
De nombreux clients choisissent de migrer leur système de messagerie Exchange 2010 ou 2013 vers Exchange Online au travers du mode Exchange hybride. Pour rappel, ce mode permet :
- De migrer les boites des utilisateurs au fil de l’eau
- De conserver la même expérience utilisateur lors de la migration : statut free/busy, règles propres à l’organisation Exchange…
- Une migration transparente pour l’utilisateur : conservation du profil Outlook, les mails ne sont donc pas re-téléchargés depuis le serveur après migration
- De rapatrier une boite migrée vers les serveurs on-premises en cas de besoin
- …
Lors de la mise en place d’une migration Exchange hybride, les administrateurs sont également amenés à configurer :
- La synchronisation des identités de l’annuaire Active Directory vers Azure Active Directory, au travers de l’outil Azure Active Directory Connect.
- La fédération des identités avec ADFS. Bien que l’utilisation d’ADFS n’est pas un prérequis à la migration hybride, elle permet aux utilisateurs connectés au réseau interne de s’authentifier de manière transparente aux services Office 365 (portail Office 365, Outlook Web App, et même Outlook ou Skype for Business).
Lorsque toutles les boites aux lettres sont migrées avec succès dans le cloud, se pose alors la question : comment décommissionner l’infrastructure Exchange on-premises ?
Même s’il n’y a pas de réponse universelle, je souhaiterais éclaircir avec vous certains points, et évoquer notamment les différents impacts que cela pourrait entrainer sur l’administration des boites aux lettres et des utilisateurs.
Impact sur l’administration Exchange
Dans la tête de beaucoup de clients, la fin d’une migration hybride signifie la suppression de tous les serveurs Exchange on-premises. Dans la réalité, cette suppression est un peu plus délicate à entreprendre.
Attention à la synchronisation des objets
Rappelez-vous que suite à la synchronisation des identités avec Azure AD Connect, toute modification doit être faite d’abord dans Active Directory : elle sera ensuite répliquée dans Azure Active Directory à la prochaine synchronisation. Ce fonctionnement s’applique à tous les objets synchronisés : utilisateurs, groupes, contacts.
Une telle restriction apparait de manière très concrète dans l’interface d’administration Exchange Online, lorsque par exemple vous modifiez les adresses SMTP d’une boite aux lettres :
L’erreur est claire : vous essayez de modifier dans le cloud un objet qui est synchronisé depuis Active Directory. Ainsi, même lorsque les boites aux lettres sont migrées dans Exchange Online, vous devez continuer à administrer ces boites depuis votre console d’administration Exchange on-premises.
Pour compliquer un peu plus la tâche, certaines actions d’administration échappent quand même à cette règle, et doivent être exécutées dans Exchange Online : c’est notamment le cas des droits de délégation, qui ne sont pas synchronisés.
Pour plus de facilité, voici un tableau récapitulatif des actions d’administration, et où ces dernières doivent être faites :
Pour s’affranchir complètement des serveurs Exchange pour effectuer ces actions d’administration, il convient de trouver une alternative à l’administration Exchange.
Et PowerShell ?
Et bien non. Même si quasiment tout ce que l’on peut faire dans l’interface graphique a son équivalent en commande PowerShell Exchange, vous aurez quand même besoin d’un serveur Exchange doté du virtual serveur “PowerShell” pour interpréter vos commandes. Pas de serveur Exchange = pas de commandes PowerShell Exchange.
C’est là où les choses se corsent.
La console d’administration Exchange ne fait que modifier certains attributs Active Directory dédiés. Si mettre à jour manuellement l’attribut proxyAddresses est facile pour rajouter une adresse SMTP, il devient plus difficile de savoir quels attributs modifier lorsqu’on souhaite activer une archive sur une boite.
Les solutions de contournement
Solution 1 : Gardez un serveur Exchange (conseillé)
Gardez au moins serveur Exchange d’administration ! Vous pourrez désactiver sans problème le mode hybride, supprimer tous les connecteurs dédiés et stopper la fédération Exchange, mais vous aurez tout de même besoin d’un serveur Exchange 2010 ou 2013 avec le rôle CAS.
Vous n’êtes pas encore convaincu ? Lisez cet article de l’équipe Exchange Server dédié à Exchange 2010 (mais qui s’applique également à Exchange 2013).
Solution 2 : Arrêtez la synchronisation des identités (déconseillé)
Une solution plus radicale consiste à stopper la synchronisation des identités entre Active Directory et Azure Active Directory. Dans ce cas, vous n’aurez plus d’expérience unifiée entre les deux annuaires :
- Les comptes AD et Azure AD seront considérés comme deux identités distinctes, avec chacun ses propres paramètres et son mot de passe. A chaque modification, les administrateurs devront modifier les deux identités de chaque côté pour garder une certaine cohérence, et chaque utilisateur pourra avoir un mot de passe différent pour chaque compte.
- La fédération ADFS ne fonctionnera plus. En effet, la synchronisation est essentielle à la fédération d’identité. L’utilisateur connecté au réseau interne ne bénéficiera plus de SSO, et devra s’authentifier auprès d’Azure Active Directory de manière explicite avec son login Azure AD et son mot de passe cloud.
Pour plus d’informations concernant l’arrêt de la synchronisation Azure AD, je vous conseille de lire cet article officiel.
Update : 07/12/2015 : Microsoft a mis à jour sa documentation pour expliquer également les impacts soulevés dans cet article.
Hello Maxime,
Nice job 🙂
Je pense que tu pourrais rajouter cet article ci dessous, qui a fait grand débat entre les MVP Exchange et le PG 🙂
voici “How and when to decommission your on-premises Exchange servers in a hybrid deployment” = https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx
Merci
Bonjour,
Il y a des changements depuis 1 ans ?
Bonjour,
Non la situation est toujours la même, tant que la synchronisation vers Azure Active Directory restera unidirectionnelle.
Bonjour Maxime,
Merci pour tes infos.
J’ai une migration à faire d’ici la fin de l’année et ne sais pas comment bien faire.
Voici l’énoncé du problème:
J’ai un vieux serveur 2008R2 avec un Exchange2010.
J’ai mis en place Office365 sans synchronisation des identités.
Je n’utilise plus du tout le serveur Exchange. Toutes les Bal sont migrées et mon client bosse comme cela depuis 1an.
Je dois migrer le serveur 2008R2 en 2012R2. Mais je ne veux pas récupérer l’exchange.
L’idée serait de mettre en place l’azure AD connect sur le serveur 2012R2 une fos la migration effectuée.
Comment je dois faire pour supprimer mon serveur Exchange 2010?
Bonne journée et merci d’avance pour ton aide.
Bonjour, si tu mets en place Azure AD Connect, cela veut dire synchroniser les identités qui ne l’étaient pas jusqu’à maintenant. Ce qui veut dire que tu vas introduire le problème décrit dans cet article alors que tu ne l’as pas : à partir du moment où tes identités seront synchronisées, tu devras utiliser le serveur Exchange pour manager les boites aux lettres (alors qu’avant tu ne devais pas). Pour cette raison, je ne te recommande pas de mettre en place la synchro.
Bonjour Maxime,
Merci pour ton excellent article.
Je me suis documenté pendant plus d’un mois sur la mise en place du mode hybride et malheureusement je ne suis tombé ni sur ton article que je découvre seulement maintenant, et encore moins sur des docs Microsoft prévenant du problème.
Ce que je trouve assez décevant de leur part car en utilisant des outils en ligne mis à disposition par Microsoft comme l’assistant de migration Exchange n’avertissent pas, alors que je coche le scénario souhaité : https://technet.microsoft.com/fr-fr/office/dn756393.aspx
Bref du coup on s’est lancé à pleine balle dans le mode hybride. Maintenant je cherche une solution pour éviter d’avoir à garder l’Exchange.
Je vois que tu renvois vers cette article : https://blogs.technet.microsoft.com/exchange/2012/12/05/decommissioning-your-exchange-2010-servers-in-a-hybrid-deployment/.
=> petite question là dessus car dans cet article Microsoft parle de la synchronisation SMTP Matching. Voici le principe : https://support.microsoft.com/fr-fr/help/2641663/how-to-use-smtp-matching-to-match-on-premises-user-accounts-to-office-365-user-accounts-for-directory-synchronization
Qu’en penses tu si pas exemple :
1 – Je supprime le mode hybride, les connecteurs, etc…
2 – Je désactive la syncrho AD Azure Connect
3 – je supprime Exchange
4 – Je réactive la synchro AAD en utilisant cette méthode SMTP matching
Penses tu que cela soit envisageable ?
Bonjour Thomas, il existe bien une documentation qui résume ces impacts lorsqu’on utilise un environnement synchronisé : https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150)
Tant qu’Azure AD Connect ne supportera pas le write-back des attributs pour tous les comptes Azure AD et groupes de distribution, cette limitation d’avoir un serveur d’admin Exchange restera.
L’activation du SMTP Matching ne changera en rien le problème, puisqu’il sert à passer d’un environnement full-cloud à un environnement synchronisé.
Pour revenir à l’obligation de garder un serveur d’admin Exchange, ce n’est pas le mode hybride à proprement parlé qui impose cette restriction, mais la synchronisation des objets AD. Le seul moyen pour administrer des boites aux lettres dans Exchange Online est d’arrêter la synchronisation, et de tout administrer depuis le cloud (ce qui est difficilement envisageable pour la plupart des clients).
Cet article reprend les points évoqués, avec leurs impacts : https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150)
Merci Maxime pour ta réponse rapide.
Oui j’ai vu cet article mais trop tard, le projet avait déjà été acté. Il aurait été bien que Microsoft intègre cela dans les études de scénario. Car quand on mène un projet on l’étudie avant dans son ensemble, mais on n’étudie pas à l’avance forcément tous les points techniques en détail. Ceci dit ça ne change rien car quelque soit la méthode de migration, le problème est le même. Ou alors on aurait décidé de garder l’infra de messagerie sur site, ou de partir sur une autre solution.
Du coup on se retrouve dans cette situation pour une PME de 200 personnes avec un choix à faire :
Solution 1
Soit on garde l’Exchange en maintenant uniquement un CAS sur une VM, mais je suis obligé de le maintenir (mise à jour de CU) tous les 3 mois (ou 6 maximum) à la sortie du nouveau CU pour rentrer dans le scénario supporté par microsoft (Version V et V-1 supporté). C’est quand même dommage si on ne l’utilise plus. Il faut continuer à former une personne, ne serait ce que pour passer le CU et savoir réagir en cas de soucis.
Solution 2
On coupe la synchro. Mais du coup on administre 200 comptes en double. Ça commence à faire beaucoup 🙂
J’espère que Microsoft aura la volonté de trouver une solution à cela. En discutant avec un certain nombre d’admin de PME et de SSII, je sais que ne suis pas le seul à remonter ce besoin.
En tout cas merci beaucoup pour ton article qui nous apporte précisément les impacts et la localisation du lancement de l’action sur les BALs. Top 😉
Bonne journée.
Bonjour
tout d’abord super Article très Explicite
une question quand même se pose , mon client veut absolument supprimer son Exchange local,
et supprimer la synchro AADconnect ( prévenu qui devra gérer en double les identités AD.
Dans cette ordre ?
1) je supprime le mode hybride
2) je supprime la synchro AADconnect
3) je désinstalle L’exchange
ma question :
que vas il advenir des mots de passe des boites mails des user faudra t’il retaper un nouveau mot de passe ou vont t’il garder les options d’expiration réglé par L’AD local auparavant
D’avance merci
Bonjour,
Oui les étapes sont bonnes, pour l’étape 2 notamment, il faudra utiliser le module PowerShell Azure AD et la commande Set-MsolDirSyncEnabled –EnableDirSync $false.
Une fois la synchro coupée, tous les utilisateurs basculeront en mode “cloud”, ils conserveront leur dernier mot de passe synchronisé, mais appliqueront cette fois la stratégie de mot de passe d’Office 365 (à modifier ici : https://portal.office.com/AdminPortal/Home#/settings/security)
Salut,
Premièrement, merci pour ton article, il est très clair un intéressant.
Maintenant, je m’occupe de la migration d’un Exchange 2010 sur SBS2011 vers Office 365 et Exchange Online. J’ai déjà mis en place la synchro Azure AD et j’ai tous mes comptes locaux (~100) dans Office 365 avec les licences pour Office. Actuellement les utilisateurs utilisent ces comptes pour activer leur Office, il est donc plus que délicat de les supprimer ou de désactiver la synchronisation.
Je dois maintenant faire la migration des e-mails, et comme je souhaite garder la synchro Azure AD je suis parti sur la migration hybride. Le défaut de cette méthode comme tu le dis est qu’il faut garder un serveur Exchange en local, mais chez mon client (comme beaucoup d’autres j’imagine), le serveur SBS 2011 avec Exchange est à bout de souffle et je suis gentil, d’ailleurs le but de cette migration est de se débarrasser de ce serveur. Donc ma question, comment faire au mieux ?
1) Une fois la migration hybride terminée, est-il possible de garder un Exchange en local mais sur un autre serveur ou qqch de plus léger ?
2) Sur cet article (https://www.itpromentor.com/remove-hybrid-keep-sync/) l’auteur supprime son Exchange local et ajour un rôle Windows Server Essentials sur un autre serveur pour gérer les identités et faire le lien entre local et cloud, as-tu déjà testé cette méthode, qu’en penses-tu ?
3) Si je désactive la synchro AD Azure, que je fais une migration à basculement, est-ce que je peux ensuite ré-activer la synchro Azure AD afin que les utilisateurs aient le même mot de passe pour leur session, l’adresse e-mail et Office ?
4) J’ai lu que Microsoft avait annoncé qu’ils bossaient sur une solution pour supprimer un Exchange local après une migration hybride plus facilement, es-tu au courant de qqch ?
5) Je suis preneur de toutes autres suggestions 😉
Merci pour ton aide
A+
Bonsoir et merci pour ce bel énoncé des différentes possibilités de cohabitation entre un Exchange On-Premise et Office 365.
J’ai procédé à ma première migration Hybride d’un SBS 2011 (Exchange 2010) vers Office 365 pour le compte d’un de nos clients (30 BàL). Le client ne souhaite pas conserver pour des raisons de coûts une synchronisation AD => Office 365 (Le prix des licences Plan 1 étant moins cher que les licences Business Essentials). Auriez-vous à disposition une procédure permettant de “couper définitivement le cordon” entre l’AD et Office 365 ?
Bonjour,
Dans le cas où les hash de mot de passe étaient synchronisés (Password Hash Sync), il suffit juste de taper la commande Set-MsolDirSyncEnabled –EnableDirSync $false dans le module PowerShell Azure Active Directory. Les utilisateurs conserveront leur dernier mot de passe synchronisé, et leur gestion pourra ensuite se faire directement dans les portails Office 365 / Azure.
Dans le cas d’un environnement fédéré avec ADFS par exemple, il faut aussi convertir le domaine avec la commande Convert-MsolDomainToStandard
Bonjour Maxime,
Article super ! Comme tout le monde te le dit 🙂
J’ai deux questions sur ces problèmes d’administration avec une synchro AD.
1 Si je fais une synchro Azure AD, que je fais une migration à basculement, est-ce que je peux ensuite ré-activer la synchro Azure AD et administrer Exchange dans le Cloud ?
2 Si je fais une migration Hybride avec des licences Azure AD en synchro bi-directionnelle, est-ce que je peux supprimer l’exchange local (vu que j’ai une synchro bi-directionnelle) ?
Bonjour
Effectivement il s’agit d’un super article extrêmement clair. Dommage que je ne soit pas tombé dessus avant 🙁
Je me retrouve exactement dans le même cas que beaucoup : Je ne peux plus supprimer mes 2 serveurs Exchange 2010 GAL 🙁 🙁
De plus j’avais cru comprendre qu’il suffisait de “désactiver” une BAL coté OnPremise pour pouvoir l’administrer coté o365, ce qui n’est bien sûr pas le cas.
Quid si mes serveurs OnPremise me lâchent ? ls sont vieillissants et c’est justement pour cela que nous avons choisi de migrer dans le Cloud)
La seule solution serait effectivement une version Azure Active Directory Connect qui permette l’écriture vers L’AD local, mais bon, ça ne semble toujours pas prévu.