Windows: Nach Neustart bei Netzwerkkategorie kein Domänennetzwerk mehr

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.

17 Kommentare

  1. Christian

    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?

  2. andy

    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”

  3. pq_magic

    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.

  4. Marianne Adlmaier

    ich kann nicht drucken , der aktive Domänendienst steht nicht zur Verfügung. warum?

  5. Foegi

    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.

  6. Frank

    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

  7. Toni

    Auf Server 2019 hat ein Neustart des Dienstes “NLA (Network Location Awareness)” (Dienstname: NlaSvc) geholfen.
    Vielen Dank für euren Tipp.

  8. Christoph

    Hallo,
    auf Server 2019 Essentials hat es auch geholfen, den Dienst NLA neu zu starten.
    Danke für de Tipp

  9. Stefan

    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.

  10. Lutz

    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) ¯_(ツ)_/¯

  11. Stefan

    Sehe gerade, dass aus irgendeinem Grund das “192.168.1.98/255” steht. Sollte natürlich “192.168.1.98/24” heißen.

  12. Gino Glatz

    Mit dem Hinweis von Frank (Es muss nur der Registry-Eintrag “DependOnService”) hat es funktioniert!

  13. Ben Sommer

    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

  14. Ralf Foerster

    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

  15. Ralf Foerster

    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

  16. Frank p

    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

  17. Andy

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

© 2024 Andy's Blog

Theme von Anders NorénHoch ↑