DHCP Failover Auto Config Sync sous Windows Server 2012

Dans Windows Server 2012, le service DHCP peut être configuré pour fournir une haute disponibilité. Les baux d’adresses IP d’une étendue sont ainsi synchronisés entre deux serveurs DHCP en relation de basculement. Cependant, lorsque l’administrateur effectue des modifications dans la configuration d’une étendue, celle-ci n’est pas répliquée sur l’autre serveur DHCP.

L’outil DHCP Failover Auto Config Sync écrit en Windows PowerShell, permet de réaliser cette réplication automatiquement.

La documentation que je vous propose, présente cette problématique et met en œuvre l’outil DHCP Failover Auto Config Sync (DFACS) à travers un atelier pratique.

Télécharger la documentation sur DHCP Failover Auto Config Sync [1.33 Mo]

Problème de serveur DNS avec Windows 7 et dhcp (dans un cas bien particulier)

Imaginons un serveur isc dhcpd configuré de la sorte (centos 6.4) :


...
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name-servers  192.168.0.1;
option  routers 192.168.0.254;
authoritative;
deny client-updates;
deny
pool {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
}
host  monposte.be-root.com {
option domain-name-servers  192.168.0.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.10;
}
}

Symptômes :

Sur la machine monposte :
si l’on boote sur un livecd (ubuntu), nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (les paramètres sont donc ceux attendus)
si l’on boote sur windows 7, nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1  (le serveur dns n’est pas celui déclaré dans la section host. Il s’agit du dns déclaré dans la section subnet).

Si sous windows 7, nous effectuons un ipconfig /renew alors les parametres sont 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2. Cependant, au redémarrage suivant, les paramètres sont de nouveau 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1.

Analyse :
Si l’on sniffe l’echange entre le poste windows 7 et le serveur dhcp, on remarque :
-1 requête DHCP Request de la part du client
-1 réponse DHCP ACK de la part du serveur DHCP lui fournissant les paramètres  192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (donc corrects).
-1 requête DHCP Inform de la part du client précisant sont adresse 192.168.0.10 et demandant les paramètres subnet mask/domain name/ router/ domain name server/…/private-proxy autodiscovery
-1 réponse DHCP ACK de la part du serveur dhcp lui fournissant la passerelle 192.168.0.254 et le dns 192.168.0.1 (donc erronés).
– …
A priori, tant que le client ne reçoit pas de réponses valides pour la recherche automatique de proxy, il continue a faire des requêtes DHCPInform toutes les 100 secondes.
La norme concernant les requêtes DCHP Inform stipule :

The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

Ainsi, le serveur dhcpd n’utilise pas les informations de son fichier de leases pour répondre avec les même paramètres que ceux envoyés lors du DHCP Request mais parcours le fichier de configuration.
Comme l’adresse ip indiquée dans la requête DHCP Inform fait partie du subnet 192.168.0.0, il répond avec les paramètres globaux de la zone.

Résolution :
On peut contourner de problème de plusieurs façons :

  • Virer le paramètre authoritative dans le subnet. Le serveur ne répondra plus aux requêtes DHCP Inform … (moyen)
  • Supprimer les déclarations globales de serveurs dns et les mettre par hôte/pool. (long et pas très pratique).
  • Si l’on n’utilise pas la fonctionnalité de découverte automatique de proxy (wpad) : sur le client Windows7, lancer l’éditeur de base de registres.
    Sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Identifiant-de-l-interface , créer une clé nommée UseInform de type DWORD. Initialiser à la valeur 0.
    Ainsi le client Windows 7 ne fera plus de requêtes DHCP Inform et donc conservera les informations retournées par lors de la première transaction DHCP Request.

Activer un disque dynamique iscsi au boot sous Windows 2003

Sous windows, il se peut qu’un disque dynamique composé d’un ou plusieurs volumes iSCSI ne se réactive pas automatiquement au boot, du fait que l’initiateur iSCSI n’est pas chargé au moment de l’activation du volume.

Dans cet exemple, le volume dynamique V: (VLS)  est composé de deux volumes iSCSI (Disque 2 de 2To et Disque 3 de 1.5To).
Du fait des raisons citées auparavant, il faut le réactiver manuellement dans le gestionnaire de disques après chaque boot
en faisant un click droit sur le disque 2 ou 3 et choisir « Activer ».

Nous allons donc automatiser cette procédure. Nous allons créer un script d:\script\activation_vls.bat qui contient :

c:\windows\system32\diskpart.exe  /s "d:\script\connect_vls.txt"

Nous allons créer un fichier texte d:\script\connect_vls.txt qui contient les lignes :

Select Disk 2  
Online
Exit

Bien évidemment la ligne select disk 2 est à modifier en fonction du numéro du disque à réactiver (indiqué par le gestionnaire de disques).

Pour exécuter le script au démarrage de la machine, nous allons lancer gpedit.msc :

Nous allons dans Configuration ordinateur -> Paramètres Windows -> Scripts et nous cliquons sur Démarrage dans la fenêtre de droite. Aprés avoir cliqué sur Ajouter, il nous reste à sélectionner le script d:\script\activation_vls.bat.

Un reboot permet ensuite de vérifier le bon fonctionnement de la manip.