Windows Server praktisch einrichten

Voraussetzungen vor der Installation

Die VM benötigt eine feste Serveradresse, passende Maske und Route zu den Clientnetzen. Beispiel: DHCP01 mit 192.168.20.10/24, Gateway .20.1. Die DHCP-Rolle braucht lokale Administrationsrechte. Der virtuelle Switch darf nicht mit einem fremden Produktions-LAN gebrückt sein.

AD-Autorisierung betrifft einen DHCP-Server in einer Active-Directory-Umgebung. Sie benötigt einen vorhandenen erreichbaren Domänendienst und ausreichende Rechte. In einem isolierten Workgroup-Labor ohne AD wird dieser Schritt nicht als erfundene Pflicht ausgeführt. Autorisierung ersetzt weder Scopeaktivierung noch eine korrekte Bindung.

Rolle, Scope und Parameter

Die Reihenfolge trennt Installation von Freigabe: Rolle installieren, Bereich zunächst inaktiv anlegen, Schutz und Optionen setzen, prüfen, dann aktivieren. Eine Reservierung muss zur erfassten Clientkennung passen. Verwende die echte Schnittstelle und das geplante Netz statt blind die Beispielwerte zu übernehmen.

Install-WindowsFeature DHCP -IncludeManagementTools
# Nur im vorbereiteten AD-Labor mit ausreichenden Rechten:
Add-DhcpServerInDC -DnsName dhcp01.nordlicht.test -IPAddress 192.168.20.10
Add-DhcpServerv4Scope -Name 'Buero' -StartRange 192.168.10.100 -EndRange 192.168.10.199 -SubnetMask 255.255.255.0 -State InActive
Add-DhcpServerv4ExclusionRange -ScopeId 192.168.10.0 -StartRange 192.168.10.110 -EndRange 192.168.10.119
Set-DhcpServerv4OptionValue -ScopeId 192.168.10.0 -Router 192.168.10.1 -DnsServer 192.168.20.10 -DnsDomain nordlicht.test
Add-DhcpServerv4Reservation -ScopeId 192.168.10.0 -IPAddress 192.168.10.150 -ClientId '02-00-00-00-10-50' -Name Drucker
Set-DhcpServerv4Scope -ScopeId 192.168.10.0 -State Active

Betrieb kontrollieren

Get-Service DHCPServer prüft den Dienst. Get-DhcpServerv4Binding zeigt, auf welchen IPv4-Schnittstellen er gebunden ist. Get-DhcpServerv4Scope und Get-DhcpServerv4Lease -ScopeId 192.168.10.0 zeigen Bereich und Leases. In der Ereignisanzeige die verfügbaren DHCP-Server-Kanäle und Systemereignisse zum Zeitpunkt des Versuchs untersuchen.

Die grafische Alternative ist die DHCP-Konsole: Server → IPv4 → Bereich → Adresspool, Reservierungen und Bereichsoptionen. Vergleiche beide Sichten. Ein vorhandenes Objekt im Dialog ist kein Beweis für eine erfolgreiche Clientvergabe.

Vier getrennte Ebenen der Windows-Abnahme

Die installierte Rolle beweist nur, dass die Software vorhanden ist. Der laufende Dienst muss außerdem an der vorgesehenen Netzwerkschnittstelle arbeiten. In einer passenden Active-Directory-Umgebung ist die Autorisierung ein weiterer Verwaltungsschritt. Schließlich braucht der Client einen aktiven, passenden Scope mit freien Adressen und richtigen Optionen. Jede Ebene kann funktionieren, während die nächste noch fehlt.

Eine sinnvolle Reihenfolge lautet daher: stabile Serverkonfiguration prüfen, Rolle und Dienst prüfen, Bindungen und gegebenenfalls Autorisierung prüfen, anschließend Scope und effektive Optionen prüfen. Erst danach einen neuen Testclient beobachten. Windows-Reservierungen und Policies sind zusätzliche Auswahlregeln; sie sollten nicht gleichzeitig mit einer noch ungeprüften Grundvergabe eingeführt werden.

Änderungen an einem bestehenden Bereich verifizieren

Vor einer Änderung notierst du den bisherigen effektiven Wert und eine aktuelle Clientkonfiguration. Ändere beispielsweise zunächst nur den DNS-Wert des Testbereichs. Prüfe danach, dass die Verwaltung den Wert gespeichert hat, ein neuer beziehungsweise erneuernder Client ihn im ACK erhält und die tatsächliche Namensauflösung funktioniert. Diese drei Ergebnisse sind verschiedene Aussagen.

Bei einem Failoverpaar muss zusätzlich die Scopekonfiguration kontrolliert zum Partner repliziert werden. Lease-Synchronisierung bedeutet nicht automatisch identische Optionen. Teste einen Bezug über beide vorgesehenen Anbieter, bevor die Änderung als abgeschlossen gilt. Die konkreten PowerShell-Schritte liegen in den verlinkten Laboranleitungen; ihre Ausgabe ist jeweils gegen den geplanten Zustand zu prüfen.