123290
07.07.2019, aktualisiert um 21:33:31 Uhr
58170
19
0
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?
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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator tomolpi am 07.07.2019 um 21:33:23 Uhr
Titel korrigiert
Content-ID: 470794
Url: https://administrator.de/contentid/470794
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
19 Kommentare
Neuester Kommentar
.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...
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...
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....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...
Hallo,
Mal versucht nach dem Einrichten und vor dem Installieren der Updates deine Domäne zu erstellen? Was ist dann nach einen Neustart?
Gruß,
Peter
Zitat von @123290:
Mit .local lief aber schon immer alles seit dem Server 2008
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?Mit .local lief aber schon immer alles seit dem Server 2008
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
Hallo,
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
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
Zitat von @Pjordorf:
Hallo,
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,
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
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.
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.
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)
Gibts zu dem Problem noch evtl informationen?
(Falls ein neuer Thread aufgemacht werden soll weil dieser bereits "gelöst" ist dann bitte Bescheid geben)
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:
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:
Nach einem Neustart ist das aktuelle Netzwerkprofil bei mir die Domäne.
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:
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:
Nach einem Neustart ist das aktuelle Netzwerkprofil bei mir die Domäne.
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
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%
)
)
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
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
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
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
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
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.
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.