123290
Goto Top

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

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 Jul 07, 2019 um 19:33:23 Uhr
Titel korrigiert

Content-Key: 470794

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

Printed on: April 27, 2024 at 00:04 o'clock

Member: Mikrofonpartner
Mikrofonpartner Jul 07, 2019 at 14:51:48 (UTC)
Goto Top
Hallo

Welche DNS-Server sind eigetragen?

Gruß Mikro
Mitglied: 123290
123290 Jul 07, 2019 at 14:58:52 (UTC)
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.
Member: GrueneSosseMitSpeck
GrueneSosseMitSpeck Jul 07, 2019 at 16:00:37 (UTC)
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...
Member: tomolpi
tomolpi Jul 07, 2019 at 17:15:47 (UTC)
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 Jul 07, 2019 at 17:32:48 (UTC)
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?
Member: Pjordorf
Pjordorf Jul 07, 2019 updated at 18:29:39 (UTC)
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
Member: Mikrofonpartner
Mikrofonpartner Jul 07, 2019 at 20:02:55 (UTC)
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?
Member: Pjordorf
Pjordorf Jul 07, 2019 at 20:28:29 (UTC)
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
Member: Mikrofonpartner
Mikrofonpartner Jul 07, 2019 at 20:53:07 (UTC)
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 Jul 08, 2019 at 05:36:48 (UTC)
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.
Member: Mikrofonpartner
Solution Mikrofonpartner Jul 08, 2019 updated at 17:01:57 (UTC)
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 Jul 09, 2019 at 06:01:42 (UTC)
Goto Top
Hat tatsächlich geklappt!!! Lösung war den NLA-Dienst abhängig des Anmeldedienstes zu machen.

In einer administrativen Eingabeaufforderung:
sc config NlaSvc depend= Netlogon
Member: installer
installer Oct 07, 2019 at 17:29:07 (UTC)
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)
Member: MehmetYaman
MehmetYaman Feb 06, 2020 at 17:32:08 (UTC)
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?
Member: pmontz
pmontz Nov 03, 2020 updated at 23:15:10 (UTC)
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
Member: Michael.H
Michael.H May 15, 2021 at 14:28:28 (UTC)
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
@rem This script restarts the service nlasvc (Network Location Awareness Service)
@rem to correct the firewall profile to Domain in case of the station is a domain controller

@rem readout DomainRole
FOR /F "tokens=2 delims==" %%i in ('wmic.exe ComputerSystem get DomainRole /value ^| find /i "DomainRole"') do set DomainRole=%%i  
@rem	Value	DomainRole
@rem	0	Standalone Workstation
@rem	1	Member Workstation
@rem	2	Standalone Server
@rem	3	Member Server
@rem	4	Backup Domain Controller
@rem	5	Primary Domain Controller

rem readout current firewall profile status
FOR /F %%i in ('netsh advfirewall monitor show currentprofile ^| find /i "Profile"') do set FirewallProfile=%%i  

@rem save current script path
set ScriptPath=%~dp0
set Logfile=%ScriptPath%FirewallProfile.log

@rem build date-time string
set mydatetime=%date%_%time%

@rem do the following in case of Backup or Primary Domain Controller
@rem GEQ - greater than or equal
IF /I %DomainRole% GEQ 4 (
	@rem stop an start the nlasvc-Service in case of not Domain
	IF /I  NOT %FirewallProfile%==Domain (
		@rem store date and time in logfile
		echo. >> %Logfile%
		echo %mydatetime% >> %Logfile%
		@rem store current status in logfile
		echo      System is in the firewall profile: %FirewallProfile% >> %Logfile%
		echo      Restart NLA-Service >> %Logfile%
		@rem option /y force stop of dependent services
		net stop /y nlasvc
		net start nlasvc
		@rem wait for 5 seconds
		@rem because there is not wait-command, we use the ping-command to spend some time
		echo      wait 5 seconds >> %Logfile%
		ping 127.0.0.1 -n 6 > nul
		@rem check status again
		FOR /F %%i in ('netsh advfirewall monitor show currentprofile ^| find /i "Profile"') do set FirewallProfile=%%i  
		echo      new firewall profile: %FirewallProfile% >> %Logfile%
	)
)
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:

Allgemein
---------------
Name: correct-firewall-profile-dc
Benutzerkonto: System
Ja, mit höchsten Privilegien ausführen
Konfigurieren für: Windows Server 2019

Trigger
--------
Aufgabe starten: Beim Start
Verzögern für 1 Minute
Wiederholen jede: 5 Minuten für die Dauer von: Unbegrenzt
Aufgabe beenden nach: 1 Minute

Aktionen
------------
Aktion: Programm starten
Skript: correct-firewall-profile-dc.bat

Bedingungen
-----------------
Ja, nur starten, wenn folgende Netzwerkverbindung verfügbar ist: Alle Verbindungen

Einstellungen
---------------
Ja, Aufgabe beenden, falls Ausführung länger als 1 Minute (man kann dort selbst Minute hinschreiben, es steht nicht in der Auswahl)
Ja, Beenden der aktiven Aufgabe erzwingen, falls sie auf Aufforderung nicht beendet wird
Folgende Regel anwenden, falls die Aufgabe bereits ausgeführt wird: Vorhandene Instanz anhalten

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
Member: Michael.H
Michael.H Sep 01, 2021 updated at 19:34:55 (UTC)
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:

@rem This script restarts the service nlasvc (Network Location Awareness Service)
@rem to correct the firewall profile to Domain in case of the station is a domain controller

@rem readout DomainRole
FOR /F "tokens=2 delims==" %%i in ('wmic.exe ComputerSystem get DomainRole /value ^| find /i "DomainRole"') do set DomainRole=%%i  
@rem	Value	DomainRole
@rem	0	Standalone Workstation
@rem	1	Member Workstation
@rem	2	Standalone Server
@rem	3	Member Server
@rem	4	Backup Domain Controller
@rem	5	Primary Domain Controller

rem readout current firewall profile status
FOR /F %%i in ('netsh advfirewall monitor show currentprofile ^| find /i "Profile"') do set FirewallProfile=%%i  

@rem save current script path
set ScriptPath=%~dp0
set Logfile=%ScriptPath%FirewallProfile.log

@rem build date-time string
set mydatetime=%date%_%time%

@rem do the following in case of Backup or Primary Domain Controller
@rem GEQ - greater than or equal
IF /I %DomainRole% GEQ 4 (
   @rem stop an start the nlasvc-Service in case of not Domain
   IF /I  NOT %FirewallProfile%==Domain (
      @rem store date and time in logfile
      echo. >> %Logfile%
      echo %mydatetime% >> %Logfile%
      @rem store current status in logfile
      echo      System is in the firewall profile: %FirewallProfile% >> %Logfile%
      echo      Restart NLA-Service >> %Logfile%
      @rem option /y force stop of dependent services
      net stop NlaSvc /y
      IF errorlevel 1 (
         echo      No Success: net stop NlaSvc  >> %Logfile%
         @rem hard way
         taskkill /f /fi "SERVICES eq NlaSvc"  
         IF errorlevel 1 (
            echo      No Success: taskkill NlaSvc >> %Logfile%
         ) ELSE (
            echo      Success: taskkill NlaSvc >> %Logfile%
         )

      ) ELSE (
         echo      Success: net stop NlaSvc >> %Logfile%
      )
      net start NlaSvc
   )
)

Grüße
Michael
aus Bad Oeynhausen
Member: Michael.H
Michael.H Dec 24, 2021 updated at 15:21:39 (UTC)
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
Member: tomtom77
tomtom77 Sep 12, 2022 at 14:59:05 (UTC)
Goto Top
Ist zwar ein alter Thread, aber das Problem gibt es bis heute immer noch.

Ich habe das Problem hauptsächlich bei standalone DCs gesehen. Wenn diese einen Neustart machen ist der DNS noch nicht bereit und NLA schaltet auf Öffentlich oder Privat.

Wenn Euch die oben genannten Lösungsansätze nicht zusagen gibt es auch die Möglichkeit per Registry das Verhalten der NLA zu steuern.
Gefunden habe ich das hier: Network location awareness not detecting domain network from offsite location

Bei mir hat schon der NegativeCachePeriod Key auf 0 setzen gereicht.

Zitat:
Please try to modify the following registry keys to see if the issue can be resolved:

First, disable Domain Discovery negative cache by adding the NegativeCachePeriod registry key to following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Name: NegativeCachePeriod
Type: REG_DWORD
Value Data: 0* (default value: 45 seconds; set to 0 to disable caching)

If issue doesn’t resolve, furtherly disable DNS negative cache by adding the MaxNegativeCacheTtl registry key to the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Name: MaxNegativeCacheTtl
Type: REG_DWORD
Value Data: 0 (default value: 5 seconds; set to 0 to disable caching)

Note: This registry key disables the Domain detection negative cache. NLA normally detect Domain multiple times at network setup (triggered by route change, IP address change etc). But if the first time detection failed with negative result (such as ERROR_NO_SUCH_DOMAIN), this negative result gets cached in netlogon, and will be reused in next time NLA domain discovery.

There is also another registry key we need add:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters

Add a DWORD parameter :AlwaysExpectDomainController

Set value to:1

Note: This registry key alters the behavior when NLA retries domain detection.