Avoir un contrôleur de domaine (DC) ou même certains serveurs membres exécutant Windows Server 2025 qui basculent leur profil réseau de Domaine à Public après un redémarrage est l’un de ces petits problèmes qui peuvent causer bien des soucis. C’est particulièrement vrai si vous avez des règles de pare-feu qui dépendent du profil réseau approprié. Ce problème n’est pas entièrement nouveau ; il était déjà présent dans les versions 2019 et 2022, mais Windows Server 2025 semble avoir ajouté quelques complications, comme la désactivation par défaut de la détection de l’emplacement réseau (NLA).En clair, le serveur ne reconnaît pas son appartenance au domaine tant que vous n’intervenez pas, ce qui peut perturber vos paramètres réseau et de sécurité. Voici donc des solutions qui ont fonctionné sur certaines configurations, ainsi que des points à prendre en compte pour que tout fonctionne correctement.
Comment résoudre le problème d’identification erronée du profil réseau sur Windows Server 2025
Méthode 1 : Redémarrer le service de géolocalisation réseau
Cette astuce classique permet à Windows de reconnaître son appartenance à un domaine après un redémarrage. Le service NlaSvc (Détection de l’emplacement réseau) étant souvent à l’origine du changement de profil, son redémarrage peut forcer le serveur à réévaluer son type de réseau. Sur certaines machines, cela fonctionne immédiatement ; sur d’autres, un redémarrage complet ou manuel peut être nécessaire.
- Ouvrez PowerShell avec des privilèges d’administrateur. Si vous n’avez pas d’accès direct à la console, vous pouvez utiliser PowerShell via RDP ou WinRM.
- Courir:
Restart-Service NlaSvc
Après le redémarrage, vérifiez Get-NetConnectionProfilesi le profil est passé à « DomainAuthenticated ».Si ce n’est pas le cas, essayez de désactiver puis de réactiver la carte réseau dans Réseau et Internet > Connexions réseau ou via la ligne de commande :
Get-NetAdapterpour lister les adaptateurs, puisDisable-NetAdapter -Name "Ethernet"suivi deEnable-NetAdapter -Name "Ethernet"
Cela force une nouvelle détection du réseau — un peu étrange, mais sur certaines configurations, ça fonctionne. N’oubliez pas de vérifier que les règles du pare-feu et les politiques de sécurité sont bien configurées une fois le profil approprié défini. Sur une configuration, un simple redémarrage du service a suffi, tandis que sur une autre, un redémarrage complet ou une nouvelle connexion a été nécessaire.
Méthode 2 : Activer ou modifier les paramètres de géolocalisation
Par défaut, Windows Server 2025 désactive l’authentification au niveau du réseau (NLA), ce qui est surprenant puisqu’il est censé détecter automatiquement les types de réseau. Vous pouvez la réactiver manuellement via le registre ou la stratégie de groupe, mais une astuce consiste à configurer une clé de registre pour que le serveur attende plus systématiquement le rôle de contrôleur de domaine.
- Ouvrez PowerShell en tant qu’administrateur.
- Exécutez cette commande :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" -Name "AlwaysExpectDomainController" -Value 1 -Type DWORD
Cela indique au serveur NlaSvc de s’attendre à un contrôleur de domaine et devrait permettre au serveur de s’identifier correctement après un redémarrage. C’est pratique, mais attention : si vous constatez un comportement anormal du réseau par la suite, il est conseillé de rétablir la configuration précédente ou de vérifier les stratégies de votre profil réseau.
Méthode 3 : Résoudre les problèmes de DNS et de carte réseau pour éviter l’attribution d’un type de réseau incorrect.
Parfois, le problème ne vient pas uniquement de l’authentification au niveau du réseau (NLA), mais d’une question de DNS. Si le contrôleur de domaine se configure lui-même comme serveur DNS, il se peut qu’il ne réponde pas assez rapidement aux requêtes DNS au démarrage. Windows le considère alors comme un réseau public, car il ne peut pas confirmer sa connexion au domaine. La solution ? S’assurer que le DNS secondaire pointe vers les autres contrôleurs de domaine, afin que la résolution DNS soit ultra-rapide après le démarrage.
Évitez également de redémarrer plusieurs contrôleurs de domaine simultanément. Espacez les redémarrages afin de laisser le temps aux enregistrements DNS et à la reconnaissance réseau de se stabiliser. Car, bien sûr, Windows se doit de compliquer les choses inutilement.
Méthode 4 : Utiliser un script PowerShell avec le Planificateur de tâches pour automatiser la redétection du réseau
Cela peut paraître excessif, mais si vous gérez plusieurs contrôleurs de domaine, automatisez la réparation avec une tâche planifiée qui attend le démarrage du DNS puis redémarre les cartes réseau. Une fois configurée, cette solution est très fiable.
- Créez une tâche planifiée (exécutée en tant que SYSTEM) qui exécute cette commande :
powershell.exe -ExecutionPolicy Bypass -NonInteractive -WindowStyle Hidden -command "do {$status = (Get-Service dns)} until ($status. Status -eq 'Running'); Get-NetAdapter -Physical | Restart-NetAdapter"
Ce script attend patiemment que le DNS soit prêt, puis redémarre toutes les cartes réseau physiques, forçant ainsi Windows à réévaluer l’état de son réseau. Déployez-le via une stratégie de groupe sur tous les contrôleurs de domaine, ou exécutez-le manuellement sur chacun d’eux si vous êtes pressé. L’opération n’est pas toujours instantanée, mais dans la plupart des configurations, elle fonctionnera correctement et maintiendra la cohérence de votre profil réseau.
Honnêtement, ces solutions sont un peu superficielles, mais elles semblent fonctionner dans différents environnements. Sur certaines configurations, un simple redémarrage du service NlaSvc suffit. Sur d’autres, une petite modification du registre permet au serveur de s’attendre à être dans le domaine dès le départ. Et si les états DNS ou des adaptateurs sont incorrects, leur synchronisation est généralement la solution. Le plus important est la patience : parfois, le serveur a simplement besoin d’un petit coup de pouce pour reconnaître son emplacement.
Résumé
- Redémarrez le service NlaSvc pour forcer une réévaluation du profil réseau.
- Modifiez les paramètres du registre tels que « AlwaysExpectDomainController » pour renforcer les exigences de détection du domaine.
- Vérifiez que les paramètres DNS sont corrects et que plusieurs redémarrages ne se produisent pas simultanément.
- Utilisez des scripts PowerShell et le Planificateur de tâches pour l’automatisation si vous gérez de nombreux serveurs.
Conclure
Tout cela est un peu fastidieux, mais la plupart des solutions consistent à faire en sorte que le serveur reconnaisse à nouveau son appartenance au domaine. Qu’il s’agisse de redémarrer manuellement les services, de modifier les clés de registre ou d’automatiser le processus avec des scripts, ces approches semblent permettre de maintenir le profil réseau à sa place. Espérons que cela aidera d’autres administrateurs système à éviter les changements incessants de profil réseau. Ce n’est pas parfait, mais c’est un début.