Server 2019 – Privates Netzwerk nach Neustart anstelle Domänennetzwerk

[peterg 15]

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

[NorbertFe 2.045]

vor 5 Minuten schrieb peterg:

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

 

Dann starte doch per Task den NLA immer 2Minuten nach Reboot bis eine andere Lösung vorhanden ist. Ich gehe davon aus, dass du nur einen DC hast? 

[peterg 15]

Ja, ich habe mir schon ein Script gebastelt. Ja, es gibt nur einen DC.

[NorbertFe 2.045]

SChaltet er denn nach einer gewissen Zeit evtl um? Bei mir hat es "meist" geholfen den NLA Service auf verzögerten Start zu konfigurieren. Dann war nach ein bisschen Warten auch wieder alles ok.

[Weingeist 159]

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 12. November 2020 von Weingeist

[peterg 15]

Ich führe 2 Minuten nach den Neustart ein Script aus um den NLA-Dienst neu zu starten. Das funktioniert einwandfrei. Danke für die weiteren Infos.

[daabm 1.356]

Den NLA-Restart haben wir als "Notnagel" auch eingebaut. Funktioniert eigentlich immer.

[Weingeist 159]

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 12. November 2020 von Weingeist

[Weingeist 159]

Push für eventuell sinnvollere Lösung als ein Neustart (siehe Edit) ;)

[peterg 15]

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.

 

 

[Weingeist 159]

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 12. November 2020 von Weingeist

[Chris_30 10]

Durch Zufall über dieses alte Thema gestolpert. Geht auch pragmatischer:

 

Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters neuen DWORD-Wert (32-Bit) Schlüssel  namens AlwaysExpectDomainController mit dem Wert 1 erstellen.

 

 

[Damian 1.535]

@Chris_30 Ist ja nett, dass Du noch an solchen Themen dran bleibst. Das Board hat dir jedoch vor dem posten einen Warnhinweis bezüglich des Themenalters angezeigt. Dieser Hinweis existiert nicht ohne Grund. Bitte beim nächsten Mal beachten. Danke.

 

Hier schließe ich zu.

 

VG

Damian