Etude de cas — Migration & Windows Server
Migrer un serveur de fichiers 8 To sans changer une seule lettre du chemin d'acces
Comment j'ai remplace le serveur de fichiers principal d'un organisme de formation multi-sites dans Azure — bascule du disque de donnees, droits NTFS preserves, DNS et Kerberos geres proprement — sans que les ~450 collaborateurs ne voient la difference.
- 8 To
- migres par bascule de disque, sans recopie
- ~450
- collaborateurs — migration invisible cote utilisateur
- 0
- octet recopie, droits NTFS preserves a l'identique
- 0
- rollback necessaire — mais documente et pret
Le contexte
Un organisme de formation professionnelle multi-sites heberge son serveur de fichiers principal sur une VM Windows dans Azure : un disque de donnees manage de 8 To (Standard HDD, zone de disponibilite fixee), des partages SMB et des droits NTFS construits au fil des annees. Le serveur doit etre remplace par une nouvelle VM.
Contrainte absolue : environ 450 collaborateurs accedent aux donnees via un alias DNS unique — chemin UNC mappe par GPO, scripts et habitudes. Ce chemin ne doit pas changer d'une seule lettre, et la migration doit etre invisible pour les utilisateurs en dehors d'une courte fenetre planifiee.
La demarche
- 01
Audit prealable du service rendu, pas seulement du disque
Inventaire complet des partages SMB et de leurs permissions de partage, export des ACL NTFS de reference, releve des dependances (mappages de lecteurs par GPO, scripts, applications pointant sur le chemin UNC), et verification que les acces passent bien par l'alias DNS et non par le nom reel de la machine — la condition qui rend la bascule transparente possible. Releve des sessions et fichiers ouverts pour dimensionner la fenetre de coupure.
- 02
Choix de la strategie : bascule de disque plutot que copie
Plutot que recopier 8 To — des jours de robocopy, avec un risque de derive entre passes — le disque manage est detache de la VM source et rattache a la VM cible. Les droits NTFS etant portes par le systeme de fichiers et exprimes en SIDs de domaine, ils survivent integralement a l'operation : zero recopie, zero re-permissionnement. Point de vigilance traite : un disque manage zonal ne s'attache qu'a une VM de la meme zone de disponibilite — la VM cible a ete provisionnee en consequence (sinon, passage oblige par snapshot pour recreer le disque dans la bonne zone).
- 03
Filet de securite avant tout geste
Snapshot du disque de 8 To pris avant la bascule. Cout marginal, rollback garanti — la migration ne detruit rien tant que la validation n'est pas complete.
- 04
Reprise de la configuration des partages
Les definitions de partages SMB ne vivent pas sur le disque de donnees mais dans la configuration du serveur : export depuis la source et recreation scriptee en PowerShell sur la cible (partages + permissions de partage), pour un etat strictement identique et rejouable.
- 05
La partie DNS/AD, faite proprement
Abaissement du TTL de l'enregistrement de l'alias plusieurs jours avant la bascule ; le jour J, re-pointage de l'alias vers la nouvelle VM dans le DNS integre a l'AD. Et surtout le piege que beaucoup oublient : l'authentification Kerberos — enregistrement des SPN de l'alias sur le compte machine de la nouvelle VM (et retrait cote ancienne), plus la configuration serveur necessaire pour qu'il accepte les connexions sous un nom qui n'est pas le sien. Voir l'encadre ci-dessous.
- 06
Repetition et validation avant ouverture
Tests avec des comptes pilotes representatifs des differentes populations de droits : acces par le chemin UNC historique, verification des ACL effectives, ecriture/lecture, comportement des mappages GPO.
- 07
Cutover maitrise
Communication en amont aux utilisateurs, fermeture propre des sessions SMB sur la source, detachement/rattachement du disque, recreation des partages, bascule DNS, purge des caches, batterie de verifications — le tout dans une fenetre courte et annoncee.
- 08
Rollback toujours possible, nettoyage differe
Retour arriere documente : re-pointage DNS + rattachement du disque a la source. Snapshot et VM source conserves jusqu'a validation complete, la decommission n'intervenant que dans une phase de nettoyage separee.
L'architecture
Les resultats
- Un chemin d'acces strictement inchange pour ~450 collaborateurs — la migration est invisible cote utilisateur
- 8 To migres sans recopier un seul octet : bascule du disque manage au lieu d'une copie, droits NTFS preserves a l'identique
- Une authentification Kerberos preservee sur l'alias grace a la gestion des SPN — pas de retrogradation NTLM silencieuse
- Un rollback documente et jamais necessaire ; snapshot et serveur source conserves jusqu'a validation complete
- Un processus scripte (export/recreation des partages, verifications) reutilisable pour de futures migrations
Competences mises en oeuvre
- Azure (disques manages, snapshots, zones de disponibilite)
- Windows Server
- SMB & NTFS (ACL, permissions de partage)
- PowerShell
- DNS (zones integrees AD, TTL, alias)
- Active Directory & Kerberos (SPN, comptes machine)
- GPO (mappages de lecteurs)
- Methodologie (audit → repetition → cutover court, rollback systematique, decommission differee)
Une migration sensible a preparer ?
Audit, strategie, repetition et rollback : parlons de votre contexte.