Windows Server 2025 Netzwerkprofil Domäne nicht verfügbar

[-peet- 1]

Hallo Gemeinde,

 

ich habe ein Problem mit einem frisch aufgesetzten Windows Server 2025.

Der Server fungiert als Domaincontroller DC02.

Es gibt einen DC01 Windows Server 2019, der durch den DC02 ersetzt werden soll.

Soweit wurden alle Daten migriert bis auf die Rollen und der DHCP ist noch nicht aktiv.

Leider hängt der neue DC02 im Netzwerkprofil Privat oder Öffentlich fest, ich komme nicht in das Domänen Netzwerkprofil.

Die IP Adresse wurde statisch vergeben. Soweit ich es abgleichen konnte, sind die Einstellungen gleich.

Den verzögerten Start des NLA und Registry Eintrag auf den Wert 02 für Domäne haben leider nichts gebracht.

Daher bin ich mittlerweile relativ ratlos.

Bitte um Hilfe, danke.

[testperson 1.786]

Hi,

 

setze auf dem neuen DC einmal folgende Registry Keys:

New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" `
    -Name "AlwaysExpectDomainController" `
    -PropertyType Dword `
    -Value 1 `
    -Force
 
New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
    -Name "MaxNegativeCacheTtl" `
    -PropertyType Dword `
    -Value 0 `
    -Force
 
New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" `
    -Name "NegativeCachePeriod" `
    -PropertyType Dword `
    -Value 0 `
    -Force

 

Und plane folgendes PowerShell Script beim Systemstart mit 30 Sekunden Verzögerung:

Get-NetConnectionProfile |
    Where-Object { $_.NetworkCategory -eq "Public" } |
        ForEach-Object {
            Disable-NetAdapterBinding -Name $_.InterfaceAlias `
                -ComponentID ms_tcpip6
            Start-Sleep -Seconds 2
            Enable-NetAdapterBinding -Name $_.InterfaceAlias `
                -ComponentID ms_tcpip6
        }

 

Gruß

Jan

 

P.S.: Solange du den DC01 noch in Betrieb hast, _dürfte_ das eigentlich nicht auftreten. Generell würde ich auch immer zu zwei Domain Controller tendieren.

bearbeitet 10. März von testperson

[NorbertFe 2.197]

vor 3 Minuten schrieb testperson:

_dürfte_ das eigentlich nicht auftreten.

Doch tut es leider. Hab ich letzte Woche auch gesehen. :)

[testperson 1.786]

vor 1 Minute schrieb NorbertFe:

Doch tut es leider. Hab ich letzte Woche auch gesehen. :)

 

Dann schätze ich mich glücklich, das noch nicht beobachtet zu haben und richte die Regkeys samt Task einfach erstmal vorsorglich überall ein. :)

[-peet- 1]

Danke für euere Beiträge.

Habe die Registry Einträge gesetzt bzw. das PowerShell Script angelegt, leider ist das Netzwerk nach dem Serverneustart immer noch auf "Privat".

Bin um jede Hilfe dankbar.

[NorbertFe 2.197]

https://www.frankysweb.de/windows-server-2025-falsches-netzwerkprofil-auf-domain-controller/

[testperson 1.786]

vor 13 Stunden schrieb -peet-:

Habe die Registry Einträge gesetzt bzw. das PowerShell Script angelegt, leider ist das Netzwerk nach dem Serverneustart immer noch auf "Privat".

 

Wurde das Script denn auch ausgeführt?

Was ist denn wenn nach dem Serverneustart das Script / der Code einmalig von Hand ausgeführt wird? Ändert sich das Profil dann?

[-peet- 1]

Hallo Leute,

 

danke für euere Beiträge.

Durch den Link von @NorbertFe bin ich auf die Lösung mit dem Netzwerkadapter gekommen.

Habe mir ein eigenes Powershell Skript gebastelt, das dann ein LogFile ausgibt, ob alles sauber gestartet wurde Serverabhängig.

Danke für euere Hilfe! Ebenfalls großen Dank an @NorbertFe 

[testperson 1.786]

Btw.: Windows Server 2025 known issues and notifications | Microsoft Learn

 

Zitat

Windows Server 2025 domain controllers (such as servers hosting the Active Directory domain controller role) might not manage network traffic correctly following a restart. As a result, Windows Server 2025 domain controllers may not be accessible on the domain network, or are incorrectly accessible over ports and protocols which should otherwise be prevented by the domain firewall profile.

 

This issue results from domain controllers failing to use domain firewall profiles whenever they’re restarted. Instead, the standard firewall profile is used. Resulting from this, applications or services running on the domain controller or on remote devices may fail, or remain unreachable on the domain network. 

 

[Weingeist 172]

Das ist doch das gängige Problem mit dem NlaSvc (Network Location Awareness) als Schuldigen. Dürfte bei Server 2025 nicht anders sein. Ein Kaltstart statt reboot löst manchmal das Problem. am zuverlässigsten ist das aktivieren/deaktivieren des Netzadapters oder jede sonstige Aktualisierung welche den NlaSvc triggert. Dazu gehört das Beispiel ein Protokoll deaktivieren oder aktivieren was schon genannt wurde. Das abrufen einer IP bei DHCP gehört bei einer dynamischen IP üblicherweise auch dazu. Auch wenn die IP wieder identisch ist weil der Lease noch gültig ist. Das geht mit herkömmlich Userrights. --> Hilfreich bei Clients

 

Schöner wäre allerdings, wenn jemand nen Trigger bei MS ausfindig machen könnte, der auch mit User-Rechten manuell anstossbar ist und auch bei fixen IP's hilft. Dann wäre das ganze gegessen. Ein (sinnvolle) Doku gibts ja nicht. Allenfals gäbe es auch einen WMI-Befehl.

 

Sonstige Hintergrundinfos

Die Ereichbarkeit der Adressen für das Active und Passive-Probing sind quasi Voraussetzung. Hier würde ich aber mittlerweile nichts am Standard mehr ändern ausser eben allenfalls interne Server anzugeben für den Connection Test. Alle anderen gängigen Tipps habe ich mittlerweile verworfen und alles auf Standard gelassen weils eh nicht langfristig hilft, Build-abhängig oder etwas krass ist. NlaSvc verzögern, NlaSvc restart erzwingen (möglich mit Process-Kill oder TI-Rights), DNS-Suffix vorgeben, NlaSvc von anderen Diensten abhängig machen um Start aktiv zu verzögern, Netzadapteränderungen, DNS-Cache usw. usf.

 

In der Vergangenheit habe ich mich schon mehrere male recht lange damit beschäftigt. Konnte es damals so eingrenzen, dass nun entweder neu erstellte Netzwerk-Profile zusätzlich erstellt wurden (rauslöschen half mind. für 1 Reboot, manchmal hälts dann manchmal nicht) oder die Netzwerkkarte in der Registry nicht als erste in der Auflistung erschien. Vor allem mussten alte Einträge alle raus weil auch Überreste zählten die nicht mehr Gerätemanager erschienen, auch nicht bei den ausgeblendeten. Etwas doof weil GUID's mit von der Party sind. Das zuverlässig zu fixen war allerdings nur äusserst mühsam möglich und vor allem nicht langzeitstabil (OS, Treiberudates etc.) Habe ich aufgegeben. Reine Bastellösung.

Das heftigste Problem hatte ich mal auf einem Client mit aktivierten Management-Funktionen von Intel, da war nichtmal der DHCP-Abruf beim Reboot erfolgreich ohne den Adapter zu deaktivieren/aktivieren. Bekam eine generische. Selbst eine fixe IP wurde durch eine generische ersetzt. Nach dem deaktivieren und löschen von all dem Zeugs war dann NlaSvc "geflickt" und DHCP wieder funktionstüchtig. Ganz schräg.