Vous migrez un serveur Exchange 2019 hébergé sur Windows Server 2019 vers Windows Server 2022 ? Voici une réponse tranchée et un mode opératoire complet pour réussir sans prise de risque : pas d’« in‑place upgrade », mais des chemins supportés, reproductibles et réversibles.
Sommaire
Vue d’ensemble de la question
Peut‑on faire une mise à niveau sur place (in‑place) de Windows Server 2019 vers Windows Server 2022 en conservant « fichiers, paramètres et applications » lorsqu’un Exchange Server 2019 est installé ? Que faire si l’option est grisée ? Et surtout, quelles voies sont officiellement supportées pour atteindre Windows Server 2022 sans perdre la configuration Exchange ?
Réponse & solution courte
Non, la mise à niveau in‑place n’est pas supportée sur un serveur qui exécute Exchange 2019. Le fait que l’option « Conserver fichiers, paramètres et applications » soit grisée est donc normal dans ce scénario. Vous devez procéder par installation propre, via l’une des deux approches supportées :
- Migration latérale (recommandée) : déployer un nouveau Windows Server 2022, y installer Exchange 2019 (CU supportée), basculer les services et les données, puis décommissionner l’ancien serveur.
- Réinstallation propre + RecoverServer sur le même nom d’hôte : réinstaller l’OS, puis reconstruire le rôle Exchange depuis Active Directory avec
Setup.exe /RecoverServer.
Voies supportées et recommandées
Migration latérale (recommandée, la plus souple)
Cette approche minimise le risque, permet un retour arrière facile et n’implique aucune opération hors support.
Préparer l’existant
- Sauvegardes complètes : système, bases de données Exchange, dossiers publics, partages, scripts, clés de registre spécifiques, et captures de configuration (screenshots, exports CSV).
- Mettre Exchange 2019 à jour vers la dernière CU + SU supportée sur Windows Server 2019 (sur l’ancien serveur), afin d’être dans un état sain avant la migration.
- Inventorier et exporter la configuration : connecteurs d’envoi/réception, règles de transport, certificats (PFX), répertoires virtuels/URLs (OWA, ECP, EWS, ActiveSync, Autodiscover), listes d’adresses, politiques, journaux, connecteurs de journaling, agents de transport, tâches planifiées, fichiers web.config modifiés, etc.
Déployer le nouveau serveur
- Installer Windows Server 2022 complètement à jour (même domaine AD), puis les prérequis Exchange (rôles/Features, .NET supporté, redistribuables requis).
- Installer Exchange Server 2019 avec une CU supportée sur Windows Server 2022, dans la même organisation.
- Assigner les certificats TLS (import PFX), configurer les namespaces/URLs, vérifier Autodiscover et les protocoles clients.
Basculer la charge
- Migrer les boîtes d’arbitrage, les boîtes aux lettres et, si présents, les dossiers publics.
- Si vous utilisez un DAG : ajouter le nouveau nœud, créer/répliquer des copies de bases, puis réaliser des bascules contrôlées (activation preference, AutoDatabaseMountDial).
- Recréer/ajuster les connecteurs SMTP (send/receive) et valider le flux mail interne/externe.
Bascule des services & DNS
- Pointer les namespaces (Autodiscover, OWA/ECP, EWS, MAPI/HTTP, SMTP) vers le nouveau serveur.
- Mettre à jour DNS, reverse proxy / WAF, load‑balancer, certificats TLS côté périphériques.
Validation & retrait de l’ancien
- Tester Outlook (MAPI/HTTP), OWA, mobiles,
Test-Mailflow, santé des services et des files. - Retirer l’ancien serveur du DAG si applicable, désinstaller Exchange proprement, puis décommissionner le serveur.
Avantages clés : risque faible, roll‑back simple (on ne coupe pas l’ancien tant que le nouveau n’est pas validé), possibilité de coexister pour réaliser une bascule progressive et transparente.
Réinstallation propre sur le même hôte (RecoverServer)
Utile si vous devez réutiliser le même nom d’hôte et/ou le même matériel/VM.
Avant réinstallation
- Sauvegardes complètes, export des certificats PFX (avec clés), inventaire de tous les paramètres.
- Relever précisément la version d’Exchange (CU/SU) et les chemins des bases/journaux.
Réinstaller l’OS
- Installer Windows Server 2022 avec le même nom d’hôte, joindre au domaine, appliquer mises à jour & prérequis.
Récupérer le serveur Exchange
- Lancer :
Setup.exe /Mode:RecoverServer /IAcceptExchangeServerLicenseTerms_DiagnosticDataON(ou..._DiagnosticDataOFFselon votre politique). - La CU du support d’installation doit correspondre à celle enregistrée dans Active Directory pour ce serveur.
- Restaurer/assigner les certificats, revalider les URLs, reconnecter les bases/dossiers publics, réintégrer au DAG si nécessaire.
Valider
- Contrôler la connectivité (clients & protocoles), la santé des bases (
Get-MailboxDatabaseCopyStatussi DAG), le flux mail et les sauvegardes.
À retenir : RecoverServer n’est pas une mise à niveau in‑place. C’est une reconstruction supportée à partir de la configuration stockée dans Active Directory. Vous obtenez un serveur propre sur Windows Server 2022, réinséré correctement dans l’organisation Exchange.
Pourquoi l’in‑place upgrade n’est pas supportée
- Exchange modifie profondément l’OS (IIS, HTTP.SYS, services, ACLs, registres, composants .NET, librairies). Une mise à niveau sur place introduit un état non déterministe et difficilement supportable.
- En cas d’incident ultérieur, l’éditeur peut refuser la prise en charge si l’OS a été upgradé in‑place avec Exchange installé.
- Les chemins supportés offrent un point de restauration clair, une traçabilité et l’assurance de rester conforme.
Tableau de décision rapide
| Critère | Migration latérale | RecoverServer (même nom) |
|---|---|---|
| Contrainte de conserver le nom d’hôte | Non nécessaire | Oui, c’est le cas d’usage |
| Temps d’indisponibilité | Très faible, bascule progressive | Courte fenêtre lors du switch |
| Complexité | Faible à moyenne | Moyenne (discipline sur versions) |
| Retour arrière | Facile (ne pas décommissionner l’ancien) | Possible via restauration intégrale |
| Conformité/Support | 100% supporté | 100% supporté |
Checklist détaillée et bonnes pratiques
Avant de commencer
- Valider la santé Active Directory (réplication, DNS, temps, lingering objects inexistants).
- S’assurer que l’ancienne plate‑forme est stable et à jour (CU/SU Exchange, OS patché).
- Dimensionner le nouveau serveur (CPU/RAM/IOPS) selon le profil de charge et le sizing Exchange.
- Préparer le plan DNS (durées de TTL réduites quelques jours avant la bascule pour accélérer la propagation).
- Documenter toutes les dépendances : relais SMTP internes, scanners, applicatifs LOB, archivage/journaling, anti‑spam, appliances d’authentification, load balancers.
Inventaire de configuration – exemples de commandes
# Version d’Exchange installée sur l’ancien
Get-ExchangeServer | fl Name,Edition,AdminDisplayVersion
# URLs et namespaces
Get-ClientAccessService | fl Name,AutoDiscoverServiceInternalUri
Get-MapiVirtualDirectory | fl Identity,InternalUrl,ExternalUrl,IISAuthenticationMethods
Get-OwaVirtualDirectory | fl Identity,InternalUrl,ExternalUrl
Get-WebServicesVirtualDirectory | fl Identity,InternalUrl,ExternalUrl
Get-ActiveSyncVirtualDirectory | fl Identity,InternalUrl,ExternalUrl
# Certificats (export PFX ensuite)
Get-ExchangeCertificate | fl Thumbprint,Services,NotAfter,Subject
# Connecteurs SMTP
Get-SendConnector | fl Identity,AddressSpaces,SmartHosts,SourceTransportServers
Get-ReceiveConnector | fl Identity,Bindings,RemoteIPRanges,AuthMechanism,PermissionGroups
# Règles de transport / DLP / Journaling / Agents
Get-TransportRule | select Name,Mode,State
Get-JournalRule | select Name,State,JournalEmailAddress
Get-TransportAgent
# Dossiers publics (si utilisés)
Get-OrganizationConfig | fl PublicFoldersEnabled Déploiement Exchange 2019 sur Windows Server 2022
- Installer les Features Windows requises pour Exchange (IIS, .NET, RSAT‑ADDS, etc.).
- Exécuter le Setup Exchange 2019 avec une CU supportée sur Windows Server 2022 (compte membre de Schema Admins si une mise à jour du schéma est nécessaire).
- Après installation, importer le PFX et assigner les services :
Enable-ExchangeCertificate -Thumbprint <TP> -Services IIS,SMTP. - Configurer les URLs : Autodiscover, OWA/ECP, EWS, MAPI/HTTP, OAB, ActiveSync.
Bascule des boîtes et des services
- Boîtes d’arbitrage : les déplacer en premier (pré‑requis à certaines opérations).
- Boîtes aux lettres : planifier des move requests par lots (heures creuses).
- Dossiers publics : préparer la migration/réassociation selon le type (modern public folders).
- Connecteurs : recréer ou réassigner les serveurs source/target, ajuster les plages IP de confiance, retester le flux.
- DNS/Load balancer : basculer progressivement, vérifier la persistance/affinité si nécessaire.
Validation post‑bascule – commandes utiles
# Santé des services Exchange
Get-Service *Exchange* | sort Status,Name
# Flux de courrier
Test-Mailflow
Get-Queue
# Santé des bases (en DAG)
Get-MailboxDatabaseCopyStatus \*
# Vérification des URLs
Get-MapiVirtualDirectory | fl Identity,InternalUrl,ExternalUrl
Get-OwaVirtualDirectory | fl Identity,InternalUrl,ExternalUrl
Get-WebServicesVirtualDirectory | fl Identity,InternalUrl,ExternalUrl Spécificités par scénario
Environnement hybride Microsoft 365
- Planifier la revalidation du connecteur hybride via l’assistant (HCW) après la bascule des namespaces.
- Revoir les connecteurs Exchange Online (smarthosts, IPs de confiance) et les enregistrements DNS publics (Autodiscover, MX si concernés, SPF, DKIM/DMARC si gérés localement).
- Tester la libre/busy, le flux cross‑premises et la discoverability Outlook.
Avec DAG
- Ajouter le nouveau serveur comme membre du DAG (stockage, réseau, witness).
- Créer des copies de bases, laisser l’indexation rattraper, puis promouvoir le nouveau serveur via activation preference.
- Basculer les bases les unes après les autres, observer la latence de réplication et la santé du cluster.
- Retirer proprement l’ancien membre du DAG puis désinstaller Exchange.
Edge Transport / relais SMTP / appliances
- Mettre à jour les listes d’émetteurs approuvés, plages IP et ACLs.
- Régénérer les abonnements Edge si utilisés.
- Vérifier TLS : ciphersuites, versions de protocole, et certificats côté périphériques.
Pièges à éviter
- Confondre « ça marche » et « c’est supporté » : certains témoignages d’in‑place « réussis » ne sont pas opposables en production.
- Ignorer les versions exactes (CU/SU) : RecoverServer exige une correspondance stricte avec l’objet serveur en AD.
- Oublier d’exporter les certificats (avec clé privée) : impossible de réassigner IIS/SMTP sans PFX.
- Négliger le namespace (Autosdiscover, OWA, EWS, MAPI/HTTP) : cause n°1 d’incidents post‑bascule.
- Basculer DNS avec des TTL élevés (propagation lente) : pensez à réduire les TTL en amont.
Modèle de plan de migration
| Période | Tâches principales | Livrables | Critères de réussite |
|---|---|---|---|
| J‑10 à J‑5 | Inventaire, sauvegardes, mises à jour Exchange/OS, baisse des TTL DNS | Exports CSV, PFX, rapports de santé AD/Exchange | Santé OK, backups validés |
| J‑4 à J‑2 | Installation Windows Server 2022, prérequis, installation Exchange 2019 (CU supportée) | Serveur prêt, certificats importés | Services Exchange démarrés, URLs configurées |
| J‑1 | Tests protocole, préparation des lots de migration | Plan de bascule documenté | Tests clients OK |
| J0 (bascule) | Move des boîtes, bascule DNS/LB, validation mailflow | Procès‑verbal de bascule | Aucun message en file, clients connectés |
| J+1 à J+3 | Monitoring, correctifs mineurs, retrait DAG si besoin | Rapport post‑migration | Stabilité confirmée |
| J+5 | Désinstallation Exchange sur l’ancien, décommission | Serveur supprimé de l’org | Clean‑up AD/DNS terminé |
Exemples de scripts utiles
Export de la configuration (à exécuter sur l’ancien serveur) :
# Dossier d’exports
$dir = "C:\Export-Exchange"
New-Item -ItemType Directory -Force -Path $dir | Out-Null
# Connecteurs
Get-SendConnector | Export-Csv "\$dir\SendConnectors.csv" -NoTypeInformation -Encoding UTF8
Get-ReceiveConnector | Select-Object Identity,Bindings,RemoteIPRanges,AuthMechanism,PermissionGroups |
Export-Csv "\$dir\ReceiveConnectors.csv" -NoTypeInformation -Encoding UTF8
# Règles de transport
Get-TransportRule | Export-Csv "\$dir\TransportRules.csv" -NoTypeInformation -Encoding UTF8
# Certificats
Get-ExchangeCertificate | Export-Csv "\$dir\Certificates.csv" -NoTypeInformation -Encoding UTF8
# URLs virtuelles
Get-OwaVirtualDirectory | Select Identity,InternalUrl,ExternalUrl | Export-Csv "\$dir\OWA.csv" -NoTypeInformation
Get-WebServicesVirtualDirectory | Select Identity,InternalUrl,ExternalUrl | Export-Csv "\$dir\EWS.csv" -NoTypeInformation
Get-ActiveSyncVirtualDirectory | Select Identity,InternalUrl,ExternalUrl | Export-Csv "\$dir\EAS.csv" -NoTypeInformation
Get-MapiVirtualDirectory | Select Identity,InternalUrl,ExternalUrl | Export-Csv "\$dir\MAPI.csv" -NoTypeInformation Export/Import du certificat PFX :
# Sur l’ancien serveur (export)
$pwd = ConvertTo-SecureString "MotDePasseFort!" -AsPlainText -Force
$mypfx = "C:\Export-Exchange\certificat.pfx"
Get-ExchangeCertificate -Thumbprint <THUMBPRINT> | Export-ExchangeCertificate -FileName $mypfx -Password $pwd
# Sur le nouveau serveur (import + assignation)
\$pwd = ConvertTo-SecureString "MotDePasseFort!" -AsPlainText -Force
Import-ExchangeCertificate -FileData (\[Byte\[]]\$(Get-Content \$mypfx -Encoding byte -ReadCount 0)) -Password \$pwd |
Enable-ExchangeCertificate -Services IIS,SMTP Contrôles finaux après bascule
- Autodiscover répond et renvoie les bons endpoints.
- OWA/ECP/EWS/MAPI/HTTP/ActiveSync opérationnels (tests depuis LAN et Internet).
- Flux SMTP interne/externe OK (tests depuis applications et périphériques).
- Journalisation/Journaling, règles de transport et DLP appliquées.
- Files de transport vides, journaux d’événements propres.
- Sauvegarde complète relancée et validée sur le nouveau serveur.
Questions fréquentes
Et si l’option « Conserver fichiers, paramètres et applications » n’était pas grisée ?
Même si elle apparaissait, l’in‑place resterait non supportée pour un serveur Exchange. Vous resteriez hors des bonnes pratiques et risqueriez un refus de support.
Puis‑je changer le nom du serveur lors d’une migration latérale ?
Oui, c’est le cas général. Les namespaces/URLs assurent la continuité côté clients. Si vous devez conserver le même nom, préférez RecoverServer.
Quid des versions de CU/SU ?
Alignez toujours vos versions. Installez sur Windows Server 2022 une CU d’Exchange 2019 explicitement supportée par cet OS. Sur l’ancien serveur, mettez à jour au plus récent niveau supporté pour limiter les écarts.
Combien de temps prévoir ?
La préparation et la validation sont la majeure partie du travail. La bascule elle‑même peut être très courte si la migration est bien scénarisée.
Synthèse opérationnelle
- In‑place upgrade : non supporté sur un serveur Exchange 2019 → Windows Server 2022.
- Chemins supportés :
- Migration latérale vers un nouveau Windows Server 2022 + Exchange 2019 (CU supportée), puis décommission de l’ancien.
- Réinstallation propre + RecoverServer sur le même nom d’hôte.
- Clés de réussite : préparation minutieuse, sauvegardes validées, CU/SU à jour, export complet de la configuration, plan DNS clair, validation post‑bascule exhaustive.
Modèle de validation technique
| Domaine | Vérifications | Commande/Action | Résultat attendu |
|---|---|---|---|
| Services | Exchange & IIS démarrés | Get-Service *Exchange* | Tous en Running (excepté ceux non utilisés) |
| Certificats | PFX importé et assigné | Enable-ExchangeCertificate ... -Services IIS,SMTP | Pas d’alerte TLS |
| Autodiscover | Endpoint correct | Test via client/outil | Découverte OK, pas de prompt d’auth |
| Mailflow | Interne & externe | Test-Mailflow, envoi/réception | Messages livrés, files vides |
| DAG | Copies saines | Get-MailboxDatabaseCopyStatus * | État Healthy, index OK |
| Surveillance | Événements critiques | Observateur d’événements | Aucune erreur récurrente |
Conclusion
La mise à niveau in‑place d’un serveur Exchange 2019 vers Windows Server 2022 n’est pas supportée. Pour rester conforme, robuste et réversible, choisissez une installation propre : migration latérale (souple et recommandée) ou RecoverServer (si vous devez conserver le même nom). En appliquant la préparation, l’alignement des versions et les contrôles listés ici, vous obtenez une transition maîtrisée, sans surprise et prête pour la production.