Préambule Je pars d’une situation où j’ai déjà un serveur Windows 2012R2 configuré en contrôleur de domaine, avec GPO et partage de fichiers. Je veux ajouter un 2e serveur sous Windows Server 2016, qui fasse office principalement de failover si un des 2 serveurs tombe en panne. Ceci pour les rôles de contrôleur de domaine, de serveur DHCP, serveur DNS, de serveur SMB et déploiement automatique de partages réseaux et d’imprimantes.
Le domaine est WINDOMAIN, le serveur actuel est WINDOMAIN\DC1.
Configurer le serveur secondaire
On commence par relier le serveur au réseau, on lui configure une adresse ip fixe, le hostname souhaité (ici DC2). on le connecte au domaine.
On peut ensuite installer le rôle AD DS, puis promouvoir le serveur en contrôleur
de domaine. La réplication de l’AD se fait automatiquement, avec toutes les GPO.
DNS Intégration à l’AD
Normalement, le serveur DNS est installé et configuré en même temps que le
serveur AD DS. Ceci permet aux enregistrements DNS d’être stockés dans l’AD directement, et donc d’être répliqués entre tous les controleurs de domaine. Cela se vérifie dans le gestionnaire DNS, avec un clic droit -> Propriétés sur une zone, on doit voir l’Etat “Intégré à AD”. Ceci ne fonctionne que si les 2 serveurs DNS sont aussi des controleurs de domaine, ce qui est le cas ici. Si un serveur DNS n’est pas controleur, il faut passer par la création sur le second serveur d’une zone secondaire qui pointera vers le premier serveur).
Un peu plus d’infos chez Microsoft
Redirecteurs
Toujours dans le gestionnaire DNS, dans les propriétés de chaque serveur, il faut penser à aller vérifier les redirecteurs (serveur DNS utilisé si le serveur intégré ne sait pas résoudre, c’est-à-dire pour tout ce qui ne relève pas du domaine). Typiquement, on peut mettre l’IP de notre box, ou 8.8.8.8 par exemple. Il y’a aussi l’option de se rapatrier sur les serveurs DNS racines en cas d’indisponibilité des redirecteurs. On trouve la liste de ces serveurs dans l’onglet “Indications de racine”.
Distribution par DHCP
Enfin, il faut aller paramétrer les options du DHCP pour qu’il distribue les 2 serveurs DNS. Pour ceci, dans DC1 (actuellement le seul serveur DHCP), aller dans le gestionnaire DHCP, IPv4 -> Étendue -> Options d’étendue et ajouter l’IP du nouveau serveur dans les Serveurs DNS (006).
Note : si un des 2 serveurs venait à être en panne/hors-ligne durablement, penser à
s’assurer que le serveur toujours en place est bien distribué en serveur primaire, ceci accélérera la résolution DNS.
DHCP La première étape est d’avoir une étendue active sur un des 2 serveurs, dans cet exemple sur DC1. Si ce n’est pas le cas, on peut en créer une dans le gestionnaire DHCP -> Nouvelle étendue. L’installation est complètement guidée. Penser à spécifier les options telles que serveurs DNS, passerelle par défaut.
Sur DC2, installer le rôle Serveur DHCP. Ne pas configurer d’étendue maintenant, elle va être automatiquement répliquée depuis DC1. Aller sur DC1 dans le gestionnaire DHCP, IPv4 -> Clic-droit sur “Étendue” -> Configurer un basculement Suivre les étapes en ajoutant l’IP du serveur secondaire (DC2).
Au cours de la création du basculement, les options du serveur DHCP de DC1
seront répliquées sur DC2 (étendue, route par défaut, serveur DNS etc°. Toutefois ces options ne seront par la suite plus synchronisées automatiquement. Pour les synchroniser, on peut lancer sur le serveur “source”, qui possède les informations à jour, la commande Powershell suivante :
Invoke-DhcpServerv4FailoverReplication qui va répliquer l’ensemble de ses paramèters sur tous les serveurs partenaires. Il y’a aussi un script planifié qui permet de faire ceci automatiquement, disponible sur cette page avec l’archive zip mirroré sur mon memo.
Si on souhaite supprimer la relation de basculement, il faut savoir que si on procède
à la déconfiguration du basculement sur DC1, cela supprimera automatiquement l’étendue sur DC2 (et vice-versa).
Partage de fichiers Afin d’assurer l’accès aux partages réseaux même si un des 2 serveurs (hébergeant directement les données) tombe, nous allons passer par la réplication DFS. Celle-ci va nous permettre une synchronisation instantanée et permanente de l’état des dossiers de travail, tout en y accédant de manière transparente par le réseau, via un espace de nom DFS.
Dans mon cas, je pars d’un dossier de travail déjà existant, sur DC1, avec le chemin D:\Travail\ . Celui-ci est paramétré avec des droits d’accès spécifiques, et le partage réseau est déployé automatiquement via GPO avec le chemin \\DC1\Travail\ .
Configuration de la réplication DFS (DFSR)
Il faut commencer par installer le rôle Services de fichiers et de stockage -> Services de fichiers et iSCSI -> Espaces de noms DFS et Réplication DFS sur DC1 ET sur DC2.
On lance le Gestionnaire de système de fichiers distribué DFS.
Réplication -> Nouveau groupe de réplication... . J’ai laissé le choix par défaut, groupe de réplication multi-usages. On donne un nom au groupe de réplication, dans mon cas “Travail”. On ajoute DC1 et DC2 dans la liste des serveurs. Pour une réplication dans les 2 sens, quel que soit le serveur sur lequel les données sont modifiées, on choisit “Maille pleine”. J’ai laissé les options de bande passante par défaut, puisq’on est ici en réseau local.
On prend bien garde à choisir le serveur qui contient actuellement les données en tant que Membre principal. Il s’agit ici de DC1, car DC2 ne contient actuellement aucune donnée. Ainsi, au cours de la synchro initiale, toutes les données présentes actuellement sur DC1 seront répliquées sur le ou les autres serveurs. une fois la synchro initiale terminée, cela ira dans les 2 sens.
On choisit ensuite le dossier local où sont stockées les données sur DC1. C’est D:\Travail comme indiqué au-dessus. Note : Microsoft eux-même déconseillent de répliquer directement une lettre de lecteur, bien que ce soit censé fonctionner. J’ai personnellement eu des soucis lorsque j’ai essayé. Il faut ensuite la réplication sur chaque serveur membre. On coche la case Activé, et on définit un chemin local sur le membre en question. Il n’est pas obligatoire que tous les membres aient le même chemin d’accès local.
On valide, et la réplication commencera sous peu. Les données seront ainsi sur les 2 serveurs. Toutefois, le partage réseau déployé chez les clients ne fait toujours appel qu’au serveur DC1.
Par défaut, lorsque le service DFSR s’arrête, par exemple lorsqu’un serveur reboote, le système lui laisse 30 secondes pour s’éteindre proprement. S’il sépasse ce délai, alors la fermeture sera forcée, de façon brutale. Or il arrive régulièrement que le service aie besoin de plus de temps que ça pour s’éteindre (dans le cas d’une grosse base de fichiers). Pour éviter ce problème, on peut, sur chaque serveur, accéder à la clé de registre
`HKLM\SYSTEM\CurrentControlSet\Control`
et régler la valeur WaitToKillServiceTimeout sur le nombre de millisecondes que l’on
souhaite accorder à l’extinction (de chaque service). Par exemple, 600000 pour laisser 10 minutes. À noter que cette valeur ne peut excéder 1h, sans quoi elle est réinitialisée à la valeur par défaut de 30 secondes. Source2012
DFSR - Problème de synchronisation
Il peut arriver que certains dossiers ou fichiers ne soient pas répliqués correctement. Plusieurs raisons peuvent expliquer ceci, des problèmes de taille de la Staging Area étant régulièrement évoqués. (cf comment définir une taille de staging)
Une autre raison possible est que les éléments en question soient chiffrés. DFSR ne synchronise pas les fichiers chiffrés. Le script suivant, strippé de cette page (script bien plus complet et détaillé), permet de lister les fichiers chiffrés dans le fichier $logFile , puis de les déchiffrer
juste avant la dernière accolade pour ajouter le déchiffrement automatique.
Une autre raison possible est que DFSR, par design, ne synchronise pas les dossiers/fichiers avec l’attribut “temporaire”. Source : https://blogs.technet.microsoft.com/askds/2008/11/11/dfsr-does-not- replicate-temporary-files/ Or, il peut arriver, sur de gros volumes de données, que des dossiers légitimes contiennent, par erreur (humaine ?), cet attribut. Rien n’indique graphiquement sa présence, et l’utilitaire attrib.exe non plus. Il faut utiliser fsutil pour le consulter.
fsutil usn readdata X:\path\to\folder\
qui retournera quelque chose du genre
Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x0021000000002350
Parent FileRef# : 0x0003000000005f5e
Usn : 0x000000004d431000
Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x5fb
File Attributes : 0x120
File Name Length : 0x10
File Name Offset : 0x3c
FileName : test.txt
On y voit que, dans les attributs du fichier, le masque 0x100 est présent. Selon la table donnée dans le lien ci-dessus, il correspond à l’attribut TEMPORARY.
Pour le supprimer récursivement, on passe par Powershell :
L’idée est de pouvoir centraliser les partages réseaux en y accédant via le nom de domaine. Par exemple, au lieu de déployer \\DC1\Travail , on va déployer le partage \\WINDOMAIN\Travail , et ce sera un des serveurs hébergeant l’espace de nom Travail qui va répondre.
Cette techno est complètement dissociable de la réplication, bien qu’elles soient
souvent utilisées ensemble. On peut décider de partager sous des chemins unifiés des ressources venant de serveurs différents (par exemple \\DC1\Travail et \\DC2\Direction , même si uniques sur leurs serveurs respectifs, peuvent être accessibles sous \\WINDOMAIN\Travail et \\WINDOMAIN\Direction ). On peut aussi utiliser la réplication sans espace de noms, juste pour dupliquer les données d’un site à l’autre par exemple.
Si 2 serveurs hébergent le même espace de nom, mais sans réplication des dossiers, le contenu affiché sera alternativement le contenu de l’un ou l’autre. Par exemple, si \\DC1\Travail et \\DC2\Travail sont tous les 2 référencés par l’espace de nom \\WINDOMAIN\Travail mais que les 2 dossiers ne sont pas répliqués et ont des contenus différents, on ne sait jamais quel sera le contenu affiché par \\WINDOMAIN\Travail , ce sera celui qui répond le plus vite.
Mise en place
On ouvre le gestionnaire DFS.
Espace de noms (clic-droit) -> Nouvel espace de noms . On choisit DC1 comme premier serveur. On nomme notre espace de nom, ici Travail ; Dans Modifier les paramètres , on peut choisir l’emplacement des données locales. On choisit ici D:\Travail, comme défini précédemment, et on choisit les droits d’accès Admin : Full ; Users : RW (les vrais droits d’accès sont gérés par le NTFS). On choisit l’option “Espace de noms de domaine”, puis on valide la création.
Le serveur DC1 est maintenant prêt à répondre lorsqu’on appelle
\WINDOMAIN\Travail. On veut maintenant que DC2 puisse répondre aussi. Pour ceci, dans le gestionnaire DFS, sous Espaces de noms, clic-droit sur \WINDOMAIN\Travail -> Ajouter un serveur d’espaces de noms. Comme ci- dessus, on rentre le nom du serveur, on choit l’emplacement local des données, on met les droits sur le partage et on valide.
Et voilà : les 2 serveurs sont désormais capables de répondre lorsque l’on interroge le partage directement auprès du domaine, et grace à la combinaison avec la réplication, la continuité en cas de chute d’un serveur est quasi-transparente (à un caffouilage d’explorer près, sur les postes clients).
Note : il est possible, directement sous l’espace de noms DFS? de “Publier” des dossiers, qui seront créés puis partagés automatiquement, et référencés dans le gestionnaire. Il n’est pas du tout obligatoire de les utiliser si l’on souhaite créer des sous-dossiers et les partager, et le faire manuellement permet une plus grande souplesse (chemin du partage réseau notamment).
