Un plan sauvegarde simple et efficace

Bonjour,

me revoilà à l'attaque!

Aujourd'hui nous voyons un élément essentiel et incontournable d'un système d'information, la sauvegarde.

/!\
Je précise en préambule que cet article a pour but de contourner des limitations de l'interface d'un Windows Backup classique, et donc une analyse fine du système devra toujours être réalisée par des experts.
En effet certains éléments, comme des bases de données, peuvent nécessiter des procédures, et logiciels spécifiques, pour mettre en œuvre un plan de sauvegarde adapté. Le périmètre spécifique à l'entreprise devra également être pris en compte.

Je ferme la parenthèse, et en rouvre une autre, pour parler des limitations de l'outil Windows Backup.

Il est aujourd'hui performant, et peut très bien convenir pour des utilisations basiques, ou en complément d'autres systèmes professionnels.
Cependant, il comporte des limitations qui sont incompréhensibles, mais qui pourtant existent:

• Lorsqu'on sauvegarde sur un partage réseau, la sauvegarde est toujours complète, il n'est pas possible de réaliser de l'incrémentiel, et donc limiter le temps de sauvegarde, ainsi que le retour en arrière dans le temps grâce aux versions précédentes de ces sauvegardes.
• Lorsqu'on utilise l'interface graphique, il n'est pas possible de programmer plusieurs jobs de sauvegardes différents.

Je vous avoue que j'ai du mal à comprendre pourquoi de telles limitations existent, mais c'est le cas, et il faut faire avec.
J'ose espérer que ces limitations seront levées avec le temps, mais rien n'est moins sûr.

Mais nous sommes pragmatiques, donc nous allons faire avec!

Nous allons contourner partiellement ces limitations, en utilisant des tâches planifiées de sauvegarde! Nous aurons donc bel et bien plusieurs jobs de sauvegarde. Par contre le fait que les jobs soient "complets" fait que in fine la volumétrie de l'espace de stockage sera plus volumineuse!

Un coup pour rien :

La première action à effectuer est de créer un dossier que je vais appeler "backup" sur mon NAS ou sur mon serveur distant.

Pas besoin de mapper un lecteur réseau, ceci n'est pas pris en charge par Windows Backup.

Je vérifie tout de même que j'ai bien accès à ce dossier depuis mon serveur:

J'accède à mon partage réseau

Ensuite, et cela peut sembler paradoxal, mais je lance un backup complet de mon serveur. Ceci afin de vérifier ce qui est sauvegardé, et donc vérifier que mon script sauvegardera bien tous les éléments.

Je créé une "sauvegarde unique":

Je lance la console Sauvegarde Windows et je sélectionne sauvegarde unique.

Je sélectionne serveur complet:
 

Je sélectionne "dossier partagé distant":
 

Je rentre mon chemin, dans mon cas "\\NAS\backup":

Je visualise les éléments qui seront sauvegardés, et j'aurai un point de comparaison une fois mes jobs mis en place:

Tout est sauvegardé, même mon état du système et mes volumes de démarrage et de récupération.

A ce stade inutile d'aller plus loin, j'ai récupéré les informations dont j'avais besoin.

Les mains dans le cambouis :

Maintenant les choses sérieuses commencent...on va créer un plan de sauvegarde professionnel, avec des sauvegardes "grand-père, père, fils".

Nous allons donc créer un job par jour de la semaine, du lundi au vendredi, puisque nous ne travaillons pas le weekend.

Chaque fois la sauvegarde précédente étant écrasée, dans ce cas de figure nous ne pouvons remonter qu'une semaine en arrière.
Nous mettons donc en place une sauvegarde bi-hebdomadaire, par exemple le 1 et le 15 de chaque mois (il faut toujours être vigilent sur les jobs de fin de mois, certains mois finissent à 30 jours, voir à 28 pour février, ou 29 pour les années bissextiles).
Nous mettons en place une sauvegarde mensuelle, qui permettra de remonter 1 mois en arrière, et enfin une sauvegarde trimestrielle, en janvier, avril, juillet et octobre.

Nous serons donc à même de remonter loin de le temps, au détriment de l'espace disque disponible.
Cependant il est important de conserver des sauvegardes sur une longue durée, ceci afin de pouvoir récupérer une version de document différente de celle actuelle, ou si un fichier a disparu et qu'on s'en rend compte un long moment après.

Je vais créer l'arborescence qui va recevoir ces jobs sur mon NAS de destination:

Ils sont dans l'ordre car je viens de les créer, je vais les organiser pour que cela soit plus pro.

Là tout est à la racine, pour bien faire je vous laisse le soin d'organiser les dossiers en séparant les jours, des quinzaines, des trimestres.

Œuvrer dans la lumière :

Me voilà prêt à œuvrer, et à vous éclairer (petit clin d’œil à mes étudiants) sur la manière de configurer concrètement mes jobs.

Je vais utiliser l'utilitaire en ligne de commande de Windows, wbadmin.

Pour valider les options et paramètres, je tape mes commandes dans une invite de commande DOS.
Je pourrais le faire dans une invite de commande PowerShell, mais il faudrait que je modifie les paramètres, en rajoutant des guillemets, que je devrais ensuite supprimer pour mon job, je reste efficient et tape directement dans ma fenêtre cmd.

La commande wbadmin est bien faîte, et permet de réaliser plus d'actions que l'interface graphique le permet, et notamment créer plusieurs jobs distincts!

Nous souhaitons sauvegarder l'ensemble du serveur, en incluant les partitions de boot et de récupération, qui n'ont pas de lettre de lecteur attribué. Je vais donc identifier ma partition grâce à son numéro de volume, en tapant la commande mountvol:

Je vois bien l'ID de mon volume sans point de montage...

Je sélectionne et copie l'ID de volume.

Maintenant je tape la commande suivante, qui va me permettre de sauvegarder tous mes volumes, avec des points de montage ou non, mais surtout l'état du système et tous les paramètres:

wbadmin.exe start backup -backuptarget:\\nas\backup\lundi\ -include:c:,d:,\\?\Volume{e847a19f-2f6d-4e74-a8bb-aa1c2bfd35e2}\ -allcritical -systemstate -quiet

Voici le lien Technet avec toutes les options possibles de cette commande:
https://technet.microsoft.com/fr-fr/library/cc742083%28v=ws.10%29.aspx


Je démarre un job de sauvegarde, avec comme destination le dossier lundi de mon NAS, j'inclue dans la sauvegarde mes volumes C: et D:, ainsi que le volume de boot EFI, en incluant tous les éléments critiques pour le système, ainsi que son état.
Je vois l'avancement de mon job, et que tout se déroule correctement:

L'avantage de ce système c'est que non seulement je vois le job en cours, chose qui ne sera plus vraie lorsque j'automatiserai les sauvegardes, mais surtout je visualise l'état du job depuis la console Windows Backup.
Je vérifie donc que j'ai bien les bons arguments, et que le périmètre de sauvegarde est identique à celui que j'ai créé au tout début:

Me voilà rassuré, je sauvegarde bien l'intégralité de mes données!

Je vais maintenant créer une tâche planifiée pour automatiser cela, en utilisant le planificateur de tâches :

Je crée une tâche avec pour nom "backup lundi", qui s'exécute même si l'utilisateur n'est pas connecté.

L'action réalisée par cette tâche est de démarrer un programme, je rentre simplement wbadmin.exe, et je copie/colle le reste de la commande dans les arguments:

Je crée un déclencheur, qui se lance à l'heure programmée chaque lundi à 22h, j'aurai adapté cet horaire en fonction des autres tâches qui tourneront la nuit, en prenant en compte que la durée peut être assez longue du fait que la sauvegarde sera complète :

Je valide ma tâche planifiée, et pour contrôle je la lance manuellement:

Voilà, tout est Ok, je répète l'opération pour chaque jour de la semaine, et pour tous mes autres jobs.

La cerise sur le gâteau :

Nous voilà avec un plan de sauvegarde correct, ne restera qu'à mettre en place le suivi de ces sauvegardes.

Pour ce faire nous allons recevoir à chaque sauvegarde réussie un mail qui m'indiquera que tout s'est bien déroulé!

Ne faîtes surtout pas l'inverse, à savoir recevoir un mail quand ça ne fonctionne pas, car si n'importe quel autre événement se produit entre temps qui empêcherait la réception de mail, vous pourriez vous retrouver avec des données non sauvegardées, et ne pas vous en rendre compte juste parce que le serveur de mail n'a pas transmis le message.

Pour envoyer ce message, la méthode sera différente si nous nous trouvons sous Windows 2012 ou sous Windows 2008.

En effet une sécurité empêche d'envoyer un mail directement depuis Windows 2012, nous passerons donc par un script.
De même, si  nous avons besoin d'une authentification SMTP, nous procéderons également via un script.

Je retourne simplement dans le planificateur de tâches, et créé une tâche de base que je nomme "réussite sauvegarde" :

 Je sélectionne en déclencheur, un événement spécifique:

Je sélectionne "Microsoft-Windows-Backup/Operational", "backup" comme source, et renseigne 4 en "ID de l'événement":

Cet événement correspond à une réussite du Windows Backup.

En tâche je sélectionne "démarrer un programme", et je renseigne mon script:

Si je suis sous 2008, je peux sélectionner directement "envoyer un courrier électronique", en renseignant les informations qui vont bien.

Voici un script PowerShell à adapter en fonction de son cas de figure, et notamment en fonction du besoin d'authentification SMTP ou non :

function EmailNotification()
{
 #Sender email
 $Sender = "sender.at.corpnet.net"

 #Receipt email
 $Receipt = "receipt.at.contoso.com"

 #SMTP Server
 $Server = "smtp.corpnet.net"
 
#Mail subject
 $Object = $env:computername+": Backup report of "+(Get-Date)
 
#Mail content
 $Content = Get-WBJob -Previous 1 | ConvertTo-Html -As List | Out-String
 
 $SMTPclient = new-object System.Net.Mail.SmtpClient $Server
 
 #Specify SMTP port if needed
 #$SMTPClient.port = 587
 
 #Activate SSL if needed
 #$SMTPclient.EnableSsl = $true
 
 #Specify email account credentials if needed
 #$SMTPAuthUsername = "login"
 #$SMTPAuthPassword = "password"
 #$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($SMTPAuthUsername, $SMTPAuthPassword)
 
 $Message = new-object System.Net.Mail.MailMessage $Sender, $Receipt, $Object, $Content
 $Message.IsBodyHtml = $true;
 $SMTPclient.Send($Message)
}
EmailNotification

Et maintenant?

Et bien rien! (enfin presque)
Nous avons réalisé un plan de sauvegarde qui tient la route.
Je précise tout de même que dans notre cas de figure le NAS en question serait dans un autre bâtiment, la règle étant de ne pas avoir la sauvegarde au même endroit que le serveur, en cas d'incendie, de vol, de dégât dû à une inondation...
Ce plan devra être complété par une sauvegarde complémentaire, et surtout par des tests réguliers de remise en production, afin de valider que tout se déroule comme on l’espérait.

Cette nuit on va pouvoir aller faire la fête dormir tranquillement, nous sommes serein en ayant sécurisé les données de notre entreprise à moindre frais.

Je vous dis à très bientôt, pour un autre article qui traitera des règles concernant les ACL lors de la copie de fichiers/dossiers.

Bonne fête nuit!

Une migration presque parfaite

Bonjour,
aujourd'hui c'est le grand jour, comme promis on va parler migration!
Non j'ai dit le grand jour, pas le grand soir, ce n'est pas la révolution, mais plutôt l'évolution du système d'information.

Dans une infrastructure bien gérée, nous avons notre annuaire qui est bien organisé, nos GPO qui sont configurées correctement, nos partage qui sont bien maîtrisés.

D'ailleurs à ce propos j'ai une préférence pour un lecteur réseau unique, avec l'accès basé sur les énumérations activé. C'est beaucoup plus simple pour l'utilisateur, qui a un unique point d'entrée sur les partages. Cela nécessite juste à la mise en place une petite configuration supplémentaire au niveau des droits et de l'héritage. De plus, cela évite les problèmes de lecteurs réseaux non mappés, ou encore comme je l'ai vu récemment qu'un lecteur de carte mémoire connecté au pc utilise la lettre du lecteur réseau, qui du coup n'était plus accessible.
Encore une fois, notre métier n'est pas de monter des usines à gaz, mais de rendre un service aux utilisateurs, de la manière la plus simple et la plus efficace possible (le patron demandera évidemment à ce que cela soit efficient également)!

Revenons à notre article, du coup dans cette configuration, quand on souhaite faire une modification, tout est très simple, et en quelques secondes on peut paramétrer l'ensemble de notre parc pour utiliser un serveur de fichier plutôt qu'un autre par exemple. Si j'étais seul maître à bord dans une entreprise, cela se passerait comme ça.

Sauf que la vie est cruelle, et les systèmes d'informations souvent mal gérés! D'où le titre une migration presque parfaite, car notre migration va être parfaite, c'est le contexte qui ne l'est pas.
Il arrive parfois qu'il faille migrer des serveurs, alors même qu'une partie des configurations sont gérées via des scripts individuels vieux de 10 ans, qui en plus font des choses inutiles comme vérifier si le système utilisé est un Windows 2000, ou encore synchroniser l'horloge de l'ordinateur avec un autre ordinateur...autant de choses qui sont totalement inutiles en 2015, qui plus est avec des ordinateurs dans un domaine! (si si c'est du vécu ça existe).

Donc dans ce cas, la migration doit avoir lieu, mais évidemment aucune réorganisation de l'annuaire n'est prévue, rien ne doit être modifié, cela doit fonctionner comme avant, sans perturber les utilisateurs, et tout ça dans un temps record.

Mission impossible? Non!

Et oui,  il existe des outils et des astuces pour réaliser cette délicate opération avec un temps d'indisponibilité de 5 minutes maximum.

Pour reprendre les grandes lignes, voici ce que nous allons réaliser:

• Installation d'une VM que nous appellerons "temp".
• Installation d'une VM qui sera notre nouveau serveur, et que nous appellerons "new" de manière temporaire.
• Copie de l'ensemble de l'arborescence existante du serveur en production sur le serveur "new".
• Jonction du serveur "temp" au domaine existant, promotion de celui-ci en contrôleur de domaine, et transfert des rôles FSMO sur celui-ci.
• Transfert des imprimantes de l'ancien serveur vers le nouveau.
• Transfert des paramètres DHCP.
• Export des clés de registre pour partager les dossiers sur le nouveau serveur.
• Rétrogradation de l'ancien contrôleur de domaine et sortie du domaine.
• Renommage du serveur "new" en "serveur".
• Reprise de l'adresse IP de l'ancien serveur.
• Jonction de celui-ci au domaine, puis promotion en contrôleur de domaine.
• Transfert des rôles FSMO sur celui-ci.
• Élévation du niveau fonctionnel de la forêt et du domaine.
• Finalisation de la migration (import partages).
• Rétrogradation du serveur "temp" et sortie du domaine.
• Nettoyage des enregistrements DNS.
• On fait la fête car tout s'est bien passé et tout le monde est content (cette partie est optionnelle, mais vivement recommandée)!

Voilà, vous avez un serveur qui a le même nom, les mêmes partages, les mêmes imprimantes, les mêmes fichiers, la même adresse IP, sauf qu'il est neuf, et qu'il est en niveau fonctionnel actuel.

Dans ce cas de figure, même si les postes sont tous configurés de manière individuelle, cela sera totalement transparent pour eux, et cela ne nécessitera aucune configuration. Bref, des utilisateurs contents, et des dirigeants également! 

Voilà nous avons vu les grandes lignes, maintenant remontons-nous les manches et attaquons-nous en vrai à ces opérations, avec les commandes concrètes à utiliser pour s'en sortir.

Je précise simplement que pour la maquette, j'ai fait assez simple, mais que tout fonctionne de la même manière qu'il y ait 1 ou 1000 dossiers, 1 ou 1000 imprimantes, 1 ou 1000 utilisateurs.

On passe à l'action.

La partie la plus longue dans la migration, c'est la copie des partages de fichiers, car évidemment il y a forcement une volumétrie à copier d'un serveur à un autre, mais surtout les utilisateurs travaillent et on ne va pas leur couper l'accès au serveur pendant plusieurs jours, le temps de réaliser la migration.

Il existe un outil miracle, j'ai nommé Robocopy.

Non seulement il va être capable de nous créer une copie exacte de tous les fichiers et dossiers de notre ancien serveur vers le nouveau, tout en conservant les droits du système de fichier, mais en plus de cela il va gérer le fait que certains fichiers soient bloqués car utilisés par des utilisateurs, et reviendra dessus ultérieurement jusqu'à ce qu'ils soient accessibles et "copiables".

Donc partant de ce principe, il faut anticiper cette phase, et placer le nouveau serveur plusieurs jours à l'avance sur le réseau de l'entreprise, et lancer notre robocopy.

Attention! ROBOCOPY est un outil performant, mais si vous vous trompez dans la commande, vous pouvez perdre toutes vos données! Par exemple si vous intervertissez la source et la destination, cela va tout vous écraser!

1/ Transfert des documents:

Si je vais regarder sur mon serveur en production, j'ai un partage à la racine du D: qui contient tous les documents utilisateurs, j'ai également un autre partage dédié au personnel IT, mais surtout j'ai plein de choses en vrac à la racine du D:

Mon serveur initial, avec les dossiers sur le D:

On l'a dit, je veux migrer le serveur à l'identique, je ne me préoccupe pas de savoir si l'arborescence est bien faite, ou si tout est utile par exemple.
Je vais donc faire simple, je vais tout prendre!


Je vais donc simplement mapper le partage administratif D$ depuis mon nouveau serveur.
Je mappe le lecteur S, comme Source. Si ma cible était sur un autre serveur, je mapperais le T comme Target. Comme ça pas de confusion possible.

Je mappe le D$ et je rentre les identifiants de l'administrateur du domaine pour me connecter au partage.

J'ai donc un lecteur mappé sur mon nouveau serveur, qui est la racine du volume D de mon serveur de production.

Mon lecteur S: sur mon nouveau serveur.

Nous voilà donc fin prêts, maintenant on va lancer notre Robocopy.

Il existe plein d'options, voici ce que je vous conseille dans notre cas:

Plusieurs jours à l'avance, depuis mon nouveau serveur je lance une copie initiale grâce à la commande:

robocopy S: D: /MIR /SEC /W:2 /R:2 /RH:2200-0600 /TEE /LOG+:c:\temprobocopy\copieinitiale.log

Cette commande va donc prendre tout le contenu de notre lecteur réseau S (le D de notre ancien serveur), pour le copier sur le D: de notre nouveau serveur.
L'option /MIR créé un miroir, c'est à dire que si un fichier est supprimé du S, il le sera également sur le D.
L'option /SEC conserve les droits NTFS initiaux. Dans notre cas c'est indispensable!
L'option /W:2 précise qu'il faut attendre 2 secondes après une erreur de lecture (fichier ouvert par un utilisateur par exemple). Cette option est précieuse, car par défaut le délai est de 30 secondes.
L'option /R:2 défini à 2 le nombre d'essais en cas de lecture infructueuse.
L'option /RH copie les fichiers et dossier de 22h à 6h du matin, ceci afin de ne pas dégrader les performances quand les utilisateurs arrivent au travail.
L'option /TEE permet de conserver l'affichage des actions réalisées, malgré le fait qu'on log tout ça dans un fichier texte.
Enfin, l'option /LOG défini un fichier qui va enregistrer tout ce qui se passe lors de la copie.

Vous remarquerez que je n'ai pas écrit le fichier log à la racine du C, sur 2012 server vous aurez un problème de droit, j'ai donc créé un dossier temporaire à cette fin, et tout va bien s'enregistrer.
Il est par contre nécessaire de créer ce dossier manuellement.

Ensuite, une fois que tout est copié, je vais faire des copies régulières pour mettre à jour et n'avoir que quelques fichiers à copier le jour J.

Je vais donc utiliser cette fois cette commande:

robocopy S: D: /MIR /SEC /MOT:10 /W:2 /R:2 /TEE /LOG+:c:\temprobocopy\copies.log

Cette fois je ne copie pas l'intégralité entre 22h et 6h, mais toutes les 10 minutes, si il y a un changement.
Ceci grâce à l'option /MOT:10.
Cela me permet de copier régulièrement des petits fichiers, ceci afin d'être à jour, et de ne pas utiliser toute la bande passante.

Enfin, le jour J, nous le verrons plus tard, je déconnecte l'accès aux utilisateurs de l'ancien serveur, et je réalise mon dernier miroir:

robocopy S: D: /MIR /SEC /TEE /LOG+:c:\temprobocopy\copiefinale.log

J'ai donc tout mon D de mon ancien serveur qui est copié à l'identique sur le D de mon nouveau serveur!
Ici je n'ai pas d'option de retry car je ne dois avoir aucun fichier verrouillé.
J'ai également des fichiers logs qui me permettent de retracer tous les événements qui se sont déroulés lors des copies.

Donc concrètement je lance la commande depuis mon nouveau serveur:

Ici il est 16h58, la console va attendre 22h pour démarrer la copie et utiliser la bande passante disponible.

Une fois la première copie réalisée, je lance ma seconde commande, qui va scanner le lecteur toutes les 10 minutes et copier les fichiers modifiés ou créés.

Maintenant la copie fonctionne sans restriction d'horaire...

Ici cela fait 1 min que la copie est terminée, elle reprendra dans 9 minutes si des modifications ont lieu sur la source.

Nos copies sont donc lancées, nous n'avons qu'à attendre le jour de la migration, en vérifiant quand même auparavant qu'il n'y ait pas de problèmes de droits ou autre pendant la copie.

2/ Jonction du serveur temporaire au domaine, et transfert des rôles FSMO:

 

Maintenant on attaque la migration de l'AD. Notre serveur temporaire va nous servir de contrôleur de domaine le temps que l'on renomme le nouveau serveur avec le nom de l'ancien serveur.

Nous faisons la jonction du serveur temporaire dans le domaine.
Puis nous installons le rôle AD DS sur ce serveur.

Maintenant je promeus ce serveur en contrôleur de domaine.

Je joins mon contrôleur au domaine existant migration.lan

Et là j'obtiens une erreur fatale:

Le niveau fonctionnel de la forêt est Windows 2000.

Par défaut sur 2003 server, le niveau fonctionnel du domaine et de la forêt sont sur Windows 2000.

Il suffit donc de lancer la console "Domaines et approbations Active Directory" sur l'ancien serveur, et d'augmenter le niveau fonctionnel du domaine.

J'augmente le niveau fonctionnel de mon domaine.

Je sélectionne le niveau 2003 Server et je valide.

Ensuite depuis la même console, on augmente le niveau fonctionnel de la forêt, qui va ensuite nous permettre de promouvoir notre serveur temporaire et contrôleur de domaine de notre domaine.

J'augmente le niveau fonctionnel de ma forêt.

Je sélectionne le niveau 2003 Server et je valide.

Ne me reste plus qu'à relancer la promotion de mon serveur temporaire, qui cette fois-ci va se dérouler correctement.

Cette fois ça passe!

J'ai un avertissement concernant la mise en œuvre d'un RODC impossible, du fait que je n'ai pas de contrôleur de domaine en version 2008 ou ultérieur, mais ça ne dérange pas.
Par contre il est indispensable de conserver le catalogue global et le DNS sur ce serveur, sinon je ne pourrai pas transférer les rôles FSMO et conserver ce serveur seul sur le domaine.

Il peut se passer un petit délai lors de cette opération, le temps que le catalogue global se réplique.

Maintenant ne reste qu'à transférer les rôles FSMO sur le nouveau serveur.

Il existe plusieurs moyens de faire cela, mais une méthode simple et rapide est d'utiliser la ligne de commande, et notamment l'utilitaire NTDSUTIL.

Sur l'ancien serveur, je lance donc la console, et lance l'utilitaire en tapant simplement "ntdsutil".

Ensuite je passe en mode maintenance FSMO, pour cela je tape "role".

J’établis ensuite la connexion avec mon serveur pour lui transférer les rôles. Je tape donc "connections", puis "connect to server temp". Remplacez simplement le nom de votre serveur par celui que vous utilisez.

Je tape ensuite "q" pour retourner en mode maintenance FSMO.

Ne reste plus qu'à transférer les 5 rôles (dans le cas où ces rôles sont effectivement tous sur le serveur que vous migrez).
 

Les différentes actions avec NTDSUTIL.

Pour cela je tape "transfer rid master", puis "transfer schema master", puis "transfer infrastructure master", puis "transfer domain naming master" (si cette commande ne fonctionne pas, tapez "transfer naming master"), et enfin "transfer pdc".
A chaque transfert de rôle, une fenêtre apparaît demandant confirmation du transfert du rôle.
Il est nécessaire évidemment de valider par "oui".

Validation du transfert du rôle FSMO.

Une fois les 5 rôles transférés, on vérifie que notre serveur "temp" possède bien les 5 rôles et que tout s'est bien passé.
Pour cela je tape "q" pour sortir du mode maintenance FSMO, et une seconde fois "q" pour sortir de l'utilitaire NTDSUTIL.

Enfin, je tape "NETDOM QUERY /domain:migration FSMO".
Je tape cette commande depuis mon serveur temporaire, car par défaut l'utilitaire NETDOM n'est pas disponible en natif sur 2003 server, et même s'il est possible facilement de l'installer depuis le CD, cela reste une perte de temps sachant que ce serveur va bientôt être éteint définitivement.

Mon serveur temp possède bien les 5 rôles FSMO, c'est donc lui désormais le chef d'orchestre de mon réseau.

3/ Transfert des imprimantes:

Ici rien de plus simple! Enfin, quand tout peut être migré, car avec les pilotes 32 et 64 bits, vous pouvez avoir des problèmes avec des imprimantes à réinstaller, mais pour un simple "transfert" de machine à machine c'est très simple.

Dans notre exemple, j'ai deux imprimantes sur mon serveur d'impression, un copieur pour la direction, et un copieur pour le service IT.

La méthode est très simple, depuis le nouveau serveur on installe le rôle "services d'impression et de numérisation de documents", puis on valide bien "serveur d'impression".

Ensuite, on lance la console " Gestion de l'impression".

On ajoute notre serveur dans la liste des serveurs gérés.

On ajoute notre ancien serveur à la console de gestion des imprimantes.

On renseigne son nom, on l'ajoute à la liste et on valide par OK.

Puis on le sélectionne dans la liste des serveurs, et on clique droit dessus, pour exporter nos imprimantes et paramètres dans un fichier spécifique.

Je sélectionne "exporter les imprimantes vers un fichier"

J'exporte mes imprimantes dans un fichier que je met sur le bureau.

Mes imprimantes qui vont être exportées.

Le fichier que je viens de créer.

Maintenant ne me reste qu'à faire l'opération dans le sens inverse, à savoir importer ce fichier, cette fois dans mon nouveau serveur d'impression.

Les imprimantes qui vont être importées.

Mon importation terminée...

Me voilà donc avec un serveur d'impression qui possède les mêmes imprimantes et paramètres que mon ancien serveur d'impression!

4/ Transfert des paramètres du DHCP:

 

Nous allons maintenant effectuer la même opération, mais cette fois avec le DHCP.

Ici j'illustre la méthodologie pour réaliser cette opération, j'ai créé quelques enregistrements DHCP, dans les faits cette manipulation est intéressante si il y a beaucoup d'options, de réservations etc.
Si vous avez une "simple" étendue avec trois options, et une réservation, vous aurez sûrement plus facile et plus rapide a simplement recréer ces enregistrements dans l'interface.

Dans notre cas de figure, nous allons imaginer que nous avons des centaines d'enregistrements et réservations.

L'outil qui va nous sauver, c'est Netsh!

Netsh est un outil en ligne de commande.

Je vais donc en premier lieu exporter ma configuration DHCP.

Pour cela je lance mon invite de commande, et je tape les commandes suivantes:
"NETSH", puis "DHCP", puis "server \\serveur", et enfin "export c:\oldDHCPdb 172.16.0.0".

Je précise l'étendue quand je fais l'export, car si j'utilise "all" à la place, j'aurai une erreur à l'importation sur un 2012 server.

Mon fichier est donc exporté à la racine de mon C: sur mon ancien serveur. Je copie ce fichier sur le nouveau serveur, et je tape les commandes suivantes:
"NETSH", puis "DHCP", puis "server \\new", et enfin "import c:\oldDHCPdb" :

J'ai un avertissement, car il y a une autre procédure pour réaliser cette opération, s'appuyant sur des commandes PowerShell mais nécessite des prérequis sur l'ancien serveur, donc inadaptée dans notre cas.

Je lance ma console DHCP sur mon nouveau serveur, j'ai bien mon étendue, mes options d'étendue, mes réservations, ainsi que les baux distribués aux clients.

Ma console DHCP sur mon nouveau serveur.

Ne reste donc plus qu'à désactiver l'étendue sur mon ancien serveur. Je réaliserai cette opération par la suite, car mon serveur n'est pas encore dans le domaine, je ne peux donc pas encore autoriser mon DHCP dans l'AD sur le nouveau serveur, cela se fera automatiquement à l'installation d'AD DS et de la promotion en contrôleur de domaine, mais tout est prêt pour la bascule.

5/ Export de mes partages:

Là je souhaite simplement me simplifier la tâche, en exportant la liste des mes partages, pour les réimporter simplement dans mon nouveau serveur.

Sur mon ancien serveur, j'exécute "regedit" pour avoir accès à ma base de registre.

Je vais ensuite à cet endroit : "HK_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares":

J'aperçois tous les partages de ma machine.

Je clique droit sur le dossier "Shares", et je choisis "Exporter":

J'exporte les partages de mon ancien serveur vers un fichier .reg.

J'enregistre ce nouveau fichier sur mon serveur, et le transfère vers mon nouveau serveur.

Je conserve pour le moment ce fichier, je ne l'importe pas, je ne souhaite pas que des utilisateurs puissent accéder à des partages de mon nouveau serveur!

6/ Rétrogradation de l'ancien contrôleur de domaine et sortie du domaine:

 

Maintenant que nous sommes bien avancés, c'est le moment de la coupure!
Nous avons averti les utilisateurs qu'une interruption du service au niveau du serveur de fichier allait avoir lieu, c'est l'heure fatidique, on lance le chrono et on se bouge!

Évidemment au préalable nous avons pris soin de vérifier que le robocopy a bien copié l'intégralité de nos fichiers, et que tout est à jour. Je vous conseille de reporter l'opération, même si celle-ci avait été planifiée, si tout n'est pas Ok. Mieux vaut repousser de 24h, quitte à prévenir une nouvelle fois les utilisateurs, que de lancer une migration et que des fichiers manquent, ou que tout autre problème survienne!

Bref nous sommes prêt, tout est Ok, les utilisateurs sont informés qu'on y va, alors on y va!

Je vais rétrograder mon ancien serveur. Rappelez-vous, nous avons un serveur temporaire qui possède les rôles FSMO.

WARNING: Pour réaliser cette opération, il est indispensable de modifier les paramètres DNS du serveur à rétrograder, et lui indiquer l'adresse IP du serveur temporaire!

Si ces opérations plantent à cause d'un problème de promotion ou rétrogradation, vos 5 minutes de coupure vont se transformer en quelques minutes, voir heures!

Je vais donc en premier lieu spécifier que le DNS est géré par mon serveur temporaire :

Opération primordiale pour ne pas que l'opération échoue et créé des problèmes en cascade.

Cette opération effectuée, je lance la commande "dcpromo":

Fenêtre DCPROMO.

Je clique "suivant", et je valide l'avertissement, j'ai bien un serveur qui possède le catalogue global :

Avertissement concernant le catalogue global.

Je clique sur "suivant", et je ne coche pas qu'il est dernier contrôleur de domaine, ce n'est pas le cas :

Je clique "suivant", et je coche pour effacer les partitions de l'annuaire présentes sur ce serveur, on ne sait jamais où va finir le serveur, et ses données :

J'efface les données de l'annuaire stockées sur ce serveur.

Je tape mon mot de passe pour valider l'opération :

Et l'opération de rétrogradation débute réellement. Cette opération peut être plus ou moins longue suivant la taille de votre base.

L'opération en cours...

Je clique sur "terminer" :

Voilà mon serveur qui n'est plus contrôleur de domaine!

Voilà, c'est terminé, je débranche mon serveur du réseau, et je l’éteins, en le maudissant pour ses pannes à répétition remerciant pour ces années de bons et loyaux services.

7/ A l'attaque!

Maintenant on attaque avec notre nouveau serveur, c'est lui qui va devenir la star de mon réseau!

On va commencer par lui donner l'adresse ip et le nom de l'ancien serveur :

Je le renomme "serveur" au lieu de "new".

Je n'oublie pas de lui mettre le serveur "temp" comme DNS.

Je redémarre mon serveur, et le joins au domaine.

Puis une fois redémarré, j'installe le rôle "AD DS", puis je promeus le serveur en contrôleur de domaine.

Je valide bien qu'il soit catalogue global et DNS, j'installe, et mon serveur redémarre.

Mon serveur intègre bien le DNS et le catalogue global.

Maintenant que mon serveur est contrôleur de domaine, on va passer les rôles FSMO sur celui-ci de la même manière que nous avons procédé pour passer les rôles sur le serveur temporaire.

Je rentre en mode maintenance FSMO grâce à NTDSUTIL et je transfère les rôles à mon nouveau serveur.

L'opération a réussie, j'ai bien transféré les rôles!

Je vais directement en profiter pour augmenter le niveau fonctionnel de ma forêt et de mon domaine.
Comme pour le début de cet articles, je vais aller dans la console "Domaines et approbations Active Directory".

J'augmente le niveau fonctionnel de ma forêt.

Je passe directement à un niveau fonctionnel 2012 R2.

Le domaine passe automatiquement au même niveau fonctionnel.

Mon domaine migration.lan en niveau fonctionnel 2012 R2.

Je vais importer les partages, grâce à mon fichier .reg précédemment exporté de mon ancien serveur, tout simplement en double cliquant dessus, et en validant par "oui". J'ai donc une fois cette importation effectuée, les mêmes partages sur mon nouveau serveur que sur mon ancien serveur.

Maintenant que toutes les actions ont été réalisées, je stoppe le chrono, et je contrôle que tout fonctionne correctement.

8/ Hallelujah!

Nous y sommes, la migration est terminée, les utilisateurs peuvent reprendre une activité normale, et nous aussi! Tout s'est bien passé, nous savions où nous allions.
Avant de partir faire la fête, et demander une augmentation car après tout si tout s'est bien passé c'est parce que nous sommes de vrais pros, nous pouvons tranquillement rétrograder notre serveur temporaire.

Comme pour l'ancien serveur, nous supprimons le contrôleur de domaine, ainsi que le contenu des bases stockées localement.

Nous pouvons également en profiter pour aller jeter un coup d’œil à nos DNS, voir si il ne reste pas d'anciens enregistrements du serveur temporaire.

9/ Faire la fête (et "bookmarker" mon blog):

Comme je l'indiquais, cette partie est optionnelle, mais vivement recommandée.

Par contre gardez bien en tête que votre expertise est nécessaire à chaque étape de ces actions, pour pouvoir le cas échéant débloquer une phase qui ne se déroulerait pas correctement, ou encore adapter en fonction de votre contexte.
Et comme je l'indiquais également, dans ce cas concret, nous restons à ISO-périmètre, situation qui est satisfaisante sur l'instant, mais qui nécessite que le système soit mieux géré pour éviter ces actions la prochaine fois...car même si la coupure a été minime, nous aurions pu faire mieux, dans un contexte plus favorable.

Les prochains articles repréciseront le comportement des droits NTFS lors des différents cas de figure (copie, déplacement, même partition, partition différente...), ainsi qu'une méthodologie de mise en place d'un plan de sauvegarde cohérent sur le réseau en utilisant uniquement l'utilitaire Windows et les tâches planifiées.

D'ici là "may the force be with you"!

Pierre