Technische Dokumentation · Windows 11 · Hyper-V
Windows-Clients im Labor: bereitstellen, standardisieren und absichern
Fünf zusammenhängende Arbeitsblöcke führen von der virtuellen Client-Bereitstellung über Updates, Netzwerk und Speicher bis zu Berechtigungen und Basishärtung.
Orientierung
Umgebung und technische Arbeitsfolge
Die Arbeiten entstanden in virtuellen Windows-11-Laborumgebungen auf Hyper-V. Im Mittelpunkt standen nachvollziehbare Entscheidungen, kontrollierte Änderungen und die Prüfung sichtbarer Zustände.
Die Kapitel folgen dem technischen Lebenszyklus eines Clients: Installation, Nachbereitung, Konnektivität und Speicher, Rechtekonzept sowie lokale Sicherheitsmaßnahmen.
Client-Bereitstellung
Windows 11 Pro als virtuelle Arbeitsbasis
Der erste Block dokumentiert Auswahl, Neuinstallation und Ersteinrichtung eines Windows-11-Clients in Hyper-V.
Ziel und Praxisbezug
Eine definierte Neuinstallation schafft eine kontrollierbare Ausgangsbasis für weitere Konfigurations-, Netzwerk- und Sicherheitsaufgaben. Windows 11 Pro wurde gewählt, weil diese Edition besser zu einem verwaltbaren Laborclient passt als eine reine Home-Edition.
Vorgesehen waren eine Generation-2-VM, 4096 MB Arbeitsspeicher, zwei virtuelle Prozessoren, ein Windows-11-Installationsmedium und eine benutzerdefinierte Neuinstallation.
Bereitstellungsweg
Virtuelle Maschine beginnen
Im Hyper-V-Manager wurde der Assistent für einen neuen virtuellen Computer geöffnet.
Im Hyper-V-Manager ist im Aktionsmenü „Virtueller Computer“ für eine neue VM ausgewählt. Grundkonfiguration festlegen
Der Assistent zeigt eine Generation-2-VM mit 4096 MB RAM, virtueller Festplatte und eingebundenem ISO. In diesem Zwischenstand heißt die VM noch
Win11.
Der Assistent fasst Win11 als Generation-2-VM mit 4096 MB, virtueller Festplatte und Installations-ISO zusammen. Sicherheitsrelevante VM-Einstellungen prüfen
Als Konfiguration sind Sicherer Start und TPM festgehalten. Die gezeigte Einstellung nennt Sicherer Start und einen virtuellen Prozessor, enthält aber keinen TPM-Eintrag. Wie sich dieser Stand zu den vorgesehenen zwei virtuellen Prozessoren entwickelt hat, ist nicht festgehalten.
„Sicherer Start“ ist aktiviert; im Navigationsbaum ist ein virtueller Prozessor angegeben. Ein TPM-Eintrag ist nicht zu sehen. Edition und Installationsweg auswählen
Im Windows-Setup wurde Windows 11 Pro ausgewählt und als Neuinstallation auf nicht zugewiesenem Speicherplatz vorbereitet.
Windows 11 Pro ist in der Editionsliste markiert. 
Der Installationsdialog bietet Upgrade und benutzerdefinierte Neuinstallation. 
127,0 GB nicht zugewiesener Speicherplatz stehen als Installationsziel bereit. Ersteinrichtung durchführen
Die regionale OOBE-Einrichtung wurde durchlaufen und ein lokales Benutzerkonto angelegt. Sicherheitsfragen und Kennwortdetails sind nicht dargestellt.
Deutschland ist im OOBE-Dialog als Region ausgewählt.
System- und Kontokontext
Die Systemansichten nennen später Win11Pro als Gerätenamen, kennzeichnen das System als virtuelle Maschine, zeigen ein lokales Konto und weisen auf die fehlende Windows-Aktivierung hin. Die separate Editionsauswahl enthält Windows 11 Pro. Ob Win11 und Win11Pro durch Umbenennung oder Neuerstellung verbunden sind, bleibt ungeklärt.
Für das System wurden außerdem Version 21H2, Build 22000.194, ein x64-System und ein Workgroup-Kontext festgehalten. Der gezeigte Kontenausschnitt enthält diese Angaben nicht und nennt weder Windows-Version noch Buildnummer.
Die Installation führte zu einem startfähigen Client, der anschließend für Updates sowie Netzwerk-, Rechte- und Sicherheitsübungen verwendet wurde.
Post-Install-Standardisierung
Den frisch installierten Client nachbereiten
Updates, Geräteprüfung, Browser-Setup und eine kleine App-Bereinigung bilden den dokumentierten Grundzustand vor weiteren Laboraufgaben.
Standardisierungsschritte nach der Installation
- Windows Update und Updateverlauf geprüft
- virtuelle Geräte und Treiber im Geräte-Manager kontrolliert; dabei wurden keine auffälligen kritischen Warnsymbole festgehalten
- zentrale Systemeinstellungen gesichtet
- Mozilla Firefox installiert, gestartet und als Standardbrowser festgelegt
- Browser-Basiseinstellungen geprüft
- nicht benötigte Xbox-App entfernt
Diese Nachbereitung ist von späterer Systemhärtung getrennt: Der Block schafft einen nutzbaren Laborzustand, keine vollständige Sicherheitsbaseline.
Netzwerk und Speicher
Zwei Clients verbinden und Arbeitsdaten absichern
Der Block verbindet ein isoliertes IPv4-Testnetz mit einer getrennten Speicheraufgabe auf einer eigenen VM.
Im Netzwerkteil wurden zwei Windows-11-Clients über den virtuellen Switch Privat1 verbunden, statisch adressiert und in beide Richtungen geprüft. Im Speicherteil wurde eine separate VM mit rund 80 GB bereitgestellt, in System- und Arbeitsdatenbereich aufgeteilt und der Status von BitLocker dokumentiert.
Privates Testnetz und Konnektivität
Für die Client-zu-Client-Kommunikation wurde ein isoliertes virtuelles Netz vorgesehen. Der erste Dialog zeigt noch keinen fertigen privaten Switch; die spätere Adapteransicht weist jedoch die Bindung an Privat1 nach.
Der erste Ping schlug fehl. Nach dem Freigeben eingehender ICMPv4-Echoanfragen antworteten beide Clients. Gateway und DNS waren für die isolierte Direktkommunikation nicht vorgesehen; die beidseitigen Ping-Ergebnisse betreffen ausschließlich dieses Labornetz.
ipconfig /all
netsh advfirewall firewall add rule name="ICMPv4 Ping Allow" protocol=icmpv4:8,any dir=in action=allow
ping 192.168.50.11
ping 192.168.50.12Datenträger und Arbeitsdaten
Eine separate VM Win11DataLab hielt Netzwerk- und Speicheraufgabe sauber getrennt. Der 80-GB-Datenträger wurde im Setup in einen Systembereich von 39,9 GB und 40,0 GB freien Bereich aufgeteilt.
BitLocker: Fehlerbild, Zwischenzustand und späterer Status
Die Bildfolge hält drei getrennte Zustände fest: eine BitLocker-Fehlermeldung am Systemlaufwerk, ein weiterhin gemountetes ISO in Hyper-V und einen späteren BitLocker-Stand für das Datenlaufwerk. Das Installationsmedium wurde zur Fehlerbehebung entfernt; die mittlere Ansicht zeigt jedoch noch den Zustand davor.
Netzwerk
cl01 und cl02 verwenden statische IPv4-Adressen und antworten in beide Richtungen auf Ping.
Speicher
Aus dem freien Bereich entstand das NTFS-Volume Arbeitsdaten (D:).
Fehlersuche
Eine ICMP-Regel löste die Ping-Störung; das eingebundene ISO war die Ursache des BitLocker-Fehlers.
Benutzer und Rechte
Freigaben, NTFS und kontrollierter Zugriff
Der Block betrachtet lokale Rollen, UAC, Freigaberechte, NTFS-Berechtigungen und typische Fehler bei Netzwerkanmeldungen.
Auf cl01 wurde unter C:\Freigabe eine einfache Struktur für drei Zugriffsniveaus aufgebaut. Der fachliche Kern ist die Kombination zweier Ebenen: Freigabeberechtigung wirkt beim Netzwerkzugriff, NTFS-Berechtigung auf Dateisystemebene. Die restriktivere effektive Kombination entscheidet.
Für die Tests wurden die lokalen Rollen Admin und User unterschieden. Die Benutzerkontensteuerung blieb auf der üblichen Bestätigungsstufe, sodass administrative Änderungen weiterhin bewusst freigegeben werden mussten.
Freigabestruktur und beabsichtigte Rechte
| Ordner | Zweck | Beabsichtigter Zugriff |
|---|---|---|
| Admin | administrativer Bereich | nur administrativer Zugriff |
| Austausch | gemeinsamer Arbeitsbereich | lesen und schreiben |
| Lesen | Informationsbereich | lesen, nicht schreiben |
Zugriffstests und Fehlersuche
Geprüft wurden Standard- und Administratorkonto: Austausch sollte beschreibbar, Lesen nur lesbar und Admin für den Standardbenutzer gesperrt sein. Bei Problemen wurden Freigabe, NTFS, verwendetes Konto und vorhandene Netzwerkanmeldungen getrennt kontrolliert.
- Eine zunächst verlangte Kennwortänderung des Testbenutzers wurde in den lokalen Benutzereigenschaften behandelt.
- Beim verweigerten Admin-Zugriff wurden Freigabe- und NTFS-Berechtigung gemeinsam statt isoliert geprüft.
- Ein falscher oder bereits zwischengespeicherter Netzwerkanmeldekontext wurde durch eine ausdrücklich angegebene lokale Admin-Identität eingegrenzt.
net use \\192.168.50.11\Admin /user:CL01\Admin *Nach diesen Schritten folgten User-, Nur-Lesen-, Admin- und Schreibtests. Das dritte Bild hält noch den vorausgehenden Fehlerzustand fest.
Systemhärtung
Windows-Sicherheitsfunktionen und lokale Richtlinien
Der letzte Block umfasst Basisschutz auf einer separaten Windows-11-Pro-VM. Die Einstellungen und Prüfungen sind schriftlich festgehalten; separate Screenshots liegen für diesen Arbeitsblock nicht vor.
Der Arbeitsansatz trennt bewusst zwischen aktiv gesetzten Maßnahmen, geprüften Schutzfunktionen und Optionen, die in einer virtuellen Umgebung nicht ohne weitere Bewertung erzwungen wurden.
Damit wird Hardening nicht als Sammlung grüner Schalter behandelt, sondern als begründete Reduktion von Risiken und unnötiger Angriffsfläche.
Defender und Firewall
Eine Schnellüberprüfung endete ohne gefundene Bedrohung; Schutzupdates waren vorhanden und die Firewall blieb aktiv. Domänen-, Privat- und Öffentlich-Profil wurden betrachtet.
SmartScreen und unerwünschte Anwendungen
Aktiviert wurden die Prüfung von Apps und Dateien, SmartScreen für Edge und Store-Apps sowie die Blockierung potenziell unerwünschter Apps und Downloads.
Gerätesicherheit bewerten
Kernisolierung, Sicherheitschip-Bezug und Sicherer Start wurden geprüft. Speicherintegrität und weitergehende Virtualisierungs- oder Treiberschutzoptionen wurden in der VM nicht pauschal erzwungen, sondern als gesondert zu bewertende Funktionen eingeordnet.
Kennwort- und Sperrrichtlinien
Kennwortkomplexität wurde aktiviert, die Mindestlänge auf 10 Zeichen gesetzt und eine Kontosperrung nach 5 Fehlversuchen für 15 Minuten eingerichtet; der Zähler wird nach 15 Minuten zurückgesetzt.
Unnötige Zugänge begrenzen
Remote Desktop und Remoteunterstützung blieben deaktiviert. Gastkonto und integriertes Administratorkonto blieben ebenfalls deaktiviert.
Schutzverlauf und Geräteintegrität lesen
Schutzverlauf sowie Geräteleistung und -integrität wurden ohne auffällige Basisprobleme geprüft. „Sauberer Start“ wurde als Windows-Funktion eingeordnet und nicht als zusätzlich ausgeführte Maßnahme dargestellt.
| Bereich | Arbeitsschritt | Fachliche Idee |
|---|---|---|
| Malware-Schutz | Defender prüfen, Schnellüberprüfung ausführen | Schutzstatus nicht nur anzeigen, sondern aktiv kontrollieren |
| Netzwerk | Firewall aktiv belassen und Profile prüfen | Laborkomfort nicht durch Abschalten des Basisschutzes erkaufen |
| Anwendungen | SmartScreen und PUA-Schutz | Risiko unbekannter Downloads reduzieren |
| Konten | Komplexität, Mindestlänge, Sperrlogik | Triviale Kennwörter und einfaches Durchprobieren erschweren |
| Remotezugriff | nicht benötigte Funktionen deaktiviert lassen | unnötige Angriffsfläche vermeiden |
Technische Ergebnisse
Ergebnisse aus Bereitstellung, Betrieb und Härtung
Client bereitgestellt und nachbereitet
Windows 11 Pro wurde in Hyper-V installiert und anschließend mit Updates, Browser- und App-Schritten standardisiert.
Netzwerk, Speicher und Rechte umgesetzt
Statische IPv4-Adressen, ein Arbeitsdaten-Volume, BitLocker sowie Freigabe- und NTFS-Rechte bilden die technischen Kernarbeiten.
Fehler systematisch eingegrenzt
ICMP-Firewallregel, eingebundenes Installationsmedium und Netzwerkanmeldung wurden als konkrete Fehlerursachen bearbeitet.