Technische Dokumentation · Windows-Server-Lernumgebung

Windows Server 2022 – Administration und Infrastruktur

Die dargestellten Arbeiten umfassen Serverbetrieb, PowerShell, Hyper-V, Speicher, Netzwerkdienste, Active Directory, Gruppenrichtlinien, PKI und standortübergreifende Dienste. Gezeigt werden Konfiguration, Fehlerkorrektur, Ergebnisprüfung und fachliche Grenzen in der Lernumgebung.

Systeme: Windows Server 2022 · Windows 11
Technologien: PowerShell · Hyper-V · DNS/DHCP/RRAS · AD DS/GPO · AD CS · DFS/BranchCache
Einsatzrahmen: Lern- und Laborumgebung; kein heutiger Produktiv- oder Livezustand

Technologiebereich

Serveradministration und PowerShell

Systemzustand erfassen, Rollen und Features kontrolliert verwalten sowie PowerShell-Hilfe, Cmdlets und Dateioperationen nachvollziehbar einsetzen.

Praxis und Ergebnis

Serveranalyse und Administrationswerkzeuge

Rollen, Features und Serverzustand mit Server-Manager, PowerShell, DISM, Windows Admin Center und Sicherungswerkzeugen untersuchen.

Ausgangslage

Ausgangspunkt war ein installierter Windows Server 2022 ohne zusätzliche dauerhaft vorausgesetzte Rollen. Server-Manager, PowerShell, DISM und Windows Admin Center wurden für Zustandsprüfung, Rollenverwaltung und Validierung kombiniert.

1. Ziel

Ziel des Blocks war es, einen Windows Server 2022 systematisch zu analysieren und zentrale Administrationswerkzeuge praktisch einzusetzen. Ziel war nicht der dauerhafte Betrieb zusätzlicher Dienste, sondern deren kontrollierte Installation, Prüfung und Entfernung.

Konkret wurden folgende Ziele umgesetzt:

lokale Servereigenschaften über den Server-Manager prüfen
Serverrollen und Features über die GUI installieren und entfernen
Featurezustände mit PowerShell validieren
eine Serverrolle per PowerShell installieren und wieder entfernen
einen PowerShell-Fehler erkennen und korrigieren
DISM zur Featureverwaltung verwenden
Windows Admin Center installieren und als webbasiertes Verwaltungswerkzeug nutzen
Windows Server-Sicherung über WAC installieren und wieder entfernen

3. Ausgangslage / Lab-Kontext

Der geprüfte Server war der Lab-Host [Laborhost] mit Windows Server 2022 Datacenter. Der Server befand sich noch in der Arbeitsgruppe WORKGROUP und war zu diesem Zeitpunkt nicht Mitglied einer Active-Directory-Domäne.

Die Umgebung diente als Schulungs- und Lab-System. Deshalb wurden einige Einstellungen sichtbar, die in einer produktiven Umgebung anders bewertet werden müssten, z. B. deaktivierte IE Enhanced Security Configuration oder DHCP-basierte IP-Zuweisung auf einem Server.

4. Lokale Serveranalyse über den Server-Manager

Im Server-Manager wurde die Ansicht Lokaler Server geöffnet. Diese Ansicht fasst zentrale lokale Servereigenschaften zusammen und ist ein typischer Einstiegspunkt für die Erstprüfung eines Windows Servers.

Lokale Serverübersicht im Server-Manager

Aus dem Nachweis gehen folgende relevante Informationen hervor:

Bereich	Beobachtung
Computername	`[Laborhost]`
Arbeitsgruppe	`WORKGROUP`
Betriebssystem	Microsoft Windows Server 2022 Datacenter
Umgebung	Microsoft Corporation Virtual Machine
Arbeitsspeicher	24 GB RAM
Firewall	aktiv
Remoteverwaltung	aktiviert
Remotedesktop	aktiviert
NIC-Teaming	deaktiviert
Netzwerkadapter	`vEthernet (externer Lab-Switch)`
IP-Konfiguration	IPv4-Adresse per DHCP
Defender Antivirus	Echtzeitschutz aktiviert
IE Enhanced Security Configuration	Aus

Technische Bedeutung

Der Server war zum Zeitpunkt der Prüfung noch nicht Teil einer Domäne. Das ist für diesen frühen Projektstand korrekt, weil Active Directory erst in einem späteren Block aufgebaut wird.

Remoteverwaltung und Remotedesktop waren aktiviert. In der Laborumgebung ist das sinnvoll, weil administrative Arbeiten remote durchgeführt werden können. In einer produktiven Umgebung müssten diese Einstellungen zusätzlich über Firewallregeln, Zugriffskonzepte und Sicherheitsrichtlinien kontrolliert werden.

Der vorhandene Netzwerkadapter ist an einen Lab-Switch angebunden, der ausdrücklich nicht verändert oder gelöscht werden soll. Diese Beobachtung ist relevant für spätere Hyper-V- und Netzwerkblöcke.

5. Rollen und Features über den Server-Manager verwalten

5.1 Installation über die GUI

Über den Server-Manager wurde der Assistent Rollen und Features hinzufügen verwendet. Installiert wurden testweise:

Datendeduplizierung
Internetdruckclient

Die Installation wurde erfolgreich abgeschlossen.

Erfolgreiche Installation von Datendeduplizierung und Internetdruckclient

5.2 Entfernung und Validierung

Anschließend wurden die zuvor installierten Komponenten wieder entfernt. Nach dem erforderlichen Neustart wurde der Zustand über PowerShell geprüft.

Der PowerShell-Nachweis zeigt:

Feature	Zustand nach Entfernung
FS-Data-Deduplication / Datendeduplizierung	Available
Internet-Print-Client / Internetdruckclient	Available

Technische Bedeutung

Der wichtige Punkt ist nicht nur die Installation, sondern die kontrollierte Rücknahme der Änderung. Dadurch bleibt das System nach der Übung wieder in einem sauberen Zustand. Die PowerShell-Validierung ist belastbarer als ein reiner GUI-Screenshot, weil der Zielzustand direkt aus der Rollen-/Featureverwaltung abgefragt wurde.

6. DNS-Rolle über PowerShell installieren und entfernen

6.1 Fehler erkannt und korrigiert

Im PowerShell-Teil wurde testweise die DNS-Serverrolle installiert. Zunächst wurde ein Befehl mit einem nicht akzeptierten Parameter ausgeführt. PowerShell meldete, dass der Parameter -IncludeManagementTools in dieser Umgebung nicht gefunden wurde.

Anschließend wurde der Befehl korrigiert und die DNS-Rolle erfolgreich installiert.

Weiterer NachweisPowerShell-Fehler, Korrektur und erfolgreiche DNS-Installation

Der Nachweis zeigt drei fachlich relevante Punkte:

Der erste Befehl erzeugte einen Parameterfehler.
Der Installationsbefehl wurde korrigiert.
Die DNS-Rolle wurde erfolgreich installiert.

Zusätzlich erschien eine Warnung, dass auf dem Computer keine statische IP-Adresse gefunden wurde. Diese Warnung ist fachlich wichtig, weil DNS-Server in einer produktiven Serverumgebung üblicherweise mit statischer IP-Adresse betrieben werden sollten.

6.2 Entfernung und Endzustand

Nach dem Test wurde die DNS-Rolle wieder entfernt. Der finale Zustand wurde erneut geprüft.

Weiterer NachweisDNS-Rolle nach Entfernung wieder verfügbar

Der finale Zustand zeigt:

DNS-Server / DNS = Available

Technische Bedeutung

Dokumentiert sind ein realer Parameterfehler, seine Ursache, die korrigierte Installation und die anschließende Rücknahme der Änderung.

Der Ablauf umfasste:

Fehler erkannt → Befehl korrigiert → Installation erfolgreich → Rolle geprüft → Rolle entfernt → Endzustand validiert

7. Featureverwaltung mit DISM

Neben Server-Manager und PowerShell wurde DISM verwendet, um Windows-Features auf Betriebssystemebene zu verwalten. Der Schwerpunkt lag auf dem DHCP-Feature.

7.1 DHCP-Feature aktiviert und geprüft

Das DHCPServer-Feature wurde mit DISM aktiviert. Anschließend wurde die Featureinformation ausgegeben.

Weiterer NachweisDISM-Featureinformation: DHCPServer aktiviert

Der Nachweis zeigt:

Feature: DHCPServer
Status: Aktiviert
Neustart erforderlich: Possible

7.2 DHCP-Feature deaktiviert und geprüft

Danach wurde das Feature wieder deaktiviert und der Zustand erneut geprüft.

Weiterer NachweisDISM-Featureinformation: DHCPServer deaktiviert

Der finale Zustand zeigt:

Feature: DHCPServer
Status: Deaktiviert

Technische Bedeutung

DISM arbeitet auf einer anderen Ebene als der Server-Manager und PowerShell-Cmdlets. Windows-Features wurden zusätzlich direkt mit dem Bereitstellungs- und Imageverwaltungstool geprüft, aktiviert und wieder deaktiviert.

Während der Bearbeitung war DHCP im Server-Manager nicht wie erwartet als direkt nutzbares Verwaltungselement sichtbar. Da Aktivierung, Prüfung und Deaktivierung über DISM erfolgreich waren und die Abweichung im Unterrichtskontext als unkritisch eingeordnet wurde, blieb kein offener technischer Fehler.

8. Windows Admin Center installieren und verwenden

8.1 Installation und Zugriff

Das Windows Admin Center wurde über das Installationspaket aus dem Lab-Verzeichnis installiert:

C:\ISOs\tools\WindowsAdminCenter2211.msi

Nach Abschluss der Installation zeigte der Assistent die Zugriffsmöglichkeit über HTTPS an.

Weiterer NachweisInstallationsabschluss und URL des Windows Admin Centers

Die angezeigte URL lautete:

https://[Laborhost]:443

8.2 Verbindung zur Serverübersicht

Nach dem Aufruf der URL im Browser wurde der Server [Laborhost] im Windows Admin Center geöffnet.

Weiterer NachweisServerübersicht in Windows Admin Center

Die Serverübersicht zeigt zentrale Informationen wie Computername, Arbeitsgruppe, Betriebssystem, Version, RAM, Prozessoren, Modell und Defender-Status. Damit wurde nachgewiesen, dass WAC nicht nur installiert, sondern tatsächlich mit dem Server verbunden wurde.

8.3 Diensteverwaltung über WAC

Anschließend wurde der Bereich Dienste geöffnet.

Weiterer NachweisDiensteübersicht in Windows Admin Center

Der Nachweis zeigt, dass WAC als Verwaltungsoberfläche für klassische Serververwaltungsaufgaben genutzt werden kann. Sichtbar sind Dienstname, Anzeigename, Status und Startmodus.

Technische Bedeutung

Windows Admin Center ergänzt den klassischen Server-Manager um eine browserbasierte Verwaltungsoberfläche. In einer Laborumgebung ist die Nutzung mit selbstsigniertem Zertifikat vertretbar. In einer produktiven Umgebung wäre ein vertrauenswürdiges Zertifikat erforderlich.

9. Windows Server-Sicherung über WAC installieren und entfernen

Zusätzlich wurde innerhalb des Windows Admin Centers der Bereich Rollen und Features verwendet, um das Feature Windows Server-Sicherung zu installieren und anschließend wieder zu entfernen.

9.1 Installation

Nach der Installation war das Feature Windows Server-Sicherung im WAC als installiert sichtbar.

Weiterer NachweisWindows Server-Sicherung über WAC installiert

9.2 Deinstallation

Anschließend wurde das Feature wieder deinstalliert. Der finale Status zeigte wieder Verfügbar.

Weiterer NachweisWindows Server-Sicherung über WAC deinstalliert

Technische Bedeutung

WAC wurde nicht nur zur Anzeige verwendet, sondern auch aktiv zur Featureverwaltung eingesetzt.

10. Validierung

Die erfolgreiche Bearbeitung des Blocks wurde durch mehrere Arten von Nachweisen validiert:

Bereich	Validierung
Server-Manager	lokale Servereigenschaften sichtbar und ausgewertet
Rollen/Features GUI	Installation von Datendeduplizierung und Internetdruckclient erfolgreich
PowerShell	Entfernung der Features mit `Available` bestätigt
DNS PowerShell	Fehler korrigiert, DNS installiert und anschließend wieder entfernt
DISM	DHCPServer aktiviert, geprüft, deaktiviert und erneut geprüft
Windows Admin Center	Installation, Browserzugriff, Serverübersicht und Diensteverwaltung nachgewiesen
WAC Rollen/Features	Windows Server-Sicherung installiert und wieder entfernt

11. Troubleshooting und Abweichungen

11.1 PowerShell-Parameterfehler

Beim ersten DNS-Installationsversuch wurde ein nicht akzeptierter Parameter verwendet. Der Fehler wurde anhand der PowerShell-Fehlermeldung erkannt und der Befehl korrigiert. Die DNS-Rolle wurde anschließend erfolgreich installiert.

11.2 Warnung zur statischen IP-Adresse

Bei der DNS-Installation erschien eine Warnung, dass keine statische IP-Adresse gefunden wurde. Diese Warnung wurde fachlich eingeordnet. Für einen produktiven DNS-Server wäre eine statische IP-Adresse erforderlich. Im aktuellen Lab-Kontext war die Installation nur ein temporärer Übungsschritt.

11.3 DHCP nicht wie erwartet im Server-Manager sichtbar

Nach der DISM-Aktivierung war DHCP im Server-Manager nicht wie erwartet als Verwaltungseintrag verfügbar. Da DISM den Featurezustand korrekt zeigte und der Tutor diese Abweichung als unkritisch bewertete, wurde die Übung über DISM abgeschlossen.

Ergebnis

Serverzustand, Rollen und Features wurden mit mehreren Administrationswegen untersucht. Ein fehlerhafter PowerShell-Parameter wurde korrigiert; temporär installierte DNS-, DHCP- und Sicherungskomponenten wurden anschließend wieder entfernt und der Endzustand kontrolliert.

Einsatzrahmen: Die gezeigten Rollenänderungen gehören zur Lernumgebung; daraus wird kein dauerhafter Produktivrollenzustand abgeleitet.

Praxis und Ergebnis

PowerShell und Hilfe zur Selbsthilfe

PowerShell-Version, Cmdlets, Approved Verbs, Hilfesystem, Filter, Parameter und Dateioperationen systematisch nachvollziehen.

Ziel

Ziel dieses Blocks war es, PowerShell als zentrales Administrationswerkzeug für Windows Server 2022 praktisch zu verwenden. Im Fokus standen PowerShell-Version, Cmdlet-Struktur, Wildcards, genehmigte Verben, das Hilfesystem, Parameterarten und einfache Dateioperationen.

Ausgangszustand

Die Arbeiten wurden auf dem Server [Laborhost] durchgeführt. Der Server befand sich weiterhin in der Arbeitsgruppe WORKGROUP. In diesem Block wurden keine produktiven Serverrollen eingerichtet; der Schwerpunkt lag auf administrativer Grundlagenarbeit mit PowerShell.

2.1.3 – PowerShell-Version, Cmdlets und IntelliSense

Die Windows PowerShell wurde in der regulären 64-Bit-Variante gestartet. Über $PSVersionTable wurde die installierte PowerShell-Version ausgelesen.

Die Ausgabe zeigt Windows PowerShell 5.1.20348.320, Edition Desktop, Build-Version 10.0.20348.320, CLR-Version 4.0.30319.42000, WSManStackVersion 3.0, PSRemotingProtocolVersion 2.3 und SerializationVersion 1.1.0.1.

Mit Get-Command | Select-Object -First 20 wurde ein kompakter Auszug verfügbarer Befehle angezeigt.

In der PowerShell ISE wurde IntelliSense geprüft. Nach Eingabe von $PSV wurde $PSVersionTable vorgeschlagen.

2.2.1 – Cmdlet-Aufbau, Wildcards und Dienstfilterung

PowerShell-Cmdlets folgen dem Muster Verb-Substantiv -Parameter. Dienste mit dem Anfangsbuchstaben P wurden über Get-Service -Name "P*" gefiltert.

Weiterer NachweisDienstfilter P

Die Wildcard * wurde mit Get-Command Get-NetIP* verwendet.

Weiterer NachweisGet-NetIP Wildcard

Die Wildcard ? wurde mit Get-Command Get-NetIPv?Protocol verwendet und grenzte die Ausgabe auf IPv4- und IPv6-Protokoll-Cmdlets ein.

Weiterer NachweisFragezeichen Wildcard

2.3 – Genehmigte PowerShell-Verben

Mit Get-Verb -Verb "a*" wurden genehmigte Verben angezeigt, die mit A beginnen.

Weiterer NachweisGenehmigte Verben

2.4 – Cmdlets nach Verb und Substantiv filtern

Mit Get-Command -Verb Get wurden alle verfügbaren Befehle mit dem Verb Get angezeigt.

Weiterer NachweisGet-Command Verb Get

Mit Get-Command -Verb Get -Noun *memory* wurde die Suche auf Speicherbezug eingeschränkt.

Weiterer NachweisGet-Command Memory

2.4.5 – PowerShell-Hilfesystem verwenden

Die Hilfe zu Get-EventLog wurde mit Get-Help -Name Get-EventLog aufgerufen. Da keine vollständigen Hilfedateien installiert waren, wurden reduzierte Basisinformationen angezeigt.

Weiterer NachweisGet-EventLog Hilfe

Die Parameterhilfe zu ComputerName wurde gezielt aufgerufen.

Weiterer NachweisParameterhilfe ComputerName

2.5.1a – Dienste filtern, ausschließen und Parameterreihenfolge prüfen

WinRM wurde aus einer Win*-Dienstabfrage ausgeschlossen. Die vertauschte Reihenfolge der benannten Parameter führte zum gleichen Ergebnis.

Weiterer NachweisExclude und Parameterreihenfolge

2.5.1b – Positionsparameter und benannte Parameter prüfen

Die Hilfeausgabe zeigt, dass Name Position 0 besitzt, während Exclude als benannter Parameter geführt wird.

Weiterer NachweisParameterarten

2.5.1c – Datei mit Copy-Item kopieren und umbenennen

Mit Get-Command *copy* wurde Copy-Item als Kopier-Cmdlet identifiziert. Anschließend wurde die Datei C:\ISOs\Win11-TPM_aktivieren!.jpg nach C:\VM\test.jpg kopiert und validiert.

Weiterer NachweisCopy-Item Nachweis

2.6 – Hilfe zu Get-TimeZone abrufen

Mit Get-Help -Name Get-TimeZone wurde die Basishilfe zu Get-TimeZone aufgerufen. Die Ausgabe enthält Syntaxvarianten, Alias gtz und den Hinweis auf fehlende vollständige Hilfedateien.

Weiterer NachweisGet-TimeZone Basishilfe

Ergebnis

PowerShell-Version, Cmdlet-Suche, Approved Verbs, Wildcards, Dienstfilter, Parameterformen, Hilfesystem und Dateioperationen wurden anhand konkreter Befehle nachvollzogen.

Einsatzrahmen: Die gezeigten Befehle belegen den jeweiligen Laborlauf, nicht einen heutigen Livezustand.

Technologiebereich

Virtualisierung und Lab-Grundumgebung

Hyper-V, virtuelle Datenträger, Netzwerke, Zielsysteme und die wiederverwendbare AD-Labgrundlage aufbauen.

Praxis und Ergebnis

Hyper-V und virtuelle Lab-Infrastruktur

Hyper-V-Rolle, VHDX, virtuelle Switches und die Ziel-VMs über GUI, Windows Admin Center und PowerShell aufbauen.

Ziel

Eine reproduzierbare Hyper-V-Basis mit virtuellen Datenträgern, getrennten Switchtypen und fünf vorbereiteten Zielsystemen aufbauen.

Ausgangslage

Die Hyper-V-Rolle war bereits vorhanden und wurde deshalb geprüft statt erneut installiert. Der geschützte externe Switch blieb unverändert; für die Übungsumgebung wurden ein interner und ein privater Switch verwendet.

Die Zielsysteme DC, Server1, Server2, Server3 und W11 wurden als Generation-2-VMs mit den jeweils vorgesehenen Ressourcen und Datenträgern vorbereitet.

Umsetzung

Technische Arbeitsschritte

1. Hyper-V-Rolle prüfen

Der Rollenstatus wurde mit Get-WindowsFeature -Name Hyper-V geprüft. Ergebnis: Hyper-V war installiert. Dadurch wurde ein unnötiger Installations- oder Neustartvorgang vermieden.

2. VHDX-Dateien erstellen und erweitern

Test1.vhdx wurde über den Hyper-V-Manager erstellt und erweitert,test2.vhdx vollständig per PowerShell. Beide Wege wurden mit Get-VHD validiert.

3. Virtuelle Switches einrichten

Die Switches Intern und Privat wurden erstellt. Der bestehende externe Lab-Switch wurde wegen seines Schutzhinweises nicht verändert.

4. Ziel-VMs bereitstellen

DC und W11 wurden über den Hyper-V-Manager vorbereitet,Server1 über Windows Admin Center und Server2/Server3 per PowerShell.

VM-Zielkonfiguration

VM	Methode	Generation	RAM	Switch	Besonderheit
`DC`	Hyper-V-Manager	2	2048 MB	`Privat`	OS später installieren
`Server1`	Windows Admin Center	2	2048 MB	`Privat`	2 virtuelle Prozessoren
`Server2`	PowerShell	2	2048 MB	`Privat`	dynamische 127-GB-VHDX
`Server3`	PowerShell	2	2048 MB	`Privat`	dynamische 127-GB-VHDX
`W11`	Hyper-V-Manager	2	4096 MB	`Privat`	Client-VM vorbereitet

Technische Entscheidungen

Begründung der technischen Entscheidungen

Rollenstatus statt Neuinstallation

Die Hyper-V-Rolle war bereits installiert. Die fachlich saubere Entscheidung war daher die Prüfung des vorhandenen Zustands statt einer redundanten Installation.

externer Lab-Switch nicht verändern

Der vorhandene Switch externer Lab-Switch wurde ausdrücklich nicht angepasst. Damit wurde die Host- und Laborumgebung geschützt.

Server1-Konfiguration korrigiert und validiert

Server1 sollte über Windows Admin Center erstellt werden. Eine mögliche Abweichung wurde vor der finalen Umsetzung erkannt, geprüft und sauber korrigiert.

Validierung

Ergebnisvalidierung

Kritische GUI-Ergebnisse wurden zusätzlich per PowerShell validiert.

Get-WindowsFeature -Name Hyper-V

Get-VHD -Path "C:\VM\Test1.vhdx" | Select-Object Path, VhdType, Size

Get-VMSwitch | Select-Object Name, SwitchType, NetAdapterInterfaceDescription | Format-Table -AutoSize

Get-VM | Select-Object Name, State, Generation, MemoryStartup, ProcessorCount | Sort-Object Name

Bildnachweise

Rollenprüfung und VHDX-Grundlagen

**Hyper-V-Rolle bereits installiert**PowerShell-Prüfung mit Get-WindowsFeature bestätigt den vorhandenen Hyper-V-Rollenstatus auf dem Lab-Host.

**Test1.vhdx über GUI erstellt**Assistent für neue virtuelle Festplatten: VHDX, feste Größe, Pfad C:\VM, Größe 1 GB.

**1-GB-VHDX validiert**Get-VHD bestätigt Typ Fixed und Größe 1 GiB für Test1.vhdx.

Weiterer NachweisTest1.vhdx erweitert

Weiterer Nachweis2-GB-VHDX validiert

Weiterer Nachweistest2.vhdx per PowerShell erstellt und erweitert

Bildnachweise

Virtuelle Switches

Weiterer NachweisInterner Switch Intern erstellt

Weiterer NachweisPrivater Switch Privat erstellt

Weiterer NachweisSwitches per PowerShell validiert

Bildnachweise

VM-Erstellung und Werkzeugvergleich

Weiterer NachweisVM DC über Hyper-V-Manager vorbereitet

Weiterer NachweisServer1-Korrektur geprüft

Weiterer NachweisWindows Admin Center Inventar vor Server1

Weiterer NachweisServer1 im Windows Admin Center konfiguriert

Weiterer NachweisServer1-Erstellung erfolgreich

Bildnachweise

PowerShell-Erstellung und Abschlussvalidierung

Weiterer NachweisServer2 per New-VM erstellt

Weiterer NachweisServer2-VHDX erstellt und angebunden

Weiterer NachweisServer2 validiert

Weiterer NachweisServer3 per PowerShell erstellt

Weiterer NachweisServer3 validiert

Weiterer NachweisW11 über Hyper-V-Manager vorbereitet

Weiterer NachweisAbschlussvalidierung der Ziel-VMs

Einsatzrahmen: Der geschützte externe virtuelle Switch blieb unverändert. Hyper-V-Rolle, VHDX, interne/private Switches und Ziel-VMs wurden ausschließlich in der Lernumgebung geprüft.

Praxis und Ergebnis

Virtuelle Windows-Systeme installieren und vorbereiten

Windows Server 2022 und Windows 11 installieren, Nested Virtualization, MAC-Spoofing, Speicher und private Adressierung vorbereiten.

Ziel-VMs: DC, Server1, Server2, Server3, W11

192.168.1.200–204

korrigierter Projektadressbereich

Basis

finaler Prüfpunkt je Ziel-VM

Ziel

Windows Server 2022 und Windows 11 in den vorbereiteten virtuellen Maschinen installieren, die Nested-Hyper-V-Voraussetzungen einrichten, das private Labornetz adressieren und belastbare Basis-Prüfpunkte anlegen.

2. Verbindlicher Adressplan

Adresskorrektur: Der belegte Endbereich ist 192.168.1.200–204; niedrigere Beispieladressen waren nur Zwischenstände und wurden nicht als Endzustand verwendet.

System	Hostname / Bezeichnung	IPv4	Subnetzmaske	DNS	Gateway
DC	`DC`	`192.168.1.200`	`255.255.255.0`	`192.168.1.200`	leer
Server1	`Server1 / VM-Name`	`192.168.1.201`	`255.255.255.0`	`192.168.1.200`	leer
Server2	`Server2`	`192.168.1.202`	`255.255.255.0`	`192.168.1.200`	leer
Server3	`Server3`	`192.168.1.203`	`255.255.255.0`	`192.168.1.200`	leer
W11	`w11`	`192.168.1.204`	`255.255.255.0`	`192.168.1.200`	leer

3. Umsetzung in technischen Schritten

VM-Vorbereitung:
ISO-Medien, DVD-Laufwerke, Firmware-Bootreihenfolge und W11-spezifische Hardwareparameter wurden vorbereitet.

Installation:
Windows Server 2022 Datacenter auf vier Server-VMs, Windows 11 Enterprise auf W11.

Nested Hyper-V:
Server1 wurde hostseitig vorbereitet, Hyper-V wurde temporär installiert und eine Test-VM gestartet.

Netzwerkbasis:
Alle Zielsysteme wurden im internen Labnetz statisch adressiert, DNS zeigt auf 192.168.1.200.

Prüfpunkte:
Alle Ziel-VMs erhielten einen Prüfpunkt Basis als Rückfallpunkt.

Adresskorrektur:
Falsch verwendete Zwischenadressen wurden erkannt und nicht als Endzustand verwendet.

4. Nested-Hyper-V-Konfiguration

Der erste Versuch,ExposeVirtualizationExtensions zu ändern, schlug fehl, weil Server1 noch lief. Danach wurde die VM heruntergefahren und korrekt konfiguriert:

Set-VMProcessor -VMName Server1 -ExposeVirtualizationExtensions 1
Get-VMNetworkAdapter -VMName Server1 | Set-VMNetworkAdapter -MacAddressSpoofing On
Set-VMMemory -VMName Server1 -DynamicMemoryEnabled $false

Die Validierung zeigt: Virtualisierungserweiterungen aktiv, MAC-Spoofing aktiv und dynamischer Speicher deaktiviert.

5. Fachliche Grenze

Für DC, Server2, Server3 und W11 liegen klare Endzustandsnachweise mit Hostname und IP-Konfiguration vor. Für Server1 liegt ein Nachweis der IP-/DNS-Konfiguration vor; der sichtbare Windows-Hostname im Screenshot ist jedoch noch der Installationsname. Deshalb wird die Server1-Hostname-Umbenennung in dieser Version nicht als bildlich final validiert behauptet.

VM-Vorbereitung und Installationsmedien

W11-Ressourcen: Generation-2-VM mit aktivem TPM, 4 GB RAM und zwei virtuellen Prozessoren.

Windows-11-ISO ist als DVD-Laufwerk eingebunden.

Firmware-Startreihenfolge: DVD-Laufwerk vor Festplatte.

Weiterer NachweisDC: Windows-Server-2022-ISO als Installationsmedium eingebunden.

Weiterer NachweisDC: Startreihenfolge mit DVD-Laufwerk als erstem Bootmedium.

Weiterer NachweisServer1: Windows-Server-2022-ISO eingebunden.

Weiterer NachweisServer1: Bootreihenfolge auf DVD-Laufwerk vor Festplatte gesetzt.

Weiterer NachweisServer2: Windows-Server-2022-ISO eingebunden.

Weiterer NachweisServer2: Bootreihenfolge auf DVD-Laufwerk vor Festplatte gesetzt.

Weiterer NachweisServer3: Windows-Server-2022-ISO eingebunden.

Weiterer NachweisServer3: Bootreihenfolge auf DVD-Laufwerk vor Festplatte gesetzt.

Betriebssysteminstallation

Weiterer NachweisMehrere Server-VMs sind installiert und über die Hyper-V-Konsole erreichbar.

Weiterer NachweisServer2 nach Installation: Server-Manager startet automatisch.

Weiterer NachweisWindows 11: OOBE-Netzwerkdialog im isolierten Labnetz ohne Internet.

Weiterer NachweisWindows 11 ist installiert und zeigt den Desktop.

Nested Hyper-V auf Server1

Weiterer NachweisHyper-V-Manager: Ziel-VMs sind vorhanden und mehrere VMs laufen.

Weiterer NachweisFehlernachweis: Nested-Virtualization-Einstellung kann an einer laufenden VM nicht geändert w…

Fehlernachweis: Nested-Virtualization-Einstellung kann an einer laufenden VM nicht geändert werden.

Weiterer NachweisServer1: Nested-Virtualization-Einstellungen validiert – Virtualisierungserweiterungen aktiv,…

Server1: Nested-Virtualization-Einstellungen validiert – Virtualisierungserweiterungen aktiv, MAC-Spoofing an, dynamischer Speicher aus.

Weiterer NachweisServer1: Installation der Hyper-V-Rolle erfolgreich abgeschlossen.

Weiterer NachweisServer1: PowerShell-Prüfung zeigt Hyper-V als installiert.

Weiterer NachweisNested Hyper-V: Test-VM innerhalb von Server1 erstellt.

Weiterer NachweisNested Hyper-V: Test-VM startet und erreicht PXE-Boot.

Weiterer NachweisNach Rücksetzung: Hyper-V ist in Server1 wieder nur verfügbar, nicht installiert.

IP-Konfiguration und Namensprüfung

Weiterer NachweisDC: Hostname DC, IPv4 192.168.1.200, DNS 192.168.1.200, DHCP deaktiviert.

Weiterer NachweisServer1-VM: IPv4 192.168.1.201 und DNS 192.168.1.200 gesetzt; sichtbarer Windows-Hostname im …

Server1-VM: IPv4 192.168.1.201 und DNS 192.168.1.200 gesetzt; sichtbarer Windows-Hostname im Screenshot noch Installationsname.

Weiterer NachweisServer2: Hostname Server2, IPv4 192.168.1.202, DNS 192.168.1.200, DHCP deaktiviert.

Weiterer NachweisServer3: Hostname Server3, IPv4 192.168.1.203, DNS 192.168.1.200, DHCP deaktiviert.

Weiterer NachweisW11: Gerätename auf w11 gesetzt, Windows 11 Enterprise installiert.

Weiterer NachweisW11: Hostname w11, IPv4 192.168.1.204, DNS 192.168.1.200, DHCP deaktiviert.

Basis-Prüfpunkte

Weiterer NachweisAufgabenhinweis: Basis-Prüfpunkte für alle VMs erstellen und umbenennen.

Weiterer NachweisDC: Prüfpunkt in Basis umbenannt.

Weiterer NachweisServer1: Basis-Prüfpunkt sichtbar.

Weiterer NachweisServer2: Basis-Prüfpunkt sichtbar.

Weiterer NachweisServer3: Basis-Prüfpunkt sichtbar.

Weiterer NachweisW11: Basis-Prüfpunkt sichtbar.

Ergebnis

Vier Server-VMs und der Windows-11-Client wurden installiert, die Nested-Hyper-V-Konfiguration auf Server1 erprobt und die privaten IP-/DNS-Werte kontrolliert. Für Server1 ist die IP-/DNS-Konfiguration sichtbar; der finale Betriebssystem-Hostname ist im vorhandenen Bildbestand nicht eindeutig zu erkennen.

Praxis und Ergebnis

Grundkonfiguration der AD-Labumgebung

Windows-11-Neuaufbau, IP-/DNS-Basis, Domäne, zusätzlicher Domänencontroller, Domänenbeitritte, Übungs-OUs und geordnete Prüfpunkte vorbereiten.

Ausgangspunkt und Prüfpunktlogik

Der bearbeitete Arbeitsumfang beginnt in der Aufgabenbeschreibung ab Abschnitt 16.3.5. Die bereits vorkonfigurierten Abschnitte 16.1.1 bis 16.2.6 gehören nicht dazu. Ausgangspunkt war der Prüfpunkt Basis-AD; für den Neuaufbau wurde auf Basis zurückgegangen, der bisherige Basis-AD-Prüfpunkt entfernt und nach Abschluss neu erstellt.

Windows-11-Client neu aufbauen

Die vorhandene W11-VM und ihr Ablageordner wurden entfernt, weil eine andere Windows-Edition benötigt wurde. Anschließend wurde die VM per PowerShell neu angelegt: Ordnerstruktur, dynamische 127-GB-VHDX mit New-VHD, Generation-2-VM mit New-VM, DVD-Laufwerk und vorbereitete ISO, Secure Boot, zwei virtuelle Prozessoren sowie ein virtueller TPM über Guardian und Key Protector.

Die Installation verwendete eine vorbereitete autounattend.xml. Danach wurden für den Client die statische Laboradresse und der DNS-Server mit New-NetIPAddress und Set-DnsClientServerAddress gesetzt.

Ersten Domänencontroller und DNS bereitstellen

Auf der VM DC wurden AD DS und DNS installiert und eine neue Gesamtstruktur gfnlab.test eingerichtet. Die Domänen- und Gesamtstrukturfunktionsebene blieb bei Windows Server 2016. DSRM wurde konfiguriert; das verwendete Labkennwort bleibt aus Sicherheitsgründen ungenannt. Nach der Heraufstufung wurden Netzwerkprofil und DNS-Einstellungen geprüft; bei Bedarf wurde der Adapter neu gestartet.

Server1 als zusätzlichen Domänencontroller einbinden

Server1 erhielt AD DS und wurde als zusätzlicher Domänencontroller in die vorhandene Domäne aufgenommen. Der globale Katalog wurde zunächst für den demonstrierten Installationsschritt abgewählt und anschließend über die NTDS-Einstellungen wieder aktiviert. DNS- und Netzwerkprofilwerte wurden danach kontrolliert und angepasst.

Mitgliedssysteme der Domäne hinzufügen

Server2 wurde über die Systemeigenschaften, Server3 per Add-Computer und der neu aufgebaute Windows-11-Client über die Windows-Systemeinstellungen der Domäne hinzugefügt. Neustart und Anmeldung im Domänenkontext gehörten zum Ablauf. Zugangsdaten werden nicht angezeigt.

Organisationseinheiten, Übungskonten und SYSVOL-Basis

Auf DC wurden die OUs Arbeit und Administratoren angelegt. Ein reguläres Übungskonto wurde der OU Arbeit zugeordnet; ein administratives Übungskonto wurde per PowerShell erstellt und der Gruppe Domänen-Admins hinzugefügt. Die Anmeldung des regulären Übungskontos auf W11 gehörte zur Vorbereitung der späteren Richtlinienarbeit.

Danach wurde das bereitgestellte SysvolFix-Skript auf dem Hyper-V-Host geprüft und ausgeführt. Es kopiert den Reparaturbaustein auf den Domänencontroller und richtet die geplante Ausführung ein. Spätere SYSVOL- und Richtlinienzustände zeigen die Nutzung beziehungsweise erneute Stabilisierung dieser Basis indirekt.

Geordneter Abschluss und neue Basis-AD-Prüfpunkte

Für einen konsistenten AD-Zustand wurden zunächst Mitgliedsserver und Client, danach der zusätzliche und schließlich der erste Domänencontroller geordnet heruntergefahren. Anschließend wurden für alle VMs neue Prüfpunkte Basis-AD erstellt und die alten Basis-Prüfpunkte kontrolliert entfernt beziehungsweise zusammengeführt.

Fachliche Grenze: Der beschriebene Arbeitsumfang wurde bearbeitet. Eine direkte Bildkette für die einzelnen Schritte fehlt; spätere Laborzustände zeigen wesentliche Voraussetzungen nur indirekt.

Technologiebereich

Speicher, Freigaben und Datenschutz

Lokalen Speicher, Freigaben, Berechtigungen, FSRM, Datendeduplizierung und BitLocker im Lab administrieren.

Praxis und Ergebnis

Lokaler Speicher und Hyper-V-Ablage

VHDX, GPT-Volumes, Mountpoints, dynamische Datenträger, Spiegelung, RAID-5 und die Verschiebung der VM-Ablage bearbeiten.

Ziel

Virtuelle Datenträger innerhalb von Server3 mit mehreren Administrationswerkzeugen verwalten und anschließend den Hyper-V-Host so strukturieren, dass die VM-Ablagen getrennt vom Systemvolume liegen.

2. Ausgangslage / Lab-Kontext

Gearbeitet wurde in der Laborumgebung auf dem Hyper-V-Host [Laborhost]. Die Zielumgebung bestand aus den virtuellen Maschinen DC,Server1,Server2,Server3 und W11. Für die Storage-Übungen wurde hauptsächlich Server3 verwendet.

System	Rolle im Block	Bemerkung
Server3	Übungsserver für Datenträger- und Volumeverwaltung	Zusätzliche virtuelle Festplatten wurden angebunden und anschließend nach der Aufgabenstellung über den Prüfpunkt zurückgesetzt.
[Laborhost]	Hyper-V-Host	Hostlaufwerk wurde für Hyper-V-Dateien neu aufgeteilt.
DC, Server1, Server2, Server3, W11	Zu verschiebende VMs	Wurden nach `H:\VM\%VMName%` verschoben.

3. Übung 5.1.1 - Virtuelle Festplatten für Server3

Im ersten Abschnitt wurden über den Hyper-V-Manager drei zusätzliche virtuelle Festplatten für Server3 erstellt und an den SCSI-Controller angebunden:

Server3_HDD_02.vhdx
Server3_HDD_03.vhdx
Server3_HDD_04.vhdx

Gemäß Aufgabenstellung wurden dynamisch erweiterbare VHDX-Dateien erstellt. Anschließend wurde in Server3 die Datenträgerverwaltung verwendet, um den zusätzlichen Speicher im Gastbetriebssystem sichtbar zu machen.

Fachlich wichtig ist hier die Trennung zwischen Host-Storage und Gast-Storage: Das Erstellen und Anhängen der VHDX-Dateien erfolgt auf dem Hyper-V-Host, während Online-Schalten, Initialisierung und Partitionierung innerhalb des Gastbetriebssystems stattfinden.

**VHDX-Erstellung für Server3 – Server3_HDD_02.vhdx** Der Hyper-V-Assistent zeigt die erste zusätzliche dynamisch erweiterbare VHDX-Datei für Server3 mit 127 GB Zielgröße.

**Server3 mit drei zusätzlichen VHDX-Dateien am SCSI-Controller** Die Einstellungen von Server3 zeigen die zusätzlich angebundenen virtuellen Festplatten Server3_HDD_02, Server3_HDD_03 und Server3_HDD_04.

**Datenträger 1 in Server3 initialisiert** Die Datenträgerverwaltung zeigt Datenträger 1 als Basisdatenträger mit nicht zugeordnetem Speicher nach der Initialisierung.

4. Übung 5.1.2 - Volumes mit verschiedenen Werkzeugen erstellen

Der zweite Abschnitt diente dazu, denselben Grundprozess mit verschiedenen Administrationswerkzeugen umzusetzen. Dadurch wurde nicht nur eine GUI-Aufgabe erledigt, sondern gezeigt, dass Speicherverwaltung über mehrere Werkzeuge nachvollzogen werden kann.

Volume	Werkzeug	Größe	Dateisystem	Zweck
E: / Volume1	Datenträgerverwaltung	10 MB	NTFS	GUI-Weg über klassische MMC
F: / Volume2	diskpart	10 MB	NTFS	CLI-Weg über Eingabeaufforderung
G: / Volume3	PowerShell	10 MB	NTFS	Automatisierbarer Weg per Cmdlet
H: / Volume4	Server-Manager	10 MB	NTFS	Server-Manager-Datei-/Speicherdienste
C:\Mount / Volume5	Datenträgerverwaltung	10 MB	NTFS	Bereitstellung in leerem NTFS-Ordner statt Laufwerksbuchstabe
C: verkleinert	Datenträgerverwaltung	10 MB	-	Freien Speicher durch Volume-Verkleinerung erzeugen

Im Arbeitsverlauf wurden unter anderem diskpart,New-Partition,Format-Volume und Get-Volume eingesetzt. Damit wurde die Aufgabe nicht nur grafisch, sondern auch über administrative Shell-Werkzeuge nachvollzogen.

New-Partition -DiskNumber 1 -Size 10MB -DriveLetter G | Format-Volume -FileSystem NTFS -NewFileSystemLabel "Volume3" -Confirm:$false
Get-Volume -DriveLetter E,F,G | Select-Object DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining

Weiterer NachweisVolume2 per diskpart erstellt

Weiterer NachweisVolume3 per PowerShell erstellt und validiert

Weiterer NachweisServer-Manager-Ansicht der Storage-Verwaltung

Weiterer NachweisVolumes 1 bis 4 auf Datenträger 1 vorhanden

Weiterer NachweisBereitstellungsordner C:\Mount angelegt

Weiterer NachweisVolume5 als Mountpoint C:\Mount erstellt

Weiterer NachweisC: in Server3 um 10 MB verkleinert

5. Übung 5.1.3 - Dynamischer Datenträger, Spiegelung und RAID-5

Im nächsten Abschnitt wurde Datenträger 1 in einen dynamischen Datenträger konvertiert. Zusätzlich wurden Datenträger 2 und Datenträger 3 online geschaltet, initialisiert und für gespiegelte sowie RAID-5-Volumes verwendet.

Konzept	Umsetzung im Lab	Einordnung
Dynamischer Datenträger	Konvertierung von Datenträger 1	Voraussetzung für dynamische Volume-Typen wie Spiegelung und RAID-5 in der Windows-Datenträgerverwaltung.
Gespiegeltes Volume	Volume6 / I: über Datenträger 2 und 3	Redundanzkonzept: identische Daten auf zwei Datenträgern.
RAID-5-Volume	Volume7 / J: über Datenträger 1, 2 und 3	Paritätsbasierter Verbund im Labkontext. Geeignet zur Demonstration, nicht als moderne Produktivempfehlung.

Technischer Zusammenhang: Dynamische Datenträger und softwarebasierte RAID-5-Volumes sind im Windows-Server-Lab didaktisch sinnvoll. Für moderne Produktivumgebungen würde man abhängig vom Szenario eher Storage Spaces, Hardware-RAID, SAN/NAS, Cluster Storage oder hypervisornahe Storage-Konzepte prüfen.

Weiterer NachweisDatenträger 1 in dynamischen Datenträger konvertiert

Weiterer NachweisGespiegeltes Volume6 / I: erstellt

Weiterer NachweisRAID-5-Volume7 / J: erstellt

Rücksetzung auf Prüfpunkt Basis

Nach Abschluss der Zusatzspeicherübungen sah die Aufgabenstellung vor,Server3 auf den Prüfpunkt Basis zurückzusetzen und die zusätzlich erzeugten VHDX-Dateien zu löschen. Im Arbeitsverlauf wurde dabei bewusst nachvollzogen, dass die Rücksetzung nicht nur den Gastzustand, sondern auch die VM-Konfiguration auf den Stand des Prüfpunkts zurückführt.

Weiterer NachweisServer3 mit Prüfpunkt Basis vor Rücksetzung

Weiterer NachweisWarnung beim Anwenden des Prüfpunkts

Weiterer NachweisServer3-Einstellungen nach Rücksetzung auf Basis

Weiterer NachweisServer3 nach Rücksetzung auf den Basiszustand

Saubere Fehlerbehandlung: Die nach dem Prüfpunktsprung verbliebenen, aber nicht mehr angebundenen VHDX-Dateien wurden nicht blind weiterverwendet. Sie wurden in einen ergänzende Quelldateien verschoben, damit keine veralteten Übungsartefakte die weitere Arbeit verfälschen.

6. Übung 5.1.4 - Hostlaufwerk für Hyper-V vorbereiten

Für die eigentliche Speicherumstellung der Labumgebung wurde auf dem Host [Laborhost] das Systemvolume verkleinert und der freigewordene Speicher als separates Laufwerk H: eingerichtet. Das Laufwerk wurde als Hyper-V-Datenspeicher genutzt.

Element	Zielzustand	Nachweis / Beobachtung
C:	ca. 250 GB	Datenträgerverwaltung zeigt C: mit 250,86 GB.
H:	separates NTFS-Volume für Hyper-V	Datenträgerverwaltung zeigt `Hyper-V (H:)` mit ca. 249 GB.
Ordnerstruktur	`H:\VM` mit Unterordnern je VM	Per PowerShell erstellt und geprüft.
Hyper-V-Standardpfade	`H:\VM` für virtuelle Festplatten und virtuelle Computer	Per Hyper-V-Einstellungen gesetzt und später per PowerShell validiert.

Weiterer NachweisHost-Datenträger vor Aufteilung

Weiterer NachweisHostlaufwerk C: verkleinert

Weiterer NachweisNeues Host-Volume H: im Assistenten vorbereitet

Weiterer NachweisHyper-V-Volume H: erstellt

Weiterer NachweisH:\VM-Ordnerstruktur erstellt

Weiterer NachweisHyper-V-Standardpfade auf H:\VM gesetzt

7. VM-Speicherorte nach H:\VM verschieben

Im Anschluss wurden die Hyper-V-Standardspeicherorte auf H:\VM geändert. Danach wurden die virtuellen Maschinen heruntergefahren beziehungsweise verschoben und mit dem Hyper-V-Verschiebe-Assistenten in die neue Zielstruktur überführt.

Die folgenden Screenshots zeigen die Zusammenfassungen des Verschiebe-Assistenten für die relevanten virtuellen Maschinen.

Weiterer NachweisDC nach H:\VM\DC verschieben

Weiterer NachweisServer1 nach H:\VM\Server1 verschieben

Weiterer NachweisServer2 nach H:\VM\Server2 verschieben

Weiterer NachweisServer3 nach H:\VM\Server3 verschieben

Weiterer NachweisW11 nach H:\VM\W11 verschieben

Finale PowerShell-Validierung

Nachgereicht wurden die zuvor fehlenden PowerShell-Screenshots. Damit ist der finale Zielzustand nicht mehr nur textlich beschrieben, sondern zusätzlich bildlich nachgewiesen.

VM	Status	VM-Pfad
`DC`	Running	`H:\VM\DC`
`Server1`	Running	`H:\VM\Server1`
`Server2`	Running	`H:\VM\Server2`
`Server3`	Running	`H:\VM\Server3`
`W11`	Running	`H:\VM\W11`

Weiterer NachweisFinalvalidierung: VM-Pfade und aktive virtuelle Festplatten

Weiterer NachweisFinalvalidierung: Ordnerstruktur H:\VM

Weiterer NachweisFinalvalidierung: Hyper-V-Hostpfade

Hinweis zu AVHDX-Dateien: Die sichtbaren aktiven Datenträgerpfade enden auf .avhdx. Das passt zu einer Umgebung mit vorhandenem Prüfpunkt. Die AVHDX-Datei ist in diesem Fall die aktive Differenzdatei; die Basiskette gehört weiterhin zur VM.

Ergebnis

VHDX-Dateien wurden angebunden, initialisiert und als Volumes über Datenträgerverwaltung,diskpart, PowerShell und Server-Manager eingerichtet. Spiegelung und RAID-5 wurden als Laborkonzepte nachvollzogen. Auf dem Host entstand das separate Hyper-V-Volume H:; die fünf VM-Ablagen wurden nach H:\VM verschoben und anschließend per PowerShell kontrolliert.

Erkenntnisse aus der Umsetzung

Ein Prüfpunktwechsel kann virtuelle Datenträger aus der VM-Konfiguration lösen, obwohl die VHDX-Dateien noch vorhanden sind.
Nicht mehr aktive Datenträger wurden vor weiteren Änderungen isoliert, statt sie vorschnell zu löschen.
Get-VM,Get-VMHardDiskDrive,Get-VMHost und Get-ChildItem dienten zur abschließenden Pfad- und Zustandskontrolle.

Praxis und Ergebnis

Freigaben, Berechtigungen und FSRM

Freigabe- und NTFS-Rechte, effektiven Zugriff, versteckte Freigaben, Quotas, Dateiscreening und Dateiverwaltungsaufgaben umsetzen.

Ziel

SMB- und NTFS-Berechtigungen, effektiven Zugriff, eine versteckte Freigabe sowie FSRM-Kontingent, Dateiscreening und eine Dateiverwaltungsaufgabe praktisch umsetzen.

2. Ausgangslage / Lab-Kontext

Gearbeitet wurde in der Laborumgebung mit den virtuellen Maschinen Server3 und W11.Server3 ist in diesem Block der Dateiserver.W11 dient als Client für die UNC-Zugriffstests.

System	Rolle im Block	Verwendung
Server3	Dateiserver / Administrationsziel	Lokale Benutzer, Ordner, Freigaben, NTFS-Berechtigungen und FSRM werden hier eingerichtet.
W11	Client	Zugriffstests über `\\server3`,`\\server3\Daten` und `\\server3\Tools$`.
`C:\Freigaben`	Arbeitsverzeichnis	Enthält die Ordner `Daten`,`Tools` und `Backup`.

3. Übung 6.1.2 - Ordner, Benutzer und Datenfreigabe

3.1 Ordnerstruktur unter C:\Freigaben

Auf Server3 wurden im Ordner C:\Freigaben die drei vorgesehenen Ordner Backup,Daten und Tools erstellt. Der Ablauf wurde gemäß Aufgabenstellung über mehrere Werkzeuge nachvollzogen: Explorer, CMD und PowerShell.

Der temporäre Ordner Notizen wurde nach dem PowerShell-Test wieder entfernt. Der relevante Zielzustand bestand aus Backup, Daten und Tools.

**Ordnerstruktur C:\Freigaben per CMD validiert** CMD zeigt die drei relevanten Ordner Backup, Daten und Tools unter C:\Freigaben. Damit ist die Ausgangsstruktur für Freigaben, Berechtigungen und FSRM vorbereitet.

3.2 Lokale Benutzer mit drei Methoden

Die lokalen Benutzer wurden nicht mit nur einer Methode erstellt, sondern entsprechend der Aufgabenstellung über drei verschiedene Wege. Dadurch werden grafische Verwaltung, PowerShell und klassische CMD-Befehle abgedeckt.

Benutzer	Methode	Zweck im Block
`User1`	Computerverwaltung / Lokale Benutzer und Gruppen	Lesender Zugriff auf `Daten`.
`User2`	PowerShell `New-LocalUser`	Ändernder Zugriff auf `Daten`.
`User3`	CMD `net user`	Ändernder Zugriff auf die versteckte Freigabe `Tools$`.

**User1 über Computerverwaltung erstellt** Die lokale Benutzerliste zeigt User1 nach Erstellung über die grafische MMC Computerverwaltung.

**User2 per PowerShell erstellt** PowerShell erstellt User2 und validiert den Benutzer anschließend. Dies belegt den zweiten geforderten Administrationsweg.

Weiterer NachweisUser1, User2 und User3 final validiert

3.3 Freigabe Daten und NTFS-Berechtigungen

Für den Ordner C:\Freigaben\Daten wurde zunächst die Freigabe Daten eingerichtet. Die Freigabeberechtigung wurde für Jeder auf Ändern gesetzt. Danach wurden die NTFS-Berechtigungen separat gehärtet: Vererbung deaktivieren, vererbte Berechtigungen in explizite Berechtigungen konvertieren, die allgemeinen Benutzer-Einträge entfernen und gezielt User1 sowie User2 hinzufügen.

Technischer Zusammenhang: Bei SMB-Freigaben gilt effektiv die restriktivere Kombination aus Freigabe- und NTFS-Berechtigung. Eine Freigabe mit „Jeder: Ändern“ bedeutet also nicht automatisch, dass jeder Benutzer schreiben darf, wenn NTFS dies verhindert.

Weiterer NachweisFreigabe Daten aktiviert

Weiterer NachweisNTFS-Vererbung für Daten deaktiviert

Weiterer NachweisUser1 und User2 als explizite NTFS-Berechtigungen

3.4 Zugriffstests von W11

Die Zugriffstests wurden von W11 aus durchgeführt. Zuerst wurde gezeigt, dass eine sichtbare Freigabe ohne passende NTFS-Berechtigung nicht nutzbar ist. Danach wurden die Zielrechte geprüft.

Test	Erwartung	Ergebnis
User1 vor expliziter NTFS-Berechtigung	Freigabe sichtbar, Zugriff nicht möglich	Erfüllt
User1 nach NTFS-Berechtigung	Ordner öffnen möglich, Datei erstellen nicht möglich	Erfüllt
User2 nach NTFS-Berechtigung	Ordner öffnen und Datei erstellen möglich	Erfüllt

Weiterer NachweisUser1: Zugriff zunächst verweigert

Weiterer NachweisUser1: Datei erstellen wird verweigert

Weiterer NachweisUser2: Datei erstellen erfolgreich

4. Übung 6.1.4 - Versteckte Freigabe Tools$

Der Ordner C:\Freigaben\Tools wurde über die Computerverwaltung als versteckte Freigabe Tools$ eingerichtet. Das Dollarzeichen am Ende bewirkt, dass die Freigabe bei normaler Auflistung über \\server3 nicht sichtbar erscheint. Der Zugriff funktioniert nur, wenn der Pfad direkt angegeben wird.

Element	Konfiguration	Ergebnis
Freigabename	`Tools$`	Versteckte Freigabe
Freigabepfad	`C:\Freigaben\Tools`	Freigabeziel auf Server3
Berechtigter Benutzer	`User3`	Ändern auf Freigabe- und NTFS-Ebene
Client-Test	`\\server3\Tools$`	Zugriff über direkte UNC-Eingabe

Weiterer NachweisFreigabe Tools$ erfolgreich erstellt

Weiterer NachweisFreigabenliste mit Daten und Tools$

Weiterer NachweisNTFS-Berechtigung für User3 auf Tools

Weiterer NachweisW11 fordert Anmeldung für Tools$ an

Weiterer NachweisUser3 kann in Tools$ eine Datei erstellen

5. Übung 6.2 - Effektiven Zugriff prüfen

Im nächsten Abschnitt wurde der effektive Zugriff auf den Ordner Daten geprüft. Diese Ansicht ist wichtig, weil sie die tatsächlich wirksamen Rechte eines Benutzers unter Berücksichtigung von NTFS-Berechtigungen, Gruppenmitgliedschaften und Freigabeeinschränkungen zusammenfasst.

Benutzer	Effektiver Zugriff auf Daten	Interpretation
`User1`	Lesen / Ausführen, Ordner auflisten, Attribute lesen; kein Schreiben, kein Löschen	Lesender Benutzer für Daten.
`User2`	Lesen und Schreiben möglich; Löschen eingeschränkt; Besitzübernahme nicht erlaubt	Benutzer mit Änderungsrechten im Datenordner.
`User3`	Kein effektiver Zugriff auf Daten	User3 ist bewusst auf Tools$ beschränkt.

Weiterer NachweisEffektiver Zugriff User1

Weiterer NachweisEffektiver Zugriff User2

Weiterer NachweisEffektiver Zugriff User3

6. Übung 6.3.2 - Ressourcen-Manager für Dateiserver und Kontingent

Für die FSRM-Aufgaben wurde die Rolle Ressourcen-Manager für Dateiserver installiert. Anschließend wurde auf C:\Freigaben\Backup ein hartes 100-MB-Kontingent erstellt.

Hartes Kontingent: Bei einem harten Kontingent wird das Überschreiten der Grenze verhindert. Im Lab wurde das durch einen Kopiertest mit C:\Windows\Fonts geprüft.

Weiterer NachweisFSRM-Rolle erfolgreich installiert

Weiterer NachweisHartes 100-MB-Kontingent für Backup

Weiterer NachweisKontingenttest: Fonts-Ordner überschreitet Limit

7. Übung 6.3.3 - Dateiprüfung für Bilddateien

In diesem Abschnitt wurde eine Dateiprüfung konfiguriert, die Bilddateien im Backup-Ordner blockiert. Damit der Effekt eindeutig nachweisbar ist, wurde die Dateigruppe Bilddateien um die künstliche Endung *.bild erweitert.

FSRM-Element	Konfiguration	Zweck
Dateigruppe	Bilddateien +`*.bild`	Testdateien mit eindeutiger Endung blockieren.
Dateiprüfungspfad	`C:\Freigaben\Backup`	Backup-Ordner vor unerwünschten Dateitypen schützen.
Prüfungstyp	Aktiv / blockierend	Speichern der definierten Dateitypen verhindern.

Weiterer NachweisDateigruppe Bilddateien um *.bild erweitert

Weiterer NachweisDateiprüfung Bilddateien blockieren aktiv

Weiterer NachweisDateiprüfung blockiert Testdatei

8. Übung 6.3.7 - Dateiverwaltungsaufgabe „Alte Daten“

Die Dateiverwaltungsaufgabe verschiebt Dateien mit entsprechend altem Zeitstempel aus C:\Freigaben\Daten nach C:\Freigaben\Backup. Entscheidend sind die Konfiguration, die vorbereiteten Testdateien und die anschließende Ergebniskontrolle.

Korrekturhinweis: Das bloße Anlegen der Aufgabe reicht als Nachweis nicht aus. Der fachlich wichtige Teil ist der Test mit künstlich alten Dateien und die anschließende Prüfung, dass genau die alte Datei verschoben wurde.

8.1 Aufgabe anlegen

Register	Einstellung
Allgemein	Aufgabenname `Alte Daten`, aktiviert, Beschreibung: 100 Tage alte Daten werden nach Backup verschoben.
Bereich	`C:\Freigaben\Daten`
Aktion	Dateiablauf nach `C:\Freigaben\Backup`
Zeitplan	Wöchentlich Freitag, 23:00 Uhr

Weiterer NachweisDateiverwaltungsaufgabe „Alte Daten“ - Allgemein

Weiterer NachweisBereich der Dateiverwaltungsaufgabe

Weiterer NachweisZeitplan der Dateiverwaltungsaufgabe

Weiterer NachweisAktion Dateiablauf nach Backup

Weiterer NachweisDateiverwaltungsaufgabe angelegt

8.2 Testdateien erstellen und Zeitstempel ändern

Für den Funktionstest wurden drei Dateien erstellt. Anschließend wurden nur die Zeitstempel von Datei1.txt auf den 08.08.2018 gesetzt. Damit ist Datei1.txt die einzige Datei, die die Ablaufbedingung erfüllt.

cd C:\Freigaben\Daten
New-Item -Name Datei1.txt -ItemType File
New-Item -Name Datei2.txt -ItemType File
New-Item -Name Datei3.txt -ItemType File (Get-ChildItem -Path C:\Freigaben\Daten\Datei1.txt).CreationTime='08.08.2018'
(Get-ChildItem -Path C:\Freigaben\Daten\Datei1.txt).LastAccessTime='08.08.2018'
(Get-ChildItem -Path C:\Freigaben\Daten\Datei1.txt).LastWriteTime='08.08.2018'
Get-Item C:\Freigaben\Daten\Datei1.txt | Select-Object Name, CreationTime, LastAccessTime, LastWriteTime

Weiterer NachweisTestdateien Datei1 bis Datei3 erstellt

Weiterer NachweisZeitstempel von Datei1.txt auf 08.08.2018 gesetzt

8.3 Aufgabe manuell ausführen und Ergebnis prüfen

Die Aufgabe wurde anschließend im FSRM manuell über Dateiverwaltungsaufgabe jetzt ausführen gestartet. Danach wurde geprüft, ob Datei1.txt aus dem Datenordner entfernt und im Backup-Pfad abgelegt wurde.

Weiterer NachweisDateiverwaltungsaufgabe manuell gestartet

Weiterer NachweisDatenordner nach Ausführung

Weiterer NachweisFSRM erzeugt Ablagepfad im Backup

Ergebnis

Die Freigaben Backup,Daten,Tools und Tools$ wurden eingerichtet und mit getrennten Freigabe-/NTFS-Rechten geprüft. Das harte 100-MB-Kontingent, das Dateiscreening und die Dateiverwaltungsaufgabe wurden konfiguriert und anhand der vorhandenen Resultate ausgewertet.

Fachliche Grenze: Soll-Beschreibungen ohne eigenes Ergebnisbild werden nicht als Bildnachweise gewertet. Auch der spätere Rücksprung auf den Ausgangsprüfpunkt ist nicht separat belegt.

10. Fachliche Erkenntnisse

Freigabe ≠ NTFS: Eine großzügige Freigabeberechtigung ersetzt keine NTFS-Berechtigung.
Vererbte Standardrechte wurden bewusst deaktiviert und Zielbenutzer explizit gesetzt; dadurch waren die Berechtigungen gezielt prüfbar.
Versteckte Freigaben sind nicht unsichtbar sicher:Tools$ wird nicht normal angezeigt, ist aber bei bekanntem UNC-Pfad erreichbar. Sicherheit entsteht durch Rechte, nicht durch das Dollarzeichen.
Kontingent, Dateiscreening und Dateiablauf wurden mit Positiv- und Negativtests geprüft.
Für die Dateiverwaltungsaufgabe reichte das Erstellen allein nicht aus; erforderlich waren ein Altdatei-Test und die anschließende Ergebniskontrolle.

Praxis und Ergebnis

Datendeduplizierung und BitLocker-Recovery

VHDX und Deduplizierung messen, BitLocker ohne TPM sowie mit TPM/PIN umsetzen und AD-gestützte Wiederherstellung einordnen.

Kurzfassung

Der Arbeitsblock verbindet Speichererweiterung und Datendeduplizierung mit BitLocker auf einem Server ohne TPM sowie auf einem Windows-11-Client mit TPM und PIN.

Der Ablauf enthält die Wiederherstellung der Domänenkommunikation, die Erweiterung des Datenlaufwerks, den messbaren Deduplizierungstest, die BitLocker-Richtlinien sowie die Recovery- und ISO-Zwischenfehler.

Diagnose- und Arbeitsverlauf

Nach der Rückkehr auf den Basiszustand wurden Secure Channel, DNS und Replikation geprüft und korrigiert.
Das Datenlaufwerk wurde erweitert und als Grundlage für die Deduplizierung vorbereitet.
Der Deduplizierungstest mit zehn BMP-Dateien ergab im Laborlauf rund 457 MB beziehungsweise 99 Prozent Einsparung.
BitLocker wurde auf Server2 ohne TPM und auf W11 mit TPM/PIN konfiguriert; Richtlinien-, Start- und Wiederherstellungszustände wurden getrennt ausgewertet.
Eine ISO-bedingte Startblockade wurde erkannt und korrigiert. Wiederherstellungswerte werden nicht angezeigt.

5. Infrastruktur-Preflight nach Checkpoint-Rücksetzung

Ziel

Vor der Arbeit an Datendeduplizierung und BitLocker musste die AD-Labumgebung nach Rücksetzung auf den geeigneten Prüfpunkt validiert werden. Relevant waren DC-/Server1-Replikation, SYSVOL/NETLOGON, DNS/Forward-Auflösung, Secure Channel der Domänenmitglieder und Erreichbarkeit der beteiligten Systeme.

Technischer Zusammenhang

In einer Hyper-V-Labumgebung können Checkpoints AD-bezogene Folgeprobleme erzeugen: Replikationsstände, Computerkonto-Kennwörter und Secure Channels können inkonsistent werden. Deshalb wurde nicht direkt mit der Deduplizierungs- und BitLocker-Konfiguration begonnen, sondern zuerst ein kontrollierter Infrastruktur-Preflight durchgeführt.

Umsetzung und Nachweise

Zunächst waren SYSVOL und NETLOGON auf DC vorhanden. Danach zeigte repadmin /replsummary erneut den bekannten Fehler 8524 zwischen DC und Server1. Die Replikation wurde über beidseitige repadmin /syncall-Läufe stabilisiert.

**Nachweis 2:** Belegt, dass DC nach dem Rücksprung grundsätzlich erreichbar ist und SYSVOL/NETLOGON vorhanden sind.

**Nachweis 3:** Zeigt den nach Prüfpunkt-Rücksetzung aufgetretenen Replikationsfehler 8524 und belegt den Ausgangspunkt der Reparatur.

**Nachweis 4:** Belegt den ersten Reparaturschritt zur Stabilisierung der AD-Replikation aus Sicht von DC.

Weiterer NachweisBelegt den zweiten Reparaturschritt zur Stabilisierung der AD-Replikation aus Sicht von SERVER1.

**Nachweis 5:** Belegt den zweiten Reparaturschritt zur Stabilisierung der AD-Replikation aus Sicht von SERVER1.

Weiterer NachweisBelegt die erfolgreich stabilisierte AD-Replikation nach dem SyncAll-Lauf.

**Nachweis 6:** Belegt die erfolgreich stabilisierte AD-Replikation nach dem SyncAll-Lauf.

Server2 zeigte anschließend einen gebrochenen Secure Channel zur Domäne. Netzwerk und Ping zu DC funktionierten, aber der sichere Kanal war unterbrochen. Die Reparatur erfolgte lokal auf Server2 über Domänenadmin-Credentials und Reset-ComputerMachinePassword, danach Neustart und erneute Domänenanmeldung.

Weiterer NachweisZeigt das Checkpoint-Folgeproblem: Server2 konnte zunächst keine Vertrauensstellung zur Domän…

**Nachweis 11:** Zeigt das Checkpoint-Folgeproblem: Server2 konnte zunächst keine Vertrauensstellung zur Domäne herstellen.

Weiterer NachweisBelegt, dass Netzwerk und DNS-Ziel grundsätzlich erreichbar waren, obwohl die Domänenvertraue…

**Nachweis 12:** Belegt, dass Netzwerk und DNS-Ziel grundsätzlich erreichbar waren, obwohl die Domänenvertrauensstellung defekt war.

Weiterer NachweisBelegt den unterbrochenen Secure Channel von Server2 zur Domäne vor der Reparatur.

**Nachweis 14:** Belegt den unterbrochenen Secure Channel von Server2 zur Domäne vor der Reparatur.

Weiterer NachweisBelegt die technische Reparatur des Server2-Computerkonto-/Secure-Channel-Problems.

**Nachweis 15:** Belegt die technische Reparatur des Server2-Computerkonto-/Secure-Channel-Problems.

Weiterer NachweisBelegt, dass die Anmeldung mit Domänenkonto nach dem Fix wieder möglich war.

**Nachweis 17:** Belegt, dass die Anmeldung mit Domänenkonto nach dem Fix wieder möglich war.

Weiterer NachweisBelegt den erfolgreich reparierten Secure Channel und funktionierende Domänenkommunikation.

**Nachweis 18:** Belegt den erfolgreich reparierten Secure Channel und funktionierende Domänenkommunikation.

Zusätzlich wurden Server3 und W11 geprüft. Beide Systeme waren im Domänenkontext bzw. Netzwerk erreichbar und lieferten die erforderliche Grundlage für die späteren BitLocker- und Client-Tests.

Weiterer NachweisBelegt, dass Server3 im Domänenkontext korrekt funktioniert.

**Nachweis 22:** Belegt, dass Server3 im Domänenkontext korrekt funktioniert.

Weiterer NachweisBelegt Netzwerkkonfiguration und DC-Erreichbarkeit von Server3.

**Nachweis 23:** Belegt Netzwerkkonfiguration und DC-Erreichbarkeit von Server3.

Weiterer NachweisBelegt Netzwerkkonfiguration und DC-Erreichbarkeit des Windows-11-Clients.

**Nachweis 24:** Belegt Netzwerkkonfiguration und DC-Erreichbarkeit des Windows-11-Clients.

Interpretation

Der Preflight ist als eigenständige technische Leistung zu bewerten. Ohne stabile AD-/DNS-/Secure-Channel-Basis wären die späteren BitLocker-AD-Backups, Recovery-Viewer-Tests und Domänenanmeldungen nicht belastbar gewesen.

6. Storage-Erweiterung und Deduplizierungsbasis

Ziel

Server2 sollte eine zusätzliche virtuelle Festplatte erhalten. Im Gastbetriebssystem wurde daraus das NTFS-Volume E: erstellt. Auf diesem Volume wurde Datendeduplizierung als allgemeiner Dateiserver mit Mindestalter 0 Tage aktiviert.

Technischer Zusammenhang

Datendeduplizierung reduziert Speicherverbrauch, indem identische Datenblöcke nur einmal physisch abgelegt und Dateien logisch über Metadaten referenziert werden. Für dieses Lab wurde eine bewusst einfache Testmethode gewählt: mehrere nahezu identische BMP-Dateien mit hoher Rohgröße.

Weiterer NachweisDeduplizierungslogik: neues Volume, Feature-Aktivierung, große Testdateien, manueller Optimie…

Deduplizierungslogik: neues Volume, Feature-Aktivierung, große Testdateien, manueller Optimierungsjob und Ergebnisprüfung.

Umsetzung: VHDX und Volume E:

Die virtuelle Festplatte wurde als dynamisch erweiterbare VHDX mit 127 GB erstellt und an Server2 angebunden. Im Betriebssystem wurde der neue Datenträger initialisiert und als NTFS-Volume E: formatiert.

Weiterer NachweisBelegt die Erstellung und Zuordnung der zusätzlichen virtuellen Festplatte zu Server2.

**Nachweis 25:** Belegt die Erstellung und Zuordnung der zusätzlichen virtuellen Festplatte zu Server2.

Weiterer NachweisBelegt, dass die neue virtuelle Festplatte im Gastbetriebssystem erkannt wurde.

**Nachweis 27:** Belegt, dass die neue virtuelle Festplatte im Gastbetriebssystem erkannt wurde.

Weiterer NachweisBelegt die GPT-Initialisierung des neuen Datenträgers.

**Nachweis 29:** Belegt die GPT-Initialisierung des neuen Datenträgers.

Weiterer NachweisBelegt die Erstellung des NTFS-Volumes E: auf Datenträger 1.

**Nachweis 31:** Belegt die Erstellung des NTFS-Volumes E: auf Datenträger 1.

Weiterer NachweisBelegt das erfolgreich eingerichtete Datenvolume E: für die Deduplizierungsaufgabe.

**Nachweis 32:** Belegt das erfolgreich eingerichtete Datenvolume E: für die Deduplizierungsaufgabe.

Umsetzung: Deduplizierung aktivieren

Die Rolle/Feature-Komponente für Datendeduplizierung wurde installiert. Danach wurde das Volume E: im Server-Manager ausgewählt und für Datendeduplizierung konfiguriert. Das Mindestalter wurde auf 0 Tage gesetzt, damit die erzeugten Testdateien sofort in die Deduplizierungsrichtlinie fallen.

Weiterer NachweisBelegt die ausgewählten Datei-/Speicherdienste inklusive Datendeduplizierung auf Server2.

**Nachweis 33:** Belegt die ausgewählten Datei-/Speicherdienste inklusive Datendeduplizierung auf Server2.

Weiterer NachweisBelegt die erfolgreiche Installation der Datendeduplizierung auf Server2.

**Nachweis 34:** Belegt die erfolgreiche Installation der Datendeduplizierung auf Server2.

Weiterer NachweisBelegt, dass Volume E: im Server-Manager als verwaltbares Volume erkannt wurde.

**Nachweis 35:** Belegt, dass Volume E: im Server-Manager als verwaltbares Volume erkannt wurde.

Weiterer NachweisBelegt die Aktivierung der Datendeduplizierung für Volume E: mit einer für den sofortigen Labortest gewählten Dateialter-Einstellung

**Nachweis 36:** Belegt die Aktivierung der Datendeduplizierung für Volume E: mit einer für den sofortigen Labortest gewählten Dateialter-Einstellung.

Weiterer NachweisBelegt die aktivierte Hintergrundoptimierung und die geplanten Deduplizierungsjobs.

**Nachweis 37:** Belegt die aktivierte Hintergrundoptimierung und die geplanten Deduplizierungsjobs.

26.1.1: PowerShell-Basisprüfung

Vor den Testdaten wurden die Deduplizierungsinformationen über PowerShell betrachtet. Die Ausgabe zeigte den aktivierten Dedupe-Kontext, aber noch keine optimierten Dateien und keine Einsparung.

Get-DedupStatus
Get-DedupVolume
Get-DedupMetadata
Get-DedupSchedule

Weiterer NachweisBelegt den Ausgangszustand der Deduplizierung: aktiviert, aber noch keine optimierten Dateien.

**Nachweis 38:** Belegt den Ausgangszustand der Deduplizierung: aktiviert, aber noch keine optimierten Dateien.

26.1.2: Testdaten und manueller Optimierungsjob

Für den Test wurde eine 4000×4000-Pixel-BMP-Datei erzeugt und anschließend neunmal kopiert. Damit lagen zehn BMP-Dateien auf E: vor. Jede Datei war etwa 45,78 MB groß.

Weiterer NachweisBelegt die Speicherung der Testdatei auf dem Deduplizierungsvolume E:.

**Nachweis 41:** Belegt die Speicherung der Testdatei auf dem Deduplizierungsvolume E:.

Weiterer NachweisBelegt die erzeugte große BMP-Datei vor der Vervielfältigung.

**Nachweis 42:** Belegt die erzeugte große BMP-Datei vor der Vervielfältigung.

Weiterer NachweisBelegt die Erzeugung von zehn großen, identischen BMP-Testdateien.

**Nachweis 43:** Belegt die Erzeugung von zehn großen, identischen BMP-Testdateien.

Vor dem Job zeigten Get-DedupStatus und Get-DedupProperties noch keine optimierten Dateien. Danach wurde der manuelle Optimierungsjob gestartet.

Start-DedupJob -Volume "E:" -Type Optimization -Memory 50 -Cores 75

Weiterer NachweisBelegt den Vorher-Zustand der Deduplizierung direkt vor dem manuellen Job.

**Nachweis 44:** Belegt den Vorher-Zustand der Deduplizierung direkt vor dem manuellen Job.

Weiterer NachweisBelegt, dass die Dateien noch nicht dedupliziert waren und als unoptimiert erkannt wurden.

**Nachweis 45:** Belegt, dass die Dateien noch nicht dedupliziert waren und als unoptimiert erkannt wurden.

Weiterer NachweisBelegt den Start der manuellen Deduplizierungsoptimierung.

**Nachweis 48:** Belegt den Start der manuellen Deduplizierungsoptimierung.

Der Nachher-Zustand belegt die eigentliche Wirkung: zehn Dateien wurden optimiert, die Dateiersparnis lag bei 99 %, und die sichtbare Dateigröße blieb logisch erhalten, während die Größe auf Datenträger für die ausgewählte Datei 0 Bytes zeigte.

Weiterer NachweisBelegt das erfolgreiche Deduplizierungsergebnis anhand konkreter PowerShell-Kennzahlen.

**Nachweis 49:** Belegt das erfolgreiche Deduplizierungsergebnis anhand konkreter PowerShell-Kennzahlen.

Weiterer NachweisBelegt den praktischen Effekt der Deduplizierung aus Dateisystem-/Explorer-Sicht.

**Nachweis 50:** Belegt den praktischen Effekt der Deduplizierung aus Dateisystem-/Explorer-Sicht.

Interpretation

Die Deduplizierung wurde nicht nur installiert, sondern anhand eines bewusst redundanten Dateisets praktisch validiert. Der Unterschied zwischen logischer Dateigröße und physischer Belegung wurde sichtbar und fachlich nachvollziehbar.

8. Serverseitige BitLocker-Absicherung ohne TPM

Ziel

Server2 sollte als System ohne nutzbares TPM über BitLocker geschützt werden. Dazu musste eine lokale BitLocker-Richtlinie gesetzt werden, die Wiederherstellungsinformationen in Active Directory speichert und BitLocker ohne kompatibles TPM zulässt.

Technischer Zusammenhang

Ohne TPM benötigt BitLocker eine alternative Startauthentifizierung, hier ein Kennwort. Zusätzlich ist die AD-Sicherung des Wiederherstellungskennworts zentral, damit das System nach Fehlversuchen oder vergessenen Startkennwörtern kontrolliert wiederhergestellt werden kann.

Weiterer NachweisBitLocker-Schutzlogik: Server2 ohne TPM nutzt Kennwortschutz und AD-Recovery; W11 nutzt TPM/PIN.

BitLocker-Schutzlogik: Server2 ohne TPM nutzt Kennwortschutz und AD-Recovery; W11 nutzt TPM/PIN.

Richtlinien und Featureinstallation

Die Recovery-Richtlinie wurde aktiviert: Wiederherstellungskennwort/-schlüssel zulassen, Wiederherstellungsoptionen im Assistenten unterdrücken, Informationen in AD DS speichern und BitLocker erst nach AD-Sicherung aktivieren. Danach wurde zusätzliche Authentifizierung beim Start aktiviert und BitLocker ohne kompatibles TPM zugelassen.

Weiterer NachweisBelegt, dass Wiederherstellungsinformationen vor der Verschlüsselung in AD …

**Nachweis 52:** Belegt, dass Wiederherstellungsinformationen vor der Verschlüsselung in AD DS gespeichert werden sollen.

Weiterer NachweisBelegt die Richtlinie für den TPM-losen Server2-BitLocker-Betrieb mit Kennwort/USB-Option.

**Nachweis 53:** Belegt die Richtlinie für den TPM-losen Server2-BitLocker-Betrieb mit Kennwort/USB-Option.

Weiterer NachweisBelegt die Installation der BitLocker-Komponenten und Verwaltungstools auf Server2.

**Nachweis 54:** Belegt die Installation der BitLocker-Komponenten und Verwaltungstools auf Server2.

Weiterer NachweisBelegt die erfolgreiche Installation der BitLocker-Funktion mit notwendigem Neustart.

**Nachweis 55:** Belegt die erfolgreiche Installation der BitLocker-Funktion mit notwendigem Neustart.

Verschlüsselung von C:

Für Laufwerk C: wurde Kennwortschutz eingerichtet, nur der verwendete Speicherplatz verschlüsselt, der neue Verschlüsselungsmodus gewählt und die Systemprüfung bewusst abgewählt. Die Verschlüsselung wurde abgeschlossen.

Weiterer NachweisBelegt die Auswahl eines Kennwortschutzes für das Betriebssystemlaufwerk oh…

**Nachweis 56:** Belegt die Auswahl eines Kennwortschutzes für das Betriebssystemlaufwerk ohne TPM.

Weiterer NachweisBelegt die gewählte Verschlüsselungsstrategie für das OS-Laufwerk.

**Nachweis 57:** Belegt die gewählte Verschlüsselungsstrategie für das OS-Laufwerk.

Weiterer NachweisBelegt die Auswahl des aktuellen XTS-AES-basierten Verschlüsselungsmodus.

**Nachweis 58:** Belegt die Auswahl des aktuellen XTS-AES-basierten Verschlüsselungsmodus.

Weiterer NachweisBelegt die bewusste Deaktivierung der BitLocker-Systemprüfung vor dem Start.

**Nachweis 59:** Belegt die bewusste Deaktivierung der BitLocker-Systemprüfung vor dem Start.

Weiterer NachweisBelegt den erfolgreichen Abschluss der BitLocker-Verschlüsselung auf Server2.

**Nachweis 62:** Belegt den erfolgreichen Abschluss der BitLocker-Verschlüsselung auf Server2.

Wiederherstellungswerte und zugehörige Kennungen werden nicht angezeigt.

Nachweis 63: Belegt 100% Verschlüsselung, aktiven Schutz, XTS-AES 128 und vorhandene Kennwort-/Recovery-Protektoren.

Recovery-Test

Nach der Verschlüsselung wurde der Pre-Boot-Schutz geprüft. Ein falsches Kennwort führte in den Wiederherstellungsmodus. Auf dem DC wurde der BitLocker-Wiederherstellungskennwort-Viewer installiert und der Recovery-Key über das Computerobjekt von SERVER2 im AD ausgelesen. Der sensible Wiederherstellungswert wird nicht angezeigt.

Weiterer NachweisBelegt, dass Server2 beim Start durch BitLocker-Kennwort geschützt ist.

**Nachweis 64:** Belegt, dass Server2 beim Start durch BitLocker-Kennwort geschützt ist.

Weiterer NachweisBelegt den in der Aufgabenstellung geforderten Test mit falschem Kennwort.

**Nachweis 65:** Belegt den in der Aufgabenstellung geforderten Test mit falschem Kennwort.

Wiederherstellungswerte und zugehörige Kennungen werden nicht angezeigt.

Nachweis 66: Belegt den Wechsel in die BitLocker-Wiederherstellung nach Fehlversuch.

Weiterer NachweisBelegt die erfolgreiche Installation des BitLocker-Recovery-Viewer-Features auf dem DC.

**Nachweis 68:** Belegt die erfolgreiche Installation des BitLocker-Recovery-Viewer-Features auf dem DC.

Wiederherstellungswerte und zugehörige Kennungen werden nicht angezeigt.

Nachweis 69: Belegt, dass der Server2-BitLocker-Recovery-Key im Active Directory gespeichert wurde.

Fachliche Grenze: AD-Abruf des Wiederherstellungskennworts sowie Eingabe- und Fehlerkontext sind belegt. Der konkrete Moment der erfolgreichen Recovery-Key-Eingabe wurde nicht separat fotografiert. Die spätere Nutzbarkeit von Server2 und das Abschalten von BitLocker per PowerShell machen die Wiedererreichbarkeit plausibel, ersetzen aber kein eigenes Recovery-Erfolgsbild.

Wiederherstellungswerte und zugehörige Kennungen werden nicht angezeigt.

Nachweis 70: Dokumentiert einen fehlgeschlagenen Eingabeversuch im Recovery-Modus und unterstützt die Troubleshooting-Erzählung.

Interpretation

Die Server2-Konfiguration zeigt den vollständigen Schutzpfad ohne TPM: lokale Richtlinie, AD-Recovery-Pflicht, Verschlüsselung, Pre-Boot-Abfrage, falsches Kennwort und Recovery-Key-Abruf über ADUC. Das ist fachlich deutlich mehr als eine reine GUI-Aktivierung von BitLocker.

9. Clientseitige BitLocker-Absicherung mit TPM/PIN

Ziel

W11 sollte mit TPM-basierter BitLocker-Startauthentifizierung und PIN geschützt werden. Im Gegensatz zu Server2 durfte die Option „BitLocker ohne kompatibles TPM zulassen“ nicht aktiviert werden.

Technischer Zusammenhang

Beim TPM-/PIN-Szenario wird die Vertrauensbasis des Geräts durch TPM-Messungen ergänzt; die PIN stellt eine zusätzliche Benutzerinteraktion vor dem Boot dar. Dadurch unterscheidet sich der Schutzmechanismus deutlich vom reinen Kennwortschutz ohne TPM.

Richtlinien

Auf W11 wurden Recovery-Informationen für AD DS konfiguriert und die zusätzliche Authentifizierung beim Start so gesetzt, dass TPM und PIN verwendet werden können, ohne den TPM-losen Modus zu aktivieren.

Weiterer NachweisBelegt, dass auch W11 Recovery-Informationen vor Aktivierung im AD speichern soll.

**Nachweis 72:** Belegt, dass auch W11 Recovery-Informationen vor Aktivierung im AD speichern soll.

Weiterer NachweisBelegt den TPM-/PIN-basierten BitLocker-Startschutz für W11.

**Nachweis 73:** Belegt den TPM-/PIN-basierten BitLocker-Startschutz für W11.

ISO-Blockade und Korrektur

Beim Start der BitLocker-Konfiguration meldete W11 einen startbaren Datenträger im DVD-Laufwerk. Das war kein BitLocker-Fehler, sondern eine Sicherheitsprüfung. Die ISO wurde über Hyper-V ausgeworfen, anschließend konnte die BitLocker-Konfiguration fortgesetzt werden.

Weiterer NachweisBelegt die Abweichung, dass eine eingelegte Windows-ISO BitLocker-Konfiguration zunächst bloc…

**Nachweis 74:** Belegt die Abweichung, dass eine eingelegte Windows-ISO BitLocker-Konfiguration zunächst blockierte.

Weiterer NachweisBelegt die Korrekturmaßnahme zur Beseitigung der BitLocker-Blockade durch startbares Medium.

**Nachweis 75:** Belegt die Korrekturmaßnahme zur Beseitigung der BitLocker-Blockade durch startbares Medium.

PIN, Verschlüsselung und Boot-Test

Der Assistent wurde mit PIN-Eingabe durchgeführt. Danach wurden nur der verwendete Speicherplatz und der neue Verschlüsselungsmodus ausgewählt. Auch hier wurde die Systemprüfung abgewählt. Der Abschluss der Verschlüsselung und die spätere PIN-Abfrage beim Boot sind nachgewiesen.

Weiterer NachweisBelegt die Auswahl des PIN-basierten TPM-Startschutzes.

**Nachweis 76:** Belegt die Auswahl des PIN-basierten TPM-Startschutzes.

Weiterer NachweisBelegt die Einrichtung einer BitLocker-Start-PIN auf W11.

**Nachweis 77:** Belegt die Einrichtung einer BitLocker-Start-PIN auf W11.

Weiterer NachweisBelegt die gewählte Verschlüsselungsstrategie für den Client.

**Nachweis 78:** Belegt die gewählte Verschlüsselungsstrategie für den Client.

Weiterer NachweisBelegt die Auswahl des aktuellen Verschlüsselungsmodus für W11.

**Nachweis 79:** Belegt die Auswahl des aktuellen Verschlüsselungsmodus für W11.

Weiterer NachweisBelegt die gewählte Startentscheidung vor der Verschlüsselung.

**Nachweis 80:** Belegt die gewählte Startentscheidung vor der Verschlüsselung.

Weiterer NachweisBelegt den erfolgreichen Abschluss der BitLocker-Verschlüsselung auf W11.

**Nachweis 82:** Belegt den erfolgreichen Abschluss der BitLocker-Verschlüsselung auf W11.

Weiterer NachweisBelegt, dass W11 nach Neustart eine BitLocker-PIN zur Entsperrung verlangt.

**Nachweis 83:** Belegt, dass W11 nach Neustart eine BitLocker-PIN zur Entsperrung verlangt.

Interpretation

W11 wurde korrekt als TPM-/PIN-Szenario behandelt. Der ISO-Zwischenfall ist als nützlicher Troubleshooting-Nachweis zu werten, weil BitLocker startbare Medien vor der Aktivierung als Risiko betrachtet.

10. Kommandozeilenverwaltung und kontrollierter Cleanup

Ziel

Zum Abschluss wurde die BitLocker-Verwaltung bewusst über Kommandozeile und PowerShell geprüft. Der Fokus lag auf Statusabfragen, Protectoren, Syntaxhilfe, sicherem Löschen freien Speicherplatzes und kontrollierter Deaktivierung/Entschlüsselung.

CMD / manage-bde

Die CMD-Seite ist gut nachgewiesen. Zunächst wurde die Hilfe von manage-bde aufgerufen. Danach folgten Statusprüfung, ein bewusst fehlerhafter Protector-Aufruf ohne Volume, Syntaxermittlung über manage-bde -protectors -?, Protector-Anzeige, WipeFreeSpace und Deaktivierung auf W11.

manage-bde -?
manage-bde -status
manage-bde -protectors
manage-bde -protectors -?
manage-bde -protectors -get C:
manage-bde -WipeFreeSpace C:
manage-bde -off C:

Weiterer NachweisBelegt den Einstieg in die Kommandozeilenverwaltung mit manage-bde.

**Nachweis 85:** Belegt den Einstieg in die Kommandozeilenverwaltung mit manage-bde.

Weiterer NachweisBelegt Statusprüfung und Syntaxermittlung bei fehlerhafter protectors-Verwendung.

**Nachweis 86:** Belegt Statusprüfung und Syntaxermittlung bei fehlerhafter protectors-Verwendung.

Weiterer NachweisBelegt Protector-Anzeige, sicheres Löschen freien Speicherplatzes und Start der Bi…

**Nachweis 88:** W11 CMD: `manage-bde -protectors -get C:`, `WipeFreeSpace C:`, `manage-bde -off C:`.

PowerShell

Auf Server2 wurde die Deaktivierung/Entschlüsselung über PowerShell gestartet. Damit ist der PowerShell-Cleanup nachgewiesen. Die in der Aufgabenstellung zusätzlich vorgesehenen PowerShell-Ausgabe-Cmdlets, etwa Get-Command -Module Bitlocker oder vollständige Get-BitLockerVolume-KeyProtector-Ausgaben, sind nicht in gleicher Tiefe als einzelne Screenshots vorhanden.

Disable-BitLocker -MountPoint "C:" -Confirm:$false

Weiterer NachweisBelegt die Deaktivierung/Entschlüsselung von BitLocker auf Server2 per PowerShell.

**Nachweis 89:** Belegt die Deaktivierung/Entschlüsselung von BitLocker auf Server2 per PowerShell.

Fachliche Grenze: Die Kommandozeilenverwaltung mit manage-bde ist direkt belegt. Die PowerShell-Verwaltung ist über den ausgeführten Deaktivierungsbefehl auf Server2 belegt, jedoch nicht vollständig für jede in der Aufgabenstellung genannte PowerShell-Abfrage einzeln nachgewiesen.

11. Troubleshooting-Casebook und Abweichungen

Die folgenden Fälle zeigen zentrale Diagnose-, Korrektur- und Ergebniszusammenhänge aus dem Arbeitsverlauf.

Fall	Symptom	Diagnose	Lösung	Fachliche Erkenntnisse
AD-Replikation nach Checkpoint	`repadmin /replsummary` meldete Fehler `8524` zwischen DC und Server1.	Checkpoint-Rücksetzung hatte erneut einen AD-Replikations-/DNS-bezogenen Folgefehler ausgelöst.	`repadmin /syncall DC /AdeP` und `repadmin /syncall SERVER1 /AdeP`; danach `0/5` Fehler.	Vor jedem neuen Arbeitsblock zuerst Replikation und SYSVOL/NETLOGON absichern.
Server2-Vertrauensstellung	Domänenanmeldung auf Server2 schlug mit Vertrauensstellungsfehler fehl.	Netzwerk und DNS/Ping funktionierten, aber der Secure Channel war defekt.	Lokale Anmeldung,`Test-ComputerSecureChannel`,`Reset-ComputerMachinePassword`, Neustart,`nltest /sc_verify`.	Erreichbarkeit beweist keine funktionierende Domänenvertrauensstellung.
DNS-Anzeige „Server: Unknown“	`nslookup` zeigte Timeouts/Unknown, löste aber Namen wie `dc.gfnlab.test` korrekt auf.	Vorwärtsauflösung funktionierte; Anzeige deutet eher auf Reverse-DNS/PTR-Thema hin.	Nicht als blockierenden Fehler behandelt, solange Forward Lookup und Domänenkommunikation funktionieren.	DNS-Ausgaben präzise interpretieren: Forward Lookup, Reverse Lookup und Secure Channel getrennt bewerten.
Dedupe-Hilfe hängt	`Get-Help Start-DedupJob -ShowWindow` löste Update-Help-Frage/Wartezustand aus.	Hilfefenster war für die praktische Aufgabe nicht erforderlich.	Direkte Nutzung des bekannten Cmdlets `Start-DedupJob -Volume "E:" -Type Optimization -Memory 50 -Cores 75`.	Ein blockierender Hilfewartezustand wurde beendet und der technische Ablauf fortgesetzt.
BitLocker-Recovery-Eingabe	Im Recovery-Prompt wurden Buchstaben nicht akzeptiert; Zahlen wurden angenommen.	Das abgefragte Recovery-Kennwort ist ein numerischer 48-stelliger Schlüssel, kein alphanumerisches Passwort.	Recovery-Konzept korrekt eingeordnet; ADUC-BitLocker-Tab zur Identifikation des passenden Recovery-Keys genutzt.	BitLocker unterscheidet zwischen Kennwort/PIN und numerischem Wiederherstellungsschlüssel.
W11-ISO blockiert BitLocker	BitLocker meldete einen startbaren Datenträger im DVD-Laufwerk.	Die eingelegte Windows-Installations-ISO wurde als bootfähiges Medium erkannt.	ISO über Hyper-V-Medienmenü ausgeworfen; danach BitLocker-Konfiguration erneut gestartet.	Vor BitLocker-Aktivierung Bootmedien entfernen, sonst kann die Systemprüfung blockieren.
`manage-bde -protectors` Syntaxfehler	Aufruf ohne Volume führte zu „Ein Volumebuchstabe ist erforderlich“.	Das Tool erwartet bei Protector-Verwaltung ein konkretes Volume, z. B.`C:`.	Hilfe mit `manage-bde -protectors -?` geprüft; danach `manage-bde -protectors -get C:` verwendet.	Der CLI-Syntaxfehler führte zur korrekten Befehlsform.
Sensible Recovery-Daten	Screenshots enthielten Recovery-Keys, Key-IDs und Protector-Informationen.	Wiederherstellungsdaten sind sicherheitsrelevant und werden nicht angezeigt.	Wiederherstellungswerte und zugehörige Kennungen werden nicht angezeigt.	Recovery-Werte werden aus Sicherheitsgründen nicht angezeigt.

Bewertung: Die Diagnose- und Korrekturkette belegt den technischen Ablauf über den Endzustand hinaus.

Ergebnis und fachliche Grenzen

Das zusätzliche Volume E: wurde eingerichtet; der Deduplizierungstest mit zehn BMP-Dateien ergab im Labor rund 457 MB beziehungsweise 99 Prozent Einsparung. BitLocker wurde auf Server2 ohne TPM sowie auf W11 mit TPM/PIN konfiguriert. Secure-Channel-, Replikations- und ISO-Probleme wurden vor beziehungsweise während der Umsetzung behoben.

Fachliche Grenze: Die konkrete erfolgreiche Eingabe des Server2-Wiederherstellungsschlüssels, jeder einzelne PowerShell-Befehl und die vollständig abgeschlossenen Entschlüsselungszustände sind nicht jeweils separat fotografiert. Wiederherstellungsschlüssel und zugehörige Kennungen werden nicht angezeigt.

Technologiebereich

Netzwerk-, Namens- und Bereitstellungsdienste

Routing, NAT, DNS, DHCP, VPN sowie MDT/WDS für vernetzte Windows-Systeme konfigurieren und prüfen.

Praxis und Ergebnis

IP-Adressierung, Routing und NAT

Private Hyper-V-Netze, statische IPv4-Konfiguration, ICMP-Regeln, RRAS-LAN-Routing und NAT nachvollziehbar verbinden.

1. Ziel des Blocks

In diesem Block wurde die IP-Adressierung des Windows-Server-Labs aufgebaut und geprüft. Der Schwerpunkt lag nicht nur auf dem Eintragen statischer IP-Adressen, sondern auf dem vollständigen Zusammenhang aus virtueller Netzsegmentierung, Routing zwischen Subnetzen und NAT für den Internetzugriff.

Netzsegmentierung Zwei private Hyper-V-Switches Berlin und Hamburg wurden erstellt. Der vorhandene externe Lab-Switch wurde unverändert weiterverwendet.

IPv4-Adressierung DC, Server1 und Server2 wurden statisch adressiert. Server1 übernimmt die Routerrolle zwischen Berlin, Hamburg und Extern.

Routing Server1 wurde mit Routing und RAS für LAN-Routing vorbereitet und als Gateway zwischen den internen Netzen verwendet.

NAT Nach NAT-Aktivierung auf der externen Schnittstelle konnte der DC 8.8.8.8 erreichen.

2. Zieltopologie und Adressplan

Die Übung verwendet mehrere virtuelle Netzsegmente. In der tatsächlichen Laborumgebung weichen einzelne IP-Adressen von der Aufgabenstellung ab. Maßgeblich ist daher die tatsächlich konfigurierte Umgebung.

System	Schnittstelle / Switch	IPv4-Adresse	Rolle
`DC`	`Berlin`	`192.168.1.200/24`	Domain Controller / DNS, Testsystem für Routing und NAT
`Server1`	`Berlin`	`192.168.1.201/24`	Router-Schnittstelle im Berlin-Netz
`Server1`	`Hamburg`	`172.16.1.1/24`	Router-Schnittstelle im Hamburg-Netz
`Server1`	`Extern` / Labornetz	`10.100.24.24/24` per DHCP	Öffentliche NAT-Schnittstelle ins Lab-/Internetnetz
`Server2`	`Hamburg`	`172.16.1.2/24`	Server im zweiten internen Subnetz

Wichtige Abweichung zur Aufgabenstellung: in der Aufgabenstellung wird an einer Stelle mit 192.168.1.1 gearbeitet. In dieser konkreten Umgebung ist die Router-Schnittstelle von Server1 im Berlin-Netz aber 192.168.1.201. Deshalb muss der Standardgateway des DC auf 192.168.1.201 zeigen.

3. Vorbereitung: Rücksetzen und Start der VMs

Vor Beginn des eigentlichen IP-Adressierungsblocks wurden die relevanten virtuellen Maschinen auf den vorhandenen Prüfpunkt zurückgesetzt. Dadurch wurde ein sauberer Ausgangszustand hergestellt.

**Hyper-V-Ausgangszustand vor dem Rücksetzen** Server3 und W11 sind sichtbar; der vorhandene Prüfpunkt dient als Ausgangspunkt für den nächsten Übungsstand.

**Server3 auf Prüfpunkt zurücksetzen** Die Rückfrage im Hyper-V-Manager bestätigt das Zurücksetzen von Server3 auf den vorherigen Prüfpunkt.

**W11 auf Prüfpunkt zurücksetzen** Die Rückfrage im Hyper-V-Manager bestätigt das Zurücksetzen von W11 auf den vorherigen Prüfpunkt.

Weiterer NachweisVMs nach dem Zurücksetzen gestartet

4. Virtuelle Switches erstellen

Im Hyper-V-Manager wurden die privaten Switches Berlin und Hamburg erstellt. Der vorhandene externe Lab-Switch wurde nicht umbenannt und nicht verändert.

Switch	Typ	Verwendung
`Berlin`	Privat	Internes Netz für DC und Server1-Berlin-Schnittstelle.
`Hamburg`	Privat	Internes Netz für Server1-Hamburg-Schnittstelle und Server2.
`externer Lab-Switch`	Extern	Vorgegebener externer Lab-Switch für Internet/NAT. Dieser Switch bleibt unverändert.

Weiterer NachweisVirtual Switch Manager geöffnet

Weiterer NachweisPrivater Switch Berlin erstellt

Weiterer NachweisPrivater Switch Hamburg erstellt

Weiterer NachweisSwitch-Übersicht mit Berlin und Hamburg

5. VMs mit Switches verbinden

Im ersten Zuordnungsschritt erhält keine VM mehrere neue Switches gleichzeitig. Die Aufgabe sieht zunächst eine klare Segmentierung vor: DC und Server1 werden mit Berlin verbunden, Server2 mit Hamburg. Weitere Server1-Schnittstellen für Hamburg und Extern werden im Routing-/NAT-Kontext ergänzt beziehungsweise verwendet.

VM	Zugeordneter Switch	Begründung
`DC`	`Berlin`	DC befindet sich im Berlin-Netz und testet später Routing sowie NAT.
`Server1`	`Berlin`	Server1 ist im Berlin-Netz erreichbar und wird später als Router genutzt.
`Server2`	`Hamburg`	Server2 befindet sich im zweiten internen Netz.

Weiterer NachweisDC mit Switch Berlin verbunden

Weiterer NachweisServer1 mit Switch Berlin verbunden

Weiterer NachweisServer2 mit Switch Hamburg verbunden

6. IPv4-Konfiguration und ICMP-Freigabe

Die Systeme wurden mit statischen IPv4-Adressen versehen. Zusätzlich wurde die eingehende Firewallregel für ICMPv4-Echoanforderungen aktiviert, damit Ping-Tests als Nachweis verwendet werden können.

System	Adapter	IP-Adresse	DNS / Gateway
`DC`	Berlin	`192.168.1.200/24`	DNS:`192.168.1.200`; Gateway später:`192.168.1.201`
`Server1`	Berlin	`192.168.1.201/24`	DNS:`192.168.1.200`
`Server1`	Hamburg	`172.16.1.1/24`	Routing-Schnittstelle für Hamburg
`Server1`	Extern	`10.100.24.24/24`	Gateway:`10.100.24.254`; DNS:`10.100.0.1`
`Server2`	Hamburg	`172.16.1.2/24`	Gateway im Zielbetrieb:`172.16.1.1`

Weiterer NachweisDC: IPv4-Adresse im Berlin-Netz

Weiterer NachweisDC: Netzwerkadapter Berlin

Weiterer NachweisDC: ICMPv4-Firewallregel aktiviert

Weiterer NachweisServer2: IPv4-Adresse im Hamburg-Netz

Weiterer NachweisServer2: ICMPv4-Firewallregel aktiviert

7. Routing und RAS / LAN-Routing

Vor der Routerkonfiguration sind nur Systeme im gleichen Subnetz erreichbar. Der DC konnte den Weg in das Hamburg-Netz zunächst nicht vollständig nutzen. Anschließend wurde auf Server1 Routing und RAS eingerichtet und LAN-Routing aktiviert.

Vor Routing/Gateway-Korrektur: ping 192.168.1.201 - erfolgreich, gleiches Berlin-Netz ping 172.16.1.1 - zunächst nicht erfolgreich ping 172.16.1.2 - zunächst nicht erfolgreich

Weiterer NachweisVortest: Hamburg-Netz vor Routing nicht erreichbar

Weiterer NachweisRouting-/RAS-Rolleninstallation erfolgreich

Weiterer NachweisRouting und RAS konfigurieren und aktivieren

Weiterer NachweisRRAS-Assistent: LAN-Routing

Weiterer NachweisServer1: drei relevante Netzwerkadapter

Gateway-Korrektur: Der DC muss als Standardgateway die Berlin-Schnittstelle von Server1 verwenden. In dieser Laborumgebung ist das 192.168.1.201, nicht 192.168.1.1.

Weiterer NachweisDC-Gateway auf 192.168.1.201 korrigiert

Weiterer NachweisNachtest: Routing zwischen Berlin und Hamburg erfolgreich

Ping vom DC	Ziel	Erwartung nach Routing	Ergebnis
`ping 192.168.1.201`	Server1 / Berlin	Erfolgreich	Erfolgreich
`ping 172.16.1.1`	Server1 / Hamburg	Erfolgreich	Erfolgreich
`ping 172.16.1.2`	Server2 / Hamburg	Erfolgreich	Erfolgreich

8. NAT und Internetzugriff

Nach dem reinen LAN-Routing wurde NAT eingerichtet, damit interne Systeme über Server1 das externe Netz erreichen können. Der Test erfolgte bewusst vor und nach NAT mit ping 8.8.8.8.

Weiterer NachweisVortest: Internet-Ping vor NAT fehlgeschlagen

Weiterer NachweisNAT als Routingprotokoll hinzufügen

Weiterer NachweisNAT-Knoten unter IPv4 vorhanden

Weiterer NachweisNAT-Schnittstelle Extern auswählen

Weiterer NachweisExtern als öffentliche NAT-Schnittstelle aktiviert

Weiterer NachweisNachtest: Internet-Ping nach NAT erfolgreich

Test	Vor NAT	Nach NAT	Bewertung
`ping 8.8.8.8` vom DC	100 % Verlust	0 % Verlust	NAT funktioniert

9. Fachliche Erkenntnisse

Beobachtung	Auswirkung	Saubere Schlussfolgerung
vorgegebene Adressen können von der tatsächlichen Laborumgebung abweichen.	Ein Standardgateway aus der Aufgabenstellung führte zunächst nicht zum tatsächlichen Router.	Vor Routingtests immer `ipconfig /all` auf dem Router prüfen und den Gateway aus der Ist-Konfiguration ableiten.
Server1 hat mehrere Rollen gleichzeitig.	Server1 ist zusätzlich Router mit mehreren Schnittstellen.	Adapter sauber benennen:`Berlin`,`Hamburg`,`Extern`. Das reduziert Verwechslungen.
Ping-Tests sind nur sinnvoll, wenn ICMP erlaubt ist.	Ohne aktivierte ICMPv4-Firewallregel kann ein korrekter Netzwerkpfad scheinbar fehlschlagen.	Vor Ping-Validierungen die eingehende Regel „Datei- und Druckerfreigabe (Echoanforderung - ICMPv4 eingehend)“ aktivieren.
NAT ist nicht identisch mit LAN-Routing.	Nach LAN-Routing sind interne Netze erreichbar, Internetzugriff funktioniert erst mit NAT.	Routing und NAT getrennt prüfen: erst interne Subnetze, dann externe Ziele wie `8.8.8.8`.

Zwischenstände: Screenshots mit falschen Zieladressen oder temporären Fehlannahmen werden nicht als Ergebnisnachweise gewertet.

Ergebnis

Die privaten Netze Berlin und Hamburg wurden angelegt, die Zielsysteme statisch adressiert und ICMP für die Diagnose freigegeben. Server1 übernahm das Routing zwischen beiden Segmenten; nach dem zunächst fehlgeschlagenen Test ermöglichte die korrigierte NAT-Konfiguration den externen Zugriff aus dem internen Netz.

Praxis und Ergebnis

DNS, IIS und bedingte Weiterleitung

Forward-/Reverse-Zonen, DNS-Registrierung, IIS-Namen, sekundäre Zonen, Zonentransfer und bedingte Weiterleitung prüfen.

1. Ziel und Ergebnis

In Block 9 wurde die interne Namensauflösung des Labs aufgebaut. DC wurde als primärer DNS-Server für gfnlab.test verwendet und stellte zusätzlich den IIS-Webserver bereit. W11 diente als Client zur Validierung. Server1 wurde als sekundärer DNS-Server und später als DNS-Server für example.test eingesetzt.

DC192.168.1.200
Primärer DNS + IIS

Server1192.168.1.201
Sekundäre Zone +example.test

W11192.168.1.204
Client für DNS- und Browsertests

Nachweis Forward-/Reverse-Lookup, CNAME, Subdomain, Zonenübertragung und bedingte Weiterleitung erfolgreich validiert.

Die Fehleranalyse umfasste IP-Konfiguration, Port 53, DNS-Dienst, Zone, Zonenübertragung und Hyper-V-Prüfpunktzustand.

2. Kontexttreuer Adressplan

Die Vorgabewerte wurden nicht blind übernommen. Maßgeblich war die tatsächliche Laborumgebung.

System	Rolle	Adresse	Hinweis
`DC`	Primärer DNS, IIS	`192.168.1.200/24`	Zone `gfnlab.test`
`Server1`	Sekundärer DNS, Zone `example.test`	`192.168.1.201/24`	Berlin-Schnittstelle; Ziel der Zonenübertragung und Weiterleitung
`W11`	Client	`192.168.1.204/24`	DNS-Server `192.168.1.200`

**DC-Ausgangszustand** DC ist mit `192.168.1.200` konfiguriert und nutzt sich selbst als DNS-Server.

3. DNS auf DC

Die DNS-Rolle wurde per PowerShell installiert, anschließend wurden die Forward-Zone gfnlab.test und die Reverse-Zone 1.168.192.in-addr.arpa angelegt.

Install-WindowsFeature -Name DNS -IncludeManagementTools Get-WindowsFeature DNS

**DNS-Rolle per PowerShell** Installation erfolgreich;`Get-WindowsFeature DNS` zeigt `Installed`.

**Forward-Lookupzone**`gfnlab.test` ist als primäre Zone vorhanden.

Weiterer NachweisReverse-Lookupzone

Weiterer NachweisReverse-Zone sichtbar

4. DNS-Suffix und automatische Registrierung

Auf DC und W11 wurde das primäre DNS-Suffix gfnlab.test gesetzt. Wichtig: Das ist kein Active-Directory-Domänenbeitritt. Die Systeme bleiben in WORKGROUP, erhalten aber vollständige DNS-Namen wie dc.gfnlab.test und w11.gfnlab.test.

Technischer Zusammenhang: Für diese Aufgabe ist das DNS-Suffix ausreichend. Ein Domänenbeitritt wäre eine andere Zielsetzung und war nicht nötig.

Weiterer NachweisDC DNS-Suffix

Weiterer NachweisW11 DNS-Suffix

Weiterer NachweisA-Record DC

Weiterer NachweisClientprüfung

5. DNS-Records und IIS-Test

Für die praktische Webserverprüfung wurden ein A-Record, ein CNAME und eine Subdomain erstellt. Danach wurde die IIS-Rolle installiert und vom Client getestet.

Name	Typ	Ziel
`www.gfnlab.test`	A	`192.168.1.200`
`intranet.gfnlab.test`	CNAME	`dc.gfnlab.test`
`www.sub.gfnlab.test`	A in Subdomain	`192.168.1.200`

Weiterer NachweisA-Record www

Weiterer NachweisCNAME intranet

Weiterer NachweisSubdomain

Weiterer NachweisIIS installiert

Weiterer NachweisCNAME-Auflösung

Weiterer NachweisBrowserprüfung

Weiterer NachweisSubdomain im Browser

6. Server1 als sekundärer DNS

Server1 wurde als zweiter DNS-Server vorbereitet. Die Zone gfnlab.test wurde dort als sekundäre Zone eingerichtet. Eine sekundäre Zone ist eine Kopie der primären Zone und wird nicht direkt auf dem sekundären Server bearbeitet.

Install-WindowsFeature -Name DNS -IncludeManagementTools Get-WindowsFeature DNS

Weiterer NachweisDNS-Rolle auf Server1

Weiterer NachweisSekundäre Zone

Wichtig: Neue Einträge werden in dieser Zone auf Server1 nicht direkt erstellt. Änderungen gehören auf den Masterserver DC und werden anschließend per Zonenübertragung repliziert.

7. Fehleranalyse und Korrektur

Beim ersten Versuch konnte Server1 die sekundäre Zone nicht laden. Die Analyse zeigte, dass der Masterserver 192.168.1.200 nicht erreichbar war. Die Ursache war kein falscher DNS-Eintrag, sondern der falsche Hyper-V-Prüfpunkt beziehungsweise der dadurch falsche Netzwerkzustand.

Root Cause: Der allgemeine Prüfpunkt Basis enthielt für Server1 nicht die benötigte Netzwerkkartenstruktur. Für diesen Block musste der spezifische Server1-Prüfpunkt mit den Adaptern Berlin,Hamburg und Extern verwendet werden.

Weiterer NachweisZone nicht geladen

Weiterer NachweisMasterserver nicht erreichbar

Weiterer NachweisServer1 mit drei Adaptern

Weiterer NachweisHyper-V-Prüfpunkt

Nach Korrektur wurde die Zonenübertragung auf dem DC für Server1 unter der tatsächlichen IP 192.168.1.201 erlaubt.

Weiterer NachweisVerbindung zu DC wieder möglich

Weiterer NachweisZonenübertragung erlaubt

Weiterer NachweisSekundäre Zone geladen

Weiterer NachweisValidierung per PowerShell

8. example.test und bedingte Weiterleitung

Auf Server1 wurde zusätzlich eine primäre Zone example.test erstellt. DC erhielt danach eine bedingte Weiterleitung für genau diesen Namensraum auf Server1. Dadurch beantwortet DC Anfragen für gfnlab.test selbst und leitet Anfragen für example.test gezielt an Server1 weiter.

Weiterer NachweisZone example.test

Weiterer Nachweiswww.example.test

Weiterer NachweisBedingte Weiterleitung

Weiterer NachweisDC löst example.test auf

Weiterer NachweisClienttest nslookup

Weiterer NachweisBrowser-Finaltest

9. Fachliche Erkenntnisse

Erkenntnis	Auswirkung	Regel für Folgeblöcke
vorgegebene IP-Adressen nicht ungeprüft übernehmen.	Für Server1 war `192.168.1.201` relevant.	Vor DNS-/Routing-Konfiguration immer `ipconfig /all` prüfen.
Primäres DNS-Suffix ist kein Domänenbeitritt.	FQDNs funktionieren, obwohl die Systeme in `WORKGROUP` bleiben.	DNS-Suffix, AD-Domäne und Arbeitsgruppe getrennt prüfen.
Sekundäre Zonen sind nicht direkt beschreibbar.	Neue Einträge gehören in die primäre Zone auf DC.	Änderungen am Master durchführen und per Zonenübertragung replizieren lassen.
Prüfpunkte sind Teil der Ausgangskonfiguration.	Der falsche Basis-Prüfpunkt verursachte fehlende Server1-Netzwerkkarten.	Vor jedem Tag prüfen, welcher Prüfpunkt den fachlich benötigten Zustand enthält.
DNS-Fehler systematisch eingrenzen.	Der Fehler sah zunächst wie DNS aus, war aber ein Netzwerk-/Prüfpunktproblem.	Reihenfolge: IP -> Ping -> Port 53 -> DNS-Dienst -> Zone -> Lookup.

ipconfig /all route print -4 ping <Ziel-IP> Test-NetConnection <DNS-Server-IP> -Port 53 Get-Service DNS Get-DnsServerZone Resolve-DnsName <Name> -Server <DNS-Server-IP>

Ergebnis

Forward- und Reverse-Zonen, DNS-Suffixe, Host-/Alias-Einträge, IIS-Auflösung, sekundäre Zone und Zonentransfer wurden eingerichtet. Ein falscher Prüfpunkt und fehlende Netzwerkkarten auf Server1 wurden erkannt und korrigiert; anschließend funktionierte die bedingte Weiterleitung für example.test.

Praxis und Ergebnis

DHCP und IP-Adressverwaltung

DHCP-Bereiche, Ausschlüsse, Reservierung, MAC-Filter, Multicast und PowerShell-Konfiguration praktisch verwalten.

1. Ziel und Ergebnis

In Block 10 wurde der Server DC als DHCP-Server aufgebaut und für mehrere Szenarien der IP-Adressvergabe verwendet. Die Übung deckt den Kern der IPv4-Adressverwaltung ab: dynamische Adresspools, Ausschlüsse, Reservierungen, Server- und Bereichsoptionen, Multicastbereiche, DHCP-Filter sowie die Verwaltung per PowerShell.

DHCP-ServerDC / 192.168.1.200
Rolle installiert, Dienst geprüft, Konsole validiert.

ClientW11 / MAC 00-15-5D-18-08-05
DHCP-Lease, Reservierung und Filterverhalten getestet.

Bereiche192.168.1.0/24,192.168.2.0/24,192.168.3.0/24
Bereiche erstellt, aktiviert und geprüft.

Nachweis GUI-Konfiguration, PowerShell-Prüfung und Client-Ergebnis sind dokumentiert.

DHCP wurde als Administrationsprozess mit Validierung, Fehlerwirkung und Prüfung der tatsächlichen IP-Umgebung bearbeitet.

2. Ausgangslage und Prüfpunktlogik

Vor Tag 10 wurden die virtuellen Maschinen auf den Prüfpunkt Basis zurückgesetzt. Dadurch gingen die Konfigurationen aus Tag 9 planmäßig verloren. Für diese Aufgabe war das korrekt, weil Tag 10 mit einem definierten Ausgangszustand beginnt.

Ausgangszustand: Die Netzwerkkarten wurden nach dem Rücksprung geprüft. Bei Server1 war erkennbar, dass die Netzwerkkarte wieder auf Privat steht. Für Block 10 ist primär DC und W11 relevant; die DHCP-Konfiguration wurde auf DC durchgeführt.

Vorbereitung / Prüfpunkt Hyper-V-Ausgangslage: alle fünf VMs (DC, Server1, Server2, Server3, W11) laufen; der Prüfpunkt Basis ist sichtbar.

Vorbereitung / Prüfpunkt Warnhinweis beim Anwenden des Prüfpunkts Basis; der aktuelle VM-Status geht verloren.

Vorbereitung / Netzwerkadapter Kontrolle der Hyper-V-Einstellungen von Server1 nach dem Basiszustand: Netzwerkkarte steht auf Privat.

Weiterer NachweisDC-Ausgangszustand nach Basis: statische IPv4-Adresse 192.168.1.200/24 und DNS-Server 192.168…

Ausgangszustand DC-Ausgangszustand nach Basis: statische IPv4-Adresse 192.168.1.200/24 und DNS-Server 192.168.1.200.

System	Funktion in Block 10	Relevante Adresse / Information
`DC`	DHCP-Server, DNS-Server für W11	`192.168.1.200/24`
`W11`	DHCP-Client und Testsystem	MAC `00-15-5D-18-08-05`; Lease `192.168.1.50`; Reservierung `192.168.1.70`
`Server1/2/3`	Für Block 10 nicht zentral	Nach Basis-Rücksprung geprüft, aber nicht Hauptgegenstand dieser DHCP-Übung.

3. DHCP-Rolle installieren und nachkonfigurieren

Die DHCP-Rolle wurde über den Server-Manager installiert. Danach wurde die Post-Install-Konfiguration ausgeführt, wodurch die DHCP-Verwaltungsgruppen angelegt wurden. Anschließend wurde der Dienstzustand geprüft.

Weiterer NachweisInstallation der Rolle DHCP-Server über den Server-Manager; Installationsauswahl wird bestätigt.

Weiterer NachweisDHCP-Server-Rolle wurde erfolgreich installiert; Nachkonfiguration ist erforderlich.

Weiterer NachweisDHCP-Konfigurations-Assistent nach der Installation: Beschreibung der anzulegenden Sicherheit…

10.2 DHCP-Nachkonfiguration DHCP-Konfigurations-Assistent nach der Installation: Beschreibung der anzulegenden Sicherheitsgruppen.

Weiterer NachweisDHCP-Nachkonfiguration abgeschlossen; DHCP-Sicherheitsgruppen wurden erstellt.

Get-Service DHCPServer

Weiterer NachweisPowerShell-Prüfung: Dienst DHCPServer läuft.

Weiterer NachweisDHCP-Konsole geöffnet; IPv4-Struktur auf dem Server dc ist vorhanden.

4. IPv4-Bereiche, Ausschlüsse und Gruppierung

4.1 Bereich 1

Bereich 1 stellt Adressen im Netz 192.168.1.0/24 bereit. Der Pool wurde auf 192.168.1.50 bis 192.168.1.120 begrenzt. Der Ausschluss 192.168.1.80 bis 192.168.1.90 verhindert, dass diese Adressen automatisch vergeben werden. Die Leasedauer wurde auf 7 Tage gesetzt.

Weiterer NachweisBereichserstellungs-Assistent: Bereich 1 wird benannt.

Weiterer NachweisBereich 1: Adresspool 192.168.1.50 bis 192.168.1.120 mit /24-Netzmaske.

Weiterer NachweisBereich 1: Ausschlussbereich 192.168.1.80 bis 192.168.1.90 wird eingetragen.

Weiterer NachweisBereich 1: Leasedauer auf 7 Tage gesetzt.

Weiterer NachweisBereich 1: DHCP-Optionen werden bewusst später konfiguriert.

Weiterer NachweisBereich 1 ist in der DHCP-Konsole angelegt; Struktur mit Adresspool, Adressleases, Reservieru…

10.3.1a Bereich 1 Bereich 1 ist in der DHCP-Konsole angelegt; Struktur mit Adresspool, Adressleases, Reservierungen und Optionen sichtbar.

Weiterer NachweisPowerShell-Kontrolle: Bereich 1 existiert zunächst im Status Inactive mit Pool 192.168.1.50-1…

10.3.1a Validierung PowerShell-Kontrolle: Bereich 1 existiert zunächst im Status Inactive mit Pool 192.168.1.50-192.168.1.120.

4.2 Bereich 2

Bereich 2 wurde für das Netz 192.168.2.0/24 angelegt. Der Pool umfasst 192.168.2.20 bis 192.168.2.30. Es wurden keine Ausschlüsse gesetzt und die Leasedauer blieb im Standard.

Weiterer NachweisBereichserstellungs-Assistent: Bereich 2 wird benannt.

Weiterer NachweisBereich 2: Adresspool 192.168.2.20 bis 192.168.2.30 mit /24-Netzmaske.

Weiterer NachweisBereich 2: keine Ausschlüsse konfiguriert, Standardeinstellung übernommen.

Weiterer NachweisBereich 2: DHCP-Optionen werden bewusst später konfiguriert.

Weiterer NachweisDHCP-Konsole zeigt Bereich 1 und Bereich 2 unter IPv4.

Weiterer NachweisPowerShell-Kontrolle: Bereich 1 und Bereich 2 sind aktiv; Bereich 2 nutzt die Standard-Leased…

10.3.1b Validierung PowerShell-Kontrolle: Bereich 1 und Bereich 2 sind aktiv; Bereich 2 nutzt die Standard-Leasedauer von 8 Tagen.

4.3 Bereichsgruppierung Gruppe 1

Beide Bereiche wurden testweise zur Bereichsgruppierung Gruppe 1 zusammengeführt und anschließend wieder aus der Gruppierung entfernt. Damit wurde die Verwaltung von Superscopes/Bereichsgruppierungen praktisch nachvollzogen, ohne die Bereiche selbst zu löschen.

Weiterer NachweisAssistent zur Bereichsgruppierung: Gruppe 1 wird benannt.

Weiterer NachweisFertigstellen der Bereichsgruppierung Gruppe 1 mit Bereich 1 und Bereich 2.

Weiterer NachweisDHCP-Konsole: Gruppe 1 enthält Bereich 1 und Bereich 2.

Weiterer NachweisWarnmeldung beim Entfernen eines Bereichs aus Gruppe 1; der Bereich wird nicht gelöscht, sond…

10.3.1b Bereichsgruppierung Warnmeldung beim Entfernen eines Bereichs aus Gruppe 1; der Bereich wird nicht gelöscht, sondern nur aus der Gruppierung entfernt.

Weiterer NachweisGruppe 1 nach Entfernen eines Bereichs; mindestens ein Bereich ist noch enthalten.

Weiterer NachweisBereich 1 und Bereich 2 sind wieder auf IPv4-Ebene sichtbar und aktiv.

5. Multicastbereich

Für Übung 10.3.1c wurde ein Multicastbereich mit dem Namen Multicast 1 erstellt. Der Bereich nutzt die Adressen 224.1.1.1 bis 224.1.1.9 und eine TTL von 30. Der Bereich wurde aktiviert.

Weiterer NachweisAssistent für Multicastbereiche: Multicastbereich Multicast 1 wird benannt.

Weiterer NachweisMulticastbereich: Adressbereich 224.1.1.1 bis 224.1.1.9 mit TTL 30.

Weiterer NachweisMulticastbereich wird im Assistenten aktiviert.

Weiterer NachweisDHCP-Konsole zeigt Multicastbereich Multicast 1 aktiv neben Bereich 1 und Bereich 2.

Einordnung: Multicastbereiche unterscheiden sich von normalen IPv4-DHCP-Bereichen. Sie dienen nicht der normalen Client-IP-Vergabe, sondern der Verwaltung von Multicastadressen.

6. Serveroptionen und W11 als DHCP-Client

Auf Serverebene wurde Option 006 DNS-Server mit dem Wert 192.168.1.200 gesetzt. Diese Option wird an Clients übergeben, sofern sie nicht durch Bereichsoptionen überschrieben wird.

Weiterer NachweisServeroption 006 DNS-Server wird mit 192.168.1.200 gesetzt; dies ist die tatsächliche DNS-/DH…

10.3.2 Serveroptionen Serveroption 006 DNS-Server wird mit 192.168.1.200 gesetzt; dies ist die tatsächliche DNS-/DHCP-Adresse des DC.

Weiterer NachweisDHCP-Konsole: Serveroption 006 DNS-Server ist mit dem Wert 192.168.1.200 eingetragen.

W11 wurde anschließend von statischer IP-Konfiguration auf automatische DHCP-Konfiguration umgestellt. Der erste Lease aus Bereich 1 war 192.168.1.50. Dabei wurden DHCP-Server und DNS-Server korrekt als 192.168.1.200 angezeigt.

Weiterer NachweisW11-Netzwerkeinstellungen: IP- und DNS-Zuweisung erfolgen automatisch per DHCP; Lease 192.168…

10.3.2 W11 DHCP W11-Netzwerkeinstellungen: IP- und DNS-Zuweisung erfolgen automatisch per DHCP; Lease 192.168.1.50 und DNS 192.168.1.200 sichtbar.

Weiterer NachweisW11 ipconfig /all: DHCP-Lease 192.168.1.50, DHCP-Server 192.168.1.200, DNS-Server 192.168.1.2…

10.3.2 W11 Validierung W11 ipconfig /all: DHCP-Lease 192.168.1.50, DHCP-Server 192.168.1.200, DNS-Server 192.168.1.200 und MAC 00-15-5D-18-08-05.

Parameter	Ergebnis auf W11	Bedeutung
IPv4-Adresse	`192.168.1.50`	Erster gültiger Lease aus Bereich 1.
DHCP-Server	`192.168.1.200`	DC vergibt die Adresse.
DNS-Server	`192.168.1.200`	Serveroption 006 wurde an W11 übertragen.
MAC-Adresse	`00-15-5D-18-08-05`	Für Reservierung und Filter verwendet.

7. Reservierung für W11

Für W11 wurde in Bereich 1 eine Reservierung angelegt. Die MAC-Adresse 00-15-5D-18-08-05 wurde an die Adresse 192.168.1.70 gebunden. Nach ipconfig /release und ipconfig /renew erhielt W11 die reservierte Adresse.

Weiterer NachweisReservierung für W11 wird in Bereich 1 vorbereitet: IP 192.168.1.70 und MAC 00-15-5D-18-08-05.

Weiterer NachweisDHCP-Konsole: Reservierung 1 für 192.168.1.70 wurde angelegt.

Weiterer NachweisDHCP-Konsole: Reservierung 1 ist unter Reservierungen sichtbar und bindet 192.168.1.70 an W11.

Weiterer NachweisW11 nach ipconfig /release und ipconfig /renew: reservierte Adresse 192.168.1.70 wird bezogen.

ipconfig /release ipconfig /renew ipconfig

Validierung: Der Wechsel von 192.168.1.50 auf 192.168.1.70 bestätigt, dass die DHCP-Reservierung korrekt greift.

8. DHCP-Verweigern-Filter

Für Übung 10.4 wurde die MAC-Adresse von W11 in den DHCP-Filter Verweigern eingetragen. Danach konnte W11 keinen gültigen DHCP-Lease mehr erhalten und fiel auf eine APIPA-Adresse zurück.

Weiterer NachweisFilter Verweigern: MAC-Adresse 00-15-5D-18-08-05 von W11 wurde mit Beschreibung W11 verweiger…

10.4 Filter Filter Verweigern: MAC-Adresse 00-15-5D-18-08-05 von W11 wurde mit Beschreibung W11 verweigern eingetragen.

Weiterer NachweisW11 nach DHCP-Verweigerung: APIPA-Adresse 169.254.253.209 zeigt, dass kein gültiger DHCP-Leas…

10.4 Filtertest W11 nach DHCP-Verweigerung: APIPA-Adresse 169.254.253.209 zeigt, dass kein gültiger DHCP-Lease vergeben wurde.

Nachweis	Bedeutung
Filter `Verweigern` mit MAC `00-15-5D-18-08-05`	W11 wird gezielt blockiert.
`ipconfig /release`/`ipconfig /renew` auf W11	Client versucht, eine neue DHCP-Adresse zu beziehen.
Ergebnis `169.254.253.209`	DHCP wurde verweigert; Windows nutzt APIPA.

Betriebsrelevanter Hinweis: Ein Verweigern-Filter muss vor weiteren DHCP-Tests entfernt/deaktiviert werden, sofern W11 wieder regulär eine Adresse erhalten soll. In diesem Block wurde der Zustand später durch das Zurücksetzen auf Basis bereinigt.

9. PowerShell-Aufgabe 10.6.4

Die letzte Aufgabe wurde per PowerShell umgesetzt. Dabei wurde ein dritter Bereich im separaten Netz 192.168.3.0/24 erstellt. Die Adresse 192.168.3.200 kollidiert nicht mit 192.168.1.200, weil sie in einem anderen Subnetz liegt.

Add-DhcpServerv4Scope -Name "Bereich 3" -StartRange 192.168.3.200 -EndRange 192.168.3.220 -SubnetMask 255.255.255.0 Set-DhcpServerv4Scope -ScopeId 192.168.3.0 -StartRange 192.168.3.200 -EndRange 192.168.3.230 Add-DhcpServerv4ExclusionRange -ScopeId 192.168.3.0 -StartRange 192.168.3.222 -EndRange 192.168.3.222 Set-DhcpServerv4OptionValue -ScopeId 192.168.3.0 -DnsServer 8.8.8.8 -Router 192.168.3.254 -Force Get-DhcpServerv4Scope Get-DhcpServerv4Scope -ScopeId 192.168.3.0 Get-DhcpServerv4ExclusionRange -ScopeId 192.168.3.0 Get-DhcpServerv4OptionValue -ScopeId 192.168.3.0

Weiterer NachweisPowerShell-Umsetzung 10.6.4: Bereich 3 erstellt, erweitert, Ausschluss gesetzt und Bereichsop…

10.6.4 PowerShell PowerShell-Umsetzung 10.6.4: Bereich 3 erstellt, erweitert, Ausschluss gesetzt und Bereichsoptionen für Router/DNS validiert.

Weiterer NachweisDHCP-Konsole: Bereich 3 ist sichtbar und aktiv neben Bereich 1, Bereich 2 und Multicastbereich.

Weiterer NachweisAbschlussansicht der DHCP-Konsole nach Bereich 3: DHCP-Konfigurationen sind in der MMC sichtbar.

Element	Konfiguration	Nachweis
Bereich 3	`192.168.3.200` bis `192.168.3.230`, Maske `255.255.255.0`	PowerShell und DHCP-Konsole
Ausschluss	`192.168.3.222`	`Get-DhcpServerv4ExclusionRange`
Option 003 Router	`192.168.3.254`	`Get-DhcpServerv4OptionValue`
Option 006 DNS-Server	`8.8.8.8`	`Get-DhcpServerv4OptionValue`

Wichtige Unterscheidung: Die DNS-Serveroption 192.168.1.200 aus Übung 10.3.2 ist eine Serveroption. Die Werte 8.8.8.8 und 192.168.3.254 aus 10.6.4 sind Bereichsoptionen für 192.168.3.0/24.

10. Fachliche Erkenntnisse

Erkenntnis	Auswirkung	Regel für Folgeblöcke
Prüfpunkte verändern den technischen Zustand vollständig.	Tag-9-Konfigurationen gingen durch Rücksprung auf `Basis` planmäßig verloren.	Vor jedem Arbeitsblock Ausgangszustand, VM-Prüfpunkt und Netzwerkkarten prüfen.
DHCP-Bereiche müssen aktiv sein.	Ein erstellter Bereich kann zunächst `Inactive` sein und vergibt dann keine Adressen.	Nach Erstellung immer `Get-DhcpServerv4Scope` oder GUI-Status prüfen.
Ausschluss ist nicht Reservierung.	Ausschlüsse verhindern Vergabe; Reservierungen binden eine IP an eine MAC.	Begriffe fachlich trennen und die zugehörigen Funktionen getrennt testen.
Serveroptionen und Bereichsoptionen wirken unterschiedlich.	Serveroptionen gelten global; Bereichsoptionen überschreiben gezielt in einem Scope.	Bei DHCP-Optionen immer Ebene und ScopeId angeben.
APIPA ist ein Fehlersignal, keine normale Labor-IP.	`169.254.x.x` zeigte korrekt, dass der DHCP-Filter W11 blockiert.	APIPA nur als Fehler-/Testnachweis verwenden, nicht als gültige Lab-Adresse.
Vorgabewerte müssen mit dem realen Lab abgeglichen werden.	`192.168.3.200` war unkritisch, weil es nicht im gleichen Subnetz wie `192.168.1.200` liegt.	Vor IP-Änderungen immer Subnetz, bestehende Hosts und Zweck der Adresse prüfen.

Ergebnis

DHCP-Rolle, Bereiche, Ausschlüsse, Reservierung, Multicast, Serveroptionen und MAC-Verweigern-Filter wurden eingerichtet und mit dem Windows-11-Client geprüft. Das erwartete APIPA-Verhalten nach der Sperre und ein zusätzlicher Bereich per PowerShell sind im Ablauf enthalten; danach wurde auf den Basiszustand zurückgesetzt.

Praxis und Ergebnis

VPN und Remotezugriff

RRAS-VPN, Benutzerfreigaben, Netzadapter, Port/GRE-Abhängigkeiten, Adresspool und UNC-Zugriff prüfen.

1. Ziel, Ergebnis und Laborkontext

Block 14 bildet ein typisches Remotezugriffsszenario ab: Ein Windows-11-Client befindet sich logisch außerhalb des Unternehmensnetzes und verbindet sich per VPN mit Server1. Nach erfolgreicher Einwahl soll der Client auf eine Freigabe im Unternehmensnetz zugreifen können.

VPN-ServerServer1 mit zwei Netzwerkkarten:Privat und VPN.

Externe SimulationW11 mit 172.16.0.11/16 am Switch VPN.

ZugriffssteuerungBenutzer1 erlaubt,Benutzer2 nicht erlaubt.

Ergebnis\\DC\Druckvorlagen über VPN erreichbar.

Gesamtergebnis: Die VPN-Verbindung mit GFNLAB\benutzer1 wurde erfolgreich hergestellt. Der Client erhielt nach Korrektur des RRAS-Adresspools die VPN-Adresse 192.168.1.101 und konnte auf die Freigabe \\DC\Druckvorlagen zugreifen. Der Negativtest mit benutzer2 schlug erwartungsgemäß fehl.

Diagnoseeinordnung: Der Ablauf enthält bewusste Fehleranalyse. Der zunächst fehlgeschlagene Zugriff, der nicht erreichbare Port 1723 und die anfängliche APIPA-Adresse werden als fachlich relevante Diagnosepunkte dokumentiert.

2. 14.1 - Netzwerk- und Server1-Vorbereitung

Zu Beginn wurde Server1 netzwerktechnisch für die spätere VPN-Serverrolle vorbereitet. Die vorhandene Verbindung zum internen Domänennetz blieb über den Switch Privat bestehen. Zusätzlich wurde auf dem Hyper-V-Host ein privater Switch VPN erstellt und Server1 über eine zweite Netzwerkkarte daran angeschlossen.

Bestehende Netzwerkkarte auf Server1 als Privat geführt.
Privaten Hyper-V-Switch VPN erstellt.
Zweite Netzwerkkarte an Server1 hinzugefügt und mit VPN verbunden.
VPN-Adapter auf Server1 mit 172.16.0.1 und 255.255.0.0 konfiguriert.
Per ipconfig geprüft, dass Server1 intern und extern getrennte Schnittstellen besitzt.

14.1Server1: interner Adapter Privat Server1: vorhandene Netzwerkkarte Privat im Domänennetz.

14.1Hyper-V: privater Switch VPN Hyper-V: privater virtueller Switch VPN angelegt.

14.1Server1: zweite Netzwerkkarte am VPN-Switch Server1: zweite Netzwerkkarte mit virtuellem Switch VPN.

Weiterer NachweisServer1: beide Adapter sichtbar

Weiterer NachweisServer1: VPN-Adapter 172.16.0.1/16

Weiterer NachweisServer1: ipconfig-Prüfung

3. Server1: Rollenbereinigung und RRAS-Installation

Server1 war vor Block 14 noch als zusätzlicher Domänencontroller eingebunden. Gemäß Aufgabenstellung wurde Server1 zum normalen Mitgliedsserver zurückgestuft. Anschließend wurden die nicht mehr benötigten Rollen AD-Domain-Services und DNS entfernt. Danach wurden die Rollen für Remotezugriff und Routing installiert.

Test-ADDSDomainControllerUninstallation `
-LocalAdministratorPassword (ConvertTo-SecureString '[Laborkennwort nicht angezeigt]' -AsPlainText -Force) Uninstall-ADDSDomainController `
-LocalAdministratorPassword (ConvertTo-SecureString '[Laborkennwort nicht angezeigt]' -AsPlainText -Force) Get-WindowsFeature | Where-Object {$PSItem.InstallState -eq "Installed"}
Uninstall-WindowsFeature -Name AD-Domain-Services, DNS
Restart-Computer Install-WindowsFeature RemoteAccess
Install-WindowsFeature Routing -IncludeManagementTools
rrasmgmt.msc

Einordnung: Die Rückstufung verhindert, dass Server1 gleichzeitig als Domänencontroller und VPN-/RRAS-Server in einem unklaren Rollenmix weiterläuft. Für die Übung soll Server1 als Mitgliedsserver den Remotezugriff bereitstellen.

Weiterer NachweisServer1: Rückstufung per PowerShell ISE

Weiterer NachweisServer1: AD DS und DNS entfernt

Weiterer NachweisServer1: Rollenprüfung nach Entfernung

Weiterer NachweisServer1: RemoteAccess und Routing installiert

4. 14.2 - RRAS als VPN-Server konfigurieren

In der Routing-und-RAS-Konsole wurde Server1 als VPN-Server aktiviert. Verwendet wurde eine benutzerdefinierte Konfiguration mit dem Dienst VPN-Zugriff. Nach Abschluss des Assistenten wurde der Dienst gestartet.

rrasmgmt.msc geöffnet.
Server1 über „Routing und RAS konfigurieren und aktivieren“ eingerichtet.
Konfigurationsmodus Benutzerdefinierte Konfiguration gewählt.
Option VPN-Zugriff aktiviert.
Dienst Routing und Remotezugriff gestartet.

Beobachtung: Während der RRAS-Aktivierung erschienen Hinweise zur AD-Registrierung und zu Firewallports. Diese wurden im Verlauf durch Dienst-, Port- und Firewallprüfungen aufgegriffen.

Weiterer NachweisRRAS: benutzerdefinierte Konfiguration

Weiterer NachweisRRAS: VPN-Zugriff ausgewählt

Weiterer NachweisRRAS: Dienst erfolgreich gestartet

5. AD-Benutzer, Einwahlrecht und Freigabe

Auf dem Domänencontroller wurden zwei OUs erstellt:VPN-Erlauben und VPN-Verboten. Darin wurden Benutzer1 und Benutzer2 angelegt. Nur Benutzer1 erhielt in den AD-Kontoeigenschaften unter „Einwählen“ die Berechtigung Zugriff gestatten.

New-ADOrganizationalUnit -Name VPN-Erlauben -Path "DC=gfnlab,DC=test"
New-ADUser `
-Name "Benutzer1" `
-UserPrincipalName benutzer1@gfnlab.test `
-SamAccountName benutzer1 `
-Enabled 1 `
-AccountPassword (ConvertTo-SecureString -AsPlainText '[Laborkennwort nicht angezeigt]' -Force) `
-Path "OU=VPN-Erlauben,DC=gfnlab,DC=test" `
-ChangePasswordAtLogon 0 New-ADOrganizationalUnit -Name VPN-Verboten -Path "DC=gfnlab,DC=test"
New-ADUser `
-Name "Benutzer2" `
-UserPrincipalName benutzer2@gfnlab.test `
-SamAccountName benutzer2 `
-Enabled 1 `
-AccountPassword (ConvertTo-SecureString -AsPlainText '[Laborkennwort nicht angezeigt]' -Force) `
-Path "OU=VPN-Verboten,DC=gfnlab,DC=test" `
-ChangePasswordAtLogon 0

Zusätzlich wurde auf DC eine neue Datenpartition vorbereitet, der Ordner F:\Druckvorlagen erstellt und als SMB-Freigabe bereitgestellt. Benutzer1 und Benutzer2 erhielten Leserechte auf die Freigabe; die NTFS-Grundrechte über die Domänenbenutzer wurden geprüft.

Resize-Partition -DriveLetter C -Size 100GB
New-Partition -DiskNumber 0 -DriveLetter F -UseMaximumSize
Format-Volume -DriveLetter F -FileSystem NTFS -NewFileSystemLabel "Daten"
New-Item -Path F:\ -Name Druckvorlagen -ItemType Directory
New-SmbShare -Name Druckvorlagen -Path F:\Druckvorlagen `
-ReadAccess gfnlab.test\Benutzer1, gfnlab.test\Benutzer2

Weiterer NachweisDC: OUs und Benutzer per PowerShell

Weiterer NachweisAD: Benutzer1 erhält Einwahlrecht

Weiterer NachweisDC: Partition, Ordner und SMB-Freigabe

Weiterer NachweisDC: Datei in Druckvorlagen

Weiterer NachweisDC: Freigabeberechtigungen

Weiterer NachweisDC: NTFS-Berechtigungen

6. W11 als externer VPN-Client

Der Client W11 wurde zunächst im Unternehmensnetz mit Benutzer1 und Benutzer2 angemeldet, damit die Domänenprofile lokal zwischengespeichert wurden. Anschließend wurde W11 logisch nach außen verlegt, indem der virtuelle Switch auf VPN gesetzt und die IP-Konfiguration 172.16.0.11/16 ohne Gateway und ohne DNS eingetragen wurde.

GFNLAB\benutzer1 an W11 angemeldet und wieder abgemeldet.
GFNLAB\benutzer2 an W11 angemeldet und wieder abgemeldet.
W11 auf die externe IP 172.16.0.11/255.255.0.0 gesetzt.
VPN02 für Benutzer2 mit Zielserver 172.16.0.1 eingerichtet.
VPN01 für Benutzer1 mit Zielserver 172.16.0.1 eingerichtet.

Negativtest: Der fehlgeschlagene VPN-Aufbau mit Benutzer2 ist kein Projektfehler. Er bestätigt, dass die Einwahlberechtigung aus dem AD greift und nicht jeder Domänenbenutzer automatisch VPN-Zugriff erhält.

Weiterer NachweisW11: Benutzer1 zwischengespeichert

Weiterer NachweisW11: Benutzer2 zwischengespeichert

Weiterer NachweisW11: externe IP-Konfiguration

Weiterer NachweisW11: VPN02 für Benutzer2

Weiterer NachweisW11: Benutzer2-Verbindung schlägt fehl

Weiterer NachweisW11: VPN01 für Benutzer1

Weiterer NachweisW11: erster Benutzer1-Versuch fehlerhaft

7. Troubleshooting und Korrekturen

Der erste Verbindungsaufbau mit Benutzer1 war nicht sofort vollständig funktionsfähig. Deshalb wurde die Fehleranalyse in mehreren Schichten durchgeführt: ICMP-Erreichbarkeit, TCP-Port 1723, RRAS-Dienststatus, Firewallregeln und IP-Adressvergabe für VPN-Clients.

7.1 Port 1723 und Firewallregeln

W11 konnte Server1 unter 172.16.0.1 per Ping erreichen, der TCP-Test auf Port 1723 schlug zunächst fehl. Auf Server1 lief der RemoteAccess-Dienst und Port 1723 lauschte. Danach wurden explizite Firewallregeln für PPTP und GRE gesetzt.

# W11
Test-NetConnection 172.16.0.1 -Port 1723 # Server1
Get-Service RemoteAccess
netstat -ano | findstr ":1723" New-NetFirewallRule -DisplayName "VPN PPTP TCP 1723 Inbound" `
-Direction Inbound -Protocol TCP -LocalPort 1723 -Action Allow -Profile Any New-NetFirewallRule -DisplayName "VPN PPTP GRE Inbound" `
-Direction Inbound -Protocol 47 -Action Allow -Profile Any

7.2 RRAS-Adresspool

Nach dem ersten erfolgreichen VPN-Aufbau erhielt der Client zunächst eine APIPA-Adresse 169.254.x.x. Das zeigte, dass der Tunnel grundsätzlich zustande kam, aber keine passende RAS-Clientadresse bereitgestellt wurde. Danach wurde im RRAS-Server ein statischer IPv4-Adresspool 192.168.1.100 bis 192.168.1.149 eingetragen und der interne Adapter Privat ausgewählt.

Abweichung im Ablauf: Der statische RRAS-Adresspool wurde nachträglich ergänzt, weil im PDF-Ablauf eine Seite zunächst übersprungen wurde. Nach dem Nachholen dieses Schritts erhielt der VPN-Client eine gültige Adresse aus dem Pool.

Weiterer NachweisW11: Port 1723 zunächst nicht erreichbar

Weiterer NachweisServer1: RemoteAccess läuft und Port 1723 lauscht

Weiterer NachweisServer1: Firewallregeln für PPTP/GRE

Weiterer NachweisW11: Port 1723 nach Korrektur erreichbar

Weiterer NachweisW11: VPN01 verbindet sich

Weiterer NachweisW11: APIPA-Adresse als Diagnosehinweis

Weiterer NachweisRRAS: statischen IPv4-Pool hinzufügen

Weiterer NachweisRRAS: Adresspool und Adapter Privat

8. Erfolgsnachweis

Nach Trennen und erneutem Verbinden der VPN-Verbindung erhielt GFNLAB\benutzer1 die Adresse 192.168.1.101 aus dem RRAS-Pool. Anschließend gelang der Zugriff auf die zuvor eingerichtete Freigabe \\DC\Druckvorlagen. In der RRAS-Konsole war der verbundene RAS-Client sichtbar.

Technischer Abschluss: Der Remotezugriff funktionierte nicht nur auf Verbindungsebene, sondern auch anwendungsnah über SMB-Zugriff auf eine interne Unternehmensfreigabe.

Weiterer NachweisW11: VPN-IP aus RRAS-Pool

Weiterer NachweisW11: Zugriff auf \\DC\Druckvorlagen

Weiterer NachweisServer1: RAS-Client sichtbar

9. Prüfpunkte und Rücksetzung

Nach Abschluss der Übung wurde die Laborumgebung gemäß Aufgabenstellung zurückgesetzt. Alle VMs wurden auf Basis-AD zurückgesetzt. Für Server1 wurde im Anschluss der funktionierende Server1-Prüfpunkt verwendet, weil Server1 nicht auf einen ungeeigneten älteren Basiszustand zurückgesetzt werden durfte.

Get-VM | Restore-VMCheckpoint -Name Basis-AD -Confirm:$false

Prüfpunktwahl: Wenn eine Aufgabenstellung verlangt, alle Maschinen auf Basis-AD zurückzusetzen, wird Server1 anschließend auf den geprüften Server1-Stand gesetzt. Dadurch bleibt die Umgebung für die späteren Arbeitsschritte konsistent.

Weiterer NachweisHyper-V: Restore-VMCheckpoint vorbereitet

Weiterer NachweisHyper-V: Prüfpunktrücksetzung anwenden

Einsatzgrenze: PPTP ist hier ein historisches Lernprotokoll und keine aktuelle Sicherheitsempfehlung. Fehlgeschlagene Benutzer- und APIPA-Zwischenstände bleiben als Diagnoseverlauf erkennbar; Erfolg wird nur für den belegten UNC-Zugriff behauptet.

Praxis und Ergebnis

MDT/WDS und PXE-Bereitstellung

Deployment Share, Bootstrap-Konfiguration, ISO, WDS-Bootimage und DHCP-Optionen bis zum PXE-/MDT-Lauf bearbeiten.

Ziel

Provisioning, Microsoft Deployment Toolkit und Windows Deployment Services bis zu einem nachvollziehbaren LiteTouch-/PXE-Ablauf verbinden.

Ergebnis und Grenze

Der manuelle LiteTouch-Lauf endete erfolgreich. Nach der Korrektur der Bootstrap-Zugangsdaten erreichte der automatisierte Ablauf Task Sequence, Partitionierung, Domänenbeitrittsdaten und die laufende Installation. PXE startete über WDS bis in MDT; ein separat fotografierter, vollständig installierter PXE-Endclient liegt nicht vor.

Laborumgebung

Objekt	Rolle
`[Laborhost]`	Hyper-V-/Remote-LAB-Host
`DC`/`DC.gfnlab.test`	Domänencontroller, DHCP, Software-Freigabe, WDS
`Server2`	MDT-Server, Deployment Workbench, Deployment Share
`W11`	Windows Configuration Designer / Projekt1 und Projekt2
`Test-VM`	Zielsystem für PPKG-, MDT- und PXE-Tests
`gfnlab.test`	Active-Directory-Domäne
`Private`	Hyper-V-Switch

15.1.1 - Vorbereitung, DHCP, Software-Freigabe und ADK

Zuerst wurde der erweiterte Sitzungsmodus in Hyper-V vorbereitet, damit Dateien komfortabler zwischen Host und VMs übertragen werden können. Auf DC wurde DHCP installiert und ein Bereich für das Labornetz vorbereitet. Anschließend wurde der Ordner C:\Software als \\DC\Software freigegeben und mit den Installationsquellen für 7-Zip, Chrome Enterprise und Firefox befüllt.

Auf W11 wurde das Windows Assessment and Deployment Kit installiert, damit der Windows Configuration Designer für Provisioning Packages verfügbar ist.

**Hyper-V: Richtlinie für den erweiterten Sitzungsmodus auf dem LAB-Host vorbereitet.**

**DC: DHCP-Rolle und Bereichskonfiguration per PowerShell vorbereitet.**

**DC: Freigabe- und Sicherheitsberechtigungen für den Ordner Software konfiguriert.**

Weiterer NachweisDC: Software-Ordner mit 7zip, Chrome Enterprise und Firefox als Paketquellen.

Weiterer NachweisW11: Windows ADK-Features für Windows Configuration Designer ausgewählt.

W11: Windows ADK-Features für Windows Configuration Designer ausgewaehlt. — **W11: Windows ADK-Features für Windows Configuration Designer ausgewählt.**

Weiterer NachweisW11: Ordnerstruktur C:\ICD mit Projektordnern für WCD/ICD.

15.1.2 - Windows Configuration Designer und Provisioning Packages

Mit dem Windows Configuration Designer wurde Projekt1 erstellt. Das Paket sollte Clients nach dem Schema CLIENT-%RAND:2% benennen, WLAN nicht konfigurieren, den Active-Directory-Beitritt zur Domäne gfnlab.test vorbereiten und Anwendungen aus \\DC\Software installieren.

Wichtig:Project1.ppkg wurde nicht nur kopiert, sondern auf der Test-VM aktiv angewendet. Erst dadurch wurde die Provisionierung ausgeführt. Nach dem Vorgang waren die Anwendungen sichtbar und der Client erschien im AD-Kontext. Danach wurde Projekt2 als erweiterte Bereitstellung erstellt und exportiert.

Weiterer NachweisWCD: Projekt1 mit Gerätenamensschema CLIENT-%RAND:2% vorbereitet.

WCD: Projekt1 mit Geraetenamensschema CLIENT-%RAND:2% vorbereitet. — **WCD: Projekt1 mit Gerätenamensschema CLIENT-%RAND:2% vorbereitet.**

Weiterer NachweisWCD: Projekt1 mit Active-Directory-Beitritt zur Domäne gfnlab.test und lokalem Admin-Konto.

WCD: Projekt1 mit Active-Directory-Beitritt zur Domaene gfnlab.test und lokalem Admin-Konto. — **WCD: Projekt1 mit Active-Directory-Beitritt zur Domäne gfnlab.test und lokalem Admin-Konto.**

Weiterer NachweisWCD: Projekt1 enthält die drei vorgesehenen Anwendungen aus der Software-Freigabe.

WCD: Projekt1 enthaelt die drei vorgesehenen Anwendungen aus der Software-Freigabe. — **WCD: Projekt1 enthält die drei vorgesehenen Anwendungen aus der Software-Freigabe.**

Weiterer NachweisWCD: Zusammenfassung vor Erstellung des Bereitstellungspakets Project1.ppkg.

Weiterer NachweisDC: Project1.ppkg wurde in der Software-Freigabe abgelegt.

Weiterer NachweisTest-VM: Project1.ppkg wird aktiv angewendet; reines Kopieren reicht nicht aus.

Weiterer NachweisTest-VM: Nach Anwendung des PPKG sind die bereitgestellten Anwendungen sichtbar.

Weiterer NachweisDC: Active Directory-Benutzer und -Computer mit Clientobjekt nach Provisionierung.

Weiterer NachweisWCD: Projekt2 als erweiterte Bereitstellung für alle Windows-Editionen.

Weiterer NachweisWCD: Projekt2 wird als Bereitstellungspaket exportiert.

15.2.2 - Server2 für MDT vorbereiten

Server2 erhielt eine zusätzliche virtuelle Festplatte für MDT-Daten. Danach wurden Microsoft Deployment Toolkit, Windows ADK und die Windows PE Add-ons installiert. Diese Kombination ist notwendig, damit MDT Deployment Shares verwalten und LiteTouch-Bootmedien erzeugen kann.

Weiterer NachweisHyper-V: Server2 erhält eine zusätzliche 100-GB-VHDX für MDT-Daten.

Hyper-V: Server2 erhaelt eine zusaetzliche 100-GB-VHDX für MDT-Daten. — **Hyper-V: Server2 erhält eine zusätzliche 100-GB-VHDX für MDT-Daten.**

Weiterer NachweisServer2: Microsoft Deployment Toolkit-Setup erfolgreich abgeschlossen.

Weiterer NachweisServer2: Windows ADK-Features für Deployment-Arbeiten ausgewählt.

Server2: Windows ADK-Features für Deployment-Arbeiten ausgewaehlt. — **Server2: Windows ADK-Features für Deployment-Arbeiten ausgewählt.**

Weiterer NachweisServer2: Windows Assessment and Deployment Kit-Installation abgeschlossen.

Weiterer NachweisServer2: Windows PE Add-ons werden installiert, damit MDT Bootmedien erzeugen kann.

15.2.3 - MDT-Datenvolume und Deployment Share

Die neue Festplatte wurde in Windows als GPT-Datenträger initialisiert, formatiert und als Laufwerk M: mit Label MDT bereitgestellt. In der Deployment Workbench wurde darauf der Deployment Share M:\Deployment Share erstellt. Der dazugehörige UNC-Pfad lautet \\SERVER2\DeploymentShare$.

Weiterer NachweisServer2: Datenträger 1 ist als Volume M: mit Label MDT vorbereitet.

Server2: Datentraeger 1 ist als Volume M: mit Label MDT vorbereitet. — **Server2: Datenträger 1 ist als Volume M: mit Label MDT vorbereitet.**

Weiterer NachweisDeployment Workbench: Neuer Deployment Share auf M:\Deployment Share.

Weiterer NachweisDeployment Workbench: Zusammenfassung für den Deployment Share DeploymentShare$.

Weiterer NachweisDeployment Workbench: Deployment Share erfolgreich erstellt.

15.2.4 - Windows 11 in MDT importieren

Die Windows-11-ISO wurde auf Server2 eingebunden und in MDT als vollständige Quelldateien importiert. Im Ergebnis waren mehrere Windows-11-Editionen aus der install.wim sichtbar. Für die spätere Task Sequence wurde Windows 11 Pro verwendet.

Weiterer NachweisMDT: Windows-11-Quelle wird als Full set of source files importiert.

Weiterer NachweisMDT: Import des Windows-11-Betriebssystems abgeschlossen.

Weiterer NachweisMDT: Mehrere Windows-11-Editionen aus der install.wim sind im Ordner Windows11 sichtbar.

15.2.6 - Task Sequence Clients und manuelle LiteTouch-Bereitstellung

Die x86-Unterstützung im Deployment Share wurde entfernt; x64 blieb aktiv. Anschließend wurde die Task Sequence Clients auf Basis der Standard Client Task Sequence erstellt. Nach dem Update des Deployment Share wurden LiteTouch-Bootmedien erzeugt. Die LiteTouchPE_x64.iso wurde auf den Host kopiert, in die Test-VM eingebunden und für eine manuelle MDT-Bereitstellung genutzt.

Der manuelle MDT-LiteTouch-Ablauf wurde erfolgreich abgeschlossen. Diese Aussage ist durch die Deployment-Summary mit Operating system deployment completed successfully belegt.

Weiterer NachweisMDT Deployment Share: x86-Unterstützung entfernt, x64 bleibt aktiv.

MDT Deployment Share: x86-Unterstuetzung entfernt, x64 bleibt aktiv. — **MDT Deployment Share: x86-Unterstützung entfernt, x64 bleibt aktiv.**

Weiterer NachweisMDT: Task Sequence Clients wurde erfolgreich erstellt.

Weiterer NachweisMDT: Deployment Share wurde aktualisiert und Bootmedien wurden erzeugt.

Weiterer NachweisLab-Host: LiteTouchPE_x64.iso wurde für den Teststart in MDT-ISOs abgelegt.

Weiterer NachweisHyper-V: Test-VM bootet von der LiteTouchPE_x64.iso.

Weiterer NachweisTest-VM: MDT Deployment Wizard startet aus dem LiteTouch-Bootmedium.

Weiterer NachweisTest-VM: Windows-11-Bereitstellung über MDT manuell erfolgreich abgeschlossen.

15.2.7 - Angepasste Bootstrap.ini/CustomSettings.ini und automatisierter MDT-Test

Im ersten Durchlauf trat beim automatisierten MDT-Start ein Credential-Fehler auf. Die Fehlermeldung lautete sinngemäß, dass der Zugriff auf \\SERVER2\DeploymentShare$ zwar grundsätzlich erreichbar sei, aber wahrscheinlich ungültige Anmeldeinformationen verwendet wurden. Die Ursache wurde im Nachgang eingegrenzt: In den MDT-Automatisierungsdateien war versehentlich ein falsches Kennwort hinterlegt.

Zur Korrektur wurden Bootstrap.ini und CustomSettings.ini erneut geprüft und die Anmeldeinformationen angepasst. Anschließend wurde der vorhandene Deployment Share M:\Deployment Share in der Deployment Workbench wieder geöffnet, der Deployment Share aktualisiert und ein neues LiteTouch-Bootmedium erzeugt. Wichtig ist dabei: Nach Änderungen an Bootstrap.ini oder CustomSettings.ini reicht das reine Speichern der Datei nicht aus. Das Bootmedium muss über Update Deployment Share neu erzeugt und danach in der Test-VM verwendet werden.

Die erneute Validierung war erfolgreich: Die Test-VM startete vom aktualisierten LiteTouchPE_x64.iso, erreichte den MDT Deployment Wizard, bot die Task Sequence Clients an und startete die LiteTouch-Installation bis in die Phase Format and Partition Disk (UEFI). Damit wurde der zuvor offene Teil 15.2.7 nach Credential-Korrektur erfolgreich abgeschlossen.

Weiterer NachweisServer2: Bootstrap.ini mit korrigierten Zugangsdaten für den Deployment Share. Kennwortwerte…

**Server2: Bootstrap.ini mit DeployRoot zum MDT-Deployment-Share und den konfigurierten Anmeldeparametern.**

Weiterer NachweisServer2: CustomSettings.ini mit korrigierter Automatisierungs- und Domain-Join-Konfiguration.…

**Server2: CustomSettings.ini mit automatisierter Task-Sequence-Auswahl und konfiguriertem Domänenbeitritt.**

Weiterer NachweisDeployment Workbench: Der vorhandene Deployment Share wurde wieder geöffnet.

Deployment Workbench: Der vorhandene Deployment Share wurde wieder geoeffnet. — **Deployment Workbench: Der vorhandene Deployment Share wurde wieder geöffnet.**

Weiterer NachweisMDT: Deployment Share nach Korrektur der INI-Dateien erfolgreich aktualisiert.

Weiterer NachweisServer2: Aktualisierte LiteTouch-Bootmedien im Boot-Ordner des Deployment Shares.

Weiterer NachweisLab-Host: Aktualisierte LiteTouchPE_x64.iso wurde für den Hyper-V-Test lokal ber…

**Lab-Host: Aktualisierte LiteTouchPE_x64.iso wurde für den Hyper-V-Test lokal bereitgestellt.**

Weiterer NachweisHyper-V: Test-VM verwendet die aktualisierte LiteTouchPE_x64.iso als DVD-Bootmedium.

Weiterer NachweisHyper-V: Firmware-Startreihenfolge der Test-VM mit DVD/LiteTouch als bevorzugtem Startmedium.

Weiterer NachweisTest-VM: Die Task Sequence Clients ist im MDT Deployment Wizard erreichbar.

Weiterer NachweisTest-VM: Der LiteTouch-Ablauf erreicht die Installationsphase Format and Partition Disk (UEFI).

15.2.8 - WDS/PXE-Bereitstellung nach DHCP-/PXE-Korrektur

Im ersten PXE-Test der Test-VM erschien die Meldung A boot image was not found. Das vorhandene WDS-Startabbild allein reichte also nicht aus; die PXE-Kette war noch nicht vollständig korrekt abgestimmt. Fachlich relevant waren hier vor allem WDS, DHCP, die Generation-2-/UEFI-Firmware der Test-VM und die richtige Bootdatei.

Zur Korrektur wurden die DHCP-Bereichsoptionen für PXE/WDS angepasst. Für den Startserver wurde Option 066 Hostname des Startservers verwendet. Für die Bootdatei wurde Option 067 Name der Startdatei auf die UEFI-kompatible WDS-Bootdatei boot\x64\wdsmgfw.efi gesetzt. Diese Bootdatei passt zur Hyper-V-Test-VM mit Generation 2 / UEFI. Danach wurde der Netzwerkstart erneut getestet.

Der erneute PXE-Test war erfolgreich: Die Test-VM erreichte über Netzwerkstart den MDT/LiteTouch-Ablauf, zeigte die Task Sequence Clients an, nahm die Computer- und Domain-Join-Daten entgegen und startete die LiteTouch-Installation. Damit wurde auch der zuvor offene Teil 15.2.8 erfolgreich abgeschlossen.

Weiterer NachweisDHCP: Option 066 für den PXE-/WDS-Startserver wurde gesetzt.

Weiterer NachweisDHCP: Option 067 mit UEFI-Bootdatei boot\x64\wdsmgfw.efi für Generation-2-VMs.

Weiterer NachweisDHCP: Bereichsoptionen 066 und 067 im kontrollierten Endzustand.

Weiterer NachweisPXE-Test: Die Task Sequence Clients ist nach dem Netzwerkstart erreichbar.

Weiterer NachweisPXE/MDT: Computer Details mit Clientname und Domain Join im Deployment Wizard.

Weiterer NachweisPXE/MDT: Die LiteTouch-Installation läuft nach erfolgreichem Netzwerkstart.

PXE/MDT: Die LiteTouch-Installation laeuft nach erfolgreichem Netzwerkstart. — **PXE/MDT: Die LiteTouch-Installation läuft nach erfolgreichem Netzwerkstart.**

Troubleshooting-Zusammenfassung

Credential-Fehler bei automatisiertem MDT - gelöst

A connection to the deployment share (\\SERVER2\DeploymentShare$) could not be made.
Connection OK. Possible cause: invalid credentials.

Die Formulierung Connection OK war der entscheidende Hinweis: Netzwerkpfad und grundsätzliche Erreichbarkeit waren nicht das Hauptproblem. Die Ursache lag in den hinterlegten MDT-Anmeldeinformationen. Nach Korrektur der Kennwortwerte in Bootstrap.ini und CustomSettings.ini, erneutem Update Deployment Share und Verwendung des neu erzeugten LiteTouch-Bootmediums erreichte die Test-VM die Task Sequence Clients und startete den Deployment-Ablauf.

Fehlerursache und Korrektur: Ursache war ein versehentlich falsch gesetztes Kennwort. Die Korrektur erfolgte über die INI-Anpassung, die Aktualisierung des Deployment Shares und ein neu erzeugtes Bootmedium.

PXE-Fehler bei WDS - gelöst

Network Adapter
A boot image was not found.

Obwohl das WDS-Startabbild vorhanden und online war, war die PXE-Kette noch nicht korrekt abgestimmt. Für die Hyper-V-Test-VM mit Generation 2 / UEFI musste die DHCP-/PXE-Konfiguration auf die passende UEFI-Bootdatei zeigen. Nach Anpassung der Optionen 066 und 067, insbesondere mit boot\x64\wdsmgfw.efi, führte der Netzwerkstart in den MDT/LiteTouch-Ablauf.

Zentrale Fachliche Erkenntnisse aus den Fehlern

MDT-Automatisierung ist stark von exakt korrekten Anmeldeinformationen abhängig.
Nach Änderungen an Bootstrap.ini oder CustomSettings.ini muss der Deployment Share aktualisiert und das neue Bootmedium verwendet werden.
Bei WDS/PXE muss die Bootdatei zur Firmware der Ziel-VM passen: Generation 2 / UEFI benötigt eine UEFI-kompatible Bootdatei.
Ein online sichtbares WDS-Startabbild allein garantiert noch keinen erfolgreichen PXE-Start; DHCP, WDS, Bootdatei und VM-Firmware müssen zusammenpassen.

Fachliche Grenze

Der letzte PXE-Installationslauf ist bis Task Sequence und laufender Installation belegt. Ein eigenständiger Endnachweis des fertig installierten PXE-Clients fehlt.

Technologiebereich

Active Directory, Identitäten und Wiederherstellung

Domänen, Domänencontroller, Objekte, Dienstkonten, Sicherung, Wiederherstellung, Vertrauensstellungen und Standorte bearbeiten.

Praxis und Ergebnis

Active-Directory-Gesamtstruktur und DNS-Basis

Stammdomäne, zusätzlicher Domänencontroller, Domänenbeitritte, untergeordnete Domäne, zweite Strukturdomäne und DNS-Verknüpfung aufbauen.

1. Ziel und Ergebnis

Block 11 bildet den zentralen Übergang von einer reinen Windows-Server-Labumgebung zu einer Active-Directory-basierten Unternehmensstruktur. Die Aufgabe wurde nicht nur als Rolleninstallation betrachtet, sondern als nachvollziehbarer Aufbau einer Gesamtstruktur mit mehreren Domänen, DNS-Abhängigkeiten und Hyper-V-Prüfpunktstrategie.

Stammdomänegfnlab.test
Neue AD-Gesamtstruktur auf DC eingerichtet.

DomänencontrollerDC+Server1
Server1 als zusätzlicher/replizierender DC ohne globalen Katalog gemäß Aufgabenstellung.

Weitere Domänensub.gfnlab.test+it.pro
Server2 als DC der Subdomain, Server3 als DC der Strukturdomäne.

AbschlusszustandBasis-AD
Für alle VMs wurde ein Prüfpunkt erstellt; kein Rollback am Ende von Tag 11.

Ergebnis: Die Laborumgebung besitzt nach diesem Arbeitsabschnitt eine belastbare AD-Basis für die anschließenden Arbeitsschritte.

2. Ausgangslage, IP-Kontext und Prüfpunktlogik

Die gezeigten Zustände stammen aus dem isolierten Neuaufbau der Lern- und Laborumgebung. Frühere Vorlagen und Sicherungs-VMs gehören nicht zum belegten Arbeitsumfang. Die Screenshots zeigen Hyper-V, mehrere Windows-Server-VMs und eine Windows-11-Client-VM.

System	Rolle nach Block 11	Nachweisbare Adresse / Hinweis
`DC`	erster Domänencontroller der Stammdomäne `gfnlab.test`, DNS	`192.168.1.200`
`Server1`	zusätzlicher/replizierender Domänencontroller für `gfnlab.test`	`192.168.1.201` laut DNS-Auflösung
`Server2`	Domänencontroller der untergeordneten Domäne `sub.gfnlab.test`	`192.168.1.202`
`Server3`	Domänencontroller der zusätzlichen Strukturdomäne `it.pro`	`192.168.1.203`
`W11`	Domänenclient in `gfnlab.test`	`192.168.1.204` in der DNS-Zone sichtbar

IP-Abweichung von der Aufgabenstellung: Die Aufgabenstellung nennt für die bedingte Weiterleitung zu it.pro beispielhaft 192.168.1.3. In dieser Labumgebung wurde korrekt die tatsächliche IP von Server3 verwendet:192.168.1.203.

Prüfpunktentscheidung: Block 11 endet nicht mit einem Rücksprung. Der finale Zustand wird als neuer Hyper-V-Prüfpunkt Basis-AD gesichert. Dieser Zustand ist die Grundlage für die anschließenden Aufgabenstellung.

3. Zielarchitektur nach Block 11

Nach Abschluss des Blocks existiert eine Gesamtstruktur mit der Stammdomäne gfnlab.test, einer untergeordneten Domäne sub.gfnlab.test und einer zusätzlichen Strukturdomäne it.pro. DNS ist zentraler Bestandteil der Validierung, weil Domänencontroller, Domänenbeitritte, Vertrauensstellungen und spätere AD-Aufgaben auf funktionierender Namensauflösung aufbauen.

Gesamtstruktur: gfnlab.test ├── Domäne: gfnlab.test
│ ├── DC → erster Domänencontroller, DNS, 192.168.1.200
│ ├── Server1 → zusätzlicher/replizierender DC, 192.168.1.201
│ └── W11 → Domänenclient, DNS-Eintrag in gfnlab.test
│
├── Untergeordnete Domäne: sub.gfnlab.test
│ └── Server2 → Domänencontroller, DNS, 192.168.1.202
│
└── Strukturdomäne: it.pro └── Server3 → Domänencontroller, DNS, 192.168.1.203 DNS-Ergänzung auf DC:
└── Bedingte Weiterleitung it.pro → 192.168.1.203

4. DC als erster Domänencontroller

Auf DC wurden die Rollen Active-Directory-Domänendienste und DNS-Server installiert. Anschließend wurde der Server zur ersten Gesamtstruktur gfnlab.test heraufgestuft. Die Funktionsebene wurde gemäß Aufgabenstellung auf Windows Server 2016 gesetzt;DC übernimmt DNS und globalen Katalog.

11.3.1 DC als erster Domänencontroller DC: Installationsauswahl mit Active-Directory-Domänendiensten, DNS-Server und AD-Verwaltungstools.

11.3.1 DC als erster Domänencontroller DC: Rolleninstallation erfolgreich; Heraufstufung zum Domänencontroller wird als nächster Schritt angeboten.

11.3.1 DC als erster Domänencontroller DC: Bereitstellungskonfiguration für eine neue Gesamtstruktur mit Stammdomäne gfnlab.test.

Weiterer NachweisDC: Funktionsebenen Windows Server 2016, DNS-Server, globaler Katalog und DSRM-Kennwort.

Weiterer NachweisDC: automatisch ermittelter NetBIOS-Domänenname GFNLAB.

Weiterer NachweisDC: Voraussetzungsprüfung für die ADDS-Installation vor Start der Installation.

Einordnung: Der erste Domänencontroller ist nicht nur ein weiterer Serverdienst. Mit ihm entstehen AD-Datenbank, Domänenkontext, DNS-Struktur, Kerberos-/LDAP-bezogene SRV-Einträge und die Basis für zentrale Identitätsverwaltung.

5. Server1 als zusätzlicher Domänencontroller

Server1 wurde als zusätzlicher Domänencontroller zur bestehenden Domäne gfnlab.test hinzugefügt. Laut Aufgabenstellung sollte er kein globaler Katalogserver werden. Damit wurde der Unterschied zwischen erstem DC und replizierendem DC praktisch nachvollzogen.

Weiterer NachweisServer1: Installation der Active-Directory-Domänendienste als Vorbereitung für zusätzlichen DC.

Weiterer NachweisServer1: Hinzufügen als Domänencontroller zu der vorhandenen Domäne gfnlab.test.

Weiterer NachweisServer1: Domänencontrolleroptionen; gemäß Aufgabenstellung kein globaler Katalogserver.

Weiterer NachweisServer1: Voraussetzungsprüfung vor Heraufstufung.

Weiterer NachweisServer1: Ergebnisnachweis der erfolgreichen Heraufstufung.

Weiterer NachweisServer1: Anmeldung/Validierung nach Einrichtung als zusätzlicher Domänencontroller.

Aspekt	Umsetzung	Bedeutung
Domäne	`gfnlab.test`	Server1 wird nicht neue Domäne, sondern zusätzlicher DC der bestehenden Domäne.
Globaler Katalog	nicht aktiviert	Gemäß Aufgabenstellung, um die Rolle eines replizierenden DCs differenziert zu betrachten.
DNS	beibehalten	DNS bleibt wichtig für Domänencontroller-Lokalisierung und AD-Funktion.

6. Domänenbeitritt von Server2, Server3 und W11

Server2, Server3 und W11 wurden zunächst der Domäne gfnlab.test hinzugefügt. Dabei wurden unterschiedliche Wege verwendet: Server2 und W11 über die grafische Oberfläche, Server3 per PowerShell. Anschließend wurden die Computerobjekte in AD und die Hosteinträge im DNS geprüft.

Weiterer NachweisServer2: grafischer Domänenbeitritt zu gfnlab.test.

Weiterer NachweisServer3: Domänenbeitritt per PowerShell gemäß Aufgabenstellung.

Weiterer NachweisW11: grafischer Domänenbeitritt zu gfnlab.test.

Weiterer NachweisDC: Active Directory-Benutzer und -Computer mit Server2, Server3 und W11 im Container Computers.

Weiterer NachweisDC: Organisationseinheit Domain Controllers mit DC und Server1.

Weiterer NachweisDC: Forward-Lookupzone gfnlab.test nach Domänenbeitritten.

Validierung: Die Nachweise zeigen sowohl die AD-Seite mit Computerobjekten als auch die DNS-Seite mit Namensauflösung. Genau diese Kombination ist für spätere Domänen- und Gruppenrichtlinienaufgaben entscheidend.

7. AD-Verwaltungstools, erweiterte Features und Dienste

In der nächsten Phase wurden die zentralen AD-Verwaltungskonsolen geprüft. Besonders wichtig war die Aktivierung der erweiterten Features in Active Directory-Benutzer und -Computer, weil dadurch zusätzliche Container und Registerkarten sichtbar werden. Zusätzlich wurden AD-Domänen und -Vertrauensstellungen, AD-Standorte und -Dienste, das AD-PowerShell-Modul, der ADSI-Editor und die DNS-SRV-Struktur betrachtet.

Weiterer NachweisDC: Benutzer Administrator in ADUC vor bzw. während der Prüfung der erweiterten Features.

Weiterer NachweisDC: Aktivierung der erweiterten Features in Active Directory-Benutzer und -Computer.

Weiterer NachweisDC: Active Directory-Domänen und -Vertrauensstellungen mit gfnlab.test.

Weiterer NachweisDC: Active Directory-Standorte und -Dienste.

Weiterer NachweisDC: ADSI-Editor mit Standardnamenskontext für LDAP-/Attributansicht.

Weiterer NachweisDC: Prüfung von AD-Domänendiensten und DNS-SRV-Struktur (_msdcs).

Technischer Zusammenhang: Der ADSI-Editor wurde als Administrations- und Analysewerkzeug für direkte LDAP- und Attributprüfungen eingesetzt, nicht als Routinewerkzeug für einfache Benutzerkonten.

8. Server2/Server3 austreten lassen, Subdomain und Strukturdomäne erstellen

Für Übung 11.7 mussten Server2 und Server3 zunächst wieder aus gfnlab.test austreten. Danach wurde Server2 als Domänencontroller der untergeordneten Domäne sub.gfnlab.test und Server3 als Domänencontroller der zusätzlichen Strukturdomäne it.pro aufgebaut.

Weiterer NachweisServer2: Austritt aus gfnlab.test zurück in WORKGROUP als Vorbereitung für sub.gfnlab.test.

Weiterer NachweisServer3: Austritt aus gfnlab.test zurück in WORKGROUP als Vorbereitung für it.pro.

8.1 Untergeordnete Domäne sub.gfnlab.test

Bei sub.gfnlab.test handelt es sich um eine untergeordnete Domäne innerhalb desselben zusammenhängenden DNS-Namensraums. Dadurch kann automatisch eine passende Delegierung im bestehenden Namespace entstehen.

Weiterer NachweisServer2: ADDS-Rolle für die neue untergeordnete Domäne.

Weiterer NachweisServer2: neue Domäne zu vorhandener Gesamtstruktur, Domänentyp untergeordnete Domäne.

Weiterer NachweisServer2: erfolgreiche Konfiguration als Domänencontroller der untergeordneten Domäne.

Weiterer NachweisServer2: DNS-Zone sub.gfnlab.test mit Server2-Hosteintrag.

8.2 Strukturdomäne it.pro

it.pro ist eine zusätzliche Strukturdomäne innerhalb der Gesamtstruktur, aber kein untergeordneter DNS-Namespace von gfnlab.test. Deshalb kann DC diese Zone nicht automatisch wie eine Subdomain delegieren. Genau dieser Unterschied wird später bei der DNS-Prüfung sichtbar.

Weiterer NachweisServer3: ADDS-Rolle als Vorbereitung für die zusätzliche Strukturdomäne it.pro.

Weiterer NachweisServer3: neue Strukturdomäne it.pro in vorhandener Gesamtstruktur.

Weiterer NachweisServer3: Voraussetzungsprüfung für die neue Strukturdomäne it.pro.

Weiterer NachweisServer3: IP- und DNS-Konfiguration für sub.gfnlab.test

11.7 Untergeordnete Domäne sub.gfnlab.test Server3: IP-/DNS-Prüfung; IP 192.168.1.203, DNS zunächst 192.168.1.200.

9. Gesamtstruktur-, DNS- und Namensauflösungsprüfung

Die abschließenden DNS-Tests zeigen den wichtigsten Lernpunkt von Block 11: Active Directory hängt funktional an korrekter Namensauflösung. Die Ergebnisse sind nicht alle „grün“, sondern teilweise absichtlich unterschiedlich.server2.gfnlab.test und server3.gfnlab.test sind nach dem Umzug in andere Domänen unter dem alten Namen nicht mehr auflösbar. Das ist erwartetes Verhalten, kein Fehler.

Weiterer NachweisDC: Gesamtstrukturansicht mit gfnlab.test, sub.gfnlab.test und it.pro.

Weiterer NachweisDC: _msdcs.gfnlab.test / domains mit Einträgen der Domänen.

Weiterer NachweisDC: Zone gfnlab.test nach Austritt von Server2/Server3; Host-A-Einträge für DC, Server1 und W…

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: Zone gfnlab.test nach Austritt von Server2/Server3; Host-A-Einträge für DC, Server1 und W11 bleiben sichtbar.

Weiterer NachweisDC: Namensauflösung für dc/server1 erfolgreich; server2/server3 unter gfnlab.test erwartungsg…

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: Namensauflösung für dc/server1 erfolgreich; server2/server3 unter gfnlab.test erwartungsgemäß nicht auflösbar.

Test	Erwartung	Ergebnis / Interpretation
`Resolve-DnsName dc.gfnlab.test`	erfolgreich	`DC` wird als Domänencontroller der Stammdomäne aufgelöst.
`Resolve-DnsName server1.gfnlab.test`	erfolgreich	`Server1` wird als zusätzlicher DC in `gfnlab.test` aufgelöst.
`Resolve-DnsName server2.gfnlab.test`	nicht erfolgreich	Erwartet, da Server2 jetzt zu `sub.gfnlab.test` gehört.
`Resolve-DnsName server3.gfnlab.test`	nicht erfolgreich	Erwartet, da Server3 jetzt zu `it.pro` gehört.
`Resolve-DnsName server2.sub.gfnlab.test`	erfolgreich	Subdomain-Auflösung funktioniert über Delegierung/Namensraum.
`Resolve-DnsName server3.it.pro` vor Weiterleitung	nicht erfolgreich	Erwartet, da `it.pro` kein untergeordneter Namespace von `gfnlab.test` ist.
`Resolve-DnsName server3.it.pro` nach Weiterleitung	erfolgreich	Erfolgreich über bedingte Weiterleitung auf `192.168.1.203`.

Weiterer NachweisServer2: DNS-Prüfung der Forward-Lookupzone sub.gfnlab.test mit Server2-Hosteintrag 192.168.1…

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung Server2: DNS-Prüfung der Forward-Lookupzone sub.gfnlab.test mit Server2-Hosteintrag 192.168.1.202.

Weiterer NachweisServer3: DNS-Prüfung der Forward-Lookupzone it.pro.

Weiterer NachweisDC: server2.sub.gfnlab.test erfolgreich; server3.it.pro vor bedingter Weiterleitung nicht erf…

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: server2.sub.gfnlab.test erfolgreich; server3.it.pro vor bedingter Weiterleitung nicht erfolgreich.

Weiterer NachweisDC: neue bedingte Weiterleitung für it.pro wird vorbereitet.

Weiterer NachweisDC: bedingte Weiterleitung für it.pro mit tatsächlicher Server3-IP 192.168.1.203 statt Handou…

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: bedingte Weiterleitung für it.pro mit tatsächlicher Server3-IP 192.168.1.203 statt Beispielwert aus der Aufgabenstellung 192.168.1.3.

Weiterer NachweisDC: server3.it.pro ist nach bedingter Weiterleitung erfolgreich auflösbar (192.168.1.203).

Bei der bedingten Weiterleitung wurde nicht der Beispielwert 192.168.1.3 verwendet, sondern die tatsächliche IP von Server3: 192.168.1.203.

10. Abschlusszustand: Prüfpunkt Basis-AD

Am Ende von Block 11 wurde für alle relevanten VMs ein Hyper-V-Prüfpunkt mit dem Namen Basis-AD erstellt. Dieser Prüfpunkt bildet den definierten AD-Grundzustand für die Folgeaufgaben. Im Unterschied zu mehreren späteren Aufgabenstellung wird hier nicht zurückgesetzt; der Tag endet mit diesem Zustand.

Weiterer NachweisHost: Start der Prüfpunkt-Erstellung im Hyper-V-Manager.

Weiterer NachweisHost: Prüfpunkt Basis-AD für DC sichtbar/benannt.

Weiterer NachweisHost: Prüfpunkt Basis-AD für Server1 bzw. weitere VM sichtbar.

Weiterer NachweisHost: Prüfpunkt Basis-AD für Server2 sichtbar.

Weiterer NachweisHost: Prüfpunkt Basis-AD für Server3 sichtbar.

Weiterer NachweisHost: Abschlussnachweis der Prüfpunkte Basis-AD, inklusive W11.

VM	Abschlussfunktion	Prüfpunkt
`DC`	Stammdomänen-DC / DNS	`Basis-AD`
`Server1`	zusätzlicher DC in `gfnlab.test`	`Basis-AD`
`Server2`	DC für `sub.gfnlab.test`	`Basis-AD`
`Server3`	DC für `it.pro`	`Basis-AD`
`W11`	Domänenclient	`Basis-AD`

11. Fachliche Erkenntnisse und offene Risiken

Lerngewinn:
Block 11 macht sichtbar, dass AD nicht nur aus Benutzerkonten besteht. Domänencontroller, DNS-Zonen, SRV-Einträge, Vertrauensstellungen, Namensräume und Replikation bilden zusammen die technische Identitätsinfrastruktur.

DNS-Fehler können in Active Directory als Domänen- oder Anmeldeprobleme erscheinen; deshalb wurden DNS-Zonen, Delegierungen und Weiterleitungen als getrennte technische Ebenen geprüft.

Kontexttreue IP-Werte: Die tatsächlichen Laboradressen wurden gegenüber den Beispielwerten aus der Aufgabenstellung priorisiert.
Erwartete Abweichungen: Nicht erfolgreiche Auflösungen wurden nicht als Fehler bewertet, wenn sie logisch aus dem Domänenwechsel folgten.
Prüfpunktlogik sauber getrennt: Block 10 endete mit Basis; Block 11 endet mit Basis-AD.
Ausgangsbasis für Folgeaufgaben: Aufgabenstellung 12 bis 15 können auf diesem Zustand aufbauen.

12. Weitere technische Nachweise

Abbildung anzeigen

11.3.1 DC als erster Domänencontroller DC: Installationsauswahl mit Active-Directory-Domänendiensten, DNS-Server und AD-Verwaltungstools.

Abbildung anzeigen

11.3.1 DC als erster Domänencontroller DC: Rolleninstallation erfolgreich; Heraufstufung zum Domänencontroller wird als nächster Schritt angeboten.

Abbildung anzeigen

11.3.1 DC als erster Domänencontroller DC: Bereitstellungskonfiguration für eine neue Gesamtstruktur mit Stammdomäne gfnlab.test.

Abbildung anzeigen

11.3.1 DC als erster Domänencontroller DC: Funktionsebenen Windows Server 2016, DNS-Server, globaler Katalog und DSRM-Kennwort.

Weiterer NachweisDC: DNS-Optionen im Heraufstufungsassistenten; Delegierungshinweis im Lab-Kontext.

Abbildung anzeigen

11.3.1 DC als erster Domänencontroller DC: automatisch ermittelter NetBIOS-Domänenname GFNLAB.

Weiterer NachweisDC: Standardpfade, Optionen und Übergang zur Voraussetzungsprüfung.

Abbildung anzeigen

11.3.1 DC als erster Domänencontroller DC: Voraussetzungsprüfung für die ADDS-Installation vor Start der Installation.

Weiterer NachweisDC: Abschluss der Heraufstufung; Neustart/Neuanmeldung in der Domäne vorbereitet.

Weiterer NachweisDC: Anmeldung als Domänenadministrator nach Einrichtung von gfnlab.test.

Weiterer NachweisDC: Server-Manager nach der ADDS-Bereitstellung als Domänencontroller.

Weiterer NachweisDC: Nachweis des funktionsfähigen Basiszustands nach der Heraufstufung.

Abbildung anzeigen

11.3.2 Server1 als replizierender Domänencontroller Server1: Installation der Active-Directory-Domänendienste als Vorbereitung für zusätzlichen DC.

Abbildung anzeigen

11.3.2 Server1 als replizierender Domänencontroller Server1: Hinzufügen als Domänencontroller zu der vorhandenen Domäne gfnlab.test.

Abbildung anzeigen

11.3.2 Server1 als replizierender Domänencontroller Server1: Domänencontrolleroptionen; gemäß Aufgabenstellung kein globaler Katalogserver.

Weiterer NachweisServer1: DSRM-/DNS-Optionen im Assistenten.

Weiterer NachweisServer1: zusätzliche Optionen/Replikationsquelle für den replizierenden Domänencontroller.

Abbildung anzeigen

11.3.2 Server1 als replizierender Domänencontroller Server1: Voraussetzungsprüfung vor Heraufstufung.

Weiterer NachweisServer1: Installation/Heraufstufung zum zusätzlichen Domänencontroller.

Abbildung anzeigen

11.3.2 Server1 als replizierender Domänencontroller Server1: Ergebnisnachweis der erfolgreichen Heraufstufung.

Abbildung anzeigen

11.3.2 Server1 als replizierender Domänencontroller Server1: Anmeldung/Validierung nach Einrichtung als zusätzlicher Domänencontroller.

Abbildung anzeigen

11.4 Domänenbeitritt und erste AD-/DNS-Prüfung Server2: grafischer Domänenbeitritt zu gfnlab.test.

Weiterer NachweisServer2: Bestätigung/Neustart nach Domänenbeitritt.

Abbildung anzeigen

11.4 Domänenbeitritt und erste AD-/DNS-Prüfung Server3: Domänenbeitritt per PowerShell gemäß Aufgabenstellung.

Weiterer NachweisServer3: Neustart/Anmeldung nach PowerShell-basiertem Domänenbeitritt.

Abbildung anzeigen

11.4 Domänenbeitritt und erste AD-/DNS-Prüfung W11: grafischer Domänenbeitritt zu gfnlab.test.

Weiterer NachweisW11: Bestätigung des Domänenbeitritts und Neustartaufforderung.

Abbildung anzeigen

11.4 Domänenbeitritt und erste AD-/DNS-Prüfung DC: Active Directory-Benutzer und -Computer mit Server2, Server3 und W11 im Container Computers.

Abbildung anzeigen

11.4 Domänenbeitritt und erste AD-/DNS-Prüfung DC: Organisationseinheit Domain Controllers mit DC und Server1.

Abbildung anzeigen

11.4 Domänenbeitritt und erste AD-/DNS-Prüfung DC: Forward-Lookupzone gfnlab.test nach Domänenbeitritten.

Abbildung anzeigen

11.5 AD-Verwaltungskonsolen, Dienste und SRV-Einträge DC: Benutzer Administrator in ADUC vor bzw. während der Prüfung der erweiterten Features.

Abbildung anzeigen

11.5 AD-Verwaltungskonsolen, Dienste und SRV-Einträge DC: Aktivierung der erweiterten Features in Active Directory-Benutzer und -Computer.

Weiterer NachweisDC: zusätzliche Registerkarten nach Aktivierung der erweiterten Features.

Abbildung anzeigen

11.5 AD-Verwaltungskonsolen, Dienste und SRV-Einträge DC: Active Directory-Domänen und -Vertrauensstellungen mit gfnlab.test.

Weiterer NachweisDC: Active Directory-Modul für Windows PowerShell als Administrationskonsole.

Abbildung anzeigen

11.5 AD-Verwaltungskonsolen, Dienste und SRV-Einträge DC: Active Directory-Standorte und -Dienste.

Abbildung anzeigen

11.5 AD-Verwaltungskonsolen, Dienste und SRV-Einträge DC: ADSI-Editor mit Standardnamenskontext für LDAP-/Attributansicht.

Abbildung anzeigen

11.5 AD-Verwaltungskonsolen, Dienste und SRV-Einträge DC: Prüfung von AD-Domänendiensten und DNS-SRV-Struktur (_msdcs).

Abbildung anzeigen

11.7 Austritt Server2/Server3 und Vorbereitung weiterer Domänen Server2: Austritt aus gfnlab.test zurück in WORKGROUP als Vorbereitung für sub.gfnlab.test.

Weiterer NachweisServer2: Neustart/Anmeldung nach Austritt aus der Domäne.

Abbildung anzeigen

11.7 Austritt Server2/Server3 und Vorbereitung weiterer Domänen Server3: Austritt aus gfnlab.test zurück in WORKGROUP als Vorbereitung für it.pro.

Weiterer NachweisServer3: Neustart/Anmeldung nach Austritt aus der Domäne.

Abbildung anzeigen

11.7 Austritt Server2/Server3 und Vorbereitung weiterer Domänen Server2: ADDS-Rolle für die neue untergeordnete Domäne.

Abbildung anzeigen

11.7 Austritt Server2/Server3 und Vorbereitung weiterer Domänen Server2: neue Domäne zu vorhandener Gesamtstruktur, Domänentyp untergeordnete Domäne.

Weiterer NachweisServer2: Optionen für den Domänencontroller der Subdomain sub.gfnlab.test.

Weiterer NachweisServer2: Voraussetzungsprüfung/Installation für sub.gfnlab.test.

Abbildung anzeigen

11.7 Untergeordnete Domäne sub.gfnlab.test Server2: erfolgreiche Konfiguration als Domänencontroller der untergeordneten Domäne.

Weiterer NachweisServer2: Anmeldung in der Domäne SUB nach Neustart.

Abbildung anzeigen

11.7 Untergeordnete Domäne sub.gfnlab.test Server2: DNS-Zone sub.gfnlab.test mit Server2-Hosteintrag.

Abbildung anzeigen

11.7 Untergeordnete Domäne sub.gfnlab.test Server3: ADDS-Rolle als Vorbereitung für die zusätzliche Strukturdomäne it.pro.

Abbildung anzeigen

11.7 Untergeordnete Domäne sub.gfnlab.test Server3: neue Strukturdomäne it.pro in vorhandener Gesamtstruktur.

Weiterer NachweisServer3: Domänencontrolleroptionen für it.pro.

Abbildung anzeigen

11.7 Untergeordnete Domäne sub.gfnlab.test Server3: Voraussetzungsprüfung für die neue Strukturdomäne it.pro.

Weiterer NachweisServer3: Ergebnis der Heraufstufung zum Domänencontroller von it.pro.

Abbildung anzeigen

11.7 Untergeordnete Domäne sub.gfnlab.test Server3: IP-/DNS-Prüfung; IP 192.168.1.203, DNS zunächst 192.168.1.200.

Weiterer NachweisServer3: weiterer Nachweis aus der Einrichtung der Strukturdomäne it.pro.

Weiterer Nachweisaus der Prüfung bzw. Einrichtung der Strukturdomäne it.pro.

Weiterer NachweisServer3: IP- und DNS-Konfiguration für it.pro

Weiterer NachweisWeiterer Nachweis aus der Einrichtung bzw. Prüfung der Strukturdomäne it.pro.

Abbildung anzeigen

11.7 Strukturdomäne it.pro DC: Gesamtstrukturansicht mit gfnlab.test, sub.gfnlab.test und it.pro.

Abbildung anzeigen

11.7 Strukturdomäne it.pro DC: _msdcs.gfnlab.test / domains mit Einträgen der Domänen.

Weiterer NachweisDC: weiterer DNS-Nachweis zur Gesamtstrukturprüfung.

Weiterer NachweisDC: DNS-Prüfung im Bereich gfnlab.test/sub.gfnlab.test.

Weiterer NachweisDC: Delegierung bzw. DNS-Einträge für die untergeordnete Domäne sub.gfnlab.test.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: Zone gfnlab.test nach Austritt von Server2/Server3; Host-A-Einträge für DC, Server1 und W11 bleiben sichtbar.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: Namensauflösung für dc/server1 erfolgreich; server2/server3 unter gfnlab.test erwartungsgemäß nicht auflösbar.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung Server2: DNS-Prüfung der Forward-Lookupzone sub.gfnlab.test mit Server2-Hosteintrag 192.168.1.202.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung Server3: DNS-Prüfung der Forward-Lookupzone it.pro.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: server2.sub.gfnlab.test erfolgreich; server3.it.pro vor bedingter Weiterleitung nicht erfolgreich.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: neue bedingte Weiterleitung für it.pro wird vorbereitet.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: bedingte Weiterleitung für it.pro mit tatsächlicher Server3-IP 192.168.1.203 statt Beispielwert aus der Aufgabenstellung 192.168.1.3.

Abbildung anzeigen

11.7 Gesamtstruktur-, DNS- und Namensauflösungsprüfung DC: server3.it.pro ist nach bedingter Weiterleitung erfolgreich auflösbar (192.168.1.203).

Abbildung anzeigen

Abschluss: Hyper-V-Prüfpunkte Basis-AD Host: Start der Prüfpunkt-Erstellung im Hyper-V-Manager.

Abbildung anzeigen

Abschluss: Hyper-V-Prüfpunkte Basis-AD Host: Prüfpunkt Basis-AD für DC sichtbar/benannt.

Abbildung anzeigen

Abschluss: Hyper-V-Prüfpunkte Basis-AD Host: Prüfpunkt Basis-AD für Server1 bzw. weitere VM sichtbar.

Abbildung anzeigen

Abschluss: Hyper-V-Prüfpunkte Basis-AD Host: Prüfpunkt Basis-AD für Server2 sichtbar.

Abbildung anzeigen

Abschluss: Hyper-V-Prüfpunkte Basis-AD Host: Prüfpunkt Basis-AD für Server3 sichtbar.

Abbildung anzeigen

Abschluss: Hyper-V-Prüfpunkte Basis-AD Host: Abschlussnachweis der Prüfpunkte Basis-AD, inklusive W11.

Einsatzrahmen: Die gezeigte Topologie ist eine Lernumgebung; sie wird nicht als heutiger aktiver Verzeichnisdienst dargestellt.

Praxis und Ergebnis

FSMO-Rollen, RODC und Kennwortreplikation

FSMO-Rollen übertragen, Server1 als RODC neu aufbauen, delegierte Administration, PRP und DHCP-Rollback bearbeiten.

1. Ziel, Ergebnis und Zusammenhang zu Block 11

Block 12 baut direkt auf dem in Block 11 erstellten Prüfpunkt Basis-AD auf. Während Block 11 die Active-Directory-Grundstruktur erzeugt hat, behandelt Block 12 administrative Eingriffe an dieser Infrastruktur: Betriebsmasterrollen, Rückbau und Neuaufbau eines Domänencontrollers als RODC, delegierte Verwaltung, RODC-Kennwortreplikationsrichtlinien und DHCP als zentralen Infrastrukturdienst.

FSMO-RollenSchemaMaster auf Server2.sub.gfnlab.test
DomainNamingMaster auf Server3.it.pro.

RODC-ÜbungServer1 wurde zunächst herabgestuft, bereinigt und anschließend als schreibgeschützter Domänencontroller neu bereitgestellt.

Delegierte Verwaltungrodc-admin wurde zur lokalen RODC-Verwaltung verwendet, ohne vollständige AD-Schreibrechte zu besitzen.

DHCP-TestW11 erhielt im tatsächlichen Verlauf eine DHCP-Adresse aus dem Bereich 192.168.1.40-50.

Gesamtergebnis: Die wesentlichen Aufgaben aus Arbeitsblock wurden technisch durchgeführt und über Screenshots nachvollziehbar belegt. Am Ende wurden die VMs wieder auf Basis-AD zurückgesetzt.

2. Ausgangslage und Laborkontext

Die Übung startet aus einer Active-Directory-Umgebung mit mehreren Domänencontrollern und Domänen aus Block 11. Die spätere Rücksetzung auf Basis-AD zeigt, dass Block 12 bewusst als Labor- und Lernsequenz durchgeführt wurde und nicht als dauerhaft beizubehaltender Zielzustand.

System	Rolle im Kontext von Block 12	Nachweisbare Werte / Funktion
`DC`	Hauptverwaltungsserver der Stammdomäne	`gfnlab.test`, DNS, später DHCP, IP `192.168.1.200`
`Server1`	zunächst Domänencontroller, anschließend herabgestuft und als RODC neu bereitgestellt	RODC für `gfnlab.test`, IP `192.168.1.201`
`Server2`	Domänencontroller der Subdomain	`sub.gfnlab.test`, neuer Schema-Master
`Server3`	Domänencontroller der Strukturdomäne	`it.pro`, neuer Domänennamen-Master
`W11`	Client für DHCP-Test	vorher statisch `192.168.1.204`, nach DHCP `192.168.1.40`

3. FSMO-Rollen prüfen und übertragen

Zu Beginn wurden die FSMO-Rollen mit netdom query fsmo geprüft. Der Schema-Master wurde auf Server2.sub.gfnlab.test übertragen. Anschließend wurde der Domänennamen-Master per PowerShell auf Server3.it.pro verschoben und mit Get-ADForest sowie erneut mit netdom query fsmo kontrolliert.

netdom query fsmo
regsvr32.exe schmmgmt.dll
Move-ADDirectoryServerOperationMasterRole -Identity SERVER3 -OperationMasterRole DomainNamingMaster -Confirm:$false
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
netdom query fsmo

12.1 FSMO-RollenFSMO-Zwischenstand Schema-Master bereits auf Server2, Domänennamen-Master noch auf DC.

12.1 FSMO-RollenFSMO-Endzustand SchemaMaster liegt auf Server2.sub.gfnlab.test; DomainNamingMaster liegt auf Server3.it.pro.

Technischer Zusammenhang: Der Schema-Master ist forestweit für Schemaänderungen zuständig. Der Domänennamen-Master kontrolliert Änderungen am Domänennamensraum der Gesamtstruktur. Die Verteilung auf Server2 und Server3 ist im Labor didaktisch sinnvoll, weil sie die forestweite Rolle dieser Betriebsmaster sichtbar macht.

4. Server1 als Domänencontroller herabstufen

Server1 wurde zunächst aus der Rolle als Domänencontroller entfernt. Der Server-Manager verhindert das reine Entfernen der AD-DS-Rolle, solange der Server noch Domänencontroller ist. Daher musste zuerst der Herabstufungsassistent ausgeführt werden. Anschließend wurde Server1 aus der Domäne genommen und in WORKGROUP verschoben.

12.2.2 HerabstufungValidierung: Tieferstufung erforderlich AD DS kann nicht entfernt werden, bevor der Domänencontroller tiefergestuft wurde.

Weiterer NachweisHerabstufungsassistent

Weiterer NachweisWarnung zu DNS und AD DS

Weiterer NachweisHerabstufung erfolgreich

Weiterer NachweisAustritt aus der Domäne

Weiterer NachweisDomain Controllers bereinigt

Weiterer NachweisServerobjekt in Sites löschen

Weiterer NachweisDNS-/SRV-Prüfung

5. RODC-Admin und RODC-Konto vorbereiten

Für die RODC-Übung wurde zunächst der Benutzer rodc-admin erstellt. Danach wurde auf DC ein Konto für einen schreibgeschützten Domänencontroller mit dem Namen Server1 vorbereitet. Die spätere Installation und lokale Verwaltung wurde an den Benutzer RODC Admin delegiert.

Hinweis zur Laborsicherheit: Die Aufgabenstellung verwendet [Laborkennwort nicht angezeigt] und teils nicht produktive Kennworteinstellungen. Das ist für die Laborübung zulässig, aber keine Best Practice für produktive Umgebungen.

Weiterer NachweisBenutzer rodc-admin

Weiterer NachweisRODC-Konto Server1

Weiterer NachweisDelegierung an RODC Admin

Weiterer NachweisZusammenfassung RODC-Konto

Weiterer NachweisServer1 nicht mehr im Computers-Container

Weiterer NachweisNetzwerkkontext Server1

6. Server1 als RODC bereitstellen

Nach der Vorbereitung wurde Server1 erneut als Domänencontroller in gfnlab.test eingerichtet. Entscheidend ist hier, dass nicht ein normaler schreibbarer Domänencontroller installiert wurde, sondern das zuvor vorbereitete RODC-Konto verwendet wurde.

Weiterer NachweisBereitstellung in vorhandener Domäne

Weiterer NachweisVorhandenes RODC-Konto

Weiterer NachweisRODC-Bereitstellung erfolgreich

Weiterer NachweisAnmeldung mit rodc-admin

Technischer Zusammenhang: Ein RODC speichert eine schreibgeschützte Kopie von Active Directory. Er ist für Standorte geeignet, an denen ein Domänencontroller benötigt wird, aber kein vollständiger schreibender DC betrieben werden soll.

7. Berechtigungsprüfung mit rodc-admin

Die Rechteprüfung zeigt den Unterschied zwischen lokaler RODC-Verwaltung und vollständiger AD-Administration.rodc-admin kann Server1 lokal verwalten, erhält dadurch aber keine allgemeinen Schreibrechte in Active Directory oder DNS.

ADUC
Reguläre Objektanlage im AD ist nicht als vollwertige Domänenverwaltung möglich.

DNS
DNS-Schreiboperationen sind im RODC-/Delegationskontext eingeschränkt.

Dienste
Lokale Dienstverwaltung auf Server1 ist möglich, z. B. Neustart von AD DS.

Weiterer NachweisADUC: eingeschränkte Rechte

Weiterer NachweisDNS: eingeschränkte Rechte

Weiterer NachweisDienstverwaltung möglich

Abbildung anzeigen

12.2.3 RechteprüfungRODC-Kontext als Ursache Die eingeschränkten Rechte passen zur Bereitstellung über ein vorhandenes RODC-Konto.

8. Kennwortreplikationsrichtlinie des RODC

Für den Test der Password Replication Policy wurden in OU1 zwei Benutzer erstellt:Übungskonto A(as) und Übungskonto B(dw). Danach wurde auf dem RODC Server1 festgelegt, dass Übungskonto A zugelassen und Übungskonto B explizit verweigert wird.

Weiterer NachweisOU1 als Testcontainer

Weiterer NachweisTestbenutzer in OU1

Weiterer NachweisRODC-spezifische Registerkarte

Personenbezogene Kontodaten werden nicht angezeigt.

12.2.3 KennwortreplikationZulassen/Verweigern konfiguriert Übungskonto A ist zugelassen, Übungskonto B ist explizit verweigert.

Personenbezogene Kontodaten werden nicht angezeigt.

12.2.3 KennwortreplikationFehler beim Kennwortauffüllen Der Versuch, ein nicht zugelassenes bzw. verweigertes Kennwort aufzufüllen, wird durch die Richtlinie blockiert.

Weiterer NachweisPowerShell-Prüfung

Get-ADDomainControllerPasswordReplicationPolicy -Identity Server1
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity Server1

Bewertung: Die Richtlinie selbst ist sauber belegbar: Übungskonto A ist zugelassen, Übungskonto B wird verweigert. Der vorhandene PowerShell-Nachweis zeigt jedoch nicht eindeutig, dass das Kennwort von Übungskonto A bereits erfolgreich auf Server1 aufgefüllt wurde. Deshalb wird nur die konfigurierte Richtlinie und der geprüfte Policy-Status dokumentiert, nicht eine eindeutig abgeschlossene Kennwortvorab-Replikation für Übungskonto A.

Hinweis zu krbtgt_676: Das im Screenshot sichtbare Konto krbtgt_676 ist kein von dir manuell angelegter Benutzer. In RODC-Kontexten können spezielle Kerberos-/RODC-bezogene Konten sichtbar werden. Es wird deshalb nicht als eigener Arbeitsschritt dokumentiert.

9. DHCP auf DC installieren und konfigurieren

In Übung 12.3 wurde auf DC die Rolle DHCP-Server installiert. Anschließend wurde die Postinstallationskonfiguration durchgeführt, wobei die AD-Autorisierung zunächst gemäß Aufgabenstellung übersprungen wurde. Danach wurde ein IPv4-Bereich für Client-Leases erstellt.

Weiterer NachweisDHCP-Rolle auswählen

Weiterer NachweisDHCP-Installation erfolgreich

Weiterer NachweisAD-Autorisierung überspringen

Weiterer NachweisPostinstallationsschritte abgeschlossen

DHCP-Konfiguration	Wert	Einordnung
Bereichsname	`Bereich-1`	DHCP-Scope für W11-Test
Adresspool	`192.168.1.40` bis `192.168.1.50`	11 mögliche Client-Adressen
Subnetz	`255.255.255.0`/`/24`	Netz `192.168.1.0/24`
Router/Gateway	`192.168.1.254`	DHCP-Option 003
DNS-Server	`192.168.1.200`	DC/DNS der Stammdomäne
DNS-Suffix	`gfnlab.test`	Domänensuffix für Clients

Weiterer NachweisBereich-1

Weiterer NachweisAdresspool

Weiterer NachweisRouter-Option

Weiterer NachweisDNS-Option

Weiterer NachweisBereich aktivieren

Weiterer NachweisDHCP-Konsole nutzbar

10. DHCP-Test mit W11 und beobachtete Abweichung

Auf W11 wurde die zuvor manuelle IP-Konfiguration auf Automatisch (DHCP) umgestellt. Danach erhielt der Client im tatsächlichen Laborverlauf eine Adresse aus dem konfigurierten DHCP-Bereich.

Weiterer NachweisW11 vor DHCP

Weiterer NachweisUmstellung auf DHCP

Weiterer NachweisDHCP-Lease sichtbar

Weiterer Nachweisipconfig /renew

Beobachtete Laborabweichung: Die Aufgabenstellung erwartet zunächst einen DHCP-Fehlschlag. Im vorhandenen Nachweis erhielt W11 bereits eine gültige Lease; ein nicht belegter Fehlschlag wird daher nicht behauptet.

Mögliche technische Erklärung: Der Server wurde im tatsächlichen Verlauf offenbar rechtzeitig autorisiert/aktualisiert oder die Konsole zeigte bereits den nutzbaren Zustand, bevor der W11-Test dokumentiert wurde. Entscheidend ist: Der Nachweis belegt eine funktionierende DHCP-Vergabe, nicht den von der Aufgabenstellung erwarteten Zwischenfehler.

11. Rollback auf Basis-AD

Nach Abschluss der DHCP-Übung wurden alle VMs auf den Prüfpunkt Basis-AD zurückgesetzt. Damit war der Laborzustand aus dem vorherigen Arbeitsabschnitt wiederhergestellt; die Übung hinterließ keine dauerhafte Änderung der Basisumgebung.

Get-VM | Restore-VMCheckpoint -Name Basis-AD -Confirm:$false

Weiterer NachweisRollback auf Basis-AD

Abbildung anzeigen

12.3 RollbackVorheriger Übungszustand Die Übung hatte zuvor FSMO- und Rollenänderungen erzeugt, die durch den Rollback nicht als dauerhafte Zielkonfiguration bestehen bleiben.

Ergebniszustand: Der Arbeitsblock war ein Labordurchlauf. Nach dem Rollback war Basis-AD wieder der technische Endzustand.

12. Fazit, Risiken und Fachliche Erkenntnisse

Bearbeitete Technologien und Aufgaben
FSMO-Rollen, AD DS, RODC, delegierte Verwaltung, DNS-Prüfung und DHCP-Konfiguration wurden praktisch bearbeitet.

Wichtige Systemunterscheidung
Normaler Domänencontroller, herabgestufter Server, vorbereitetes RODC-Konto und tatsächlich bereitgestellter RODC wurden klar voneinander getrennt.

Laborabweichung: Der DHCP-Test wird entsprechend dem tatsächlich beobachteten Ergebnis bewertet.

Wesentliche Erkenntnisse

FSMO-Rollen wurden nach der Assistentenmeldung zusätzlich explizit geprüft.
Ein Domänencontroller kann nicht einfach durch Entfernen der AD-DS-Rolle zurückgebaut werden; er muss zuerst sauber tiefergestuft werden.
Ein RODC trennt lokale Verwaltung von vollständiger Domänenadministration.
Die Kennwortreplikationsrichtlinie ist ein Sicherheitsmechanismus: Nur zugelassene Konten können ihre Kennwörter auf dem RODC zwischenspeichern.
DHCP ist in AD-Umgebungen nicht nur eine Adresspool-Frage; Autorisierung, Scope-Optionen, DNS-Suffix und Client-Test gehören zusammen.
Nach dem Rollback war Basis-AD wieder der Endzustand; die vorherigen Schritte bleiben Labor-Zwischenstände.

Fachliche Grenzen

DHCP-Zwischenfehler: Der erwartete APIPA-/Fehlschlagzustand ist nicht belegt; belegt ist die erfolgreiche Lease-Vergabe.
Kennwortauffüllen: Die PRP-Konfiguration ist belegt. Eine erfolgreiche Vorab-Replikation des Kennworts von Übungskonto A ist anhand des PowerShell-Screenshots nicht eindeutig belegt.
Fachliche Grenze: Kennwörter und einzelne Einstellungen sind labortypisch und keine produktive Best Practice.

14. Weitere technische Nachweise

Abbildung anzeigen

12.1 FSMO-RollenFSMO-Übersicht mit bereits übertragenem Schema-Master CMD-Ausgabe auf DC: Schema-Master liegt bereits auf Server2.sub.gfnlab.test; Domänennamen-Master liegt zu diesem Zeitpunkt noch auf DC.gfnlab.test.

Abbildung anzeigen

12.1 FSMO-RollenEndnachweis der übertragenen FSMO-Rollen PowerShell/CMD-Nachweis: SchemaMaster = Server2.sub.gfnlab.test und DomainNamingMaster = Server3.it.pro; PDC, RID-Pool-Manager und Infrastrukturmaster verbleiben auf DC.gfnlab.test.

Abbildung anzeigen

12.2.2 Server1 herabstufenAD-DS-Rolle kann erst nach Herabstufung entfernt werden Server-Manager meldet erwartungsgemäß, dass vor dem Entfernen der AD-DS-Rolle der Domänencontroller tiefergestuft werden muss.

Abbildung anzeigen

12.2.2 Server1 herabstufenAssistent zur Herabstufung von Server1 Konfigurations-Assistent für Active-Directory-Domänendienste auf Server1; Zielserver Server1.gfnlab.test, Anmeldekontext GFNLAB\Administrator.

Abbildung anzeigen

12.2.2 Server1 herabstufenWarnung beim Entfernen der DC-Rolle Server1 hostet zu diesem Zeitpunkt noch DNS; die Entfernung wird bewusst fortgesetzt, da der Server im Laborablauf vom Domänencontroller zum Mitglieds-/Workgroup-System zurückgeführt werden soll.

Weiterer NachweisTieferstufung wird ausgeführt

Abbildung anzeigen

12.2.2 Server1 herabstufenServer1 erfolgreich tiefergestuft Ergebnisfenster: Der Domänencontroller wurde erfolgreich tiefergestuft; Windows meldet den folgenden automatischen Neustart.

Abbildung anzeigen

12.2.2 Server1 herabstufenServer1 tritt aus der Domäne in WORKGROUP aus Systemeigenschaften auf Server1: Nach der Herabstufung wird die Domänenmitgliedschaft beendet und Server1 in WORKGROUP verschoben.

Abbildung anzeigen

12.2.2 BereinigungServer1 nicht mehr in Domain Controllers sichtbar ADUC auf DC: In der OU Domain Controllers ist nach Aktualisierung nur noch DC sichtbar; Server1 ist nicht mehr als aktiver Domänencontroller vorhanden.

Weiterer NachweisComputerobjekte im Container Computers

Abbildung anzeigen

12.2.2 BereinigungServer1 aus Active Directory-Standorte und -Dienste entfernt AD-Standorte und -Dienste: Das Serverobjekt SERVER1 wird aus Default-First-Site-Name/Servers gelöscht, um die frühere DC-Repräsentation zu bereinigen.

Abbildung anzeigen

12.2.2 BereinigungDNS-Prüfung nach Entfernung von Server1 DNS-Manager auf DC: Die _msdcs-Zone zeigt DC, Server2 und Server3 als Nameserver-/SRV-Kontext; Server1 ist nicht mehr als DC-SRV-Ziel enthalten.

Abbildung anzeigen

12.2.2 RODC-VorbereitungBenutzer RODC Admin wird erstellt ADUC: Benutzer RODC Admin mit Anmeldename rodc-admin wird im Container Users angelegt.

Abbildung anzeigen

12.2.2 RODC-VorbereitungRODC-Konto für Server1 vorbereiten Assistent zum Vorbereiten eines schreibgeschützten Domänencontrollers: Computername Server1, FQDN Server1.gfnlab.test.

Abbildung anzeigen

12.2.2 RODC-VorbereitungDelegierung an RODC Admin RODC-Assistent: Für Installation und lokale Verwaltung des RODC wird das Konto RODC Admin ausgewählt.

Abbildung anzeigen

12.2.2 RODC-VorbereitungZusammenfassung des vorbereiteten RODC-Kontos Zusammenfassung: RODC-Konto Server1.gfnlab.test, Globaler Katalog/DNS vorgesehen, Quelldomänencontroller DC.gfnlab.test, Kennwortreplikationsgruppe hinterlegt.

Abbildung anzeigen

12.2.2 RODC-VorbereitungServer1 nach vorbereiteter RODC-Kontoanlage nicht mehr im Computers-Container ADUC: Im Computers-Container sind Server2, Server3 und W11 sichtbar; Server1 wurde in den Domain-Controllers-Kontext vorbereitet.

Abbildung anzeigen

12.2.3 RODC-BereitstellungServer1-Netzwerkkontext vor RODC-Bereitstellung CMD auf Server1: IP-Konfiguration mit 192.168.1.201 und DNS-Server 192.168.1.200; Grundlage für die anschließende RODC-Bereitstellung.

Abbildung anzeigen

12.2.3 RODC-BereitstellungServer1 wird zur vorhandenen Domäne hinzugefügt AD-DS-Konfigurationsassistent auf Server1: Domänencontroller zu vorhandener Domäne gfnlab.test hinzufügen; Anmeldeinformationen werden angegeben.

Abbildung anzeigen

12.2.3 RODC-BereitstellungVorhandenes RODC-Konto wird verwendet Domänencontrolleroptionen: Vorhandenes RODC-Konto verwenden, schreibgeschützter Domänencontroller, globaler Katalog; DSRM-Kennwort gesetzt.

Abbildung anzeigen

12.2.3 RODC-BereitstellungServer1 erfolgreich als Domänencontroller konfiguriert Ergebnisfenster: Server1 wurde erfolgreich als Domänencontroller konfiguriert; Neustart folgt automatisch.

Abbildung anzeigen

12.2.3 RechteprüfungAnmeldung als gfnlab\rodc-admin Anmeldebildschirm auf Server1: Der delegierte Benutzer rodc-admin wird zur Prüfung der RODC-Verwaltungsrechte verwendet.

Abbildung anzeigen

12.2.3 RechteprüfungEingeschränkte ADUC-Rechte als RODC Admin ADUC auf Server1: Der Benutzer rodc-admin kann keine normalen AD-Verwaltungsaktionen wie das Erstellen neuer Objekte im erwarteten Umfang durchführen.

Abbildung anzeigen

12.2.3 RechteprüfungEingeschränkte DNS-Verwaltung als RODC Admin DNS-Manager auf Server1: Kontextmenü zeigt eingeschränkte bzw. nicht verfügbare Zonenaktionen; ein neuer Host-A-Eintrag ist im RODC-Kontext nicht als reguläre DNS-Schreiboperation vorgesehen.

Abbildung anzeigen

12.2.3 RechteprüfungNeustart des AD-DS-Dienstes durch RODC Admin möglich Dienstekonsole auf Server1: Neustart von Active Directory-Domänendienste wird angestoßen; abhängige Dienste werden mit neu gestartet.

Abbildung anzeigen

12.2.3 KennwortreplikationOU1 wird erstellt ADUC auf DC: Neue Organisationseinheit OU1 als Arbeitsbereich für Testbenutzer der RODC-Kennwortreplikation.

Weiterer NachweisBenutzer Übungskonto B wird angelegt

Weiterer NachweisBenutzer Übungskonto A wird angelegt

Abbildung anzeigen

12.2.3 KennwortreplikationTestbenutzer in OU1 angelegt ADUC: Übungskonto A und Übungskonto B sind in OU1 sichtbar und dienen als Testkonten für unterschiedliche Kennwortreplikationsrichtlinien.

Abbildung anzeigen

12.2.3 KennwortreplikationServer1 besitzt RODC-spezifische Registerkarte Eigenschaften von SERVER1: Registerkarte Kennwortreplikationsrichtlinie ist vorhanden; dies unterscheidet den RODC von einem normalen schreibbaren Domänencontroller.

Personenbezogene Kontodaten werden nicht angezeigt.

12.2.3 KennwortreplikationKennwortreplikationsrichtlinie mit Zulassen/Verweigern RODC-Kennwortreplikationsrichtlinie: Übungskonto A wird zugelassen; Übungskonto B wird explizit verweigert.

Personenbezogene Kontodaten werden nicht angezeigt.

12.2.3 KennwortreplikationFehler beim Auffüllen eines nicht zugelassenen Kennworts Erwartbare Schutzwirkung der Richtlinie: Für ein nicht zugelassenes bzw. explizit verweigertes Konto kann das Kennwort nicht auf dem RODC aufgefüllt werden.

Abbildung anzeigen

12.2.3 KennwortreplikationPowerShell-Prüfung der RODC-PRP PowerShell: Get-ADDomainControllerPasswordReplicationPolicy und Get-ADDomainControllerPasswordReplicationPolicyUsage für Server1. Die Richtlinie ist sichtbar; die tatsächlich aufgefüllten Konten sind nur teilweise eindeutig nachgewiesen.

Abbildung anzeigen

12.3 DHCPDHCP-Rolle wird auf DC installiert Server-Manager auf DC: DHCP-Server-Rolle wird ausgewählt; benötigte Verwaltungstools werden hinzugefügt.

Abbildung anzeigen

12.3 DHCPDHCP-Installation erfolgreich Installationsstatus: DHCP-Server und Verwaltungstools wurden erfolgreich installiert; Konfiguration ist noch erforderlich.

Abbildung anzeigen

12.3 DHCPDHCP-Postinstallationsassistent: AD-Autorisierung überspringen DHCP-Konfigurations-Assistent: AD-Autorisierung wird gemäß Aufgabenstellung zunächst übersprungen, um die spätere Wirkung der Autorisierung zu demonstrieren.

Abbildung anzeigen

12.3 DHCPDHCP-Postinstallationsschritte abgeschlossen Zusammenfassung: Sicherheitsgruppen wurden erstellt; DHCP-Dienst muss neu gestartet werden, damit die Gruppen wirksam werden.

Abbildung anzeigen

12.3 DHCPDHCP-Bereich Bereich-1 wird erstellt DHCP-Konsole auf DC: Bereichserstellungs-Assistent mit Name Bereich-1.

Abbildung anzeigen

12.3 DHCPDHCP-Adresspool 192.168.1.40-50 DHCP-Bereich: Start-IP 192.168.1.40, End-IP 192.168.1.50, Präfixlänge 24, Subnetzmaske 255.255.255.0.

Abbildung anzeigen

12.3 DHCPDHCP-Option Router/Standardgateway DHCP-Option 003 Router: 192.168.1.254 wird als Standardgateway an Clients verteilt.

Abbildung anzeigen

12.3 DHCPDHCP-Option DNS und Domänensuffix DHCP-Optionen: DNS-Suffix gfnlab.test und DNS-Server 192.168.1.200 werden gesetzt.

Abbildung anzeigen

12.3 DHCPDHCP-Bereich aktivieren Bereichserstellungs-Assistent: Der Bereich wird direkt aktiviert, damit Clients Leases aus dem definierten Pool erhalten können.

Weiterer NachweisDHCP-Konsole fordert Autorisierung

Abbildung anzeigen

12.3 DHCPDHCP-Konsole nach Autorisierung/Aktualisierung DHCP-Konsole: IPv4/IPv6 zeigen grüne Statussymbole; der Server ist für den weiteren Test nutzbar.

Abbildung anzeigen

12.3 W11-TestW11 vor Umstellung auf DHCP Windows 11: Vor der Umstellung ist eine manuelle IP-Konfiguration sichtbar: 192.168.1.204, DNS 192.168.1.200.

Abbildung anzeigen

12.3 W11-TestW11 wird auf Automatisch (DHCP) umgestellt Windows 11: IP-Zuweisung wird von Manuell auf Automatisch (DHCP) geändert.

Abbildung anzeigen

12.3 W11-TestW11 erhält DHCP-Adresse 192.168.1.40 Windows 11: Nach der Umstellung erhält der Client per DHCP 192.168.1.40, Gateway 192.168.1.254, DNS 192.168.1.200 und DNS-Suffix gfnlab.test.

Abbildung anzeigen

12.3 W11-Testipconfig /renew bestätigt DHCP-Lease CMD auf W11: ipconfig und ipconfig /renew bestätigen die DHCP-Adresse 192.168.1.40 und das Standardgateway 192.168.1.254.

Abbildung anzeigen

12.3 RollbackAlle VMs auf Prüfpunkt Basis-AD zurückgesetzt Lab-Host: Get-VM | Restore-VMCheckpoint -Name Basis-AD -Confirm:$false setzt alle VMs auf den Abschlusszustand aus Block 11 zurück.

Fachliche Grenze: PRP-Einstellungen sind sichtbar; tatsächliche Kennwortvorhaltung und der erwartete DHCP-Zwischenfehler sind nicht eindeutig bildlich belegt.

Praxis und Ergebnis

Active-Directory-Objektverwaltung und Delegation

OUs, Benutzer, Computer, Importwege, Gruppenverschachtelung, Freigaben, Delegation und RSAT anwenden.

1. Ziel, Ergebnis und Laborkontext

Block 13 erweitert die in den vorherigen Blöcken aufgebaute Active-Directory-Umgebung um typische Verwaltungsaufgaben eines Windows-Administrators. Der Fokus liegt nicht nur auf dem Erstellen von Objekten, sondern auf nachvollziehbarer Verwaltung: objektbezogene Berechtigungen, sichere Strukturierung durch OUs, Gruppenverschachtelung nach dem I-G-DL-P-Prinzip und gezielte Delegation von Verwaltungsrechten.

AD-Struktur OUs in gfnlab.test,sub.gfnlab.test und it.pro erstellt bzw. importiert.

Benutzerverwaltung Benutzer per GUI, PowerShell und CSV angelegt; Konten geprüft, deaktiviert und abgefragt.

Berechtigungen Freigabe \\dc\Freigabe-Produktion mit Share- und NTFS-Rechten umgesetzt und getestet.

DelegationÜbungskonto F erhielt OU-begrenzte Rechte für Benutzerverwaltung und Passwortreset.

Gesamtergebnis: Die Aufgaben 13.1 bis 13.4 wurden abgeschlossen. Die Nachweise zeigen die Objekterstellung, Funktionsprüfungen, Berechtigungswirkung und abschließende Sicherung über den Prüfpunkt Tag_13_AD_Objekte.

2. Ausgangslage und beteiligte Systeme

Die Übung wurde in der Windows-Server-2022-Laborumgebung auf dem Hyper-V-Host [Laborhost] durchgeführt. Die Domänenstruktur aus den vorherigen Blöcken war die Voraussetzung für die domänenübergreifenden Gruppen- und Freigabetests.

System / Domäne	Rolle in Block 13	Wichtige Nachweise
`DC`/`gfnlab.test`	Zentrale Verwaltung der Stammdomäne, ADUC, Freigabe `C:\Freigabe-Produktion`	OU-Struktur, Benutzer, Gruppen, Freigabe, Delegation
`Server2`/`sub.gfnlab.test`	Subdomäne für OU- und Benutzerverwaltung sowie globale IT-Gruppe	`Hacke Peter`,`Roman Held`,`G_IT-Mitarbeiter-SUB-GFNLAB`
`Server3`/`it.pro`	Weitere Domäne für CSVDE-Import und globale IT-Gruppe	`Stella Inter`,`Theo Logie`,`G_IT-Mitarbeiter-IT-PRO`
`W11`	Client für Anmelde-, Zugriff- und RSAT-Tests	Zeitbeschränkung, Freigabezugriff, RSAT/MMC

Maßgeblich ist der tatsächlich ausgeführte Verlauf; Fehler und Abweichungen bleiben als technische Zwischenzustände erkennbar.

3. 13.1 - AD-Objekte erstellen

In Aufgabe 13.1 wurden AD-Objekte auf drei verschiedene Arten erstellt: grafisch über ADUC, automatisiert per PowerShell und importiert über CSVDE bzw. CSV/PowerShell. Dadurch wird derselbe administrative Grundvorgang aus mehreren praxisrelevanten Perspektiven abgedeckt.

Durchgeführte Schritte

OU-Struktur Abteilungen / IT, Marketing, Produktion / Benutzer, Computer, Gruppen in gfnlab.test per GUI erstellt.
Gleiche OU-Struktur in sub.gfnlab.test per PowerShell erstellt.
OU-Struktur für it.pro über CSVDE exportiert, angepasst und importiert.
Benutzer Übungskonto A und Übungskonto B per GUI in IT/Benutzer angelegt.
Justin Time per New-ADUser in Marketing/Benutzer erstellt.
Mehrere Marketing-Benutzer über C:\temp\Benutzer.csv und PowerShell-ISE importiert.
Computerkonto Client1 in Produktion/Computer angelegt.

Get-ADUser -Filter * -SearchBase "OU=Abteilungen,DC=gfnlab,DC=test" | Select-Object Name New-ADUser `
-Name "Justin Time" -DisplayName "Justin Time" -Surname Time `
-GivenName Justin -UserPrincipalName jt@gfnlab.test -SamAccountName jt `
-Enabled 1 -AccountPassword (ConvertTo-SecureString -AsPlainText '[Laborkennwort nicht angezeigt]' -Force) `
-Path "OU=Benutzer,OU=Marketing,OU=Abteilungen,DC=gfnlab,DC=test" `
-ChangePasswordAtLogon 0 $password = ConvertTo-SecureString -String '[Laborkennwort nicht angezeigt]' -AsPlainText -Force
$newuser = Import-Csv -Path C:\temp\Benutzer.csv
$newuser | New-ADUser -Enabled $true -AccountPassword $password `
-Path 'OU=Benutzer,OU=Marketing,OU=Abteilungen,DC=gfnlab,DC=test'

Beobachtung aus dem Verlauf: Beim erneuten Ausführen des CSV-Imports meldete PowerShell IdentityAlreadyExistsException. Das war in diesem Fall kein Grundfehler der Umgebung, sondern die erwartbare Folge davon, dass die Benutzer bereits erfolgreich angelegt waren.

13.1OU-Struktur in gfnlab.test Die Domäne gfnlab.test enthält die OU-Struktur Abteilungen mit IT, Marketing und Produktion sowie den Unter-OUs Benutzer, Computer und Gruppen.

13.1OU-Struktur in sub.gfnlab.test per PowerShell Die OUs für die Subdomäne wurden per New-ADOrganizationalUnit vorbereitet.

13.1GUI-Prüfung der Subdomain-OUs Die über PowerShell erzeugte Struktur ist in Active Directory-Benutzer und -Computer sichtbar.

Weiterer NachweisCSVDE-Export der OU-Struktur

Weiterer NachweisCSVDE-Import in it.pro

Weiterer NachweisOU-Struktur in it.pro geprüft

Weiterer NachweisBenutzer Übungskonto A per GUI

Weiterer NachweisÜbungskonto A und Übungskonto B sichtbar

Weiterer NachweisGet-ADUser-Prüfung der Abteilungen

Weiterer NachweisJustin Time per PowerShell

Weiterer NachweisCSV-Datei Benutzer.csv

Weiterer NachweisCSV-Import per PowerShell ISE

Weiterer NachweisMarketing-Benutzer nach CSV-Import

Weiterer NachweisComputerkonto Client1 anlegen

Weiterer NachweisComputerkonto Client1 geprüft

4. 13.2 - Konten bearbeiten und prüfen

In Aufgabe 13.2 wurde gezeigt, dass Benutzerobjekte nicht nur erstellt, sondern auch administrativ gesteuert werden müssen. Dazu gehörten zeitbasierte Anmeldebeschränkungen, Gruppenmitgliedschaften mit Administrationswirkung, Konto-Deaktivierung und gespeicherte Suchabfragen.

Durchgeführte Prüfungen

Für Übungskonto A wurden Anmeldezeiten konfiguriert und auf W11 getestet.
Übungskonto B wurde von einem normalen Benutzerkonto zur Domänen-Admin-Berechtigung hochgestuft.
Mike Rosoft wurde zuerst erfolgreich angemeldet, danach deaktiviert und erneut getestet.
Eine gespeicherte AD-Abfrage Deaktivierte Konten wurde erstellt und zur Kontrolle genutzt.

Technischer Zusammenhang: Authentifizierung, Autorisierung und Kontoobjektstatus wurden voneinander abgegrenzt. Ein existierendes Konto ist nicht automatisch anmeldbar; Zeitfenster, Deaktivierung und Gruppenmitgliedschaften beeinflussen das Ergebnis.

Weiterer NachweisAnmeldezeiten für Übungskonto A

Weiterer NachweisZeitbeschränkung auf W11 geprüft

Weiterer NachweisÜbungskonto B vor Admin-Rechten

Weiterer NachweisÜbungskonto B als Domänen-Admin

Weiterer NachweisÜbungskonto B mit Administratorrechten

Weiterer NachweisMike Rosoft vor Deaktivierung

Weiterer NachweisMike Rosoft deaktiviert

Weiterer NachweisLogin als Mike Rosoft verweigert

Weiterer NachweisGespeicherte Abfrage: Deaktivierte Konten

5. 13.3 - Berechtigungsmodell, Freigabe und Zugriffstests

Aufgabe 13.3 bildet den fachlich stärksten Teil des Blocks, weil hier AD-Gruppen, Freigabeberechtigungen und NTFS-Berechtigungen zusammenwirken. Die Übung folgt dem Prinzip I-G-DL-P: Identitäten werden in globale Gruppen aufgenommen, globale Gruppen werden in domänenlokale Gruppen verschachtelt, und die domänenlokalen Gruppen erhalten Berechtigungen auf Ressourcen.

Ebene	Umsetzung im Labor	Zweck
Identitäten	Übungskonto A, Übungskonto B, Hacke Peter, Roman Held, Stella Inter, Theo Logie	Benutzerkonten aus unterschiedlichen Domänen
Globale Gruppen	`G_IT-Mitarbeiter-GFNLAB`,`G_IT-Mitarbeiter-SUB-GFNLAB`,`G_IT-Mitarbeiter-IT-PRO`	Abteilungs-/Domänenzuordnung der Benutzer
Domänenlokale Gruppen	`DL_Produktion-Freigabe-RW`,`DL_Produktion-Freigabe-R`	Berechtigungsebene an der Ressource
Ressource	`\\dc\Freigabe-Produktion`/`C:\Freigabe-Produktion`	Praktischer Zugriffstest auf Datei und Ordner

Wichtige Befehle zur Reparatur und Validierung

takeown /F "C:\Freigabe-Produktion" /R /D J
icacls "C:\Freigabe-Produktion" /inheritance:r
icacls "C:\Freigabe-Produktion" /grant "SYSTEM:(OI)(CI)(F)" "Administratoren:(OI)(CI)(F)" "GFNLAB\<Übungskonto>:(OI)(CI)(F)" "GFNLAB\DL_Produktion-Freigabe-R:(OI)(CI)(RX)" "GFNLAB\DL_Produktion-Freigabe-RW:(OI)(CI)(M)" /T
icacls "C:\Freigabe-Produktion"

Rechtekorrektur: Nach dem Deaktivieren der Vererbung fehlten erforderliche explizite Rechte. Die Berechtigungskette wurde durch Besitzübernahme und icacls repariert.

Nachweise zu Gruppen, Freigabe, ACL und Zugriffstests

Weiterer NachweisDomänenlokale Gruppe RW erstellen

Weiterer NachweisDL-Gruppen R und RW geprüft

Weiterer NachweisGlobale Gruppe G_IT-Mitarbeiter-GFNLAB

Weiterer NachweisMitglieder der GFNLAB-IT-Gruppe

Weiterer NachweisSUB-Benutzer Hacke Peter und Roman Held

Weiterer NachweisSUB-Gruppe mit Mitgliedern

Weiterer Nachweisit.pro-Benutzer per PowerShell

Weiterer Nachweisit.pro-Gruppe mit Mitgliedern

Weiterer NachweisOrdner und Datei für Freigabe

Weiterer NachweisFreigabe und Share-Berechtigungen

Weiterer NachweisNTFS-Vererbung entfernt - Stolperstelle

Weiterer NachweisNTFS-Berechtigung für R-Gruppe

Weiterer NachweisNTFS-Berechtigung für RW-Gruppe

Weiterer NachweisFinale ACL am Ordner

Weiterer Nachweisicacls-Validierung und Reparatur

Weiterer NachweisGFNLAB-Gruppe in DL-RW

Weiterer NachweisSUB-Gruppe in DL-RW

Weiterer NachweisIT-PRO-Gruppe in DL-R

Weiterer NachweisÜbungskonto B Schreibtest

Weiterer NachweisHacke Peter Schreibtest

Weiterer NachweisCory Ander Zugriff verweigert

Ergebnis der Zugriffstests: Übungskonto B und Hacke Peter konnten schreiben, weil ihre globalen Gruppen in der domänenlokalen RW-Gruppe verschachtelt waren. Die it.pro-Gruppe wurde der R-Gruppe zugeordnet. Cory Ander erhielt keinen Zugriff, da er keine passende Gruppenmitgliedschaft für die Freigabe hatte.

6. 13.4 - Delegation und RSAT-Prüfung mit Übungskonto F

In Aufgabe 13.4 wurde die Verwaltung der OU Abteilungen / Marketing / Benutzer an Übungskonto F delegiert. Ziel war nicht, Übungskonto F allgemein zur Administratorin zu machen, sondern ihr begrenzte Rechte für eine konkrete OU zu geben: Benutzerkonten erstellen, entfernen und verwalten sowie Kennwörter zurücksetzen.

Delegierte Rechte und praktische Prüfung

Die Delegation wurde über den Assistenten Objektverwaltung zuweisen in ADUC vorgenommen.
Die erweiterten Features wurden aktiviert, um die Sicherheitsberechtigungen sichtbar zu prüfen.
Auf W11 wurden die AD DS-/LDS-RSAT-Tools installiert.
Übungskonto F öffnete ADUC über MMC auf W11 und konnte das Passwort von Übungskonto E in der delegierten OU zurücksetzen.
Der Passwortreset für Übungskonto B in einer anderen OU wurde verweigert.
In anderen OUs konnte Übungskonto F keine Benutzer erstellen; das Kontextmenü bot dafür keine passende Aktion an.

ping 8.8.8.8
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Technischer Zusammenhang: Delegation wirkt objekt- und containerbezogen. Übungskonto F erhielt Rechte für Marketing/Benutzer, aber keine domänenweiten Administratorrechte. Genau diese Begrenzung wurde durch erfolgreiche und fehlgeschlagene Aktionen nachgewiesen.

Weiterer NachweisDelegation: Übungskonto F auswählen

Weiterer NachweisDelegation: Aufgaben auswählen

Weiterer NachweisAD-Berechtigungen von Übungskonto F prüfen

Weiterer NachweisW11 mit Internetzugriff für RSAT

Weiterer NachweisUAC mit Administrator für RSAT

Weiterer NachweisRSAT-Installation erfolgreich

Weiterer NachweisADUC-Snap-In in MMC hinzufügen

Weiterer NachweisADUC über MMC auf W11 geöffnet

Personenbezogene Kontonamen und lokale Benutzerdaten werden nicht angezeigt.

13.4Übungskonto E Passwort zurücksetzen Übungskonto F setzt innerhalb der delegierten OU das Kennwort für Übungskonto E zurück.

Personenbezogene Kontonamen und lokale Benutzerdaten werden nicht angezeigt.

13.4Passwortänderung für Übungskonto E erfolgreich Die Berechtigung wirkt innerhalb der OU Marketing/Benutzer.

Personenbezogene Kontonamen und lokale Benutzerdaten werden nicht angezeigt.

13.4Übungskonto B Passwortversuch Übungskonto F versucht ein Passwort außerhalb der delegierten OU zurückzusetzen.

Weiterer NachweisZugriff verweigert bei Übungskonto B

Weiterer NachweisAndere OU: Benutzer erstellen nicht möglich

7. Prüfpunkt und Rücksetzung

Nach Abschluss von Arbeitsblock wurde ein Prüfpunkt mit dem Namen Tag_13_AD_Objekte erstellt. Das entspricht dem optionalen Hinweis in der Aufgabenstellung. Anschließend wurde die Umgebung für die nächsten Aufgaben wieder auf den passenden Ausgangszustand gebracht.

Get-VM | Checkpoint-VM -SnapshotName "Tag_13_AD_Objekte"
Get-VM | Restore-VMCheckpoint -Name Basis-AD -Confirm:$false

Wichtige Prüfpunktgrenze für Server1: Wenn eine spätere Aufgabenstellung verlangt, auf Basis-AD zurückzugehen, darf Server1 nicht blind auf einen älteren fehlerhaften Prüfpunkt gesetzt werden. Für Server1 ist der funktionierende Prüfpunkt Server1 - (01.05.2026 - 23:43:24) beziehungsweise der als funktionsfähig geprüfte Server1-Stand zu verwenden.

Weiterer NachweisCheckpoint per PowerShell

Weiterer NachweisCheckpoint im Hyper-V-Manager sichtbar

Weiterer NachweisRücksetzung auf Basis-AD

8. Fazit und Fachliche Erkenntnisse

Bearbeitete Administrationsaufgaben
AD-Strukturierung, Benutzerverwaltung, Gruppenmodellierung, Freigabe-/NTFS-Rechte und Delegation.

Fehleranalyse
Der CSV-Import-Fehler und die NTFS-Vererbungsfalle wurden nicht geglättet, sondern als nachvollziehbare Lernpunkte aufgenommen.

Ergebnis: Die Berechtigungsketten und ihre gezielte Begrenzung wurden technisch nachvollzogen.

Wesentliche Erkenntnisse

OU-Strukturen sollten konsistent über Domänen hinweg aufgebaut werden, damit spätere Automatisierung und Delegation sauber funktionieren.
PowerShell- und CSV-Importe sind effizient, müssen aber idempotent gedacht werden: existierende Objekte führen bei erneutem Import zu erwartbaren Fehlern.
Anmeldezeiten, Kontodeaktivierung und Gruppenmitgliedschaft wirken direkt auf Benutzererfahrung und Administrationsrechte.
Share-Berechtigungen und NTFS-Berechtigungen sind getrennte Schichten; der restriktivere effektive Zugriff entscheidet.
Bei NTFS-Vererbung muss vor dem Entfernen geerbter Rechte klar sein, welche expliziten Rechte bestehen bleiben sollen.
Das Gruppenmodell I-G-DL-P reduziert direkte Benutzerberechtigungen und macht Zugriffe nachvollziehbarer.
Delegation ist kein Ersatz für Domänen-Admin-Rechte, sondern eine kontrollierte Rechtevergabe auf definierte OUs.
RSAT auf einem Client ist ein praxisnaher Weg, administrative Aufgaben auszuführen, ohne direkt auf dem Server arbeiten zu müssen.

Einsatzgrenzen

Die verwendeten Kennwörter sind Laborwerte und keine produktive Sicherheitsvorgabe.
Die Freigabe- und NTFS-Rechte wurden für den Übungszweck gesetzt, nicht als vollständiges produktives Berechtigungskonzept.
Die finale Rücksetzung bedeutet: Der belegte Zustand ist ein abgeschlossener Labordurchlauf, nicht zwingend der dauerhaft aktuelle Ist-Zustand der Umgebung.

Fehlerkontext: Ein fehlerhafter Server1-Prüfpunkt führte zu WORKGROUP-/RID-Problemen; nach Wiederherstellung des korrekten Zustands wurden DC-Dienste und Replikation geprüft und die Objektarbeit fortgesetzt.

Praxis und Ergebnis

Benutzerverwaltung, Dienstkonten und AD-Wiederherstellung

PowerShell-Benutzermethoden, MSA/gMSA, System-State-Sicherung, DSRM-Restore und AD-Datenbankwartung bearbeiten.

Überblick

PowerShell-Verfahren zur Benutzeranlage, drei Dienstkontenmodelle, Systemstatussicherung und DSRM-Wiederherstellung sowie Wartung der Active-Directory-Datenbank wurden als zusammenhängende Administrationsaufgaben bearbeitet.

2. Laborumgebung

System	Rolle	Details
`DC`	Domänencontroller, DNS, zentrale AD-/GPMC-Verwaltung	192.168.1.200, Domäne gfnlab.test
`Server1`	zusätzlicher Domänencontroller, Backup/Restore	Systemstatussicherung, DSRM, Replikation
`Server2`	IIS-/Anwendungsserver und Backupziel	MSA/gMSA/IIS, klassisches Dienstkonto, \\Server2\DCBackup
`Server3`	zweiter IIS-/Anwendungsserver	MSA-Grenze und gMSA-Mehrserverfähigkeit
`W11`	Domänenclient	Bestandteil der Laborarchitektur
`Hyper-V-Host`	Prüfpunktverwaltung	Bewusster Abschluss auf Basis-AD_Sysvol_fix

Der Prüfpunkt Basis-AD_Sysvol_fix blieb bewusst erhalten, damit der zuvor reparierte SYSVOL-/DFS-R-Zustand nicht verloren ging.

20.0.0 – PowerShell-Parameterübergabe und AD-Benutzeranlage

Ziel: Drei AD-Benutzer wurden auf DC mit unterschiedlichen PowerShell-Schreibweisen erstellt: Einzeiler, Backtick-Mehrzeiler und Splatting/Hashtable.

Umsetzung

Vor der Benutzeranlage wurde die OU `Arbeit` geprüft.
Der Benutzer `Theo Retisch` (`tr`) wurde per Einzeiler erstellt.
Der Benutzer `Justin Time` (`jt`) wurde per Backtick-Mehrzeiler erstellt.
Der Benutzer `Cory Ander` (`ca`) wurde per Splatting/Hashtable erstellt.
Jede Erstellung wurde mit `Get-ADUser` geprüft.

Relevante Befehle / Konfigurationen

New-ADUser -Name "Theo Retisch" ... -SamAccountName tr ...
New-ADUser ` -Name "Justin Time" ` ...
$benutzerParameter = @{ Name = "Cory Ander"; ... }
New-ADUser @benutzerParameter
Get-ADUser <samAccountName> -Properties DisplayName,UserPrincipalName,Enabled

Technischer Zusammenhang

Die Aufgabe zeigt drei typische Arbeitsweisen mit Cmdlets, die viele Parameter besitzen. Der Einzeiler ist schnell, aber bei vielen Parametern unübersichtlich. Die Backtick-Variante verbessert die Lesbarkeit, ist aber empfindlich, weil nach dem Backtick kein Leerzeichen stehen darf. Splatting trennt Parameterdaten vom Cmdlet und eignet sich am besten für wiederverwendbare Skripte, Templates und Automatisierung.

Fehler, Abweichungen oder Entscheidungen

Beim ersten `New-ADUser`-Versuch trat der Fehler „Der Verzeichnisdienst kann keinen relativen Bezeichner zuweisen“ auf. Laut dokumentierter Arbeitsverlauf war Server1 nicht gestartet. Nach dem Start von Server1 konnte der Benutzer angelegt werden. Der Fehler wurde als RID-/FSMO-/AD-Infrastrukturthema und nicht als reiner Syntaxfehler bewertet.

Fachliche Erkenntnisse

PowerShell-Syntax ist nur eine Ebene; AD-Objekterstellung hängt zusätzlich von RID-Master, Domänencontroller-Verfügbarkeit, DNS und Replikation ab.
Splatting ist für wiederholbare Administration die sauberste Schreibweise.
Nach jedem administrativen Eingriff sollte eine technische Prüfung erfolgen, nicht nur eine fehlende Fehlermeldung.

Nachweise

**RID-Zuweisungsfehler beim ersten New-ADUser-Versuch**
Fehler/Korrektur
Server1 war nicht gestartet; AD konnte keinen relativen Bezeichner zuweisen.

**Prüfung der OU Arbeit vor Benutzeranlage**
Prüfung
OU Arbeit existiert unter OU=Arbeit,DC=gfnlab,DC=test.

**Benutzer Theo Retisch per Einzeiler erstellt**
Konfiguration
Einzeilige New-ADUser-Variante erneut erfolgreich ausgeführt.

Weiterer NachweisTheo Retisch per Get-ADUser geprüft

Weiterer NachweisJustin Time per Backtick-Mehrzeiler erstellt und geprüft

Weiterer NachweisCory Ander per Splatting erstellt und geprüft

20.0.1 – Dienstkonten, MSA und gMSA – Konzeptvergleich

Ziel: Die Unterschiede zwischen klassischen Dienstkonten, verwalteten Dienstkonten (MSA/sMSA) und gruppenverwalteten Dienstkonten (gMSA) wurden fachlich eingeordnet.

Umsetzung

Klassische Dienstkonten wurden als normale AD-Benutzerkonten für Dienste/Applikationen eingeordnet.
MSA/sMSA wurde als automatisch verwaltetes Dienstkonto für genau einen Computer verstanden.
gMSA wurde als mehrserverfähiges verwaltetes Dienstkonto für Webfarmen, Cluster und geplante Aufgaben eingeordnet.
SPN/Kerberos, KDS-Root-Key, Passwortrotation und Einsatzgrenzen wurden besprochen.

Technischer Zusammenhang

Dienstkonten sind technische Identitäten für Dienste. Klassische Dienstkonten funktionieren breit, erfordern aber manuelle Kennwortpflege und häufig SPN-Pflege. MSA/gMSA reduzieren diese Risiken, weil Active Directory das Kennwort verwaltet und die Nutzung technisch kontrollierbarer wird. Ein sMSA ist auf einen Server beschränkt; ein gMSA darf von mehreren berechtigten Computern verwendet werden.

Fehler, Abweichungen oder Entscheidungen

Keine technische Fehlersituation; es handelt sich um eine Recherche- und Verständnisaufgabe.

Fachliche Erkenntnisse

Klassische Dienstkonten sind kompatibel, aber nicht ideal: manuelle Passwortpflege, „Kennwort läuft nie ab“ und überhöhte Rechte sind typische Risiken.
MSA/gMSA sind sicherer, weil Kennwörter durch AD verwaltet und nicht administrativ bekannt sind.
Das Wissen ist für das spätere eigene Homelab relevant, zum Beispiel für Webdienste, Monitoring, Backup-Jobs, geplante Tasks oder Automatisierungsdienste.

Nachweise

Für diese Recherche- und Konzeptaufgabe liegt kein separater Screenshot vor; der technische Zusammenhang ist als Text beschrieben.

20.1.1 – Verwaltetes Dienstkonto / sMSA `iis_MSA` für IIS

Ziel: IIS und RSAT-AD-PowerShell wurden remote auf Server2 und Server3 installiert. Anschließend wurde ein MSA `iis_MSA` erstellt und auf Server2 für den IIS-DefaultAppPool verwendet. Der Versuch auf Server3 wurde nach der erwarteten Warnung abgebrochen.

Umsetzung

Remote-Installation von `Web-Server` und `RSAT-AD-PowerShell` auf Server2 und Server3.
`iis_MSA` wurde mit `New-ADServiceAccount -RestrictToSingleComputer` erstellt.
Das Konto wurde im Container `Managed Service Accounts` geprüft.
Server2 wurde per `Add-ADComputerServiceAccount` berechtigt, das Konto wurde lokal installiert und mit `Test-ADServiceAccount = True` validiert.
Der IIS `DefaultAppPool` auf Server2 wurde auf `gfnlab\iis_MSA$` umgestellt und neu gestartet.
Auf Server3 wurde der MSA-Einsatz bewusst getestet; die Doppelter-Backlink-Warnung wurde mit `N` abgebrochen.

Relevante Befehle / Konfigurationen

Install-WindowsFeature -ComputerName Server2 -Name Web-Server,RSAT-AD-PowerShell -IncludeManagementTools
New-ADServiceAccount -Name "iis_MSA" -RestrictToSingleComputer
Add-ADComputerServiceAccount -Computer "Server2" -ServiceAccount "iis_MSA"
Install-ADServiceAccount -Identity "iis_MSA"
Test-ADServiceAccount -Identity "iis_MSA"

Technischer Zusammenhang

Ein standalone Managed Service Account wird durch AD mit einem verwalteten Kennwort ausgestattet. Das Dollarzeichen am Ende (`iis_MSA$`) signalisiert dem System ein verwaltetes Konto. Deshalb werden im IIS keine Kennwörter eingetragen. Ein sMSA ist jedoch nur für einen Computer geeignet; genau diese Grenze wurde durch den Test auf Server3 sichtbar.

Fehler, Abweichungen oder Entscheidungen

Der erste Remote-Installationsversuch wurde in der PowerShell ISE (x86) ausgeführt. Dort war `Install-WindowsFeature` nicht verfügbar. Nach Wechsel zur normalen 64-Bit PowerShell ISE lief die Installation erfolgreich. Zusätzlich wurde auf Server3 die Doppelter-Backlink-Warnung als erwarteter Lernnachweis erkannt und nicht als Fehler missinterpretiert.

Fachliche Erkenntnisse

Der PowerShell-Host ist relevant; x86-ISE kann ServerManager-Cmdlets nicht wie erwartet bereitstellen.
MSA/sMSA eignet sich für einen einzelnen Server, nicht für Webserverfarmen.
Warnmeldungen sind fachlich zu lesen: Die Server3-Warnung war der Beweis für die sMSA-Einsatzgrenze.

Nachweise

Weiterer NachweisPowerShell ISE x86: Install-WindowsFeature nicht verfügbar

Weiterer NachweisRemote-Installation auf Server2 und Server3 läuft

Weiterer NachweisRemote-Installation IIS und RSAT-AD-PowerShell erfolgreich

Weiterer Nachweisiis_MSA erstellt und per ADServiceAccount-Abfrage geprüft

Weiterer Nachweisiis_MSA im Container Managed Service Accounts sichtbar

Weiterer Nachweisiis_MSA auf Server2 installiert und Test ergibt True

Weiterer NachweisServer2 MSA-Test nochmals sichtbar

Weiterer NachweisIIS DefaultAppPool Identität wird vorbereitet

Weiterer Nachweisiis_MSA im IIS-Anmeldedialog eingetragen

Weiterer NachweisDefaultAppPool-Identität zeigt iis_MSA

Weiterer NachweisDefaultAppPool mit iis_MSA beendet

Weiterer NachweisDefaultAppPool mit iis_MSA gestartet

Weiterer NachweisDefaultAppPool mit iis_MSA final sichtbar

Weiterer NachweisMSA-Installation auf Server3 wegen doppeltem Backlink abgebrochen

20.1.2 – Gruppenverwaltetes Dienstkonto / gMSA `iis_gMSA`

Ziel: Ein gMSA wurde so eingerichtet, dass Server2 und Server3 es gemeinsam für den IIS-DefaultAppPool verwenden können.

Umsetzung

Die globale Sicherheitsgruppe `WebServerFarmGruppe` wurde erstellt.
Server2 und Server3 wurden als Computerobjekte in diese Gruppe aufgenommen.
Der KDS-Root-Key wurde in der Laborvariante mit `AddHours(-10)` erstellt.
Das gMSA `iis_gMSA` wurde mit `DNSHostName = WebFarmDienst.gfnlab.test` erstellt.
Die Gruppe `WebServerFarmGruppe` wurde als `PrincipalsAllowedToRetrieveManagedPassword` gesetzt.
Server2 und Server3 konnten `iis_gMSA` mit `Test-ADServiceAccount = True` verwenden.
Der IIS `DefaultAppPool` wurde auf beiden Servern auf `gfnlab\iis_gMSA$` umgestellt.

Relevante Befehle / Konfigurationen

Add-KDSRootKey -EffectiveTime ((Get-Date).AddHours(-10))
$Args = @{ Name="iis_gMSA"; DNSHostName="WebFarmDienst.gfnlab.test"; PrincipalsAllowedToRetrieveManagedPassword="WebServerFarmGruppe" }
New-ADServiceAccount @Args
Test-ADServiceAccount -Identity iis_gMSA
Install-ADServiceAccount -Identity iis_gMSA

Technischer Zusammenhang

Ein gMSA erweitert das MSA-Konzept auf mehrere Computer. Die berechtigten Computer werden über eine Sicherheitsgruppe gesteuert. Nur diese Systeme dürfen das verwaltete Kennwort abrufen. Der KDS-Root-Key ist Voraussetzung, damit Domänencontroller gMSA-Kennwörter berechnen und bereitstellen können.

Fehler, Abweichungen oder Entscheidungen

Der Server-Manager zeigte beim Neustart von Server2 und Server3 die irreführende Meldung „Möchten Sie diese Server wirklich löschen?“. Der Dialogtext ist irreführend: Tatsächlich wird der Neustart durchgeführt, nicht die Server gelöscht.

Fachliche Erkenntnisse

gMSA ist die richtige Lösung, wenn ein Dienstkonto auf mehreren Servern genutzt werden soll.
`Add-KDSRootKey -EffectiveTime ((Get-Date).AddHours(-10))` ist nur eine Laborverkürzung; produktiv muss die Replikationswartezeit berücksichtigt werden.
Die Sicherheitsgruppe ist der zentrale Kontrollpunkt dafür, welche Computer das gMSA nutzen dürfen.

Nachweise

Weiterer NachweisGlobale Sicherheitsgruppe WebServerFarmGruppe erstellt

Weiterer NachweisWebServerFarmGruppe im Container Computers sichtbar

Weiterer NachweisServer2 und Server3 der WebServerFarmGruppe hinzugefügt

Weiterer NachweisGruppenmitgliedschaft erfolgreich abgeschlossen

Weiterer NachweisServer2 und Server3 im Server-Manager ausgewählt

Weiterer NachweisServer-Manager zeigt DC, Server2 und Server3

Weiterer NachweisIrreführende Server-Manager-Warnung beim Neustart

Weiterer NachweisKDS-Root-Key mit Laborverkürzung erstellt

Weiterer Nachweisiis_gMSA erstellt und Eigenschaften geprüft

Weiterer Nachweisiis_gMSA in ADUC sichtbar

Weiterer Nachweisiis_gMSA auf Server2 getestet und installiert

Weiterer Nachweisiis_gMSA auf Server3 getestet und installiert

Weiterer NachweisServer3 DefaultAppPool auf iis_gMSA vorbereiten

Weiterer NachweisServer3 DefaultAppPool mit iis_gMSA gesetzt

Weiterer NachweisServer2 DefaultAppPool auf iis_gMSA vorbereiten

Weiterer NachweisServer2 DefaultAppPool mit iis_gMSA gesetzt

20.1.3 – Klassisches Domänenbenutzerkonto `iis_SVC` als Dienstkonto

Ziel: Ein normales AD-Benutzerkonto wurde als klassisches Dienstkonto für IIS verwendet und damit mit MSA/gMSA verglichen.

Umsetzung

Der AD-Benutzer `iis_SVC` wurde im Container `Users` erstellt.
Kennwortoptionen wie „Benutzer kann Kennwort nicht ändern“ und „Kennwort läuft nie ab“ wurden gemäß Laborvorgabe gesetzt.
Die Gruppe `ServiceAccounts` wurde erstellt; `iis_SVC` wurde aufgenommen und als primäre Gruppe gesetzt.
`Domänen-Benutzer` wurde aus den Mitgliedschaften entfernt.
`iis_SVC` wurde auf Server2 in die lokale Administratorengruppe aufgenommen.
Der SPN `http/Server2.gfnlab.test` wurde auf `gfnlab\iis_SVC` gesetzt.
Der IIS `DefaultAppPool` wurde auf `gfnlab\iis_SVC` mit manuellem Kennwort umgestellt und per `localhost` getestet.

Relevante Befehle / Konfigurationen

Add-LocalGroupMember -Group "Administratoren" -Member "gfnlab\iis_SVC"
Setspn -s http/Server2.gfnlab.test gfnlab\iis_SVC
setspn -L gfnlab\iis_SVC

Technischer Zusammenhang

Ein klassisches Dienstkonto ist ein normales Benutzerkonto, das von einem Dienst verwendet wird. Es ist sehr kompatibel, aber administrativ und sicherheitlich ungünstiger als MSA/gMSA. Kennwörter müssen manuell gepflegt werden, und Kerberos benötigt in diesem Szenario einen manuell gesetzten SPN.

Fehler, Abweichungen oder Entscheidungen

Die Aufgabenstellung nennt „Server2Service“, die Lösung verwendet jedoch `iis_SVC`. Die Umsetzung folgt der Lösung, weil alle späteren Schritte, SPN und IIS-Konfiguration auf `iis_SVC` verweisen.

Fachliche Erkenntnisse

Klassische Dienstkonten funktionieren technisch, sind aber nicht Best Practice.
„Kennwort läuft nie ab“ ist eine Laborvereinfachung und produktiv kritisch.
Lokale Administratorrechte für ein Dienstkonto verletzen das Least-Privilege-Prinzip und sollten produktiv vermieden werden.
SPNs sind für Kerberos wichtig und müssen bei klassischen Dienstkonten bewusst gepflegt werden.

Nachweise

Weiterer NachweisAD-Benutzer iis_SVC wird angelegt

Weiterer NachweisKennwortoptionen für iis_SVC gesetzt

Weiterer NachweisGruppe ServiceAccounts erstellt

Weiterer Nachweisiis_SVC wird ServiceAccounts hinzugefügt

Weiterer NachweisServiceAccounts als primäre Gruppe gesetzt

Weiterer NachweisDomänen-Benutzer entfernt, ServiceAccounts verbleibt

Weiterer Nachweisiis_SVC in lokaler Administratorengruppe auf Server2 geprüft

Weiterer NachweisSPN für iis_SVC auf Server2 gesetzt

Weiterer NachweisIIS DefaultAppPool auf klassisches Dienstkonto iis_SVC vorbereiten

Weiterer NachweisDefaultAppPool-Identität zeigt iis_SVC

Weiterer NachweisIIS-Startseite localhost erfolgreich geöffnet

20.2.1a – Systemstatussicherung von Server1 nach `\\Server2\DCBackup`

Ziel: Der Systemstatus von Server1 wurde auf eine Netzwerkfreigabe auf Server2 gesichert.

Umsetzung

Windows Server-Sicherung wurde auf Server1 installiert.
Auf Server2 wurde `C:\DCBackup` erstellt.
Die Freigabe `DCBackup` wurde mit `Domänen-Admins` und Vollzugriff eingerichtet.
Auf Server1 wurde ein Sicherungszeitplan für `Systemstatus` mit Netzwerkziel `\\Server2\DCBackup` erstellt.
Zusätzlich wurde eine Einmalsicherung gestartet und erfolgreich abgeschlossen.

Relevante Befehle / Konfigurationen

Install-WindowsFeature Windows-Server-Backup
Zielpfad: \\Server2\DCBackup

Technischer Zusammenhang

Eine Systemstatussicherung ist bei Domänencontrollern relevant, weil sie AD-bezogene Systemkomponenten wie AD DS, SYSVOL, Registry, Bootdateien und Systemdateien erfasst. Das Backupziel auf einem separaten Server schützt vor einem rein lokalen Ausfall.

Fehler, Abweichungen oder Entscheidungen

Keine kritische Störung. Der relevante Punkt ist die saubere Berechtigung des Backupziels.

Fachliche Erkenntnisse

Ein Backup ist nur so brauchbar wie seine Wiederherstellbarkeit.
Freigabe- und NTFS-Berechtigungen müssen zusammen betrachtet werden.
Ein separates Sicherungsziel ist sinnvoller als eine rein lokale Sicherung auf dem betroffenen Server.

Nachweise

Weiterer NachweisWindows Server-Sicherung zur Installation ausgewählt

Weiterer NachweisWindows Server-Sicherung erfolgreich installiert

Weiterer NachweisOrdner C:\DCBackup auf Server2 erstellt

Weiterer NachweisFreigabe DCBackup mit Domänen-Admins Vollzugriff

Weiterer NachweisSicherungszeitplan für Systemstatus bestätigt

Weiterer NachweisSicherungszeitplan wurde erstellt

Weiterer NachweisEinmalsicherung gestartet

Weiterer NachweisEinmalsicherung erfolgreich abgeschlossen

20.2.1b – Systemstatuswiederherstellung im DSRM

Ziel: Die zuvor erstellte Systemstatussicherung von Server1 wurde im Verzeichnisdienst-Wiederherstellungsmodus wiederhergestellt.

Umsetzung

Server1 wurde mit `bcdedit /set safeboot dsrepair` in den DSRM gestartet.
Die Anmeldung erfolgte als lokaler `Server1\Administrator`.
Die Systemstatusdaten wurden über Windows Server-Sicherung auf den ursprünglichen Speicherort wiederhergestellt.
Nach der Wiederherstellung wurde `safeboot` entfernt und Server1 in den Normalmodus zurückgebracht.
`repadmin /showrepl` bestätigte die erfolgreiche Replikation nach der Wiederherstellung.

Relevante Befehle / Konfigurationen

bcdedit /set safeboot dsrepair
shutdown -t 0 -r
bcdedit /deletevalue safeboot
repadmin /showrepl

Technischer Zusammenhang

DSRM ist ein spezieller Wiederherstellungsmodus für Domänencontroller. AD DS läuft dort nicht im normalen Domänenbetrieb, daher wird mit dem lokalen Administrator-/DSRM-Kontext gearbeitet. Nach der Wiederherstellung muss der Safeboot-Eintrag entfernt werden, sonst startet der Server weiterhin im Wiederherstellungsmodus.

Fehler, Abweichungen oder Entscheidungen

Keine bleibende Störung; der Schwerpunkt lag auf korrektem Moduswechsel und anschließendem Replikationsnachweis.

Fachliche Erkenntnisse

Wiederherstellung muss praktisch getestet werden, nicht nur theoretisch geplant.
DSRM-Anmeldung unterscheidet sich vom normalen Domänenkontext.
Nach einem Restore ist eine Replikationsprüfung Pflicht.

Nachweise

Weiterer NachweisServer1 in DSRM gesetzt und Neustart ausgelöst

Weiterer NachweisAnmeldung im abgesicherten Modus/DSRM

Sensible Konto- und Zugangsdaten werden nicht angezeigt.

Wiederherstellungsassistent mit Sicherungsdatum und Credentials
Konfiguration
Systemstatus-Wiederherstellung aus Sicherung wird vorbereitet.

Weiterer NachweisWiederherstellung wird bestätigt

Weiterer NachweisWiederherstellung der Systemstatusdaten läuft

Weiterer NachweisSystemstatuswiederherstellung abgeschlossen, Neustart erforderlich

Weiterer Nachweiswbadmin meldet abgeschlossene Wiederherstellung

Weiterer NachweisSafeboot entfernt und Neustart in Normalmodus

Weiterer Nachweisrepadmin /showrepl nach Wiederherstellung erfolgreich

20.2.2 – AD-Datenbank und Logs verschieben, komprimieren und prüfen

Ziel: Die AD-Datenbank wurde verschoben, komprimiert, semantisch analysiert und physisch per `esentutl` geprüft. Zusätzlich wurde das DSRM-Kennwort angepasst und die Umgebung auf den korrekten Prüfpunkt zurückgesetzt.

Umsetzung

Partition C: wurde um 20480 MB verkleinert und eine neue NTFS-Partition `N:` erstellt.
NTDS wurde gestoppt.
Datenbank und Logs wurden mit `ntdsutil` nach `N:\ntds` verschoben.
Die Datenbank wurde nach `C:\Windows\ntds` komprimiert und anschließend zurück nach `N:\ntds` kopiert.
Alte Logdateien wurden gelöscht.
Eine semantische Analyse mit `GO Fixup` wurde durchgeführt.
`esentutl /g N:\ntds\ntds.dit` meldete `Integrity check successful`.
NTDS wurde wieder gestartet und per `sc query ntds` geprüft.
Ein zwischenzeitlicher Replikationsfehler 8524 wurde mit DNS-/Replikationsprüfung und `repadmin /syncall` bereinigt.
Das DSRM-Kennwort wurde auf DC und Server1 lokal mit `reset password on server null` gesetzt.
Zum Abschluss wurden die VMs bewusst auf `Basis-AD_Sysvol_fix` zurückgesetzt.

Relevante Befehle / Konfigurationen

net stop ntds
ntdsutil → activate instance ntds → files → move db to N:\ntds → move logs to N:\ntds → compact to C:\windows\ntds
copy C:\windows\ntds\ntds.* N:\ntds
del N:\ntds\*.log
ntdsutil → semantic database analysis → go fixup
esentutl /g N:\ntds\ntds.dit
net start ntds
repadmin /syncall /AdeP
ntdsutil → set dsrm password → reset password on server null

Technischer Zusammenhang

Dieser Abschnitt zeigt direkte Wartung an der AD-Datenbank. Solche Arbeiten sind sensibel, weil AD DS aktiv von der `ntds.dit` und den Transaktionslogs abhängt. `ntdsutil` dient der AD-Datenbankwartung, `esentutl` prüft die physische Datenbankintegrität, während die semantische Analyse logische AD-Strukturen betrachtet.

Fehler, Abweichungen oder Entscheidungen

Die Aufgabenbeschreibung nennt Server1, der Lösungsteil nennt bei der Partitionierung jedoch DC. Die Umsetzung erfolgte sichtbar auf DC und wird als Abweichung zwischen Aufgabe und Lösungsteil dokumentiert. Zusätzlich wurde `Ntds.INTEG.RAW` nicht unter `C:\`, sondern im Benutzerprofil erzeugt, weil der Befehl aus `C:\Users\<lokales-konto> gestartet wurde. Nach dem NTDS-Start trat ein Replikationsfehler 8524 auf, der später erfolgreich bereinigt wurde.

Fachliche Erkenntnisse

Vor AD-Datenbankwartung muss eine brauchbare Sicherung existieren.
Abweichungen zwischen Aufgabenstellung und Umsetzung werden als fachliche Grenzen ausgewiesen.
Prüfberichte entstehen im aktuellen Arbeitsverzeichnis, wenn kein absoluter Pfad verwendet wird.
Ein erfolgreicher Datenbankcheck ersetzt keine Replikationsprüfung.
Der Prüfpunkt `Basis-AD_Sysvol_fix` wurde bewusst genutzt, um den zuvor erarbeiteten SYSVOL-/DFSR-Fix nicht wieder zu verlieren.

Nachweise

Weiterer NachweisPartition C wird um 20480 MB verkleinert

Weiterer NachweisNeue Partition N erstellt

Weiterer NachweisPartition N Assistent/Formatierung abgeschlossen

Weiterer NachweisNTDS gestoppt und Datenbank nach N:\ntds verschoben

Weiterer NachweisLogs nach N:\ntds verschoben und Komprimierung gestartet

Weiterer NachweisAD-Datenbank erfolgreich komprimiert

Weiterer NachweisKomprimierte Datenbank nach N:\ntds kopiert

Weiterer NachweisAlte Logdateien in N:\ntds gelöscht

Weiterer NachweisSemantische Analyse und esentutl-Integritätsprüfung erfolgreich

Weiterer NachweisNtds.INTEG.RAW nicht unter C:\ gefunden

Weiterer NachweisZugriffsmeldung beim Öffnen von ntds.INTEG.RAW

Weiterer Nachweisdsdit.dmp.0 Bericht geöffnet

Weiterer NachweisNTDS gestartet, Replikationsfehler 8524 sichtbar

Weiterer NachweisServer1 Basisprüfung nach Replikationsfehler

Weiterer NachweisDNS-Reparatur und Replication-Troubleshooting begonnen

Weiterer NachweisServer1 Hostname, NTDS und IP-Konfiguration geprüft

Weiterer NachweisDNS-Auflösung für DC und Server1 geprüft

Weiterer NachweisReplikation nach SyncAll wieder fehlerfrei

Sensible Konto- und Zugangsdaten werden nicht angezeigt.

DSRM-Kennwort auf DC lokal geändert
Konfiguration
ntdsutil reset password on server null, Kennwort erfolgreich gesetzt.

Sensible Konto- und Zugangsdaten werden nicht angezeigt.

DSRM-Kennwort auf Server1 lokal geändert
Konfiguration
ntdsutil reset password on server null auf Server1, Kennwort erfolgreich gesetzt.

Weiterer NachweisVMs auf Basis-AD_Sysvol_fix zurückgesetzt

5. Troubleshooting- und Entscheidungsprotokoll

Thema	Beobachtung	Umgang / Ergebnis
RID-Zuweisungsfehler bei `New-ADUser`	Server1 war nicht gestartet; AD konnte keinen relativen Bezeichner zuweisen.	Server1 gestartet, Benutzeranlage erneut ausgeführt und geprüft.
PowerShell ISE (x86)	`Install-WindowsFeature` war nicht verfügbar.	Wechsel zur 64-Bit-PowerShell-ISE; Remote-Installation erfolgreich.
MSA auf Server3	Doppelter Backlink beim Versuch, `iis_MSA` auf Server3 zu installieren.	Warnung gelesen und mit `N` abgebrochen; korrektes Ergebnis für sMSA-Grenze.
KDS-Root-Key	gMSA benötigt KDS-Root-Key; produktiv mit Wartezeit.	Für die Laborverkürzung wurde `AddHours(-10)` bewusst verwendet.
Server-Manager-Neustartwarnung	Dialog spricht von „Server löschen“, obwohl Neustart gemeint ist.	Als bekannter Aufgabenstellung-/GUI-Bug eingeordnet.
20.2.2 Server1/DC-Inkonsistenz	Aufgabenstellung nennt Server1, Lösung verweist bei Partitionierung auf DC.	Die Umsetzung auf dem DC ist sichtbar; die Abweichung zur Aufgabenstellung bleibt erkennbar.
`Ntds.INTEG.RAW` nicht unter `C:\`	Berichtdatei wurde im Benutzerprofil erzeugt.	Das Pfadproblem wurde erkannt; die Integritätsprüfung war dennoch erfolgreich.
Replikationsfehler 8524	Nach NTDS-Start zeigte `repadmin /replsummary` DNS-Aufruffehler zwischen DC und Server1.	Server1 geprüft, DNS-Auflösung geprüft, `repadmin /syncall` ausgeführt; Replikation danach fehlerfrei.
Prüfpunkt am Abschluss	Die Aufgabenstellung nennt `Basis-AD`; für den belegten Ablauf musste der SYSVOL-Fix erhalten bleiben.	Die Rücksetzung auf `Basis-AD_Sysvol_fix` erfolgte bewusst.

6. Gesamte Fachliche Erkenntnisse

Fortgeschrittene AD-Verwaltung verbindet kontrollierte Änderungen mit technischer Zustandsprüfung.
PowerShell-Arbeitsweisen wie Splatting sind für wiederverwendbare Administration deutlich besser geeignet als lange Einzeiler.
Dienstkonten müssen sicherheitlich bewusst gewählt werden: klassisch funktioniert, MSA/gMSA sind aber meist sauberer und sicherer.
gMSA ist für Mehrserverdienste wie Webserverfarmen die praxisnähere Lösung, setzt aber KDS-Root-Key und berechtigte Computer voraus.
Backups sind erst dann fachlich belastbar, wenn auch eine Wiederherstellung getestet wurde.
DSRM ist ein Spezialmodus mit lokalem Administratorkontext und muss nach der Wiederherstellung sauber verlassen werden.
AD-Datenbankwartung verlangt besondere Sorgfalt: NTDS stoppen, Datenbank/Logs kontrolliert bewegen, Integrität prüfen und Replikation anschließend validieren.
Für das spätere eigene Homelab ist die Unterscheidung zwischen Benutzerkonten, Dienstkonten, MSA und gMSA direkt nutzbar, etwa für Webdienste, Monitoring, Backup-Jobs und geplante Aufgaben.
Die gezeigten Werte stammen aus einer isolierten Laborumgebung; Kennwörter und personenbezogene Angaben werden nicht angezeigt.

Praxis und Ergebnis

AD-Snapshots, Papierkorb und Kennwortrichtlinien

AD-Snapshot über dsamain, Active Directory Recycle Bin und differenzierte Kennwortrichtlinien untersuchen.

1. Kurzfassung

In diesem Arbeitsblock wurden fortgeschrittene Verwaltungstasks für Active Directory umgesetzt. Zunächst wurde ein AD-Snapshot erstellt, über dsamain auf Port 5000 bereitgestellt und mit dem aktuellen AD-Zustand verglichen. Danach wurde der Active-Directory-Papierkorb aktiviert; ein zuerst aufgetretenes FSMO-/Replikationsproblem wurde über repadmin /syncall /PAed auf DC und Server1 bereinigt. Abschließend wurden zwei Password Settings Objects erstellt und getestet.

Datenschutz: Personenbezogene Angaben, Laborkennwörter und sicherheitsrelevante Wiederherstellungsdaten werden aus Datenschutz- und Sicherheitsgründen nicht angezeigt. Technische Laborrollen bleiben nur erhalten, soweit sie für das Verständnis des Ablaufs erforderlich sind.

Aufgabe	Thema	Ergebnis
21.1	AD-Snapshot	Alter Attributwert aus Snapshot lesbar; aktueller AD-Wert separat vorhanden; Snapshot sauber unmounted.
21.2.3	AD-Papierkorb	Nach Replikationsbereinigung aktiviert; gelöschter Benutzer wiederhergestellt; Gruppenmitgliedschaft erhalten.
21.4	Password Settings Objects	Unterschiedliche Kennwortanforderungen erstellt, resultierende Richtlinien geprüft und praktisch getestet.

3. Aufgabe 21.1 – Active-Directory-Snapshot

Ziel

Ziel war es, einen früheren Zustand der AD-Datenbank lesend bereitzustellen. Bei Übungskonto C wurde zuerst die Telefonnummer 987654321 gesetzt, danach wurde ein Snapshot erstellt. Anschließend wurde der aktuelle Wert auf 123456789 geändert und der Snapshot über DC:5000 betrachtet.

Technischer Zusammenhang

Ein AD-Snapshot ist kein Restore, sondern eine read-only Analyse eines früheren AD-Zustands.dsamain stellt die gemountete ntds.dit temporär über einen separaten LDAP-Port bereit. Dadurch lassen sich frühere Attributwerte nachvollziehen, ohne das produktive AD zu verändern.

Fachliche Erkenntnisse

AD-Snapshots eignen sich zur Analyse alter Attributwerte.
dsamain muss während der Analyse geöffnet bleiben.
Der separate LDAP-Port vermeidet Konflikte mit dem produktiven AD.
Snapshots müssen nach der Analyse wieder unmounted werden.

Nachweise

**Nachweis 001 – Telefonnummer Übungskonto C auf 987654321 gesetzt**
Ausgangswert vor dem AD-Snapshot: Übungskonto C in OU Arbeit, Register Rufnummern, Privat=987654321.

**Nachweis 002 – AD-Snapshot erstellt und gemountet**
NTDSUTIL: Snapshot erstellt, Liste angezeigt, Snapshot 1 gemountet unter C:\$SNAP_...

**Nachweis 003 – Aktueller AD-Wert auf 123456789 geändert**
Nach Erstellung des Snapshots wurde Telefonnummer von Übungskonto C im aktuellen AD auf 123456789 geändert.

Weiterer Nachweis004 – Gemounteter Snapshot im Explorer sichtbar

Weiterer Nachweis005 – Snapshot-NTDS-Datenbank mit dsamain auf Port 5000 bereitgestellt

Weiterer Nachweis007 – Snapshot-LDAP-Instanz DC:5000 online

Weiterer Nachweis008 – ADUC mit Snapshot-Verbindung geöffnet

Weiterer Nachweis009 – Snapshot-Wert von Übungskonto C geprüft

Weiterer Nachweis011 – Snapshot erfolgreich unmounted

Weiterer Nachweis012 – Snapshot-Ordner im Explorer nicht mehr sichtbar

4. Aufgabe 21.2.3 – Active-Directory-Papierkorb

Ziel

Der Active-Directory-Papierkorb wurde aktiviert. Danach wurde Übungskonto D erstellt, der Gruppe Richtlinien-Ersteller-Besitzer zugeordnet, gelöscht und aus Deleted Objects am ursprünglichen Speicherort wiederhergestellt.

Troubleshooting

Beim ersten Aktivierungsversuch trat eine FSMO-/Replikationsmeldung auf. Diese wurde durch repadmin /syncall /PAed auf DC und anschließend auf Server1 bereinigt. Erst danach wurde die forestweite Aktivierung erfolgreich bestätigt.

Technischer Zusammenhang

Der AD-Papierkorb ist eine forestweite, nach Aktivierung nicht deaktivierbare Funktion. Er ermöglicht die Wiederherstellung gelöschter Objekte inklusive wichtiger Attribute und Gruppenmitgliedschaften. In Mehr-DC-Umgebungen ist korrekte Replikation eine Voraussetzung für zuverlässige Funktion.

Fachliche Erkenntnisse

Die Funktion schützt vor versehentlichem Objektverlust.
Replikation ist bei forestweiten AD-Funktionen kritisch.
Deleted Objects dient als zentrale Wiederherstellungsansicht.
Wiederhergestellte Objekte können ihre Gruppenmitgliedschaften behalten.

Nachweise

Weiterer Nachweis013 – AD-Papierkorb vor Aktivierung

Weiterer Nachweis015 – Fehler beim Aktivieren: FSMO/Replikation

Weiterer Nachweis016 – Replikation auf DC angestoßen

Weiterer Nachweis017 – Replikation auf Server1 angestoßen

Weiterer Nachweis019 – Forestweite Aktivierung des Papierkorbs bestätigt

Weiterer Nachweis022 – Deleted Objects sichtbar

Weiterer Nachweis023 – Benutzer Übungskonto D erstellt

Weiterer Nachweis024 – Übungskonto D Gruppenmitgliedschaft zugewiesen

Weiterer Nachweis025 – Löschen von Übungskonto D bestätigt

Weiterer Nachweis026 – Übungskonto D in Deleted Objects

Weiterer Nachweis027 – Übungskonto D am ursprünglichen Ort wiederhergestellt

Weiterer Nachweis028 – Gruppenmitgliedschaft nach Wiederherstellung erhalten

5. Aufgabe 21.4 – Password Settings Objects

Ziel

Es wurden zwei Fine-Grained Password Policies erstellt:Kennwort-Leicht für Übungskonto C mit Mindestlänge 2 und Kennwort-Schwer für Übungskonto D mit Mindestlänge 12.

PSO	Zielobjekt	Mindestlänge	Zweck
Kennwort-Leicht	Übungskonto C	2	bewusst schwache Testrichtlinie
Kennwort-Schwer	Übungskonto D	12	strengere Richtlinie mit Standardkomplexität

Technischer Zusammenhang

Password Settings Objects ermöglichen differenzierte Kennwortrichtlinien innerhalb einer Domäne. Sie gelten direkt für Benutzer oder Gruppen und können die allgemeine Kennwortrichtlinie der Default Domain Policy für konkrete Zielobjekte übersteuern. Wenn mehrere PSOs greifen, entscheidet die Rangfolge.

Testergebnis

Benutzer	Test	Einordnung
Übungskonto C	kurzes Kennwort `12`	Passend zur Mindestlänge 2; kein Fehlerdialog ist belegt.
Übungskonto D	`12`	erwartungsgemäß abgelehnt
Übungskonto D	`[Laborkennwort nicht angezeigt]`	erwartungsgemäß abgelehnt, insbesondere wegen Mindestlänge 12
Übungskonto D	längeres Kennwort	als finaler Positivtest vorbereitet; kein separater Erfolgsdialog vorhanden

Fachliche Grenze: Die Eingabe eines längeren Kennworts ist sichtbar; ein abschließender Erfolgsdialog liegt nicht vor. Der positive Langpassworttest wird daher nicht als abgeschlossen behauptet.

Fachliche Erkenntnisse

PSOs ermöglichen feinere Sicherheitssteuerung als eine einzige Domänenkennwortrichtlinie.
Die resultierende Kennworteinstellung muss geprüft werden.
Konfiguration und praktische Tests gehören zusammen.
Für privilegierte Konten sind strengere PSOs ein realistisches Sicherheitsmittel.

Nachweise

Weiterer Nachweis029 – Default Domain Policy Kennwortrichtlinie geprüft

Weiterer Nachweis030 – PSO Kennwort-Leicht erstellt