Server 2019, frische Domäne - Privates Netzwerk nach dem Neustart

123290
Goto Top
Hallo, merkwürdiges Problem beim zweiten Windows Server 2019 in Folge:
Installiert, durchgepatcht, Domäne eingerichtet, DNS, DHCP fertig eingerichtet. Der eine ein 2019 Essentials, der andere ein Standard.

Server fährt hoch: "Privates Netzwerk"
Netzwerk deaktiviert, Netzwerk wieder aktiviert: "intern.local" Domänennetzwerk
Nächster Neustart, wieder Privates Netzwerk.

Dachte erst es läge am Virenscanner, deswegen zweiten Server ohne AV installiert, gleiches Phänomen...
Bissl blöd so wegen der Firewalleinstellungen etc. Dieses Problem ist mir bei älteren Servern noch nicht passiert.
Bis jetzt behelfe ich mir mit einem Script was nach einem Neustart das Netzwerk einmal aus und wieder einschaltet, aber ist keine schöne Lösung.

Jemand eine Idee?
Kommentar vom Moderator tomolpi am 07.07.2019 um 21:33:23 Uhr
Titel korrigiert

Content-Key: 470794

Url: https://administrator.de/contentid/470794

Ausgedruckt am: 24.05.2022 um 22:05 Uhr

Mitglied: Mikrofonpartner
Mikrofonpartner 07.07.2019 um 16:51:48 Uhr
Goto Top
Hallo

Welche DNS-Server sind eigetragen?

Gruß Mikro
Mitglied: 123290
123290 07.07.2019 um 16:58:52 Uhr
Goto Top
Die IP des Domänencontrollers ist als DNS eingetragen. Läuft auch, alle Clients verbinden die Domäne korrekt. Nur der Server selbst macht halt nach dem Neustart direkt Privates Netzwerk, als ob der DNS-Server Dienst irgendwie nicht rechtzeitig zum Netzwerk startet.
Mitglied: GrueneSosseMitSpeck
GrueneSosseMitSpeck 07.07.2019 um 18:00:37 Uhr
Goto Top
.local zu nehmen ist ein ziemliches Fettnäpfchen, das gibt an einigen Stellen Seiteneffekte

en.wikipedia.org/wiki/.local

da steht z.B. daß SBS Produkte von Microsoft sich beim Erkennen der TLD .local in den "privaten Netzwerk" Modus schalten...
Mitglied: tomolpi
tomolpi 07.07.2019 um 19:15:47 Uhr
Goto Top
Zitat von @GrueneSosseMitSpeck:

.local zu nehmen ist ein ziemliches Fettnäpfchen, das gibt an einigen Stellen Seiteneffekte

en.wikipedia.org/wiki/.local

da steht z.B. daß SBS Produkte von Microsoft sich beim Erkennen der TLD .local in den "privaten Netzwerk" Modus schalten...
Dann änder mal die TLD von einer SBS Domäne, die wird mit .local vorgegeben. Bei Nachfolger aus der Essentials-Reihe war/ist das nicht anders gewesen. Die Assistenten richten das so ein...
Mitglied: 123290
123290 07.07.2019 um 19:32:48 Uhr
Goto Top
Mit .local lief aber schon immer alles seit dem Server 2008 ;-) face-wink Nur der 2019 macht mir den Kummer. Kann den Start des Netzwerks vom Bootvorgang irgendwie auf später verlagern?
Mitglied: Pjordorf
Pjordorf 07.07.2019 aktualisiert um 20:29:39 Uhr
Goto Top
Hallo,

Zitat von @123290:
Mit .local lief aber schon immer alles seit dem Server 2008 ;-) face-wink
Nun, wenn du keinen Mac Rechner hast ist es ja kein Problem. Und ja, bei einen SBS 2008 war es noch nicht möglich was anderes als .local zu nehmen. Ist dein DC (der welcher zuerst von dir eingerichtet wurde) der Server 2019 Essentials oder dein Server 2019 Standard? Dein Server 2019 Essentials macht über die Asisstenten immer noch .local oder ist das mittlerweile frei wählbar?

Nur der 2019 macht mir den Kummer.
Welcher? Dein Essentials oder dein Standard?
Mal versucht nach dem Einrichten und vor dem Installieren der Updates deine Domäne zu erstellen? Was ist dann nach einen Neustart?

Gruß,
Peter
Mitglied: Mikrofonpartner
Mikrofonpartner 07.07.2019 um 22:02:55 Uhr
Goto Top
Gib bitte paar mehr Informationen zum Aufbau.

Welchen Rollen sind auf dem Essentials und welche auf dem Standard installiert und konfiguriert? Wenn beide DC sind, wer hat die FSMO-Rollen? Debugging auf dem eingetragenen DNS eingeschaltet und das Log schon mal ausgewertet?
Mitglied: Pjordorf
Pjordorf 07.07.2019 um 22:28:29 Uhr
Goto Top
Hallo,

Zitat von @Mikrofonpartner:
Wenn beide DC sind, wer hat die FSMO-Rollen?
Das sollte der Essentials sein, sonst fährt der regelmäßig herunter. Bei dem gilt das Highlanderprinzip - es kann nur eien geben (der welcher das sagen hat). Weitere DCs sind natürlich möglich, aber der Essentials muss der Boss bleiben sonst gibt es regelmässige shutdowns.
https://www.windowspro.de/news/windows-server-2019-essentials-features-v ...
https://www.thomas-krenn.com/de/wiki/Windows_Server_2019_Editionsuntersc ...

Gruß,
Peter
Mitglied: Mikrofonpartner
Mikrofonpartner 07.07.2019 um 22:53:07 Uhr
Goto Top
Zitat von @Pjordorf:

Hallo,

Zitat von @Mikrofonpartner:
Wenn beide DC sind, wer hat die FSMO-Rollen?
Das sollte der Essentials sein, sonst fährt der regelmäßig herunter. Bei dem gilt das Highlanderprinzip - es kann nur eien geben (der welcher das sagen hat). Weitere DCs sind natürlich möglich, aber der Essentials muss der Boss bleiben sonst gibt es regelmässige shutdowns.
https://www.windowspro.de/news/windows-server-2019-essentials-features-v ...
https://www.thomas-krenn.com/de/wiki/Windows_Server_2019_Editionsuntersc ...

Gruß,
Peter

Hallo Peter

Sollte so sein. Ja. Allerdings haben wir keine wirklichen Informationen über den Aufbau abgesehen von 2mal Server 2019 (1x Essentials, 1x Standard). Darum lieber nachfragen, statt weiter die Glaskugel zu bemühen.

Das es am DNS liegt, ist naheliegend.

Gruß Mikro
Mitglied: 123290
123290 08.07.2019 um 07:36:48 Uhr
Goto Top
Moin, bitte nicht zu kompliziert denken ;-) face-wink Es sind beides eigenständige Server. Keiner hat was mit dem anderen zu tun. Es sind beides neu eingerichtete Server 2019 Betriebssysteme die erst noch zum Kunden gehen sollen und in der Werkstatt stehen.

Habe gestern abend mal ein PC genommen, Server 2019 Testversion drauf, Treiber und Domäne mit DNS und DHCP. Schon war nach dem Neustart wieder Privates Netzwerk statt Domäne in den Netzwerkeinstellungen angezeigt.

Das Problem liegt am DNS, das steht außer Frage. Die Frage ist warum DNS zum Start des Systems nicht arbeitet und Windows deswegen "privat" macht. Mit der deaktivierung des Netzwerkes und erneutem aktivieren antwortet der DNS ja dann und schwups - Domänennetzwerk. Da mein Testgerät gestern Abend statt mit einer .local Domäne mit .intern Domäne eingerichtet wurde hat dieses Problem nicht verändert. Das Problem ist also reproduzierbar.
Mitglied: Mikrofonpartner
Lösung Mikrofonpartner 08.07.2019 aktualisiert um 19:01:57 Uhr
Goto Top
Morgen

Dann kram mal dein Englisch raus.

https://community.spiceworks.com/topic/2205082-new-server-2019-dc-keeps- ...

Gruß Mikro

Edit: Der Fehler liegt bei dir im NLA. Er erkennt beim Start die Netzwerkverbindung neu an und daher ist privates Netzwerk ausgewählt. Ein Restart--Service vom NLA und der Abhängigkeit Netzwerklistendienst und das Domainnetzwerk steht. Jetzt muss du nur noch herausfinden, warum dein Server meint, er hat eine neue Netzwerkverbindung bekommen.

Edit2: Es könnte ein Fehler im Build 1809 sein, da einige Seiten dazu schreiben. Dort wird als Lösung der verzögerte Start vom NLA (und DNS-Server-Dienst) vorgeschlagen. Ohne Erfolg in meiner Test-VM. Habe grade kein anderen Build verfügbar zum Gegentesten.
Mitglied: 123290
123290 09.07.2019 um 08:01:42 Uhr
Goto Top
Hat tatsächlich geklappt!!! Lösung war den NLA-Dienst abhängig des Anmeldedienstes zu machen.

In einer administrativen Eingabeaufforderung:
Mitglied: installer
installer 07.10.2019 um 19:29:07 Uhr
Goto Top
Möchte das Thema nochmal aufgreifen, da ich exakt das selbe Problem habe, die Lösung mit der Abhängigkeit von NLA an den Anmeldedienst bei mir allerdings nicht den gewünschten Effekt erzielt. Habe das ganze bei den letzten 3 Server 2019 DC's (alles eigenständige Server).

Gibts zu dem Problem noch evtl informationen?
(Falls ein neuer Thread aufgemacht werden soll weil dieser bereits "gelöst" ist dann bitte Bescheid geben)
Mitglied: MehmetYaman
MehmetYaman 06.02.2020 um 18:32:08 Uhr
Goto Top
Hallo Zusammen,

ich habe das Problem auch aktuell und das nicht nur auf einem Domänencontroller. Leider hat der Support von Microsoft nach mehreren Tagen Troubelshooting auch nicht das erhoffte Ergebnis liefern können.

Gibt es bereits andere Lösungsansätze?
Mitglied: pmontz
pmontz 04.11.2020 aktualisiert um 00:15:10 Uhr
Goto Top
Auch ich habe einen Windows Server 2019 mit Domäne frisch aufgesetzt, der im privaten Netzwerk festhängt. Habe einige Dinge konfiguriert alles ohne Erfolg.

Auch funktionierte "sc config NlaSvc depend= Netlogon" bei mir nicht. Ganz davon abgesehen, dass man mit "depend=netlogon" alle anderen Abhängigkeiten aus dem NLA-Dienst löscht.

Bei meinen Server hat nur geholfen den DNS-Server zu den Abhängigkeiten des NLA-Dienst hinzuzufügen.

NLA-Dienst Abhängigkeiten vorher:

prob1

cmd.exe als administrator starten und "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS" ausführen.

Es wird jetzt nur der DNS-Serverdienst zu den NLA-Abhängigkeiten hinzugefügt ohne alle anderen Abhängigkeiten zu löschen!

NLA-Dienst Abhängigkeiten nachher:

prob2

Nach einem Neustart ist das aktuelle Netzwerkprofil bei mir die Domäne.


prob4
prob3
prob5
Mitglied: Michael.H
Michael.H 15.05.2021 um 16:28:28 Uhr
Goto Top
Ich habe folgende Maßnahmen getroffen:

Beim Dienst NLA die Abhängigkeit zum DNS eingetragen.
Der Dienst NLA hat die Startart: "Automatisch (verzögerter Start)".

Trotzdem steht manchmal das Netzwerkprofil auf "Privat" nach einem Neustart des DC.

Erst nach einem manuellen Restart des Dienstes NLA steht das Profil dann korrekt auf "Domäne".

Der manuelle Neustart des Dienstes NLA löst zwar das Problem, war mir aber nicht komfortabel genug. Außerdem kann es immer mal sein, dass man zu spät merkt, dass der DC im falschen Profil ist.

Ich habe deshalb ein kleines Skript geschrieben, was automatisch den Dienst NLA restartet, falls sich der DC im falschen Profil befindet.
Hier ist das Skript, es heißt bei mir correct-firewall-profile-dc.bat
Das Skript liegt bei mir in einem Ordner "scripts" und der Benutzer "System" hat auf den Ordner und alles darunter Vollzugriff.
Dann habe ich mit dem Aufgabenplanung eine neue Aufgabe angelegt mit folgenden Einstellungen:


Das Skript leistet folgende Dinge:
Es stellt fest, ob es sich um einem Domänen-Controller handelt.
Wenn das so ist und das aktuelle Firewall-Profil steht nicht auf Domain, dann wird das in einem Logfile protokoliert und der Dienst NLA neu gestartet.
Danach wartet das Skript für ca. 5 Sekunden und prüft dann erneut das Firewall-Profil.
Das Logfile wird in dem Ordner angelegt, wo auch das Skript liegt. Der Benutzer "System" braucht dort Schreibrechte.
Anhand des Logfiles kann man sehen, wann und wie oft das Skript eingreifen musste und ob es Erfolg gehabt hat. Damit das Logfile übersichtlich bleibt, habe ich keine Protokollierung eingestellt, wenn alles in Ordnung ist.
Grüße
Michael Huck
aus Bad Oeynhausen
Mitglied: Michael.H
Michael.H 01.09.2021 aktualisiert um 21:34:55 Uhr
Goto Top
Leider tritt das Problem nach wie vor auch auf dem neuen Windows Server 2022 auf. Microsoft hat es nicht geschafft diesen Bug bei der neuen Version zu beseitigen.

Für den neuen Windows Server 2022 musste ich das Skript ein wenig anpassen, damit es auch dort läuft:
Unter Windows Server 2019 funktionierte noch "net stop /y nlasvc", um den Dienst nlasvc zu stoppen, bei Windows Server 2022 gibt es da im Skript eine Fehlermeldung, weil unter 2022 sich der Dienst nicht so einfach beenden läßt.

Neu ist, dass der Dienst nlasvc mit taskkill hart beendet wird, wenn er sich nicht weich mit net stop beenden läßt.

Das neue Skript für Windows Server 2022 sieht so aus und funktioniert auch auf dem Server 2019:


Grüße
Michael
aus Bad Oeynhausen
Mitglied: Michael.H
Michael.H 24.12.2021 aktualisiert um 16:21:39 Uhr
Goto Top
Es gibt einen neuen Lösungsansatz, den ich im folgenden Blog gelesen habe:
https://www.mcbsys.com/blog/2018/03/network-location-awareness-doesnt-id ...
Das Problem wird auf dem Domänen-Controller wie folgt gelöst:
1. Gerätemanager
2. Bereich Netzwerkadapter
3. WAN Miniport IP und IPv6 deaktivieren.
Bei mir hat das auf einem Windows Server 2022 funktioniert, d. h. der Domänen-Controller ist danach immer in dem richtigen Netzwerk-Profil, nämlich in dem Domänen-Profil.

Vorher der Deaktivierung des WAN Miniport Adapters selbstverständlich zu prüfen, inwieweit der WAN Miniport Adapter auf dem Domain-Controller wirklich notwendig ist. Ich habe ihn jedenfalls nicht gebraucht.

In
https://answers.microsoft.com/de-de/windows/forum/all/wan-miniport-adapt ....
steht, dass WAN Miniport Adapter z. B. für ein VPN System notwendig ist.

Grüße
Michael
aus Bad Oeynhausen