Étiquette : 2008 R2

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
Pas de commentaire

Fausse alerte de quota maximal atteint sur un répertoire partagé

  de

J’ai eu le cas aujourd’hui d’un répertoire partagé limité par un quota d’1 Go sur un serveur Windows 2008 R2 qui était considéré comme plein par la station de travail l’ayant monté alors que la taille des fichiers présents n’excède pas 200 Mo. Un démontage et remontage du répertoire ainsi qu’un redémarrage de la station n’ayant rien changé, je me suis connecté sur le serveur pour vérifier l’occupation réelle du répertoire : même résultat que sur la station cliente, et pourtant, dans la console des partages, j’obtiens un espace libre de 670 Ko.

Afin de forcer un rafraîchissement des données du quota, il existe l’outil utilisable en ligne de commande dirquota qui est installé en même temps que le rôle de serveurs de fichiers. Pour rafraîchir le quota du répertoire, en assumant que son chemin local soit C:\sharesengue :

dirquota quota scan /path:C:\sharesengue

Ensuite, un petit tour dans la console permet de voir que le quota a bien été mis à jour et qu’on ne se fera plus jeter par l’OS client pour cause d’espace disque insuffisant :

Pas de commentaire

Un serveur d’un pool DFSR n’est plus synchronisé avec les autres

  de

J’ai rencontré depuis quelques temps des soucis par rapport à un
partage réseau porté par DFSR sur 4 serveurs 2008 R2. Tout d’abord, un premier
dysfonctionnement concernant le Staging Quota plutôt simple à résoudre, et
ensuite un des 4 serveurs qui n’était plus synchronisé avec les 3 autres,
résultant en des différences notables entre les répertoires et les fichiers.

Tout d’abord, la résolution du Staging Quota et une
rapide explication de ce que c’est. Il s’agit d’un espace dont a besoin DFSR
pour opérer proprement la réplication, en fait DFSR s’en sert comme file
d’attente par rapport aux changements qui vont être propagés par la suite sur
tout le pool. La préconisation de Microsoft (voir ce
lien) est d’avoir une taille au minimum équivalente aux 32 plus gros
fichiers du partage répliqué. DFSR fait régulièrement du nettoyage dans cette
file d’attente mais il se peut qu’avec la croissance du partage, le Staging
Quota décidé au départ ne soit pas suffisant. Cette alerte est remontée
dans le journal d’événements (Source : DFSR, Event ID : 4206). J’ai donc
dû l’agrandir ; rien de complexe, cela peut être réalisé en pleine journée car
cela ne nécessite pas de redémarrer le service DFSR. 
Dans dfsmgmt.msc (ou via le Server Manager), on
déroule les réplications, puis en sélectionnant celle qui nous intéresse, on
aura les partages et les serveurs qui constituent ce pool.

L’accès au réglage du Staging Pool s’obtient avec un simple
clic-droit sur le partage, puis Staging.

Maintenant que ce problème est réglé, j’ai réalisé quelques tests
pour d’abord confirmer que le serveur ayant un nombre incohérent de fichiers
dans son partage par rapport aux autres était bien désynchronisé. Un simple
fichier unique créé chacun des 4 serveurs s’est retrouvé propagé sur tous les
autres… sauf un, et celui placé sur le serveur hors synchronisation ne s’est
pas propagé, ce qui signifie que le serveur est désynchronisé à la fois en
envoi comme en réception. Dans la suite de l’exemple, je vais appeler D le serveur
désynchronisé et S le serveur lié qui est en bon état de marche.

D et S sont
deux serveurs Windows 2008 R2 hébergeant un partage DFSR nommé partage ; D et S
doivent avoir les mêmes fichiers (sauf .BAK, .TMP et fichiers commençant par
une tilde car non répliqués par DFSR) et l’un et l’autre opèrent les
transactions en envoi comme en réception. J’ai vérifié si des fichiers
étaient programmés en envoi ou en réception avec cette instruction :

dfsrdiag ReplicationState

Rien. Je vérifie si il reste des fichiers en attente de synchronisation, autrement appelés backlog :

dfsrdiag backlog /SendingMember:D /ReceivingMember:S /RGName:partage
/RFName:partage

Et en effet, de nombreux fichiers étaient en attente de synchronisation, et dans les deux sens ; un état des lieux des fichiers a confirmé cette différence.

Il a donc été décidé de procéder à la suppression et
recréation des liens du serveur D au niveau DFSR. Tout d’abord, on procèdera à
la désactivation du partage dans la console DFS avant de procéder à sa suppression.

En choisissant la première option, non seulement on indique
que l’on ne souhaite plus que le serveur D ne se réplique plus, mais en plus,
on supprime ses liens avec le serveur S (ou le reste du pool, le cas échéant).
En choisissant la deuxième option, on pourrait toujours tomber sur le serveur D
en appelant le partage, ce qui n’est pas souhaitable.
Une fois la suppression effectuée, on procède au rajout de D
comme membre du pool DFS aux côtés de S, en prenant bien soin d’y appliquer les
mêmes paramètres. Rien de complexe, je lie le serveur D à S (qui lui-même peut
être relié à d’autres serveurs du pool), dans les deux sens (envoi et
réception). Quelques captures d’écran du wizard à titre d’exemple :

Un petit tour dans le journal d’événements de S m’indique
qu’il arrête la communication avec son partenaire D à cause d’une erreur
(Source : DFSR, Event ID : 5014).
Je dois donc attendre la réplication entre les ActiveDirectory pour qu’ils enregistrent tous la suppression du membre et son retour dans le pool. Ensuite, cette instruction exécutée sur D et S me permet de les forcer à bien actualiser les informations DFSR afin qu’ils soient totalement à jour.

dfsrdiag pollad

Tout ça, pour rien. Toujours pas une trace de
synchronisation entre D et S. Et dans le journal d’événements de D, je trouve une entrée
m’indiquant qu’il communique bien avec S ; mais ce n’est pas réciproque puisque
S me dit que D n’est plus membre du pool DFS. Je décide donc de regarder au
niveau ActiveDirectory pour voir si je peux y trouver les paramètres DFS. Le
journal d’évènements permet de savoir avec quel DC les serveurs communiquent (Event
ID : 1206).
Un petit coup d’ADSI Edit sur chaque DC sur lequel un
serveur est connecté permet d’en savoir plus : les informations propres à DFSR
se trouvent dans l’objet du serveur. Les réplications sont bonnes car les mêmes
objets sont disponibles sur le DC où D et S sont connectés. A noter que cette
référence au DC ne change que lorsque le service DFSR démarre ; si le DC en
question est arrêté ou supprimé, il faut redémarrer le service DFSR pour que la
prise en compte soit effective et cela peut occasionner des désynchronisations
si ce n’est pas fait.

 

Par acquis de conscience, je vérifie tout de même mes
réplications : repadmin /showrepl * ne me renvoie rien de particulier, toutes
les réplications sont valides et datent de 30 minutes tout au plus. Par ailleurs, le bilan de santé effectué à partir de la
console d’administration DFSR m’indique toujours le même message : « This member is
waiting for initial replication for replicated folder partage and is not
currently participating in replication. This delay can occur because the member is waiting for the DFS
Replication service to retrieve replication settings from Active Directory Domain
Services. After the member detects that it is part of replication group, the
member will begin initial replication.« 
Il est possible d’avoir ce message lorsqu’il n’y a plus de
membre primaire sur le pool DFS ; le membre principal étant celui qui sert
de maître par rapport aux fichiers et qui écrasera les autres lors de la
réplication initiale seulement. Je ne trouve aucune trace dans les journaux
d’évènements (Event ID à chercher : 4002 puis 4112). Je décide alors de
faire du serveur DFS principal le membre primaire :
dfsradmin
Membership Set /RGname:partage /RFName:partage /MemName:ServPrim
/IsPrimary:True

Je force une réplication sur tous les contrôleurs de domaine
afin que l’information se propage sur tous les sites et ensuite je demande aux
serveurs DFS de requêter l’AD pour obtenir le nouveau serveur primaire. Toujours pas mieux.

Finalement, j’ai décidé de supprimer complètement mon partage DFSR, liens et namespace et je l’ai recréé de zéro : les serveurs se synchronisent désormais proprement.

Pas de commentaire

Désactivation des ciphers AES 128, AES 256 et 3DES 168 sous Windows Server

  de

Il y a peu, j’ai dû désactiver sur une plateforme TLS 1.0 et 1.1. Aujourd’hui, rebelote, mais avec les ciphers Triple DES, ainsi qu’AES 128 et 256.

J’ai placé un extract de ces clefs de registre dans une archive disponible sur mon miroir de téléchargement.

En ouvrant regedit, on va se placer dans le chemin suivant :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

Puis, il suffira de créer une clef par cipher que l’on souhaite désactiver. Dans notre cas, nous allons créer 3 clefs ayant les noms suivants :

  • Triple DES 168
  • AES 128
  • AES 256

Dans chacune de ces clefs, il faudra créer une valeur DWORD appelée Enabled et ayant pour valeur 0.

On obtient donc quelque chose de similaire à ceci :

Un redémarrage est nécessaire pour appliquer les modifications car la DLL schannel ne lit les paramètres du registre qu’au démarrage du système. Si jamais il y a besoin d’annuler les modifications réalisées, il suffit de supprimer les clefs tout juste créées. A noter que si il y a désactivation d’un cipher utilisé pour encrypter les pages web utilisées par le serveur IIS, ces pages ne seront plus accessbiles, il convient donc de faire un test au préalable et de désactiver avec parcimonie les ciphers.

Si l’on désactive le cipher AES 256 via le registre, cette page ne sera plus accessible

Plus d’informations concernant les ciphers désactivables sous Windows sont disponibles à ce lien.