Catégorie : Non classé

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
2 Commentaires

Installation des drivers (Integration Services) sur une VM Windows Server 2003 hébergée sur Hyper-V 2016

  de

Bien qu’il puisse s’agir d’une faute professionnelle que de déployer à l’aube de 2019 des machines Windows Server 2003, dans le cadre du projet sur lequel je planche actuellement j’ai dû procéder à un tel crime de lèse-majesté.

Le hic, c’est qu’Hyper-V 2016, à la différence de 2012, ne supporte plus Windows Server 2003 (entre autres), ce qui signifie que le bon fonctionnement d’un tel OS n’est pas garanti et que les drivers (regroupés sous un pack nommé Integration Services, qui pourrait être comparé aux VMtools sous VMware) ne sont pas fournis ; si Hyper-V 2012 proposait ces drivers nativement, Hyper-V 2016 procède à leur installation par internet. Afin de les déployer sur une machine 2003 – avec toutes les précautions que cela comprend ainsi que le bon sens qui doit vous dicter de ne pas déployer cela en production si possible – il faut donc ruser un peu.

Une première solution : installer Hyper-V 2012 sur une machine et récupérer ces drivers ; ils sont situés dans C:\Windows\System32\vmguest.iso. Ensuite, monter cette image ISO sur la VM 2003 et procéder à l’installation sur le serveur 2003 des packages.

La deuxième solution est la plus simple : sur les forums de Microsoft, de nombreux sujets traitent du problème que rencontrent certains utilisateurs, et il est possible de trouver l’image ISO d’Integration Services. Je vous fais grâce de la recherche, puisque j’ai uploadé l’ISO sur le serveur de manière à ce qu’il soit disponible en téléchargement direct. Comme pour la première solution, il suffit de monter cette image sur la VM 2003 et de procéder à l’installation.

A noter qu’il faudra que le Service Pack 2 soit déployé sur la VM afin que les Integration Services s’installent. Plusieurs pilotes (dont le très important pilote de carte réseau !) vont s’installer et un redémarrage sera nécessaire.

Pas de commentaire

Powershell : listing des objets ordinateur n’ayant pas donné signe de vie depuis un laps de temps

  de

Dans la série « J’entretiens proprement mon ActiveDirectory », je vais vous proposer aujourd’hui un script vous permettant de lister dans un fichier CSV les objets Computer qui n’ont pas donné de signe de vie sur le domaine depuis un certain nombre de jours spécifié (par défaut dans ce script, 60).

Il est important de bien faire attention aux OU sur lesquelles nous souhaitons effectuer la recherche, afin d’éviter de supprimer des stations qui ne servent que ponctuellement ou qui ne sont positionnées sur le réseau que lors des campagnes de patchs par exemple. Il conviendra donc de modifier dans le script le paramètre SearchBase qui est passé lors de la requête ActiveDirectory.

$csvoutput = "$env:temp\orphan-computers.csv"
Write-Host "Orphan Computer objects listing script"
Write-Host "======================================"
Write-Host ""
Write-Host "This script will output to a file a list of Computer objects in the ActiveDirectory that haven't logged onto the domain for a specified number of days."
[int]$nbdays = Read-Host "Number of days before considering a Computer object orphan ? (default: 60)"
if ($nbdays -eq "") { $nbdays = 60 }
$today = Get-Date
$complist = Get-AdComputer -filter * -Properties LastLogonDate -SearchBase "OU=serveurs,DC=superdomaine,DC=com"
foreach ($computer in $complist) {
$lastlogondate = $computer.LastLogonDate
$fqdn = $computer.DNSHostName
if ($lastlogondate -eq $null) { Add-Content $csvoutput "$fqdn,'Object never logged on'" }
elseif ($lastlogondate.AddDays($nbdays) -lt $today) {
Add-Content $csvoutput "$fqdn,$lastlogondate"
}
}
Write-Host "All done. File is located in $env:temp."
explorer $env:temp

Les stations ont leur nom DNS et leur dernière date de communication avec le domaine de renseignées dans un fichier CSV écrit dans le répertoire des fichiers temporaires.

Télécharger
Pas de commentaire

Migration de la définition des shares Windows

  de

C’est ballot, mais Robocopy est incapable de faire une copie d’un répertoire en conservant son statut de répertoire partagé et les détails associés. Lorsqu’on migre un serveur de fichiers avec par exemple des homedirs, il faut donc transférer les dossiers vers le nouveau avec Robocopy, puis ensuite, appliquer les partages. Plutôt contraignant si il y a des centaines de répertoires à refaire.

Heureusement, si le serveur d’origine et de destination ont exactement la même configuration disque et les mêmes chemins, il est possible d’extraire la définition des shares et donc de l’importer sur le nouveau serveur pour que les répertoires soient de nouveau partagés.

La clef HKLM\System\CurrentControlSet\Services\LanmanServer\Shares contient ces définitions :

Ces clés contiennent le nom du partage, ainsi que d’autres informations (chemin, description)… Il est donc important que les chemins concordent ; en effet, ouvrir le fichier .reg contenant la clef et ses valeurs avec un éditeur de texte ne permettra pas une modification directe.

Un redémarrage est nécessaire après l’import de la clef sur le nouveau serveur afin que les partages soient visibles dans la console Computer Management.