Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Modernisation de la `zone DNS _msdcs`
<a name="hybrid_directory_msdcs"></a>

La modernisation d'une `_msdcs` zone DNS est une condition préalable obligatoire avant de créer un annuaire Hybrid AD. Dans les environnements Active Directory modernes, elle `_msdcs.<ForestRoot>` est créée sous la forme d'une zone répliquée distincte à l'échelle de la forêt stockée dans la partition de l' ForestDnsZones application. Dans les environnements existants créés à l'origine sous Windows NT 4.0 ou Windows 2000 (puis mis à niveau), il n'`_msdcs`a jamais été séparé ; il existe simplement en tant que sous-domaine standard (sous-dossier) directement dans le fichier de zone de domaine parent.

Lorsqu'un nouveau contrôleur de domaine est promu avec le DNS installé, son processus d'installation recherche la partition `_msdcs.<ForestRoot>` d'application dédiée. Comme il ne trouve pas de zone autonome, il crée automatiquement une nouvelle `_msdcs` zone vide localement et revendique l'autorité sur cet espace de noms. Cela empêche complètement le nouveau DC de lire les anciens enregistrements de sous-domaines dans la zone parent et met à jour la délégation NS pour qu'elle pointe vers elle-même.

Il en résulte un conflit architectural. Tous les clients joints à un domaine sont désormais renvoyés vers un contrôleur de domaine doté d'une `_msdcs` zone vide, tandis que les enregistrements du localisateur de domaine réel (`_ldap._tcp.dc._msdcs`,`_kerberos._tcp.dc._msdcs`, enregistrements du catalogue global, CNAME GUID DC) restent bloqués dans l'ancien sous-domaine de la zone parent où aucun client ne peut les atteindre. Cela interrompt l'authentification Kerberos, la découverte LDAP et la localisation des contrôleurs de domaine en fonction du site dans l'ensemble de la forêt.

## Conception de zones `_msdcs` ancienne ou moderne
<a name="hybrid_directory_msdcs_legacy_vs_modern"></a>

Legacy (sous-domaine délégué)  
Par défaut dans Windows Server 2000, 2003, 2008 et 2008 R2. Dans cette conception, `_msdcs` existe en tant que sous-domaine délégué sous la zone parent. Les enregistrements NS de la zone parent pointent vers des contrôleurs de domaine spécifiques faisant autorité pour l'`_msdcs`espace de noms.

Moderne (zone autonome)  
Par défaut dans Windows Server 2012 et versions ultérieures. Dans cette conception, `_msdcs.<forest>` existe en tant que AD-integrated zone propre, répliquée sur tous les contrôleurs de domaine de la forêt via la partition ForestDnsZones d'application. Tous les DC font autorité et peuvent read/write enregistrer directement.

## Comment identifier le design de la `zone _msdcs`
<a name="hybrid_directory_msdcs_identify"></a>

Vous pouvez identifier la conception de votre `_msdcs` zone en exécutant ce qui suit sur n'importe quel contrôleur de domaine :

1. **Répertoriez toutes les zones DNS et recherchez `_msdcs` :**

   ```
   Get-DnsServerZone | Where-Object { $_.ZoneName -like "*_msdcs*" }
   ```

   **Design moderne (aucune action requise)** — vous serez `_msdcs.<forest-name>` répertoriée en tant que zone principale :

   ```
   ZoneName                          ZoneType   IsAutoCreated  IsDsIntegrated  IsReverseLookupZone  IsSigned
   --------                          --------   -------------  --------------  -------------------  --------
   _msdcs.premier.local              Primary    False          True            False                False
   ```

   **Conception ancienne (conversion requise)** : n'`_msdcs.<forest-name>`apparaîtra PAS dans la liste des zones. `_msdcs`Il existe plutôt uniquement en tant que sous-domaine délégué dans votre zone forestière. Vous pouvez le confirmer en vérifiant les enregistrements NS de la délégation :

   ```
   Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS
   ```

   Si cela renvoie des enregistrements NS, votre environnement utilise l'ancienne conception de sous-domaine délégué.

1. **Validation supplémentaire : confirmez le type de zone :**

   ```
   # This will succeed on modern design
   Get-DnsServerZone -Name "_msdcs.<forest-name>"
   
   # If you get an error like "Zone _msdcs.<forest-name> was not found", you have the legacy design
   ```

## Comment moderniser la zone DNS `_msdcs`
<a name="hybrid_directory_msdcs_modernize"></a>

Ces étapes doivent être effectuées avant de lancer la création du répertoire AWS Managed Microsoft AD Hybrid. Toutes les étapes sont effectuées sur des contrôleurs de domaine autogérés existants dotés d'un accès au gestionnaire DNS avec des DnsAdmins privilèges d'administrateur de domaine.

1. **Création de la zone autonome `_msdcs`**

   Sur un contrôleur de domaine autogéré existant :

   ```
   dnscmd localhost /ZoneAdd "_msdcs.<forest-name>" /DsPrimary /dp /forest
   ```

   Cela se crée `_msdcs.<forest-name>` sous la forme d'une AD-integrated zone dédiée avec une étendue de Forest-wide réplication. Tous les contrôleurs de domaine de la forêt recevront une copie via la ForestDnsZones partition.

   Attendez que la réplication AD se propage :

   ```
   repadmin /syncall /AeD
   ```

   Vérifiez que la zone existe (exécutez sur plusieurs contrôleurs de domaine) :

   ```
   Get-DnsServerZone -Name "_msdcs.<forest-name>"
   ```

1. **Supprimer l'ancienne délégation de la zone parent**

   L'ancien nœud de `_msdcs` sous-domaine et ses enregistrements existent toujours dans la zone parent. Ils doivent être supprimés afin que les requêtes DNS soient traitées exclusivement à partir de la nouvelle zone autonome.

   ```
   # Remove the _msdcs subtree (NS delegation + all child records) from the parent zone
   dnscmd localhost /NodeDelete <forest-name> _msdcs /tree /f
   ```
**Important**  
N'effectuez cette étape qu'après avoir confirmé que la zone autonome a été créée avec succès à l'étape 1. Si vous sautez l'étape 1, la suppression des anciens enregistrements provoquera une panne immédiate.

1. **Forcer tous les contrôleurs de domaine à réenregistrer les enregistrements SRV**

   L'ancien sous-domaine ayant été supprimé et la nouvelle zone autonome mise en place, tous les contrôleurs de domaine doivent réenregistrer leurs enregistrements de localisation dans la nouvelle zone.

   Exécutez les opérations suivantes sur chaque contrôleur de domaine local :

   ```
   # Flush DNS cache
   ipconfig /flushdns
   
   # Restart Netlogon — this triggers re-registration of all SRV, CNAME, and A records
   net stop netlogon
   net start netlogon
   
   # Force host record registration
   ipconfig /registerdns
   ```

1. **Vérification**

   Attendez 5 à 10 minutes pour la réplication, puis vérifiez :

   Confirmez les enregistrements renseignés dans la nouvelle zone autonome :

   ```
   Get-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -RRType SRV
   ```

   Vous devriez voir`_ldap._tcp.dc`, `_kerberos._tcp.dc``_ldap._tcp.gc`, et des enregistrements spécifiques au site pour tous les contrôleurs de domaine locaux.

   Vérifiez que la résolution DNS fonctionne de bout en bout :

   ```
   Resolve-DnsName "_ldap._tcp.dc._msdcs.<forest-name>" -Type SRV
   Resolve-DnsName "_kerberos._tcp.dc._msdcs.<forest-name>" -Type SRV
   ```

   Tous les contrôleurs de domaine locaux doivent apparaître dans les résultats.

   Vérifiez que l'ancienne délégation n'est plus dans la zone parent :

   ```
   Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS -ErrorAction SilentlyContinue
   ```

   Cela ne devrait rien rapporter.

   Pour plus d'informations sur la modernisation des `_msdcs` zones DNS, consultez [Comment diviser et migrer les enregistrements DNS du domaine enfant vers une zone DNS dédiée](https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/how-to-split-and-migrate-child-domain-dns-records-to-a-dedicated-dns-zone/255534) sur le site Web du blog Microsoft Core Infrastructure and Security.

## Résolution des problèmes
<a name="hybrid_directory_msdcs_troubleshooting"></a>

Si la nouvelle zone autonome reste vide après l'étape 3 :

Netlogon ne peut pas se réenregistrer s'il pense que des enregistrements existent déjà. Forcer une nouvelle inscription :

```
# Delete the Netlogon DNS registration cache
Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DnsAvoidRegisterRecords" -ErrorAction SilentlyContinue

# Restart Netlogon again
net stop netlogon
net start netlogon
```

Si les enregistrements n'apparaissent toujours pas, créez manuellement les enregistrements critiques en utilisant les valeurs de l'ancienne zone parent (disponibles depuis la sauvegarde ou depuis d'autres contrôleurs de domaine qui les ont mis en cache) :

```
# Example: SRV record for LDAP DC locator
Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_ldap._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 389

# Example: SRV record for Kerberos DC locator
Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_kerberos._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 88
```

Si les applications échouent toujours après la conversion :

Videz les caches DNS sur les serveurs d'applications et les ordinateurs clients concernés :

```
ipconfig /flushdns
```

Les entrées de cache DNS négatives (datant de la période de panne) peuvent persister jusqu'à 900 secondes (15 minutes) avant d'expirer.