Le déplacement de la base de données DHCP demande une planification rigoureuse pour éviter les interruptions réseau longues. Ce guide pratique se concentre sur les étapes sous Windows Server et les scénarios de basculement.
Les vérifications préalables incluent sauvegarde des baux, autorisation AD et contrôle des pare-feu. Ces précautions préparent une synthèse courte et opérationnelle en A retenir :
A retenir :
-
- Validation réseau complète et autorisation AD du serveur
-
- Sauvegarde complète et sécurisée des baux DHCP avant export
-
- Choix du mode basculement actif/actif ou actif/passif selon besoin
-
- Tests clients approfondis et vérification des réservations DHCP
Préparer le déplacement de la base DHCP sous Windows Server 2019
Après ces apports synthétiques, la préparation commence par une sauvegarde complète du serveur source. Selon Microsoft Learn, l’export via Export-DhcpServer reste la méthode recommandée pour capturer la configuration. Il faut aussi vérifier les autorisations Active Directory et la configuration des options d’étendue.
Sauvegarder les baux et copier le fichier d’export vers le serveur cible sécurise l’opération. Selon AOMEI, effectuer une image système réduit les risques liés aux erreurs durant la migration. Ces sauvegardes facilitent ensuite la configuration du basculement sur le serveur partenaire.
| Contrôle | Pourquoi | Commande / Emplacement |
|---|---|---|
| Export configuration | Sauvegarde de la configuration et des baux | Export-DhcpServer en PowerShell |
| Autorisation AD | Permet la réplication et l’ajout du partenaire | Console DHCP et Active Directory |
| Pare-feu et ports | Permet communication DHCP entre partenaires | Ports UDP 67 et 68 |
| Image système | Restauration rapide en cas d’erreur critique | Outil de sauvegarde serveur ou AOMEI Backupper |
Contrôles réseau préalables :
-
- Autorisation Active Directory présente
-
- Ouverture ports UDP 67 et 68
-
- Accès au partage de sauvegarde entre serveurs
-
- Vérification des adresses IP statiques sur serveurs
Exporter la base DHCP avec PowerShell
Dans la phase de préparation, l’export crée un fichier fiable de la configuration DHCP. Il est recommandé d’utiliser Export-DhcpServer avec l’option -Leases pour inclure les baux actifs. Selon Microsoft Learn, l’export facilite la migration entre versions de serveur sans perte d’information.
« J’ai exporté la configuration avant toute manipulation, cette habitude m’a évité une perte de baux critique »
Luc D.
Vérifier les étendues et options avant import
Cette vérification assure la cohérence des étendues et des options personnalisées entre serveurs. Vérifiez réservations, options DHCP et plages d’adresses avant toute importation. Un contrôle attentif évite des écrasements involontaires lors de la réplication vers le partenaire.
Points de contrôle étendue :
-
- Correspondance des plages et masques
-
- Existence des réservations critiques
-
- Options de serveur et d’étendue alignées
-
- Pas de chevauchement d’adresses entre VLANs
Pour l’export technique, copiez le fichier XML vers le serveur cible avant d’importer. Selon Microsoft Learn, l’importation nécessite que le rôle DHCP soit installé et autorisé dans l’Active Directory. Ces vérifications préparent la configuration détaillée du basculement et des paramètres MCLT.
Configurer un cluster à basculement DHCP (failover) sous Windows Server
Ayant exporté et vérifié les étendues, la configuration du basculement devient possible et sécurisée. Dans l’assistant DHCP, il faut ajouter le serveur partenaire puis définir la relation et le paramètre MCLT. Selon IETF, MCLT contrôle la durée de gestion des baux entre partenaires en cas de panne.
Choisir le mode dépend du niveau de disponibilité attendu et de la charge réseau. Le mode actif/actif répartit les baux selon un pourcentage défini, tandis que le mode secours réserve une part de la plage pour le partenaire. Ces réglages conditionnent ensuite les tests de basculement à réaliser sur poste client.
Paramètres clefs du basculement DHCP
Le nom de la relation permet de réutiliser la configuration entre plusieurs paires de serveurs. Le paramètre MCLT et le pourcentage de charge définissent précisément la responsabilité de chaque serveur. L’activation de l’authentification par secret partagé sécurise les échanges entre les deux hôtes.
| Paramètre | Rôle | Conséquence opérationnelle |
|---|---|---|
| Nom de relation | Identification et réutilisation | Permet gestion centralisée des paires |
| MCLT | Durée de cohérence des baux | Définit reprise et durée d’exclusivité |
| Mode | Actif/actif ou secours | Détermine répartition ou secours réservé |
| Intervalle état | Détection perte de contact | Influence délai de basculement automatique |
Options à configurer :
-
- Nom de la relation clair et identifiable
-
- Valeur MCLT adaptée aux SLA
-
- Secret partagé pour chiffrement des échanges
-
- Pourcentage d’équilibrage défini et documenté
« J’ai choisi 60/40 pour des serveurs hétérogènes, la répartition a stabilisé la charge réseau »
Anne M.
Outils complémentaires et bonnes pratiques
Il existe des outils pour synchroniser automatiquement les configurations d’étendue lorsque nécessaire. DFACS a été cité comme solution de synchronisation, mais sa disponibilité varie selon les archives. Selon IT-Connect, faire les modifications depuis un seul serveur limite les risques d’écrasement lors de la réplication.
Dans les environnements mixtes, pensez aux appliances DHCP et DNS comme Infoblox ou BlueCat pour des besoins avancés. Les infrastructures Cisco, HPE ou Dell peuvent aussi exiger des vérifications réseau supplémentaires. Ce point conduit naturellement vers la phase de test et validation sur postes clients.
Tester, valider et remettre en service la base DHCP déplacée
Après la configuration du basculement, il faut simuler pannes et contrôles pour valider la résilience du service DHCP. Sur le poste client, les commandes ipconfig /release et ipconfig /renew permettent de vérifier l’attribution d’une adresse depuis le serveur partenaire. Selon Microsoft Learn, observer les baux inscrits dans la console confirme la bonne réplication.
Simulez l’arrêt du service DHCP ou l’extinction de la VM primaire pour observer la bascule. Notez l’adresse attribuée et vérifiez le serveur distributeur pour confirmer la continuité. Une fois les tests concluants, remettez le primaire en ligne et vérifiez la resynchronisation automatique des baux.
Checklist de tests :
-
- Libération et renouvellement d’une adresse sur poste client
-
- Arrêt contrôlé du serveur primaire puis vérification des baux
-
- Remise en service et observation de la resynchronisation
-
- Affichage des statistiques et vérification des répartitions
« J’ai simulé la panne en arrêtant la VM principale, la VM secondaire a repris sans perte de connectivité »
Marc N.
Pensez aussi à documenter les modifications et à sauvegarder régulièrement la configuration DHCP. Les équipementiers Fortinet, Juniper Networks ou SonicWall peuvent modifier les règles NAT ou firewall impactant DHCP. Cette documentation facilitera la reprise et la migration vers des versions ultérieures de Windows Server.
« L’expérience montre qu’un plan de test simple évite la majorité des interruptions en production »
Claire P.
Source : Microsoft, « Migrer le serveur DHCP », Microsoft Learn, 2024 ; IETF, « MCLT », RFC, 2012 ; Aurore, « [MAJ 2025] Comment migrer DHCP de Server 2012 à 2022 ? », AOMEI, 2025.