Peut‑on mettre à niveau sur place un serveur MBAM de Windows Server 2012 vers 2019 ? Oui, mais uniquement via un double saut 2012→2016→2019 et avec MBAM 2.5 SP1. Ce guide opérationnel détaille les étapes, limites, risques, contrôles et alternatives les plus pérennes.
Vue d’ensemble
De nombreuses organisations exécutent encore Microsoft BitLocker Administration and Monitoring (MBAM) sur des hôtes Windows Server anciens. La question récurrente est simple : peut‑on passer directement de l’OS 2012 à 2019 sans réinstallation complète ? La réponse courte est non. Le chemin pris en charge impose un double in‑place upgrade (2012 → 2016 → 2019) et la présence de MBAM 2.5 SP1. Cette trajectoire exige une préparation stricte : sauvegardes, validation d’intégrité des services (IIS, SQL, SSRS), tests méthodiques et fenêtres de maintenance dédiées. Pour un horizon long terme, l’option « clean install » associée à Configuration Manager (SCCM) ou Intune est souvent plus robuste et alignée avec l’évolution du produit.
Résumé opérationnel
| Étape | Actions clés | Points d’attention |
|---|---|---|
| Pré‑migration | • Sauvegardes complètes de l’hôte, des bases SQL MBAM et des clés BitLocker. • Contrôle de santé MBAM : services IIS, pools d’applications, jobs SQL, rapports SSRS. • Export des configurations IIS et SSRS, inventaire des comptes de service. | Appliquer les derniers correctifs sur l’OS 2012 avant de commencer. |
| Chemin supporté | Microsoft n’autorise pas le saut direct 2012 → 2019. Chemin pris en charge : 2012 → 2016 → 2019 (double in‑place upgrade). | Chaque bascule nécessite une fenêtre de maintenance planifiée. |
| Compatibilité MBAM | • Seule MBAM 2.5 SP1 est supportée sur 2016/2019. • Mettre à niveau MBAM avant de changer l’OS si nécessaire. • Après chaque upgrade, réparer ou réinstaller les portails MBAM et les rapports SSRS. | Vérifier les droits et SPN des comptes de service après chaque étape. |
| Bases de données | • Si SQL est local, suivre le même parcours d’OS ou déplacer les bases vers une instance compatible. • Tester la restauration et la récupération de clés BitLocker à blanc. | Garder une sauvegarde hors ligne pour un retour arrière immédiat. |
| Post‑migration | • Appliquer les mises à jour cumulatives OS et SQL. • Tests fonctionnels : récupération de clés, application des GPO, rapports SSRS. • Mise à jour de la documentation et validation conformité. | Effectuer un scan de vulnérabilités et un durcissement TLS. |
Périmètre et prérequis
- Serveur unique MBAM ou rôle web MBAM + instance SQL locale / distante.
- Accès administrateur au domaine, au serveur, à SQL Server et à SSRS.
- Capacité de sauvegarde/restauration vérifiée (OS, SQL, SSRS, IIS).
- Inventaire complet : versions MBAM, .NET, modules IIS, composants SSRS, comptes de service, SPN et ACL.
- Espace disque suffisant (≥ 20 % libres), antimalware en mode maintenance pendant les upgrades.
Chemin de mise à niveau supporté
Le saut direct de l’OS 2012 vers 2019 n’est pas pris en charge pour un hôte MBAM. Il faut procéder en deux étapes successives d’upgrade sur place : d’abord vers 2016, puis vers 2019. Entre les deux, valider systématiquement le bon fonctionnement de la pile MBAM (portails, API, jobs, rapports) avant de poursuivre. Ce séquencement réduit les ruptures de compatibilité et permet des corrections ciblées.
Compatibilité MBAM et composants associés
MBAM n’est plus développé activement ; ses fonctionnalités (portails, reporting, rotation des clés) sont reprises par Configuration Manager et par Intune. Sur les hôtes 2016/2019, seule MBAM 2.5 SP1 est à considérer. Prévoyez également les dépendances suivantes :
| Composant | Exigence typique | Action recommandée |
|---|---|---|
| IIS | Rôles Web requis par MBAM (ASP.NET, Windows Authentication, Static Content, etc.) | Exporter la config, vérifier modules/handlers, réinstaller les prérequis si nécessaire après upgrade. |
| .NET Framework | Version moderne (par ex. 4.7.2/4.8) pour compatibilité et TLS | Mettre à jour .NET après chaque upgrade, puis redémarrer et tester les portails. |
| SQL Server | Instance supportée par MBAM 2.5 SP1 | Maintenir ou migrer vers une version approuvée ; tester la restauration et l’accès SSRS. |
| SSRS | Catalogues et clés de chiffrement protégés | Exporter la clé de chiffrement SSRS, sauvegarder catalogues, re‑lier les sources de données MBAM après upgrade. |
| TLS/Schannel | Protocoles modernes activés (TLS 1.2) | Durcir le chiffrement OS et .NET, valider la connectivité SQL/SSRS après durcissement. |
| Comptes de service | Droits locaux et SPN corrects | Contrôler appartenance aux groupes, droits « Log on as a service », SPN HTTP/SQL. |
Sauvegardes indispensables
Avant tout changement, réalisez des sauvegardes validées et restaurables :
- OS : image système ou snapshot (si virtualisé).
- IIS : configuration et sites.
- SQL : bases MBAM (typiquement MBAM_RecoveryAndHardware et MBAM_Compliance), master et msdb si local, jobs SQL Agent.
- SSRS : clé de chiffrement et catalogues.
- Scripts/GPO : export des GPO BitLocker et scripts d’administration.
# IIS - sauvegarde logique
& "$env:SystemRoot\System32\inetsrv\appcmd.exe" add backup "PreUpgrade-MBAM"
# SQL - sauvegarde des bases MBAM (exemple T-SQL)
-- Recovery & Hardware
BACKUP DATABASE [MBAM_RecoveryAndHardware]
TO DISK = N'X:\Backup\MBAM_RecoveryAndHardware.bak'
WITH COPY_ONLY, INIT, COMPRESSION, CHECKSUM;
-- Compliance
BACKUP DATABASE [MBAM_Compliance]
TO DISK = N'X:\Backup\MBAM_Compliance.bak'
WITH COPY_ONLY, INIT, COMPRESSION, CHECKSUM;
# SSRS - export clé de chiffrement
rskeymgmt -e -f "X:\Backup\SSRS_MBM_Key.snk" -p "MotDePasseFort!"
Préparation détaillée
- Mettre à jour l’OS d’origine : appliquer les derniers correctifs disponibles pour l’édition 2012, redémarrer, vérifier l’intégrité des volumes et l’état SFC.
- Vérifier la santé MBAM : tests de connexion aux portails d’administration et libre‑service, exécution d’un rapport SSRS, contrôle des jobs SQL, consultation des journaux d’événements applicatifs.
- Documenter les dépendances : comptes de service, SPN HTTP/SQL, chaînes de connexion, chemins physiques de sites IIS, versions .NET, règles de pare‑feu, certificats liés à IIS/SSRS.
- Planifier la fenêtre : prévoir l’indisponibilité des portails et la mise en attente des tickets d’assistance sur la récupération de clés durant les bascules.
Procédure in‑place de l’OS
Passage vers une version intermédiaire
Insérer le média d’installation correspondant à l’édition cible (Standard / Datacenter), lancer le programme de mise à niveau et choisir Conserver les fichiers et applications. Pendant l’assistant, laisser cochés les rôles existants, dont IIS et, le cas échéant, SQL/SSRS si installés localement. À l’issue, réappliquer les mises à jour cumulatives disponibles puis redémarrer.
Réparation des composants MBAM
Après chaque bascule d’OS :
- Réinstaller/« Réparer » MBAM Server si un composant ne démarre pas (portails Admin/Self‑Service, service de notification, API).
- Vérifier les pools d’applications, l’authentification Windows, l’identité des pools (compte de service), et les mappings de certificats.
- Ouvrir SSRS, reconfigurer les sources de données si l’authentification intégrée ne fonctionne plus.
- Mettre à niveau .NET si nécessaire, puis redémarrer l’hôte.
Passage vers la version finale
Une fois la plateforme stable sur l’OS intermédiaire, répéter la démarche pour atteindre la cible 2019. Appliquer les mises à jour de sécurité et valider l’intégrité post‑upgrade de la pile MBAM selon le plan de tests ci‑dessous.
Durcissement TLS et .NET
Pour garantir des communications sécurisées entre les portails, les clients et SQL/SSRS, activez les paramètres forts de chiffrement ; vérifiez ensuite que les clients MBAM/BitLocker accèdent sans erreur aux services.
# Activer TLS 1.2 côté .NET (exemple)
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' `
-Name 'SchUseStrongCrypto' -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319' `
-Name 'SchUseStrongCrypto' -Value 1 -PropertyType DWord -Force
Gestion des bases de données
Si SQL Server est hébergé localement et subit lui aussi un in‑place upgrade de l’OS, coordonnez la séquence avec le DBA pour limiter l’indisponibilité et revalider les compatibilités. Si SQL est distant, vérifiez la connectivité post‑upgrade (pare‑feu, TLS, authentification). Dans tous les cas :
- Testez une restauration des bases MBAM dans un environnement de pré‑production.
- Consignez les comptes de connexion SQL utilisés par MBAM, les rôles et les permissions.
- Validez les jobs SQL Agent (purge, maintenances, rapports).
Plan de tests post‑migration
| Objet | Vérification | Résultat attendu |
|---|---|---|
| Portail d’administration | Ouverture, recherche d’un ordinateur, consultation d’un incident de clé | Affichage sans erreur, latence normale |
| Portail libre‑service | Récupération de clé BitLocker avec un identifiant de récupération | Clé retournée correctement et audit consigné |
| Rapports SSRS | Exécution des rapports de conformité | Graphiques et tableaux alimentés, pas d’erreur de source de données |
| Jobs SQL Agent | Exécution manuelle d’un job, revue des historiques | Succès et durée cohérente avec l’avant‑migration |
| GPO BitLocker | Application sur un poste de test, dépôt de clé | Événements MBAM côté client indiquant la sauvegarde réussie |
# Sanity check MBAM côté serveur (exemples)
Get-Service | Where-Object {$_.Name -match 'SSRS|SQL' } | Format-Table -Auto
# Vérification rapide de connectivité SQL depuis l'hôte web
Test-NetConnection -ComputerName "SQL-Prod" -Port 1433
# Sondage HTTP des portails
Invoke-WebRequest -Uri "https://mbam.contoso.tld/HelpDesk" -UseDefaultCredentials -UseBasicParsing | Select-Object StatusCode
# Outil d'après-migration (MBAMClientManagement.ps1) côté clients
# - Automatisation de la vérification d'enrôlement et sauvegarde des clés
Plan de retour arrière
Un rollback rapide et documenté est indispensable. Proposez un scénario T‑0 (instantané VM ou image bare‑metal) et un scénario T‑1 (restauration logique des composants) :
- Restaurer l’OS : snapshot VM ou image système.
- Restaurer IIS : rollback via
appcmd restore backup. - Restaurer SQL : bases MBAM et jobs, contrôles d’intégrité (
RESTORE VERIFYONLY,DBCC CHECKDB). - Restaurer SSRS : catalogues et clé de chiffrement, re‑validation des sources de données.
- Tester : exécuter le même plan de tests qu’en post‑migration.
Quand privilégier une nouvelle installation
Au‑delà de la faisabilité du double in‑place upgrade, la voie la plus fiable reste souvent la création d’un nouvel hôte Windows Server moderne (2019/2022) :
- Installer proprement MBAM 2.5 SP1 ou activer la gestion BitLocker dans SCCM/Intune.
- Migrer les bases MBAM vers la nouvelle instance SQL ou archiver l’historique si bascule vers SCCM/Intune.
- Exécuter une période de chevauchement contrôlée, puis désaffecter l’ancien serveur.
Cette stratégie réduit les risques liés à des héritages de configuration, simplifie la sécurité (TLS, .NET, durcissement) et facilite le retour arrière.
Conformité, licences et gouvernance
- Fin de support : l’OS 2012/2012 R2 est hors support depuis octobre 2023 ; la migration doit être priorisée.
- Licences : MBAM fait partie de MDOP, conditionné à Software Assurance. Assurez‑vous que la couverture est à jour.
- Traçabilité : conservez les journaux MBAM, SQL et SSRS, et mettez à jour la documentation d’exploitation.
Exemple de check‑list
| Item | Responsable | État | Preuve |
|---|---|---|---|
| Sauvegardes OS/IIS/SQL/SSRS | Infra + DBA | À faire / Fait | Emplacement et horodatage des fichiers |
| Export GPO BitLocker | Sécurité poste | À faire / Fait | GPO pack exporté et versionné |
| Inventaire comptes de service et SPN | AD | À faire / Fait | Tableau des comptes et SPN validés |
| Validation SSRS post‑upgrade | DBA | À faire / Fait | Rapport d’essai signé |
| Tests portails MBAM | Support | À faire / Fait | Captures d’écran et journaux d’accès |
Pièges fréquents et leur contournement
- MBAM non mis à niveau : tenter l’upgrade d’OS avec une version MBAM non supportée échoue souvent. Mettre d’abord MBAM à niveau vers 2.5 SP1.
- Perte d’authentification SSRS : après upgrade, les sources de données perdent l’identité. Réappliquer l’authentification et redéployer les rapports MBAM si besoin.
- Modules IIS manquants : certains rôles Web ne suivent pas. Comparer la liste avant/après et réinstaller les modules requis.
- Durcissement TLS trop tôt : activer TLS 1.2 avant d’avoir validé la compatibilité peut couper les flux. Tester en pré‑prod, puis activer en production.
- SPN oubliés : après changement d’OS et de comptes, les SPN HTTP/SQL doivent être revus pour éviter le Kerberos « double hop » défaillant.
Questions fréquentes
Peut‑on réaliser un saut direct d’OS ? Non, la trajectoire prise en charge impose un passage intermédiaire par 2016.
Faut‑il réinstaller MBAM après chaque upgrade ? Pas nécessairement, mais une action de Repair ou une réinstallation des portails et rapports est souvent plus rapide qu’un dépannage au cas par cas.
Que faire si SQL est hébergé à part ? Valider la connectivité, les versions supportées et les droits. L’upgrade de l’hôte web MBAM ne doit pas impacter l’instance SQL distante si les chaînes de connexion restent valides.
Peut‑on migrer vers Intune/SCCM sans perdre l’historique ? Oui : conservez l’instance MBAM comme référentiel d’archive, tout en enrôlant progressivement les nouveaux postes dans SCCM/Intune pour le chiffrement et la rotation des clés.
Procédure type condensée
- Figer le changement, sauvegarder tous les composants et exporter IIS/SSRS.
- Mettre MBAM à niveau vers 2.5 SP1 si nécessaire.
- Effectuer l’upgrade sur place vers 2016, patcher, redémarrer.
- Réparer MBAM, valider portails/rapports, exécuter le plan de tests.
- Effectuer l’upgrade sur place vers 2019, patcher, redémarrer.
- Durcir TLS/.NET, valider le fonctionnement et mettre à jour la documentation.
Conclusion
La mise à niveau sur place d’un serveur MBAM de l’OS 2012 vers 2019 est réalisable à condition de respecter le chemin pris en charge 2012 → 2016 → 2019, d’utiliser MBAM 2.5 SP1, et d’appliquer une discipline rigoureuse : sauvegardes, contrôles post‑upgrade, plan de tests et rollback. Si vos objectifs incluent la simplification opérationnelle et l’alignement avec la feuille de route produit, une nouvelle installation sur un hôte moderne assortie d’une bascule vers SCCM/Intune offre souvent la meilleure durabilité et le moindre risque.
En bref : l’in‑place upgrade est possible mais exigeant ; le « clean install » avec migration contrôlée reste la voie la plus sûre pour une plateforme BitLocker robuste et conforme.