Seit den Windows Updates von Oktober oder November 2017 beobachten wir vermehrt das vor allem bei Domänencontrollern auf Basis von Windows Server 2012 R2 Standard nach einem Neustart die Netzwerkkategorie von “Domänennetzwerk” zu “Öffentliches Netzwerk” (oder schlicht “Öffentlich”) wechselt.
In wie weit andere Versionen und Editionen von Windows davon betroffen sein können, kann aktuell nicht sicher ermittelt werden. Auffällig war jedenfall die Kombination, d.h. es gibt mehrere Domänencontroller und meist “scheitert” ab dem zweiten Domänencontroller die Ermittlung der richtigen Netzwerkkategorie nach dem Neustart (z.B. nach Windows Updates).
Der Vollständigkeit halber sei erwähnt, das die Domänencontroller nicht gleichzeitig, sondern der Reihe nach neu gestartet wurden und zudem immer gewartet wurde, bis der jeweils andere Server wieder vollständig gestartet war.
Mögliche Lösungswege
Bei verschiedenen Kunden haben verschiedene Methoden geholfen. Leider bislang immer nur in Verbindung mit einem Neustart.
I.d.R. genügt ein normaler Neustart. Als Schnellschuss, wenn der Server gerade nicht neu gestartet werden darf, kann es schonmal helfen die Netzwerkkategorie auf “Privates Netzwerk” zu ändern (siehe hier), damit die meisten Dienste wieder normal erreichbar sind oder die Windows-Firewall vorübergehend zu deaktivieren.
Zuletzt, d.h. gestern, hat bei einem Kunden nur geholfen erst die Windows-Firewall für alle Kategorien zu deaktivieren und den Server neuzustarten. So wurde die Netzwerkkategorie richtig erkannt und die Firewall konnte wieder aktiviert werden.
Was bei manchen Kollegen der Lesart nach ebenfalls (ohne Neustart) geholfen haben soll wäre folgendes:
- Den Dienst “NLA (Network Location Awareness)” (Dienstname: “NlaSvc”) neu starten.
- Via PowerShell die Netzwerkkategorie auf “Domänennetzwerk” ändern:
set-netconnectionprofile -interfaceindex <NR> -networkcategory DomainAuthenticated
Update 11.04.2021
Bitte auch die Kommentare beachten. Vielen Dank an Frank für den Tipp mit der Dienst-Abhängigkeit.
Update 03.02.2023
In den Kommentaren (Vielen Dank dafür) zu diesem und dem Beitrag
Windows: … und ewig schleicht die Netzwerkkategorie
wurde vielfach vorgeschlagen eine Abhängigkeit vom DNS-Dienst zu erstellen. Dies geht in der Eingabeaufforderung wie folgt:
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Update 06.07.2023
Der obige Befehl macht den NLA-Dienst vom DNS- und AD-Dienst abhängig, d.h. auf Member-Servern funktioniert das so nicht. Mit folgendem Befehl stellt man den Original-Zustand wieder her:
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog
Der Vollständigkeit halber sei zudem erwähnt, das ich das Problem über die Änderung der Dienste-Abhängigkeit bislang nicht angegangen bin. Laut einiger Kommentarschreibern soll das allerdings gut funktionieren.
Update 11.08.2023
Bitte die Updates im Beitrag
Windows: … und ewig schleicht die Netzwerkkategorie
beachten.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
In Windows Server 2016 lässt sich der oben genannte Powershellbefehl nicht ausführen. Die Meldung der Powershell besagt, dass dieser Status nur automatisch vergeben wird (was ja nicht funktioniert).
Kann man die Eingabe in irgendeiner Form erzwingen?
Mit Windows Server 2016 habe ich diesbezüglich noch keine Erfahrungswerte. Allerdings war vergangene Woche nach einem Neustart ein Windows Server 2016 (Domänencontroller) der Meinung im öffentlichen Netzwerk zu sein, ein Neustart des Dienstes “NLA (Network Location Awareness)” (Dienstname: NlaSvc) hat geholfen.
Ansonsten kann man über die Gruppenrichtlinie ebenfalls noch Einstellungen setzen.
Richtig ist auf jeden Fall, das man manuell nicht die Kategorie “Domänennetzwerk” (aka “DomainAuthenticated”) setzen kann. Das ging glaub’ ich noch nie. Steht auch so in der Doku:
Microsoft – Docs – Windows – PowerShell – Set-NetConnectionProfile
“You cannot set the DomainAuthenticated type by using this cmdlet. The server automatically sets the value of DomainAuthenticated when the network is authenticated to a domain controller”
Der beschriebene Fehler konnte auch jetzt noch (Oktober 2019) beobachtet werden an einem 2012R2 Domänencontroller. Der Fehler war “offen” sichtlich: es fehlte das Standardgateway. Nachdem es eingetragen war, wurde die Netzwerkzugehörigkeit korrekt erkannt und blieb es auch nach mehreren Neustarts erhalten.
ich kann nicht drucken , der aktive Domänendienst steht nicht zur Verfügung. warum?
Wir hatten diesen Fehler nachdem der Switch auf dem der Server hängt ausgefallen war. Nach austausch des Switch und Neustart des Server nach wir vor “Öffentliches Netzwerk”
Geholfen hat, per Powershell das Netzwerk auf Privat umzustellen:
set-netconnectionprofile -interfaceindex -networkcategory Private
Und anschließend das Netzwerkkabel für ein paar Sekunden ab- und anzuhängen. In meinem Falle, da VmWare Server, über die VM-Einstellungen die Netzwerkkarte off- und online zu schalten.
Hallo Andy,
der einfachste Weg zur Behebung des Problems ist, den NLA-Dienst vom DNS-Server abhängig zu machen. Die fehlerhafte Netzwerk-Erkennung kommt immer dann zustande, wenn der NLA schon vor dem DNS-Server startet, da der NLA den DNS zur sauberen Erkennung benötigt. Deswegen funktioniert es auch nach einem Neustart des NLA-Dienstes, da dann ja der DNS bereits läuft.
Es muss nur der Registry-Eintrag “DependOnService” im Zweig “HKLMSYSTEMCCSServicesNlaSvc” mit der zusätzlichen Zeile “DNS” ergänzt werden. Das hat bei uns das Problem dauerhaft behoben.
Gruß, Frank
Auf Server 2019 hat ein Neustart des Dienstes “NLA (Network Location Awareness)” (Dienstname: NlaSvc) geholfen.
Vielen Dank für euren Tipp.
Hallo,
auf Server 2019 Essentials hat es auch geholfen, den Dienst NLA neu zu starten.
Danke für de Tipp
Ich habe noch eine mögliche Ursache gefunden:
Eine zusätzliche lokale IP Adresse in einem Segment, in dem der/die DC(s) nicht erreichbar ist/sind.
Hier war es die 10.90.90.2/24. Die IP im Hauptsegment ist die 192.168.1.98/255
Solange diese zusätzliche IP eingerichtet war hat die virtuelle Maschine immer ein privates Netzwerk gesehen.
Erst das Löschen der zusätzliche IP brachte den gewünschten Erfolg.
Eine weitere zusätzliche IP 192.168.200.98/255 macht hingegen keine Probleme dieser Art.
Womit sich mal wieder zeigt, dass Domain Controller sowie die zur Domain gehörende(n) DNS-Zone(n) grundsätzlich redundant betrieben werden sollte(n) und Domain-Controller sich über Kreuz als sekundäre DNS-Server verwenden sollte(n) ¯_(ツ)_/¯
Sehe gerade, dass aus irgendeinem Grund das “192.168.1.98/255” steht. Sollte natürlich “192.168.1.98/24” heißen.
Mit dem Hinweis von Frank (Es muss nur der Registry-Eintrag “DependOnService”) hat es funktioniert!
Moin
bei mir hat folgendes geholfen, bei einer W2019 Installation im Proxmox VE
https://ronny-boettcher.de/technik/microsoft/windowsserver/dc-firewallprofile-private-to-domain
Grüße aus Berlin
Ben
Genau
Mit dem Hinweis von Frank (Es muss nur der Registry-Eintrag “DependOnService”) hat es funktioniert!
Meine Vorgehensweise:
Überprüfung Dienstabhängigkeiten
PS C:Windowssystem32> sc.exe qc nlasvc
Ergebnis in der Regel:
PS C:Windowssystem32> sc.exe config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
umstellen auf:
Sc.exe config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Ergebnis: alles schön 🙂
Domänennetzwerk funzt
Fehler unterlaufen beim Ergebnis sc.exe config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
da fehlt beim ersten überprüfen DNS
Übrigens tritt der Fehler auch auf Server2022 auf
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
Andy? kann ich das auch wieder Rückgängig machen?
Hab danach das Problem da gar kein Netzwerk mehr angezeigt wird und z.B. der Dienst NLA nicht mehr startet, auch nicht mauell Fehler 1075
Hallo Frank,
entferne mal die Abhängigkeit von DNS und dem AD:
sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog
Das wäre dann wieder der Original-Zustand.