Jump to content

Server 2019 – Privates Netzwerk nach Neustart anstelle Domänennetzwerk


Empfohlene Beiträge

Hallo,

wenn ich den neu installierten Domänenserver (MS Server2019 Std, als VM unter Hyper-V) neu starte, wird als aktives Netzwerk nicht das Domänennetzwerk, sondern das „private Netzwerk“ angezeigt.

 

Behelfen kann ich mir damit, dass ich im Netzwerk- und Freigabecenter -> Adaptereinstellungen, die Netzkarte kurz deaktiviere und wieder aktiviere. Dann wird das Domänennetzwerk angezeigt.

Oder ich starte den NLA-Dienst neu. Dann wir auch das Domänennetzwerk angezeigt.

 

Ich habe auch schon Lösungsansätze gefunden (LNA-Dienst abhängig des Anmeldedienstes zu machen, LNA und DNS-Dienst auf „verzögerten Autostart“, DNS mit 127.0.0.1 eintragen), welche aber nichts gebracht haben.

 

Gibt es noch andere Lösungsansätze?

 

Gruß,

Pit

Link zu diesem Kommentar
  • 2 Wochen später...

Dieses Verhalten gibt es seit bzw. nach einem bestimmten Sicherheitsupdate auf allen OS. War soweit ich mich erinner irgendwann 2018 oder 2019 im Frühjahr. Aber wohl nicht mit allen Netzwerkkarten. Selbst auf virtuellen Maschinen ist das möglich. Die Netzwerkkarten sind dann nach dem Update teilweise +- doppelt im System und auch Netzwerkbereiche gibt es mehrere (Arbeitsplatz etc.). Unter den Adaptern sieht man dann zwar nur einen, in der Registry gibts aber noch Überresten von der ersten Variante vor dem Sicherheitsupdate.

Oder u arbeitest nur mit IPv4 und nicht mit IPv6. Da habe ich es es auch schon erlebt. Aber eben nicht immer =)

 

Mein Verdacht ging bei physischen Maschinen auch schon in Richtung Intel Management Engine weil diese erst eine Standard-IP zuweist und ich das nur mit Intel-Onboardkarten hatte. Die verbleibt dann teilweise ohne dass sich DHCP eine neue holt.

 

Workaround wie schon genannt wurde:

Deaktivieren/aktivieren des Netzwerkadapters. Ab 2012R2 geht es sehr easy per Powershell script. Vorher ist es totaler Kack. Zumindest wenn es automatisiert werden soll. =)

 

Lösungen die manchmal funktionieren:

- OS frisch installieren, direkt mit aktuellem Updatestand, also nicht im nachhinein

- Die Netzwerkadapter komplett rausputzen, überall (also auch sämtliche Überreste in der Registry, was mitunter ziemlich mühsam werden kann, da moderne sich teilweise seltsam einklinken)

- Den ersten Netzwerkadapter erst nach der Updaterunde einklinken (aktuelles Offline-Paket holen)

- Firmware der Adapter erhöhen

- Treiber aktualisieren

- IPv6 wieder aktivieren

 

Aber selbst wenn ich alles gemacht habe, hat es nicht immer geklappt. Ersteres ist am erfolgsversprechenden.

 

Lösung die tatsächlich funktioniert (Siehe auch weitere Beiträge unten)

Den Dienst NLA (Network Location Awareness (nlasvc) von "Automatisch" auf "Automatisch (Verzögert)" umstellen.

--> In der Registry ist das ein DWORD "DelayedAutoStart" mit Wert 1 im Service. Kann man per GPO verteilen.

bearbeitet von Weingeist
Link zu diesem Kommentar

NLA ist einfacher als die Netzwerkadapter. Vor allem mit allen OS möglich. Werde ich hier auch mal testen.

 

EDIT: Habe das in einr Umgebung mal durchgespielt. Da funktioniert das mit dem nlasvc nicht zuverlässig. Das Problem: er lässt sich nicht immer beenden, manchmal klappts, manchmal nicht. Wens klappt, dann funktionierts, wenn nicht, dann nicht.

 

Habe allerdings eine Lösung die dann geklappt hat. Da es scheinbar ein Timing-Problem ist, habe ich mal die Verzögerung eingebaut:

Das heisst: den Dienst nlasvc von "Automatisch" auf "Automatisch (verzögert)" wechseln.

--> Das wiederum ist eine simple Konfig z.Bsp. per GPO und Registry.

 

Habe eine Maschine nun 20x durchgestartet und jedes mal hats geklappt. Dann auf andere ausgerollt und tut auch. =)

bearbeitet von Weingeist
Link zu diesem Kommentar
vor 3 Stunden schrieb Weingeist:

Habe allerdings eine Lösung die dann geklappt hat. Da es scheinbar ein Timing-Problem ist, habe ich mal die Verzögerung eingebaut:

Das heisst: den Dienst nlasvc von "Automatisch" auf "Automatisch (verzögert)" wechseln.

--> Das wiederum ist eine simple Konfig z.Bsp. per GPO und Registry.

 

Habe eine Maschine nun 20x durchgestartet und jedes mal hats geklappt. Dann auf andere ausgerollt und tut auch. =)

 

Das habe ich anfangs probiert und hat nicht funktioneirt.  Ich habe sogar Abhängigkeiten definiert. Scheinbar alles sehr individuell.

 

 

Link zu diesem Kommentar

Es dauert einen Moment bis es tatsächlich klappt, der Dienst wird ja verzögert gestartet. Also nicht sofort anmelden nach dem Boot. Aber in der getesteten Umgebung hat es bei allen Clients geklappt. Habe alle durchgestartet und da hatte ich den Netzwerk-Adapter-Workaround drin. Bei manchen brauchte es zwei Neustarts. Vermutlich damit die GPO sicher gezogen hat.

 

Allerdigns hat jene Umgebung fixe IP's und kein DHCP, eventuell reagiert das nochmal anders. Muss ich erst noch in einer anderen Umgebungen testen damit ich mehr dazu sagen kann.

 

Ich vermute die restlichen Punkte meiner Auflistung müssen teilweise ebenfalls erfüllt sein. Die habe ich schon überall umgesetzt. (allerdings ohne IPv6,  das deaktiviere ich immer). Und Wenn IPv6 deaktiviert wird, immer die Prioritätenliste anpassen, insbesonder für den Loopback, sonst ist dieses Problem auch immer eines davon! (Und andere, insbesondere Netzwerk-Performance, Anmeldeschwierigkeiten und was es sonst noch alles so gibt.)

netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4
netsh int ipv6 set prefixpolicy ::/96 55 3
netsh int ipv6 set prefixpolicy ::1/128 50 0
netsh int ipv6 set prefixpolicy ::/0 40 1
netsh int ipv6 set prefixpolicy 2002::/16 30 2
netsh int ipv6 set prefixpolicy 2001::/32 5 5
netsh int ipv6 set prefixpolicy fc00::/7 3 13
netsh int ipv6 set prefixpolicy 3ffe::/16 1 12
netsh int ipv6 set prefixpolicy fec0::/10 1 11

 

bearbeitet von Weingeist
Link zu diesem Kommentar
  • 3 Jahre später...
Gast
Dieses Thema wurde für weitere Antworten geschlossen.
×
×
  • Neu erstellen...