Comment migrer les données de vos anciens serveurs de fichiers

I. Objectifs de ce document :

Ce document a pour but de vous présenter :
– L’outil File Server Migration Toolkit 1.1.
– Le mode opératoire à suivre pour migrer les données de plusieurs serveurs de fichiers Windows vers un seul serveur Windows tout en conservant les permissions NTFS et vos partages.
– L’impact d’une telle migration sur votre production.
– Les avantages d’un serveur de fichier unique.

Ce document est téléchargeable à l’adresse suivante :
http://msreport.free.fr/articles/migration_serveurs_fichiers.pdf

II. Le changement d’architecture :

L’architecture de départ est composé de 2 serveurs de fichiers, un serveur Windows 2000 Server et un serveur Windows 2003 Server. Le but est de remplacer ces deux serveurs fichiers par un seul serveur de fichier Windows 2003 Server. Il n’y a pas de serveurs DFS.

Le fait de remplacer deux serveurs de fichiers en un seul permet :
– De simplifier la procédure de sauvegarde et de restauration.
– De libérer des emplacements dans votre baie (serveur rack) ou de la place dans votre salle serveur.
– De diminuer les coûts de maintenance (un seul contrat de maintenance).
– De diminuer les coûts EDF.

Cette manipulation pose néanmoins les problèmes suivants :
– Comment transférer les données des anciens serveurs vers le nouveau ? Il est en effet nécessaire de conserver les permissions NTFS sur chaque dossier/fichier et de conserver les partages. Il ne doit pas y avoir de perte de données.
– Comment va-t-on gérer le cas où il y a deux partages avec le même nom sur les deux serveurs de fichiers de départ ?
– Comment va-t-on gérer le cas où il y a deux arborescences identiques sur les deux serveurs de fichiers de départ ?
– Comment va-t-on faire pour passer de l’architecture de départ à l’architecture cible sans arrêter la production. En effet une fois les données copiés sur les nouveaux serveurs, les utilisateurs ne doivent plus modifiés les fichiers sur les anciens serveurs de fichiers. Que se passe-il si l’on dispose d’un volume très important de données ? Le transfert des données via le réseau ou la restauration des données via les sauvegardes peut prendre plusieurs heures. Doit-on couper le service pendant le transfert des données ?
– Comment fait-on quand il y a des scripts de logon qui mappent des lecteurs réseaux à partir des partages des anciens serveurs de fichiers?
– Comment fait-on quand il y a des chemins de base définis au niveau des propriétés de chaque compte utilisateur qui pointent vers des partages stockés sur les anciens serveurs de fichiers ?

III. La solution Microsoft :

Microsoft propose un outil appelé le « File Server Migration Toolkit 1.1 » qui va nous permettre de simplifier le transfert des données d’un ou plusieurs serveurs de fichiers vers un seul serveur de fichiers.
Cet outil est gratuit et peut être téléchargé à l’adresse suivante :
* http://www.microsoft.com/…/66f462f5d87b
Pour plus d’informations sur cet outil, voir :
* http://www.laboratoire-microsoft.org/whitepapers/19226/

Cet outil permet d’assurer le transfert des données en plusieurs étapes :
– La première étape (Installation) va permettre de définir quels sont les serveurs sources et le serveur de destination. Cette étape permet aussi de définir la nouvelle arborescence de fichiers sur le serveur de destination, ainsi que le nom des partages. L’utilitaire incluse un outil de détection des conflits (deux répertoires au même emplacement, deux partages avec le même nom…).
– La seconde étape va permettre de faire une copie initiale des fichiers via le réseau. Elle peut être lancée la nuit par exemple.
– L’étape 3 va permettre de finaliser la copie des fichiers (transfert des dernières modifications). Elle va permettre éventuellement de supprimer les partages sur les anciens serveurs de fichiers. C’est aussi à cette étape que les permissions NTFS et les partages sont définis sur les fichiers copiés sur le serveur de destination. Il est possible de lancer l’étape 3 plusieurs jours après l’étape 2 si nécessaire. Pendant cette étape, l’accès aux partages sur les anciens serveurs de fichiers est impossible.

A. L’étape 1 : Installation :

L’application doit être installé et exécuter sur le serveur de destination.

La première étape consiste à définir l’emplacement du fichier de projet. Il est possible de reprendre par exemple un projet arrêté à l’étape 2. Cela arrive souvent quand il y a des conflits ou des problèmes de copie de fichier (serveur éteint, problème réseau temporaire…).

Dans notre cas, nous n’avons pas de serveurs DFS. Donc nous décochons la case « Utiliser le serveur racine DFS suivant ».

On définit ensuite l’emplacement où vont être stocké les données.
Dans notre cas, il s’agit du lecteur f :. Les données seront copiées dans f:\Data.
Attention ce lecteur doit avoir suffisamment de place pour héberger les données de nos deux serveurs de fichiers d’origine.

Il faut ensuite cliquer sur suivant puis terminer.
A cette étape, nous allons pouvoir ajouter les serveurs de fichiers d’origine (serveurs sources). Pour cela il faut cliquer sur « Ajouter un serveur ».

Dans le cas de notre exemple, les deux serveurs sont :
– 172.16.1.1 : il s’agit d’un contrôleur de domaine Windows 2003.
– 172.16.1.3 : il s’agit d’un serveur membre du domaine Windows 2000 Server.

Il est important que les serveurs sources et le serveur de destination soit dans le même domaine ou dans des domaines approuvés car sinon l’exportation de permission ne servira à rien. Les SID/GUID ne seront pas reconnus.

Il y a trois réglages très importants que l’on peut faire au niveau de chaque serveur de fichiers sources.
– Le fait d’arrêter de partager les dossiers sources. Cela permettra d’être sur que les utilisateurs n’utilisent plus les anciens serveurs de fichiers. Au pire si vous souhaitez repartir sur les anciens serveurs de fichiers, le mieux est de faire un export de la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ lanmanserver\Shares. Cette clé contient en effet toutes les définitions des partages sur un serveur Windows (XP, 2000, 2003).

Une fois ce paramètre défini pour chaque serveur de fichier source, on va maintenant pouvoir définir pour chaque partage sur les serveurs sources, le nom de dossier et le nom du partage sur le serveur de destination. Pour cela, il faut aller dans «Afficher par» et sélectionner « Serveurs de fichiers sources ».

Une fois que l’on a terminé, il faut cliquer sur continuer.

Si l’on ajoute un autre serveur de fichier et qu’il existe un autre partage portant le même nom, il y a un conflit. L’application va détecter cela.

La capture ci-dessous montre les messages d’erreurs que l’on obtient lors d’un conflit (avec le dossier igration10 et le partage migration10).

Cliquer sur le bouton voir le rapport pour obtenir la fenêtre ci-dessous.

Remarque :
– Par défaut l’outils prend le nom du partage et rajoute la chaîne de caractères suivante «_adresse_ip_serveur_source). Il ne peut donc pas y avoir de conflits avec les paramétrages par défaut.
– Il est important de valider auparavant, l’arborescence de fichiers cible et les noms des partages. En effet renommer un dossier partagé supprime le partage.
– La phase de validation permet aussi de détecter les fichiers dont le chemin d’accès dépasse 260 caractères. Ces fichiers ne peuvent pas être copiés et généralement ne peuvent plus être modifiés depuis l’explorateur Windows. Cela arrive quand on utilise des outils comme « SuperCopier » pour faire des transferts de données. Ces outils outrepassent la limite définie dans Windows. La seule solution est de réduire la taille du chemin d’accès en renommant des répertoires dans lequel le fichier est contenu. Ce problème entraîne l’apparition d’un avertissement lors de la phase de validation.
– Attention quand un partage contient d’autres dossiers eux même partagés, on doit aussi modifier le nom de ces partages. Ceux-ci prennent par défaut comme nom de partage, le nom du partage sur le serveur source + _adresse_ip_serveur_source. Ce paramètre peut poser des problèmes.

La fenêtre ci-dessous montre ce que la fenêtre obtenue quand la validation a fonctionné. Il y a une croix verte sur chaque partage.

B. L’étape 2 : Copier

Une fois que la phase de validation s’est faite correctement, on peut lancer le transfert initial des données. Pour cela, cliquer sur « Continuer ».
En cas d’échec de la copie d’un fichier (serveurs hors ligne), on peut faire précédent puis continuer. Cela recopie fichiers qui ont échoués.

La copie de certains fichiers peut échouer si ces derniers sont lockés, c’est-à-dire si une application utilise de manière exclusive le fichier. Au pire ces fichiers seront recopiés lors de la phase de finalisation.

Remarque :
– N’hésiter pas à consulter le rapport.
– La vitesse du transfert des données dépendra de la capacité de votre réseau.

La capture ci-dessous montre l’arborescence obtenue.
A cet instant, les partages et les permissions n’ont pas été copiés.

Remarque :
– Lancer de préférence cette étape la nuit afin de ne pas engorger le réseau la nuit.

C. L’étape 3 : la finalisation :

Si la copie s’est bien déroulée, vous pouvez choisir de faire la mise en production final de votre nouveau serveur de fichier.
Pour cela cliquer sur « Continuer ». On obtient alors la fenêtre ci-dessous.

La finalisation est relativement rapide. Environ 20 minutes pour le transfert final de 200 Go de données et la recopie des permissions et des partages (une centaine de partage).

Pendant l’étape 3, on ne peut plus accéder aux données des serveurs sources.

Selon le paramétrage de l’application, les partages sont supprimés sur le ou les serveurs sources (configuration par défaut).
Une fois la finalisation terminée, on obtient cette arborescence :

IV. Les étapes de préparation nécessaires et les limites de l’outil :

Avant d’effectuer le transfert des fichiers, vérifier et valider les points suivants :
– Capacité disque nécessaire sur le serveur de fichiers de destination.
– Temps de transfert des données (par le réseau).
– Arborescence de dossier sur le nouveau serveur.
– Durée d’arrêt du service. Compter environ 2 heures.
– Phase de tests.
– Date et heure interruption du service pour transfert final
– Reprise ou non de l’ancien nom d’un des serveurs de fichiers.
– Audit de la base des certificats. Il faudra peut être récupérer des certificats dans le magasin des certificats sur les serveurs de fichiers sources (si utilisation EFS).
– Audit des tables de routage des serveurs. Il peut y avoir des routes statiques sur les serveurs de fichiers sources.
– Audit des permissions de partage. Attention si des permissions de partage ont été configurées sur les serveurs sources pour des groupes locaux non standards (créés dans la base SAM), ces derniers ne sont pas copiés.
– Penser à sauvegarder vos serveurs de fichiers pour le retour en arrière.
– Penser à exporter la liste des partages sur chaque serveur.
– Lister les partages sur les serveurs sources : vous pouvez utiliser la commande « net share », ou les scripts VBS fournis par Microsoft (Script Center) ou utiliser le script suivant :
http://www.developpez.net/forums/showthread.php?t=302010

V. A savoir :

Il existe des outils similaires pour migrer des serveurs d’impression Windows ou des serveurs web IIS.
* Pour IIS :
http://www.microsoft.com/…/127f933a6cd2&
* Pour les serveurs d’impression :
http://www.microsoft.com/…/msfsc.mspx