Sur les contrôleurs de domaine exécutant Windows Server 2025, un problème se produit lorsque le serveur identifie de manière incorrecte le réseau comme public au lieu de domaine après un redémarrage. Si certaines de vos règles de pare-feu Windows Defender sont appliquées à un profil réseau (emplacement), cela peut entraîner des problèmes de disponibilité du réseau du serveur.
Le problème du changement de type de réseau vers un type de réseau incorrect après un redémarrage est un ancien bug qui a été rencontré dans les contrôleurs de domaine et les serveurs membres exécutant les versions 2019 et 2022 de Windows Server. Le redémarrage du service Network Location Awareness ( NlaSvc ) était suffisant pour revenir automatiquement au profil réseau de domaine dans ces versions de Windows Server. Il est également possible de configurer le délai de démarrage du service NlaSvc ou d’implémenter une option de registre qui modifie le comportement du service NLA lorsqu’il tente de rétablir la connexion au domaine.
Set-ItemProperty-Path "HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" -Nom "AlwaysExpectDomainController" -Valeur 1-Type DWORD
Cependant, la détection de l’emplacement réseau est désactivée par défaut dans Windows Server 2025.
Pour garantir qu’un hôte Windows Server 2025 détecte correctement le type de réseau, réactivez simplement la carte réseau après le redémarrage de l’ordinateur. Si vous avez accès à la console du serveur (iLO ou équivalent), vous pouvez désactiver et réactiver la carte réseau via le panneau de configuration « Connexions réseau » ( ncpa.cpl ).
Si vous disposez uniquement d’un accès RDP ou PowerShell Remoting au DC, il est possible de redémarrer les cartes réseau à l’aide de la commande PowerShell :
Get-NetAdapter-Physique | Où-Objet { $\_.Status-eq "Up"} | Redémarrer-NetAdapter
Après cela, le réseau sera correctement identifié comme réseau de domaine ( DomainAuthenticated ).
Obtenir-NetConnectionProfile
Le problème de réinitialisation du type de réseau sur les contrôleurs de domaine Windows Server est lié aux paramètres du serveur DNS. Si le serveur s’utilise lui-même comme serveur DNS, il risque de ne pas répondre assez rapidement aux requêtes DNS lors du démarrage (avant que le service du serveur DNS ne soit complètement initialisé) pour déterminer l’état correct du réseau. C’est pourquoi le profil Public sécurisé sera attribué comme type de réseau.
Par conséquent, assurez-vous que le DNS secondaire des contrôleurs de domaine pointe vers les adresses des autres contrôleurs de domaine et évitez de les redémarrer tous en même temps en espaçant les redémarrages planifiés.
Vous pouvez également créer une solution de contournement à l’aide d’un simple script PowerShell dans le Planificateur de tâches. Il doit attendre que le service DNS démarre, puis redémarrer la carte réseau (exécuter la tâche en tant que SYSTEM) :
Programme/script : powershell.exe
Ajoutez des arguments (facultatif) : -ExecutionPolicy Bypass-NonInteractive-WindowStyle Hidden-command "do {$status=(Get-Service dns)} jusqu'à ($status.Status-eq 'Running'); Get-NetAdapter-Physical | Restart-NetAdapter"
Afin d’appliquer ce script à tous les contrôleurs de domaine, vous pouvez déployer une tâche de planification sur l’unité d’organisation des contrôleurs de domaine via GPO.
*️⃣ Lien source :
un profil réseau (emplacement), des adaptateurs réseau à l’aide de la commande PowerShell, un script PowerShell dans le planificateur de tâches, déployez une tâche de planificateur sur l’unité d’organisation des contrôleurs de domaine via GPO,