Migration d'Exchange 2010 vers 2016 avec dossiers publics et applications héritées

Je commence par vérifier la compatibilité, pas par installer : Exchange 2010 doit être au niveau SP3 avec le dernier RU, le schéma et la forêt doivent être préparés, et les contrôleurs de domaine doivent être joignables depuis les futurs serveurs 2016. Outlook 2007 n'est pas supporté avec Exchange 2016 : les 2 100 postes doivent être remplacés ou mis à niveau avant la bascule de leur boîte, sinon ils perdront la connexion.

Ensuite :

1. Étendre le schéma avec la version 2016 et préparer Active Directory.
2. Installer Exchange 2016 dans l'organisation existante, en commençant par un site pilote avec quelques boîtes de test.
3. Publier un espace de noms 2016 (par exemple mail2016.adventureworks.fr) et conserver mail.adventureworks.fr vers 2010 pendant la coexistence. Le certificat doit contenir les deux noms, plus Autodiscover, et être renouvelé avant l'expiration des 4 mois.
4. Configurer les connecteurs de transport et vérifier le flux bidirectionnel 2010 ↔ 2016, y compris le relais applicatif.
5. Déplacer les boîtes par lots, en commençant par les utilisateurs pilotes, puis basculer le nom externe vers 2016 lorsque la majorité des boîtes sont migrées.

Le point de blocage principal est le client Outlook 2007 et les applications MAPI/RPC ; le second est le certificat unique, qui doit être valide pour les deux générations pendant toute la coexistence.

Exchange 2016 ne réplique pas les dossiers publics depuis Exchange 2010 : la réplication de dossiers publics entre versions n'est pas prise en charge. Il faut utiliser la migration de dossiers publics par demande de migration, après avoir préparé la hiérarchie cible.

• Exécuter les scripts d'analyse pour exporters les statistiques et générer le fichier de correspondance dossiers/boîtes aux lettres. Cela permet de répartir 400 Go sur plusieurs boîtes aux lettres de dossiers publics et d'éviter une boîte unique trop grosse.
• Créer la hiérarchie cible dans Exchange 2016, puis lancer une demande de migration. La première synchronisation peut être longue ; elle se fait hors heures ouvrées.
• Planifier une période de gel : communication aux utilisateurs, verrouillage des dossiers publics 2010, synchronisation finale, puis bascule. Sans gel, les modifications pendant la dernière synchronisation sont perdues.
• Traiter les 180 dossiers mail-enabled : vérifier les adresses de messagerie et les autorisations après migration, car les autorisations et les adresses doivent être contrôlées séparément.
• Tester l'accès Outlook et OWA aux dossiers migrés avant de décommissionner 2010.

La migration par batch de 50 Go permet de reprendre un batch en cas d'échec sans bloquer les 400 Go.

Les applications qui envoient du SMTP non authentifié vers Exchange 2010 doivent être traitées avant la décommission : je crée un connecteur de réception dédié sur Exchange 2016, anonyme, limité aux adresses IP des applications, et je teste chaque flux. Pour MAPI/RPC, les applications doivent être migrées vers EWS ou vers un serveur 2016 ; Outlook 2007 doit être remplacé car il n'est pas supporté par Exchange 2016, et Outlook 2010 doit être au niveau de service requis.

Avant de retirer le dernier serveur 2010 :

• Vérifier qu'il ne reste aucune boîte aux lettres, boîte d'arbitrage, boîte de journal, boîte de dossiers publics ou file d'attente sur 2010.
• Vérifier que les connecteurs de transport, les règles de transport, les listes d'adresses et l'OAB sont recréés ou migrés.
• Tester Autodiscover, le nom externe unique, le courrier entrant et sortant, et les applications.
• Surveiller les files de transport et les journaux pendant plusieurs jours après la bascule.
• Mettre à jour le DNS et les enregistrements MX uniquement après validation, puis retirer 2010 du réseau.

Le risque principal n'est pas Exchange lui-même, mais les applications et les clients qui utilisent des chemins implicites (relais SMTP, MAPI/RPC, ancien nom) et qui ne sont découverts qu'après la décommission.