Migrer un Windows Server 2008 R2 vers Windows Server 2016

Dans mon cadre professionnel on m’a demandé de plancher sur la chose suivante, la migration d’un WS 2008 vers un 2016, ce qui n’est pas aussi facile que prévu…

Bien, comme dit en introduction on m’a demandé de me renseigner un peu sur un Usecase pour un de nos clients, je vais donc décrire le problème de façon brève :

Le client possède un serveur qui va être virtualisé (pas un soucis jusque là), ce serveur est un Windows Server 2008 R2 avec un AD-DNS-FS installé, pas de soucis non plus pour le rôle FileServer qui sera déplacé sur une autre machine virtuelle. Concernant l’AD, celui-ci doit continuer d’être fonctionnel après sa migration en Windows Server 2016… et c’est là qu’on va devoir un peu se retrousser les manches, car le client voudrait si possible une mise à jour, et pas une migration.

De prime abord, je n’ai jamais eut à travailler avec 2008 R2 mais soit, ça ne devrait pas poser un soucis. En me renseignant rapidement sur le site de Microsoft j’ai vu qu’il fallait d’aborder mettre à jour vers un 2012 puis seulement après sur un 2016, donc normalement ça devrait passer. A noter aussi que ce n’est pas une tâche assignée à ma propre personne, on m’a juste demandé de rechercher quelques informations « histoire d’en savoir plus ».

I) Téléchargement des différents ISOs et installation de l’AD-DNS

On démarre donc notre fameux VMware Workstation après avoir récupéré l’ISO du 2008, 2012, et 2016. Ici je vais donc commencer par installer mon AD-DNS sur mon 2008 R2. L’installation est sensiblement la même que pour les moutures plus récentes, pas la peine d’épiloguer ici donc.

*Bon à savoir: 2008 R2 proposait déjà l’installation minimale (toute en Powershell donc).

Ensuite on se rend sur l’Assistant Ajout de rôles pour lancer l’installation d’AD-DNS de manière classique, en sachant que mon serveur se nomme AD-01 et aura l’adresse IP 192.168.1.100/24 :

*Bon à savoir: contrairement à un 2012, ici il convient d’installer en premier lieu le rôle Active Directory puis seulement ensuite le service DNS.

On se rend donc nesuite sur le Gestionnaire de serveur une fois notre AD installé pour exécuter l’utilitaire dcpromo.exe :

Comme d’habitude notre forêt s’appellera notamax.local, et concernant le niveau fonctionnel de la forêt, on utiliser Windows Server 2008 R2 car dans notre usecase défini en introduction je n’ai pas d’info sur le niveau de forêt utilisé par le client, on assumera donc ici que c’est le niveau le « plus récent », et si ce n’est pas le cas, la procédure de migration restera tout de même sensiblement la même :

Ici on peut donc installer le rôle DNS :

On patiente un peu le temps du redémarrage, et entre temps j’en ai profité pour déjà lancé l’installation d’une VM Windows 7 Pro qui nous servira de client. Car oui, une fois notre AD installé nous allons déjà faire join notre client pour vérifier qu’après sa mise à jour le client sache toujours se connecter… quitte à devoir le passer en Windows 10 éventuellement, mais l’idée est de ne pas devoir s’amuser à passer sur chaque poste pour refaire la liaison AD et autres bricoles.

II) Connexion au domaine d’un client Windows 7 Pro

Ici rien de spécial, bien penser à mettre l’IP de notre AD comme DNS sur le client et le tour est joué :

On créer ensuite un utilisateur classique dans notre AD :

Et on se connecte avec celui-ci sur notre client Windows 7 pour être sûr que tout est ok :

Niquel, on peut donc poursuivre et s’âtteler au gros du boulot désormais, la mise à jour de notre AD…

Au passage j’en ai profité pour créer une OU nommée Siège principal, avec un groupe Techniciens comprenant l’utilisateur Mairien Anthony et avec une GPO pour désactiver l’invite de commandes pour ce groupe, histoire de vérifier si tout sera bien fonctionnel même après la migration.

III) Mise à jour du 2008 R2 vers 2012

Comme le préconise la documentation Microsoft, il vaut mieux d’abord passer sur 2012 avant de directement aller sur 2016, donc c’est ce qu’on va faire ici.

On ajoute donc l’ISO du 2012 dans le lecteur CD virtuel de notre AD-01, et on démarre l’installation.

*Bon à savoir: après m’être un peu plus renseigné sur certains forums, beaucoup préconisent une ré-installation propre, en créant un second AD et en l’intégrant à la forêt de base… d’ailleurs la documentation Microsoft dit
ceci : « La mise à niveau convient le mieux aux machines virtuelles qui ne nécessitent pas de pilotes de matériel OEM spécifiques pour que l’opération réussisse. ».

On suit donc le setup de manière classique, et là, premier pépin :

Hop là, pas possible de mettre à jour un 2008 R2 Standard vers un 2012 Standard en version d’essai, yes. Au passage, j’ai trouvé ce petit tableau qui peut être intéressant donc je me permets de le placer ici :

M’enfin soit, en théorie donc on peut faire notre upgrade, mais pas via une version d’essai… et si on avait une licence, la marche à suivre aurait été assez simple, on ouvre le directory du CD d’installation, on se rend dans support pour effectuer un D:\support\adprep\adprep.exe /forestprep pour mettre à jour le schéma de la forêt au delà de Windows Server 2003, et enfin un D:\support\adprep\adprep.exe /domainprep puis ensuite seulement on démarre notre mise à jour via le setup.exe

IV) Le plan B : la migration vers un 2016

Pas le choix étant donné ce petit soucis de licence, nous allons devoir opter pour le plan de secours, à savoir créer une seconde VM qui sera en Windows Server 2016 Standard. Une fois la VM installée et configurée comme il faut (AD-02, 192.168.1.150/24) nous pourrons mettre en place la migration. A noter qu’en serveurs DNS, il faudra renseigner l’IP de notre AD-01, très important !

Avant de pouvoir directement réaliser la migration, nous devons d’abord retourner sur notre AD-01 puis rentrer l’ISO d’un 2012 R2 pour mettre à niveau la forêt, on effectue donc le fameux adprep comme décrit un peu plus haut, puis on peut redémarrer notre serveur.

Une fois redémarré, on peut faire joindre notre AD-02 sous Windows Server 2016 à notre domaine :

Vient ensuite l’installation du rôle AD sur notre « nouveau serveur » :

L’installation est donc jusqu’à présent classique, mais c’est après qu’elle diffère :

Ici Windows reconnaît que notre serveur est déjà membre d’un domaine, donc logiquement nous voulons le promouvoir en tant que contrôleur de domaine supplémentaire. Il convient juste de cliquer sur Modifier pour rentrer le mot de passe Administrateur du domaine, ici ce sera NOTAMAX\Administrateur avec le mot de passe qui va bien.

On poursuit et on choisit de configurer notre nouvel AD comme serveur DNS et catalogue global :

On clique sur Suivant et on ignore l’erreur DNS :

Ici si nous avions plusieurs sites distants, on pourrait choisir de répliquer depuis l’AD le plus proche géographiquement, mais ici aucune importance :

On peut ensuite faire le classique Suivant, Suivant, Suivant… jusqu’à ce que l’installation démarre, puis une fois terminée notre serveur va redémarrer.

Et si on vérifie les contrôleurs de domaine de notre fameux domaine :

Tout est bon ! On touche presque à la fin… désormais nous devons migrer les « rôles FSMO », qui permettent de définir le « Maître » du domaine pour résumer.

On se rend donc dans Utilisateurs et ordinateurs Active Directory, clic droit sur notre domaine puis Maître d’opérations :

Ici pour le rôle RID, CDP, et Infrastructure nous cliquons sur Modifier pour transférer les rôles à notre AD-02.

Ensuite on doit faire de même pour le rôle « d’attributions des noms du domaine », en nous rendant dans Domaines et approbations Active Directory :

Courage, on y arrive ! Il faut enfin modifier le rôle « Contrôleur de Schémas » en effectuant ce coup-ci une petite commande via l’utilitaire Exécuter qui va nous permettre de transférer ce rôle graphiquement :

regsvr32 schmmgmt.dll

Ensuite on peut de nouveau démarrer puis exécuter et ce coup-ci réaliser la commande suivante :

mmc

Voilà ce que vous devriez obtenir à votre écran :

On se rend sur Fichier, puis Ajouter un composant logiciel enfichable :

On sélectionne donc Schémas Acive Directory puis Ajouter, et enfin Ok.

Ensuite en cliquan sur ce schéma, puis en allant dans Action au dessus, on peut avoir l’option Changer de contrôleur Active Directory :

On choisi donc notre nouveau serveur, et on clique sur Ok. On ignore l’avertissement qui apparaît, puis de nouveau on transfert le Maître des opérations en faisant un clic droit sur notre schéma Active Directory :

Modifier, puis on valide le tout. Pour vérifier que ce long périple est bel et bien achevé, on réaliser la commande netdom query fsmo dans une invite de commandes :

Oui ! Tout est bon ! On peut prendre une petite pause bien méritée… avant de s’attaquer à la suppression de l’ancien Active Directory.

V) Suppression de l’ancien Active Directory et tests

En général, selon plusieurs forums, il convient d’attendre plusieurs heures avant de supprimer l’ancien AD. Ici, dans le cas de ce LAB, nous n’avons presque aucun utilisateur, GPO, ou autre et tout est en local qui plus est, donc attendre un quart d’heure devrait suffire.

On se rend donc sur notre bon vieux Windows Server 2008, puis Exécuter et on rentre successivement ces commandes :

Pour la dernière commande, celle-ci sert à rétrograder le contrôleur de domaine. Une fois exécutée une interface s’affiche et en cliquant sur Suivant :

Petit avertissement toujours utile ma foi, on poursuit :

Bien entendu ici on ne coche pas cette case, et on clique sur Suivant pour rentrer son mot de passe Administrateur du domaine. Ensuite on peut lancer la suppression des services Active Directory :

Le serveur redémarre, et il ne nous reste qu’une ultime étape, le repasser en workgroup (vous connaissez la manipulation tant elle est triviale).

A partir de là, on peut même éteindre notre ancien serveur, et on peut démarrer notre bon vieux client Windows 7 pour vérifier si la connexion est toujours fonctionnelle, avec notre groupe et notre GPO :

Alors à première vue tout semble bon… mais vous verrez vite que par exemple si l’on veut réaliser une action administrateur, le mot de passe du compte Admin du domaine nous est demandé (logique) mais celui-ci ne passe pas, étrange non ? Peut être car l’adresse IP de notre serveur DNS est toujours celle de l’ancien serveur ? Et bah oui !

On se déconnecte de la session, et on se reconnecte avec une session locale, de là on peut changer l’adresse IP. Une fois fait, on rechange de session à nouveau, et là :

Tadaaa, tout fonctionne !

• La connexion au domaine est toujours fonctionnelle, avec nos utilisateurs créés ;
• Les GPOs sont toujours fonctionnelles ;
• La connexion au compte Administrateur du domaine pour des tâches administratives (comme la configuration IP sur un poste) est fonctionnelle ;

On peut donc dire que c’est une franche réussite ! Et bien j’espère que cet article vous aura appris quelques petites astuces, pour ma part comme dit en introduction je n’avais jamais touché de Windows Server 2008 et encore moins fait de migration d’AD, donc que du bénéf !

Je vous invite tout de même (et comme toujours) à bien préparer ce genre de chose, en vous documentant un maximum et en prenant bien vos dispositions, car ce n’est pas quelque chose que l’on fait de manière spontanée.

P.S: J’ai réalisé cet article en 3 heures environ, en faisant le lab à côté en même temps, donc je n’ai peut être pas eut le temps/la réflexion de pleinement me documenter sur le sujet de la migration d’un AD 2008 vers un 2016, mais le fait est que je suis assez content du résultat, tout est fonctionnel dans l’ensemble, même si je suppose que tout ceci peut être optimisé et amélioré 😉

Sur ce, bonne journée/soirée à vous !