<!--{"title": "Windows Server 2025 Domänen-Controller legt Netzwerkprofil auf Öffentlich fest", "date": "2025-05-09", "slug": "windows-server-2025-adds-netzwerk-profil-public-nicht-domainauthentifiziert", "description": "Wer sich dazu entschließt seine Domänen-Controller auf Windows Server 2025 zu aktualisieren erlebt nicht selten eine böse Überraschung. Nach jedem Neustart wird das Netzwerk-Profil auf Öffentlich gestellt. Das ist besonders für einen Domänencontroller schlecht.", "cover": "/static/img/windows-server-2025-adds-netzwerk-profil-public-nicht-domainauthentifiziert.webp"}-->
> Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: [💜 <ins>Kein Einsatz von KI</ins>](/page/ai)

**Windows Server 2025 Domänen-Controller legen nach einem Neustart das Netzwerkprofil auf Öffentlich fest.**

## Problembeschreibung

Der neu aufgesetzte Windows Server 2025 welcher zum Domänen-Controller heraufgestuft wurde, wollte sein Profil des Netzwerk-Adapters nicht mehr konstant behalten.
Normalerweise muss das Domänen-Profil zugeordnet sein. Statt dessen steht nach jedem Neustart des Systems der Netzwerk-Adapter wieder auf Öffenliches-Netzwerk.
Dieses Verhalten ist für eine konsistente Konfiguration der Firewall nicht hinnehmbar. Also was tun?

Dieser Bug ist nach meinen Recherchen mindestens seit November 2024 bekannt.
Da ich in meinem Unternehmen vor der gleichen Problematik stand, musste ich mich zwangsläufig mit der Systematik auseinandersetzen.
Die Lösungssuche gestalltete sich sehr schwierig, da es auch von Seiten Microsoft keine erkennbare Stellungnahme dazu gibt.

## Lösungsversuche und Recherche

In mehreren Blogs und in der Tech-Community von Microsoft konnte ich eine Reihe von Ansätzen erkennen, die das Problem zwar lösen, für eine reale Lösung jedoch für mich nicht zufriedenstellen genug waren.
Das Zurücksetzen der Netzwerkkarte nach Neustart in der Aufgabenplanung oder Start-Skript ist ein wirklich guter Work-Around, aber mehr auch nicht.
Niemand kann damit sicher sein, das ein zufälliges Ereignis der Netzwerkkarte nicht wieder zu einer Änderung des Profils führt.

Nach vielen Recherchen in diverser Fachlektüre bin ich zu dem Schluss gekommen, dass es etwas mit dem NLA-Dienst zu tun haben muss.
In früheren Erklärungen von Microsoft, welche bis zum Jahr 2016 zurück reichen, wurden die immer größere Relevanz von IPv6 für Systemdienste erwähnt.
Im Hintergrund funktionieren viele Dinge ungeachtet der Konfiguration, bereits seit einigen Jahren über IPv6.

## Fehlendes IPv6 als mögliche Ursache

### Warum kommt IPv6 als Ursache in Frage

Microsoft behandelt bereits seit Jahren IPv6 höher priorisiert als IPv4.
Das kann man schon daran erkennen, dass sobald der Client eine IPv6-Adresse bezogen hat, quasi ausschließlich IPv6 gesprochen wird.
Angefangen von DNS über sonstige Dienste, welche über IPv6 erreichbar sind.
Die vollständige Deaktivierung von IPv6 über Windows gestaltet sich schwierig. Verwendet man den "Slider" im neuen Einstellungs-Menü, so ist IPv6 nicht "wirklich" deaktiviert.
Möchte man dies tun, so geht dies nach wie vor nur über die alte Systemsteuerung via Netzwerk -> Adapter und den Haken bei IPv6 herauszunehmen.
Dies kann man auch gut anhand von ipconfig /all verifizieren.

Mit dem Wissen ist es naheliegend, das Windows zur Zuweisung des Profils IPv6 verwendet. Nach meinen Recherchen wird beim Start des Servers / Clients versucht einen Domänencontroller zu identifizieren.
Auf einem Domänencontroller konfiguriert man normalerweise immer 127.0.0.1 als primären DNS-Eintrag. Wenn der Server kein IPv6 Profil hat, so ist dort auch kein IPv6 DNS-Eintrag vorhanden (::1).

### Warum wird IPv6 in Unternehmen trotzdem nicht verwendet

Viele Administratoren, wie auch ich, empfinden die Nutzung von IPv6 im Unternehmen als nicht zielführend.
Die Gründe dafür sind vielfältig:

* Ausreichende Kapazitäten in IPv4-Netzen
* Komplexe Konfiguration von IPv6
* Schlechte Möglichkeiten für das Ausrollen automatischer Installationen durch Softwareverteilungen
* Komplexe Einrichtungen von DHCP-Reservierungen
* Aufwändige Notation
* Fehlendes Wissen des komplexen Protokolls

Somit haben viele Administratoren bislang einen großen Bogen um die Konfiguration und den großen Stack an Aufgaben, die im Netzwerkbereich daraus resultieren gemacht.
Doch das wird nun zunehmend zum Problem.

## Lösung

Wie Sie sich bereits gedacht haben, ist die Lösung tatsächlich die Zuweisung eines IPv6-Profils.
Zudem habe ich bei uns noch einen Registry-Schlüssel auf unseren Domänen-Controllern angelegt. Das löst die Probleme.

Der Eintrag in der Registrierung ist ein DWORD-Wert (32-Bit) im Schlüsselpfad
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
```
mit der Bezeichnung ``` AlwaysExpectDomainController ``` und dem Wert ``` 1 ```.

Ich habe für mein Unternehmen eine Möglichkeit die IPv6 bietet verwendet, die relativ unbekannt ist.
Es ist bei IPv6 vorgesehen, Teile von IPv4 zu integrieren. So kann man einen Präfix wählen, der immer (/96) ist.
Die letzten Werte sind die IPv4-Adresse des Clients.

Mit diesem Rpäfix ist es möglich nun die IPv4-Adressen der Clients, auch in der Notation, zu integrieren:

```
fd12:3456:789A:BCDE:: /96
```

Angenommen Ihr Domänen-Controller hat die IPv4 (172.16.0.10) dann wäre seine IPv6-Adresse nach dem Beispiel:

```
fd12:3456:789A:BCDE::172.16.0.10 /96
```

oder umgerechnet:

```
fd12:3456:789A:BCDE::ac10:a /96
```

Das ist eine wirklich simple Möglichkeit IPv6 schnell zu Migrieren.
Sie können diese Adresse in beiden Notationen im Windows-Interface eingeben.
Windows rechnet die Adresse dann in das rein Hex-Basierte Format um.

In meinem Fall, habe ich die Option Gateway bei IPv6 aktuell nicht konfiguriert.

> Welche IPv6 Adresse Sie verwenden ist jedoch vollkommen unerheblich. Wichtig ist lediglich, das der Domänen-Controller eine IPv6 Adresse hat.
> Ebenfalls macht es keinen Unterschied, ob die IP fest oder von einem DHCP6-Server vergeben wurde.

Trotzdem erscheint es als Zukunftssicher, sich mit der Thematik auseinanderzusetzen und den Schritt hin zu einem fläschendeckenden Ausrollen von IPv6 in Betracht zu ziehen.

## Fazit

Ich persönlich empfinde es als unzumutbar, das Administratoren für eine eigentlich gut funktionierende "Out-of-the-Box" Installation der ADDS schlecht Dokumentierte Zusatzschritte unternehmen muss, um seine Domäne lauffähig zu halten.
Der immense Zeitaufwand zur Lösungsfindung war aus meiner Sicht vollkommen vermeidbar.

Ich hoffe dieser Artikel hat Ihnen weiterhelfen können!
