Vous êtes sur la page 1sur 7

Mise en place d'une réplication/failover

AD/DNS/DHCP/DFS sur 2 Windows


Server
under WindowsServeur
Share

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

$logFile = "C:\Users\Administrateur\Desktop\EncryptedFiles.log"
$path = "X:\path\to\data"

$encryptedfiles += Get-ChildItem $path -File -Recurse -Force -ErrorAction


SilentlyContinue |
Where-Object { $_.Attributes -match "Encrypted" } |
Select-Object -ExpandProperty FullName

foreach ($file in $encryptedfiles){


Add-Content $logFile "$file"
(Get-Item -Force -LiteralPath $file).Decrypt()
}

$encryptedfolders += Get-ChildItem $path -Directory -Recurse -Force -ErrorAction


SilentlyContinue |
Where-Object { $_.Attributes -match "Encrypted" } |
Select-Object -ExpandProperty FullName

foreach ($folder in $encryptedfolders){


Add-Content $logFile "$folder"
cipher.exe /d /i $folder
}

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 :

Get-childitem X:\PATH -recurse | ForEach-Object -process {if (($_.attributes -band


0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

Configuration de l’espace de nom DFS (DFSN)

Généralités

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).

Vous aimerez peut-être aussi