Étiquette : Migration

Pas de commentaire

Faciliter sa migration de fileserver DFS avec Powershell

  de

Ayant éprouvé ces scripts lors d’une migration d’un serveur de fichiers, je vais les partager dans ce billet. Le but n’est pas d’automatiser complètement la migration mais de faciliter le travail et de limiter les risques d’erreurs humaines.

A noter qu’il est important de vérifier le bon fonctionnement des scripts sur votre environnement : en effet, il est possible que les espaces dans les noms de chemin pour les scripts Robocopy puissent causer des dysfonctionnements. Il est également important que les noms de répertoires sur le serveur correspondent au nom des répertoires DFS. Il peut donc être nécessaire d’adapter le code pour qu’il fonctionne correctement.

Ce snippet appelle Robocopy pour faire le transfert des données.

$servername = "fs001.dundermifflin.inc"
cd c:\mig\robocopy
$FoldersToDo = Get-Item \\$ServerName\C$\shares\* | select name
foreach($Folder in $FoldersToDo){
    $FolderName = $Folder.Name
	start-process "robocopy.exe" -ArgumentList "/MIR /COPYALL /ZB /W:0 /R:0 /MT:16 \\$ServerName\C$\shares\$FolderName C:\shares\$FolderName /log:robocopy_$ServerName_$FolderName.log /v" -wait
}

Ce script va s’occuper de la partie DFS ; il va ajouter le nouveau serveur de fichier en tant que répertoire cible pour chaque répertoire DFS qui contient un lien vers l’ancien serveur. Ce nouveau lien sera en désactivé, ainsi la migration peut être préparée en amont.

Param([Parameter(Mandatory=$true)][string] $OldServer, [Parameter(Mandatory=$true)][string] $NewServer, [Parameter(Mandatory=$true)][string] $Namespace)
$fNameSpace = "$Namespace\*"
$folderlist = Get-DfsnFolder $fNameSpace | foreach { (Get-DfsnFolderTarget $_.Path).TargetPath } | Where-Object { $_ -like "\\$OldServer*" }
foreach($folder in $folderlist){
	$folderName = $folder.SubString($OldServer.Length+3,$folder.Length-$OldServer.Length-3)
    echo $folderName
	New-DfsnFolderTarget -Path "$Namespace\$folderName" -TargetPath "\\$NewServer\$folderName" -State Offline
}

Par exemple, si l’on souhaite migrer de fs001 vers fs002 tous les liens DFS du namespace Documents, le script pourra être appelé de cette manière :

.\ImportationDFS-NewServer.ps1 -OldServer fs001 -NewServer fs002 -Namespace \\dundermifflin.inc\Documents

Ainsi, le jour de la migration, en jouant ce script on réalise la bascule vers le nouveau serveur fs002 puisque celui-ci va activer les liens DFS vers le nouveau serveur en désactivant ceux de l’ancien serveur.

Param([Parameter(Mandatory=$true)][string] $OldServer, [Parameter(Mandatory=$true)][string] $NewServer, [Parameter(Mandatory=$true)][string] $Namespace)
$fNameSpace = "$Namespace\*"
$folderlist = Get-DfsnFolder $fNameSpace | foreach { (Get-DfsnFolderTarget $_.Path).TargetPath } | Where-Object { $_ -like "\\$OldServer*" }
foreach($folder in $folderlist){
	$folderName = $folder.SubString($OldServer.Length+3,$folder.Length-$OldServer.Length-3)
    echo $folderName
	Set-DfsnFolderTarget -Path "$Namespace\$folderName" -TargetPath "\\$NewServer\$folderName" -State Online
    Set-DfsnFolderTarget -Path "$Namespace\$folderName" -TargetPath "\\$OldServer\$folderName" -State Offline
}

Ce script prend les mêmes paramètres que le précédent. En fonction du type de migration effectuée, il peut-être nécessaire de jouer le script plusieurs fois : si le nouveau serveur remplace et conserve le nom de l’ancien, il y a de grandes chances qu’à un moment le nouveau serveur doive être renommé. Dans ce cas, Microsoft conseille de supprimer le répertoire de destination dans DFS avant de renommer le serveur ; cependant si un répertoire DFS n’a plus de répertoire de destination, alors ce répertoire DFS est supprimé (en conservant bien sûr, les données sur le disque du serveur en question). Il sera donc nécessaire de procéder en plusieurs étapes et en jouant le script plusieurs fois afin de toujours conserver un lien DFS, qu’il soit actif ou non.

Par exemple, si l’on considère le serveur fs001 et le serveur fs001new, en admettant que l’on renomme le serveur fs001 en fs001old une fois la migration effectuée, cela nous donne ceci :

Etape #Serveurs contenus dans les liens DFSDétails
1fs001Etat pré-migration
2fs001 : actif – fs001new : inactifAjout de fs001new
3fs001 : inactif – fs001new : actifActivation de fs001new
Désactivation de fs001
4fs001new : actifRetrait de fs001
Renommage en fs001old
5fs001new : actif – fs001old : inactifAjout de fs001old
6fs001old : inactifRetrait de fs001new
Renommage en fs001
7fs001 : actif – fs001old : inactifAjout de fs001
8fs001Etat post-migration

Il n’y a pas de dysfonctionnement grave à ne pas retirer le serveur des répertoires cibles avant qu’il soit renommé. Il faudra cependant attendre une petite trentaine de minutes que côté AD tous les liens DFS soit remis en état par le système car bien qu’il s’agisse toujours de fs001, l’objet dans l’annuaire n’est pas le même. Il ne reste ensuite plus qu’à valider le bon fonctionnement.

Pas de commentaire

Migration d’une paire de contrôleurs de domaine en 2003 vers 2008 R2 puis 2012 R2

  de

Si j’ai installé un serveur 2003 (voir l’article précédent), ce n’est pas pur plaisir – quoique – mais car j’ai décidé de monter une maquette composée de deux contrôleurs de domaine en 2003 qui doivent être migré sous un OS plus récent, ici 2012 R2.

Dans cet article, je vais détailler les principales étapes pour mener à bien cette migration que j’ai réalisé en 2 temps, tout d’abord en migrant de 2003 vers 2008 R2, puis de 2008 R2 vers 2012 R2. Bien évidemment, avant de se lancer en production, valider la procédure sur un environnement de test me paraît indispensable ; tout comme valider ces quelques pré-requis : faire un dcdiag pour s’assurer qu’il n’y ait pas d’erreurs ou d’incohérences au niveau du domaine et être sûr de disposer de tous les mots de passe nécessaires aux promotions et dépromotions de contrôleurs de domaine. Je ne saurais être tenu responsable si vous appliquez ce procédé en production sur un environnement bancal et que ça coince quelque part sans que vous ayez de moyen de revenir en arrière !

Pour clarifier, j’ai nommé mon domaine maquette.local, et mes serveurs s’appelleront DCXXXPRI et DCXXXSEC.

Situation actuelle : 2 DC 2003 – DC2K3PRI et DC2K3SEC. C’est parti ! 💪

Tout d’abord, faire en sorte que le niveau fonctionnel de la forêt du domaine soit en 2003 : se rendre dans les consoles Active Directory Domains and Trusts et Active Directory Users and Computers pour faire les montées de version.

Le niveau fonctionnel de l’ActiveDirectory est en 2000 sur un domaine fraîchement configuré sur un 2003.    

Procéder à l’installation d’un serveur 2008 R2. Ce nouveau serveur sera mis sur le domaine et s’appellera DC2K8PRI. Une fois les rôles ADDS installés sur ce serveur, il est nécessaire de préparer la forêt pour recevoir un AD 2008.

Pour ce faire, monter l’ISO de Windows Server 2008 sur DC2K3PRI. Puis, ouvrir une invite de commande, se placer sur l’ISO (répertoire d:\support\adprep par défaut) et exécuter les instructions suivantes :

adprep32.exe /forestprep
adprep32.exe /domainprep
adprep32.exe /gpprep
adprep32.exe /rodcprep

La première instruction avec le paramètre forestprep demandera une confirmation en saisissant « c ».

adprep32.exe demande une confirmation lors de la demande de mise à niveau du schéma pour accueillir un DC 2008.
Préparation du schéma en cours…
Le domaine est prêt, il reste plus qu’à implémenter la nouvelle gestion des GPO et des RODC (Read-Only Domain Controller) si besoin.

Une fois que tout s’est bien déroulé, retour sur DC2K8PRI. Exécuter dcpromo pour en faire un DC. Le serveur sera donc ajouté à la forêt existante, les autres paramètres ne doivent pas être modifiés et le serveur doit être ajouté comme un contrôleur de domaine supplémentaire.

 
On ajoute simplement un DC au domaine maquette.local.  
 
On spécifie le compte d’administration à utiliser pour la promotion.      
 
 
La promotion est prête à être effectuée.

Dès que l’assistant est terminé et le
serveur promu en DC avec succès, ce dernier redémarrera. Une fois le reboot
terminé, contrôler dans la console ActiveDirectory Users and Computers sa
présence dans l’OU Domain Controllers.

Si l’étape précédente a été concluante, le domaine est donc composé de 2 DC 2003 et d’un DC 2008 R2. Le serveur DC2K3SEC doit être dépromu afin qu’il ne reste plus que 2 DC.

Se rendre sur DC2K3SEC, et effectuer un dcpromo.

Il ne faut surtout pas cocher cette case car nous souhaitons bien conserver le domaine !
 
Il y a des répertoires et arborescences propres à 2003 qui
seront supprimées en même temps que la dépromotion du serveur ; il n’est pas nécessaire d’en tenir
compte car elles ne seront plus utilisées par la suite. Une fois l’assistant terminé, le serveur va redémarrer, il ne
sera plus DC. Il ne reste plus qu’à lui retirer les rôles AD et à l’éteindre. Il nous reste donc 1 DC 2003 (master) et 1 DC 2008 R2.
 
On arrive maintenant sur l’étape cruciale de la migration. L’étape suivante consiste à
transférer les rôles opérationnels de DC2K3PRI vers DC2K8PRI.
 
Se connecter sur DC2K8PRI, ouvrir une
invite de commandes ou une invite Powershell et obtenir la confirmation que
c’est DC2K3PRI qui héberge les rôles opérationnels du domaine grâce à l’instruction netdom query fsmo :
 
Les rôles opérationnels sont bien portés par DC2K3PRI.
 
Dans cette même invite de commandes, exécuter regsvr32 schmmgmt.dll pour ajouter la console ActiveDirectory Schema. Une fois que l’instruction a été exécutée, ouvrir mmc.exe et ajouter le Snap-In ActiveDirectory Schema. Effectuer le transfert du rôle Schema Master en sélectionnant le domaine puis Operations Master. Ensuite, ouvrir la console ActiveDirectory Domains and Trusts puis effectuer le transfert du rôle Naming Operations Master.
 
Transfert du Naming Master

Ensuite, ouvrir la console
ActiveDirectory Users and Computers et faire de même pour les rôles RID, PDC et
Infrastructure.

Une fois le transfert effectué pour
les 5 rôles, exécuter de nouveau la commande netdom query fsmo. Voici ce qui devrait
ressortir de l’instruction si tout s’est bien déroulé :
 
Le transfert s’est bien déroulé : tous les rôles ont basculé sur DC2K8PRI.    
 
 
Si et seulement si les rôles ont bien
été déplacés, il est envisageable de continuer. Maintenant que le DC maître est DC2K8PRI, installer un serveur
2008 R2 nommé DC2K8SEC. Le mettre sur le domaine, installer les rôles AD,
réaliser un dcpromo pour le déclarer contrôleur de domaine. Nous avons donc en l’état 1 DC 2003 et 2 DC 2008 R2 (dont un maître). Il nous reste plus qu’à retirer le dernier DC en 2003 pour que la première partie de la migration soit réalisée.
 
 
Se connecter à DC2K3PRI. Effectuer un dcpromo de la même manière qu’il a été effectué sur DC2K3SEC. Ne pas supprimer le domaine, simplement accepter la suppression des répertoires et arborescences propres à 2003. Une fois l’assistant terminé et le redémarrage effectué, contrôler sur un des DC 2008 dans la console ActiveDirectory Users and Computers qu’il ne reste plus que les 2 DC 2008.
 
Il n’y a plus de trace des serveurs 2003 dans l’OU des contrôleurs de domaine.

Si tout s’est bien déroulé jusqu’ici, il suffit de retirer le rôle AD sur le serveur 2003 et à l’éteindre pour conclure proprement cette première partie.

Nous sommes à mi-chemin, c’est le moment de souffler un bon coup, de pourquoi pas se prendre un café, un thé, un coca, un verre d’eau ou une bonne pinte avant de continuer ! 🍺
 
 
En fonction de ce qui est hébergé sur le domaine, il peut
être nécessaire d’effectuer une montée de niveau fonctionnel de la forêt et du
domaine vers 2008 R2. Si besoin, répéter l’opération effectuée en début de
procédure pour monter de 2000 vers 2003 (ouvrir la console ActiveDirectory
Domains and Trusts, puis Raise forest functional level vers 2008, puis 2008
R2 ; ouvrir la console ActiveDirectory Users and Computers et monter le niveau
du domaine de la même manière).
Montée du niveau fonctionnel de la forêt en 2008.
Forêt et domaine en niveau fonctionnel 2008 R2.

Et c’est reparti pour une installation : un serveur 2012 R2, le mettre sur le domaine, y installer les rôles ADDS, et le promouvoir en contrôleur de domaine.

Installation des rôles ADDS
Prêt pour l’installation.

La promotion comme contrôleur de domaine se fait directement par le Server Manager, dcpromo n’existant plus en tant qu’application appelable par l’utilisateur. Il n’y a pas besoin d’effectuer un adprep avec 2012 R2 car c’est l’assistant qui va préparer le schéma. Lorsque l’assistant est terminé, le serveur redémarre, vérifier dans la console ActiveDirectory Users and Computers que DC2012PRI apparaît bien dans l’OU des DC. A ce moment, il y a 2 DC 2008 R2 (dont maître) et un DC 2012 R2.

Le transfert des rôles vers le nouveau DC en 2012 R2 s’effectue maintenant. Vérifier avec netdom query fsmo que DC2K8PRI est toujours porteur des rôles. Dans une invite de commande ou Powershell, saisir regsvr32 schmmgmt.dll puis ouvrir un mmc.exe et y ajouter la console ActiveDirectory Schema. Dans la console, s’assurer que l’on est bien connecté sur DC2012PRI.

Bien sélectionner DC2012PRI afin de le désigner comme nouveau maître du schéma.  

Ensuite réaliser l’opération de transfert des rôles, de la même manière qu’effectuée sur le 2003 (Operation Masters puis Change). Ouvrir les consoles ActiveDirectory Domains and Trusts et ActiveDirectory Users and Computers pour y réaliser le transfert des rôles de naming, RID, PDC et Infrastructure. Vérifier que le transfert a bien été appliqué :

DC2012PRI est le nouveau serveur « maître » du domaine.

Maintenant que le DC primaire est DC2012PRI, installer un serveur 2012 R2 nommé DC2012SEC. Le mettre sur le domaine, installer les rôles AD, réaliser un dcpromo pour le définir contrôleur de domaine et le définir contrôleur de domaine avec l’assistant. Si tout s’est bien déroulé jusqu’alors, il y a 3 DC : 1 2008 R2 et 2 2012 R2 (dont le maître).

Tous les rôles étant sur DC2012PRI et DC2012SEC étant fonctionnel, exécuter dcpromo sur DC2K8PRI, le dépromouvoir, puis supprimer les rôles ADDS, et procéder à l’extinction du serveur.

DC2K8PRI n’est plus que l’ombre de ce qu’il fut pendant quelques heures…

Enfin, nous avons 2 DC en 2012 R2. Afin de vérifier que tout s’est bien déroulé, réaliser un dcdiag et s’assurer que tous les tests sont concluants – pass :

dcdiag /v /c /d /e /s:DC2012PRI

Les tests sont complets et si tout s’est bien déroulé du début à la fin, ils doivent tous être passés avec succès.  

Pour conclure, il ne reste plus qu’à reconfigurer la synchronisation du temps sur le contrôleur de domaine hébergeant le rôle PDCEmulator afin d’être sûr qu’il se synchronise sur une source de temps valide et qu’il ne conserve pas une référence caduque suite aux migrations. Dans cet exemple, je prends le serveur de temps Microsoft mais il peut s’agir d’un serveur en interne.

w32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update