Das komplette Handbuch zu DUGiT_WinPrep.ps1

Was das Script macht und wie die gut 2.200 Zeilen intern gegliedert sind — nützlich, wenn du selbst mal etwas ergänzen willst.

DUGiT_WinPrep entfernt Bloatware, deaktiviert Telemetrie/Copilot/Recall, härtet Sicherheitseinstellungen, konfiguriert Windows Defender, setzt Energieoptionen, wendet das DUG-iT Look & Feel an (Taskleiste, Rechtsklick-Menü, Hintergrund, Edge) und installiert TeamViewer — auf einem frischen oder bereits genutzten Windows-11-Rechner beim Kunden. Es läuft entweder interaktiv über ein Pfeiltasten-Menü oder unattended ohne jede Rückfrage, z. B. per GPO oder Softwareverteilung.

Die acht Blöcke im Script

Neue Anpassung ergänzen

Ein neuer Eintrag nach dem Muster $Tasks['ID'] = @{ Cat=...; Default=...; IsHKCU=...; Name=...; Action={...}; Undo={...} } im Block „Task-Definitionen" reicht — Menü, -ListTasks und die Unattended-Parameter greifen den automatisch auf. Undo weglassen markiert eine Aufgabe als nicht rückgängig machbar (taucht dann beim Deinstallieren nicht auf). IsHKCU=$true markiert Aufgaben mit benutzerspezifischen Registry-Änderungen, die auch für andere angemeldete Benutzer übernommen werden (siehe Kapitel 02) — Action/Undo dürfen dafür ausschließlich HKCU:-Pfade verwenden.

Der wichtigste Stolperstein im Praxiseinsatz: Das Script läuft oft unter einem anderen Konto, als am Bildschirm angemeldet ist.

Wird „Als Administrator ausführen" mit anderen Anmeldedaten bestätigt (z. B. einem separaten Admin-Konto, während am Rechner der Praxis-Mitarbeiter „Praxis" angemeldet ist), zeigen $env:USERNAME und $env:USERPROFILE weiterhin auf das Admin-Konto — nicht auf den Menschen, der tatsächlich vor dem Bildschirm sitzt. Ohne Gegenmaßnahme würden Taskleiste, Rechtsklick-Menü, Hintergrundbild und Edge-Verknüpfung im falschen Profil landen.

WinPrep löst das automatisch: Get-InteractiveUser fragt stattdessen Win32_ComputerSystem.UserName ab, was zuverlässig den Menschen an der aktiven Konsolensitzung meldet. Der vollqualifizierte Name (z. B. PRAXIS\Praxis) wird über Windows' eigene Kontoauflösung (NTAccount.Translate()) in eine SID übersetzt — nicht über einen Namensvergleich mit Profilordnern, da Ordnername und Kontoname nach einem Profilkonflikt auseinanderlaufen können (Windows hängt dann z. B. .PCNAME an den Ordner, das Konto selbst bleibt aber sauber).

  User:    ADMIN-KONTO\vinko [Admin]
  ACHTUNG: Script laeuft als 'vinko', angemeldet ist aber 'Praxis'.
           HKCU-Anpassungen (Aussehen, Edge-Verknuepfung etc.) werden automatisch
           auf 'Praxis' umgeleitet, nicht auf dieses Elevation-Konto.

Praktisch bedeutet das: Alle Aufgaben mit IsHKCU=$true (Taskleiste, Explorer, Hintergrund, Edge-Bereinigung, TeamViewer-Downloads-Ordner) werden über Apply-ToUserHive gezielt auf das Profil von „Praxis" angewendet — per reg load/reg unload der NTUSER.DAT, oder direkt über HKEY_USERS\<SID>, falls der Benutzer bereits angemeldet ist. Das gilt für den interaktiven Lauf genauso wie für Unattended. Systemweite (HKLM-)Aufgaben wie RDP aktivieren, Defender konfigurieren oder Bloatware entfernen sind davon nicht betroffen — die gelten ohnehin maschinenweit.

Angemeldeten Benutzer abwählen

Bei Menüpunkt 1/3 zeigt die Checkliste „Betroffene Benutzer" den angemeldeten Hauptbenutzer jetzt als eigenen, ebenso abwählbaren Eintrag — „<Benutzer> (angemeldeter Hauptbenutzer)", Standard weiterhin angehakt (bisheriges Verhalten). Nur sichtbar, wenn das Script überhaupt unter einem anderen Konto läuft (RunningAsOtherAccount); läuft es unter dem angemeldeten Konto selbst, gibt es diese Unterscheidung gar nicht erst. Für Unattended-Läufe gibt es dafür den Schalter -SkipInteractiveUser (Kapitel 05) — analog zu -SkipOtherUsers, aber für den Hauptbenutzer statt für zusätzliche Profile.

Der Normalfall bei einem Vor-Ort-Einsatz: Doppelklick oder Start aus der Konsole, dann per Menü führen.

Nach dem Start zeigt das Script Logo, Haftungshinweis (mit Enter bestätigen) und eine Systeminfo-Übersicht (OS-Version, Gerät, Aktivierungsstatus, lokale Benutzer, Geräte-Manager-Probleme, Zeitpunkt des letzten Laufs). Danach folgt das Hauptmenü:

Bedienung der Aufgabenliste

Bei Menüpunkten 1–3 folgt die Aufgaben-Checkliste, gruppiert nach Kategorie, mit Ist-Zustand-Anzeige pro Zeile:

Jede Zeile trägt ein Tag, das den Zustand laut letztem Lauf zeigt: [installiert] [nicht installiert] [entfernt] [FEHLER]. Beim Rückgängig-Menü wird eine Zeile gelb hervorgehoben, wenn sie zwar installiert ist, aber gerade abgewählt wurde — also bewusst so bleiben soll. Auf Hosts ohne Pfeiltasten-Unterstützung (z. B. der PowerShell-ISE) schaltet das Menü automatisch auf Texteingabe um: Nummern bzw. Bereiche wie 3-7 toggeln, Enter führt aus.

Nach der Aufgabenauswahl fragt das Script noch, ob eine ausführliche Ausgabe (Verbose) gewünscht ist — zeigt dann zusätzliche Detailzeilen (z. B. welche Registry-Werte genau gesetzt wurden) zu jeder Aufgabe.

Alle 21 Aufgaben mit Standardauswahl (vorausgewählt bei Menüpunkt 1 bzw. bei einem Unattended-Lauf ohne Task-Parameter) und ob eine Rückgängig-Routine existiert. Referenz für Menü, -ListTasks und die Unattended-Parameter in Kapitel 05.

Für Rollouts per GPO-Anmeldeskript, RMM-Task oder Fernwartung, bei denen niemand vor der Konsole sitzt, um Häkchen zu setzen.

Schnellstart

Der Regelfall — alle Standardaufgaben installieren, ohne jede Rückfrage:

PS C:\DUGITInstall> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL

Um vorab nachzusehen, welche Aufgaben-IDs die aktuell installierte Skriptversion kennt, bevor du eine Parameterzeile schreibst:

PS C:\DUGITInstall> .\DUGiT_WinPrep.ps1 -ListTasks
  TEL01    An (Standard)  Telemetrie, Diagnose, Online-Konto-Zwang aus (System)   (Undo)
  TEL02    An (Standard)  Werbe-ID, Tracking, Sprache, Freihand, Cloud-Inhalte aus (Undo)
  ...

-ListTasks gibt nur den Katalog aus und beendet sich sofort — es wird nichts installiert oder verändert, auch nicht mit -Unattended kombiniert, und es ist keine Elevation nötig.

Parameter-Referenz

Bei -OnlyTasks, -ExcludeTasks und -IncludeTasks sind Kommas, Semikolons und Leerzeichen als Trenner erlaubt, Groß-/Kleinschreibung spielt keine Rolle — tel01,ai01 und TEL01 AI01 sind gleichwertig.

Wie die Auswahl aufgelöst wird

Die drei Task-Parameter wirken nicht gleichzeitig, sondern in einer festen Reihenfolge:

1. Ist -OnlyTasks gesetzt? Dann läuft ausschließlich diese Liste. Alles andere in diesem Abschnitt entfällt.
2. Sonst: Standardauswahl aus dem Katalog. Jede Aufgabe startet mit ihrem eigenen Vorgabewert — Spalte „Standard" in Kapitel 04.
3. -ExcludeTasks anwenden. Genannte IDs werden aus der Standardauswahl entfernt.
4. -IncludeTasks anwenden. Genannte IDs werden zusätzlich aktiviert, auch wenn ihr Standard „aus" war.

Exit-Codes

Für RMM-Tools/Aufgabenplanung, die das Ergebnis auswerten wollen, ohne das Transcript-Log zu parsen. Der Bootstrap-Schritt (Kapitel 01) wartet auf den elevierten Kindprozess und spiegelt dessen Code, das gilt also auch beim ursprünglichen, nicht-elevierten Aufruf.

Beispiele aus der Praxis

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL -ExcludeTasks "TOOL01,SONST01"

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL -IncludeTasks "DEF02"

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL -OnlyTasks "TEL01,TEL02,AI01,SEC01,SEC02"

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode DEINSTALL

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL -SkipOtherUsers -DetailedLog

PS> .\DUGiT_WinPrep.ps1 -Unattended -ScriptMode INSTALL -SkipOtherUsers -SkipInteractiveUser -SkipDesktopIcons

Menüpunkt 4 — räumt Überbleibsel der alten DUG-iT-Scripte (V1/V2-Härtung) und einer alten Lokal-GPO-Härtungsvorlage auf, bevor die neuen Aufgaben aus Kapitel 04 sauber greifen können. Läuft in dieser festen Reihenfolge:

1. V2-Schäden entfernen. Löscht hlsvchost.exe/hard.exe, korrigiert einen manipulierten DiagTrack-Dienstpfad, entfernt die zugehörige Firewall-Blockregel und die per Policy erzwungene SmartScreen-Deaktivierung.Setzt außerdem den Besitzer von svchost.exe zurück auf TrustedInstaller, falls V2s Hardlink-Trick ihn auf „Administratoren" geändert hatte.
2. Härtung zurücksetzen. LSA-Einstellungen (RunAsPPL, RestrictAnonymous*), Firewall-Profile auf „nicht konfiguriert", Kontorichtlinien (net accounts), Windows Script Host wieder aktiviert, LocalAccountTokenFilterPolicy entfernt, ExecutionPolicy zurückgesetzt, WinRM-Listener bei Bedarf wiederhergestellt.
3. Aktivierungsdienste prüfen. Reaktiviert sppsvc/LicenseManager/wlidsvc/WaaSMedicSvc, falls deaktiviert, und meldet den aktuellen Aktivierungsstatus.
4. Alte lokale Gruppenrichtlinie entfernen. Sichert registry.pol (Machine + User) und gpt.ini nach DUGITInstall\GPO_Backup_<Zeitstempel>, löscht sie, dann gpupdate /force.Bekannter Konflikt der alten Vorlage: SmartScreen und Defender-Echtzeitschutz waren dort per Policy zwangsdeaktiviert — widerspricht Kapitel 04. Als Sicherheitsnetz werden diese Policy-Werte zusätzlich direkt aus der Registry entfernt, falls gpupdate die Historie nicht sauber zurückrollt.
5. Alte Windows-Update-Verzögerung entfernen. Räumt Werte unter dem falschen, nicht-autoritativen Pfad PolicyState auf.
6. Alte NIC-Energiesparen-Registry entfernen. Sucht Netzwerkadapter mit direkt gesetztem PnPCapabilities=24 und entfernt den Wert.
7. Alte SMB-/Cortana-/Store-Policies zurücksetzen. SMB-Autodisconnect, Cortana-Firewallregeln, Store-Auto-Update-Policy, IE-„Suggested Sites".

Jeder Schritt schreibt einen kondensierten Log-Eintrag (Anzahl Funde/Reparaturen) statt einer Zeile pro Registry-Wert — für den Überblick reicht das, Details stehen bei aktivem Verbose-Modus zusätzlich im Transcript-Log.

Was nach jedem Lauf in C:\DUGITInstall liegt, was vorab geprüft wird, und wie das eigene Branding ohne Kundendaten anzutasten reinkommt.

Transcript-Log

Ab dem allerersten Bootstrap-Schritt läuft Start-Transcript mit — das Log fängt also auch dann alles ab, wenn das Script mitten im Lauf abstürzt. Dateiname: WinPrep_<JJJJMMTT_hhmmss>.log. Am Ende steht zusätzlich ein kompaktes Protokoll auf der Konsole: Zeitstempel, Task-ID, Status ([OK]/[!!]), Ergebnis und ggf. Fehlerdetail pro Zeile.

state.json

Pro Task-ID wird der Ist-Zustand gespeichert, nicht nur ob der letzte Lauf erfolgreich war — das macht das Menü (Kapitel 03) und die Deinstall-Vorauswahl erst möglich:

Werte aus früheren Läufen, die im aktuellen Lauf gar nicht ausgewählt waren, bleiben unangetastet erhalten — state.json wird also gemerged, nicht überschrieben.

Update-Check

Direkt nach der Systeminfo prüft das Script, ob unter $script:UpdateCheckUrl (aktuell https://dl.dug-it.de/winprep/VERSION.txt, überschreibbar per -UpdateUrl) eine neuere Version als die lokal laufende hinterlegt ist. Kein Internet oder die Adresse nicht erreichbar: nur eine graue Konsolenzeile, der Lauf geht normal weiter — das darf nie blockieren. Ist eine neuere Version verfügbar: interaktiv nur eine Warnung (Enter = trotzdem fortfahren), unattended bricht der Lauf mit Exit-Code 2 ab (Kapitel 05), außer bei -SkipUpdateCheck. Lädt nicht automatisch nach — siehe Kapitel 09 für den eigentlichen Update-Weg.

Vorab-Prüfung

Direkt danach prüft Get-PreflightWarnings still im Hintergrund: freier Speicherplatz auf C:, ausstehender Neustart (Component-Based-Servicing/Windows-Update-Marker), laufendes Windows-Servicing (TrustedInstaller). Reine Warnung, kein Abbruch — taucht in der Konsole und im Kunden-Report auf, landet aber bewusst nicht in state.json.

Kunden-Report

Am Ende jedes Laufs entsteht zusätzlich zum Transcript-Log ein kurzer HTML-Bericht (WinPrep_Report_<JJJJMMTT_hhmmss>.html in C:\DUGITInstall): Ergebnis-Zusammenfassung, Vorab-Prüfung-Hinweise falls vorhanden, und eine Tabelle aller ausgeführten Aufgaben mit Status. Zum Dalassen beim Kunden oder für die eigene Doku — unabhängig vom Transcript-Log, das eher fürs Troubleshooting gedacht ist.

Eigenes Hintergrundbild

Datei Hintergrund.jpg (oder .png/.bmp) unter C:\DUGITInstall ablegen — wird von den Aussehen-Aufgaben automatisch für Desktop und An-/Abmeldebildschirm übernommen. Liegt keine Datei dort, bleibt es bei Windows-Blau (Desktop) und Windows Spotlight (Anmeldung). Keine weitere Konfiguration nötig — die Datei wird bei jedem Lauf automatisch erkannt.

Kurzreferenz für den Ordner C:\DUGITInstall und ein paar Betriebs-Eigenheiten, die beim Troubleshooting relevant werden können.

Berechtigungen auf DUGITInstall

Bei jedem Lauf setzt das Script icacls ... /grant *S-1-5-32-545:(OI)(CI)(M) auf den Ordner — das öffnet Lesen/Schreiben/Löschen für die Gruppe „Benutzer" (nicht nur Administratoren), vererbt sich auch auf Dateien, die erst später dort landen, und ist idempotent. Nötig, weil z. B. eine vom Elevation-Konto heruntergeladene TeamViewer-Datei sonst vom eigentlichen, nicht-administrativen Benutzer nicht geöffnet werden könnte.

Selbst-Elevation

Läuft das Script ohne Adminrechte, startet es sich selbst über Start-Process powershell.exe -Verb RunAs neu und reicht dabei alle gesetzten Parameter (inklusive der Unattended-Task-Auswahl) als Kommandozeile durch. Der ursprüngliche, nicht-elevierte Aufruf wartet auf den elevierten Kindprozess (-Wait -PassThru) und beendet sich dann mit dessen Exit-Code (Kapitel 05) — wichtig für den Ein-Zeiler-Einsatz in Kapitel 09, sonst würde ein aufrufendes RMM-Tool immer nur den Exit-Code dieses Bootstrap-Schritts sehen. -ListTasks braucht keine Elevation und wird deshalb nicht mit durchgereicht, sondern direkt nach dem Neustart mit Adminrechten ausgewertet, sobald der Aufgabenkatalog geladen ist.

Mark-of-the-Web

Wurde die Datei per Netzwerk/Download kopiert, trägt sie unter Umständen ein Mark-of-the-Web (Zone.Identifier), das „Rechtsklick > Mit PowerShell ausführen" inkonsistent blockieren kann. Das Script entsperrt sich deshalb beim Start selbst über Unblock-File.

Wie das Script tatsächlich auf einen Kunden-PC kommt — vom Ein-Zeiler für den Vor-Ort-Termin bis zur unbeaufsichtigten Verteilung.

Alles hier basiert auf dl.dug-it.de — einem internen Download-Server (mehrere Projekte, WinPrep liegt unter /winprep/), der bei jedem git push ins WinPrep-Repo spätestens 10 Minuten später automatisch die aktuelle Version ausliefert. Kein manuelles Kopieren von USB-Sticks mehr nötig, sofern der Kunden-PC Internetzugang hat.

Der Ein-Zeiler (Regelfall für einen Vor-Ort-Termin)

PowerShell als Administrator öffnen (wichtig — siehe Hinweis unten), dann:

PS> iex(irm https://dl.dug-it.de/wp.ps1)

wp.ps1 ist der generische DUG-iT-Tool-Launcher (DUGiT_Tools_Launcher.ps1) — zeigt bei mehreren verfügbaren Tools eine nummerierte Auswahl, aktuell mit nur einem Eintrag (WinPrep) startet er ohne Rückfrage direkt durch. Er lädt dafür DUGiT_WinPrep_Bootstrap.ps1 nach, der wiederum die aktuelle DUGiT_WinPrep.ps1 nach C:\DUGITInstall herunterlädt und startet — das normale interaktive Menü (Kapitel 03) erscheint, als hätte man die Datei lokal dabei gehabt. Weitere DUG-iT-Tools kommen künftig als zusätzlicher Menüpunkt im selben Launcher dazu, ohne dass sich diese URL ändert. Bewusst ohne Pipe (|) geschrieben — auf deutschen Tastaturen braucht | AltGr+7, (/) nur Shift+8/9. Die klassische Pipe-Form funktioniert genauso: irm https://dl.dug-it.de/wp.ps1 | iex.

Mit Parametern (Unattended, Task-Auswahl, …)

iex(irm ...) kann keine Parameter entgegennehmen — dafür den Bootstrap erst als Datei speichern, dann wie gewohnt mit Parametern aufrufen (identische Parameter wie DUGiT_WinPrep.ps1 selbst, siehe Kapitel 05):

PS> iwr https://dl.dug-it.de/wp.ps1 -OutFile boot.ps1
PS> .\boot.ps1 -Unattended -ExcludeTasks "TOOL01,SONST01"

Ohne Internet auf dem Kunden-PC

Der Ein-Zeiler braucht Internetzugang auf dem Zielgerät. Ohne Internet bleibt der klassische Weg: DUGiT_WinPrep.ps1 selbst (z. B. per USB-Stick) nach C:\DUGITInstall kopieren und direkt starten — der Update-Check (Kapitel 07) schlägt dann einfach lautlos fehl und blockiert nichts.

Handbuch unterwegs

Dieses Handbuch liegt ebenfalls auf dl.dug-it.de, zum Nachschlagen ohne lokale Kopie:

• dl.dug-it.de/winprep/DUGiT_WinPrep_Handbuch.html
• dl.dug-it.de/winprep/DUGiT_WinPrep_Handbuch.pdf

Menüpunkt 5 — ein Untermenü mit drei einzeln startbaren, unterschiedlich riskanten Schritten statt einem einzigen automatischen Ablauf. Grundprinzip: der Reparaturversuch darf niemals mehr kaputt machen als reparieren.

1) Reparaturversuch

Zeigt zuerst eine Übersicht beider möglichen Key-Quellen: den lokal installierten Key (Edition, Status, sowie der von Windows selbst nur auf 5 Zeichen begrenzte Teil-Key — keine Einschränkung dieses Scripts) und einen eventuell im BIOS/UEFI hinterlegten OEM-Key (ACPI/MSDM-Tabelle, häufig bei Fertig-PCs), diesen vollständig, da er ohnehin für die OEM-Wiederherstellung gedacht und kein Geheimnis ist.

  -- Lokal installierter Key --
    Edition:  Windows 11 Pro
    Teil-Key: T83GX  (Windows zeigt fuer einen installierten Key nie mehr als die letzten 5 Zeichen)
    Status:   Unlizenziert
    HINWEIS: Das ist Microsofts oeffentlicher Platzhalter-Key (Windows 10/11 Pro) -
    kein echter Kauf-/OEM-Key. Damit aktiviert Windows NIE, ausser ueber einen eigenen
    KMS-Host im Netzwerk - es wird der echte Lizenzkey benoetigt.
  -- BIOS/UEFI-OEM-Key --
    AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

Danach folgt der eigentliche Ablauf:

1. Bereits aktiviert? Dann sofort Abbruch mit grüner Meldung — keine weiteren Schritte.
2. Online-Aktivierung versuchen (slmgr /ato). Nutzt ausschließlich den bereits installierten Key. Löscht oder ersetzt an dieser Stelle nichts.
3. Nur falls danach immer noch überhaupt kein Key installiert ist (z. B. Fehlercode 0xC004F213 „kein Product Key gefunden"): Der BIOS/OEM-Key wird zum Einspielen angeboten — ausschließlich nach expliziter J/n-Bestätigung, und ausschließlich in diesem „gar kein Key da"-Fall. Ist bereits ein Key installiert (und sei es nur der Generic/KMS-Client-Platzhalter), wird dieser Schritt komplett übersprungen — ein vorhandener Key wird nie automatisch überschrieben.
4. Bleibt die Aktivierung erfolglos: Angebot, den offiziellen Windows-Aktivierungs-Troubleshooter zu öffnen (ms-settings:activation) — Microsofts eigene geführte Problembehandlung, u. a. für Fälle mit digitaler Lizenz nach Hardwarewechsel via Microsoft-Konto-Verknüpfung.

Exakte Fehlermeldung statt „nicht aktiviert"

Erfolg/Misserfolg wird zuverlässig, sprachunabhängig per WMI-Status geprüft (Get-WindowsActivationInfo) — ein reiner Textvergleich wäre bei deutscher vs. englischer Windows-Installation fragil. Zusätzlich fängt Invoke-Slmgr die komplette Konsolenausgabe von slmgr.vbs ab (statt sie wie in früheren Versionen nach Out-Null zu schicken) und zeigt sie direkt an — bei jedem der drei slmgr-Aufrufe (/ato, /ipk, /upk), egal ob erfolgreich oder nicht. Landet zusätzlich im Detail-Feld des Protokolls, taucht also auch im Kunden-Report auf.

  Online-Aktivierung versuchen (slmgr /ato) ...
    -> Weiterhin nicht aktiviert.
    Genaue slmgr-Meldung: Aktivierungsfehler: 0xC004F213 Es wurde kein Product Key
    fuer die Aktivierung von Windows gefunden. Verwenden Sie "slmgr.vbs /ipk" zur
    Eingabe eines gueltigen Product Keys.

  Kein Product Key installiert - suche nach einem im BIOS/UEFI hinterlegten
  OEM-Key (haeufig bei Fertig-PCs vorhanden) ...
    -> BIOS/OEM-Key gefunden: W269N-WFGWX-YVC9B-4J6C9-T83GX
  Diesen Key einspielen und Aktivierung erneut versuchen? (J/n):
    slmgr-Meldung (Key einspielen): Product Key wurde erfolgreich installiert.
    -> Aktivierung mit BIOS-Key erfolgreich.
    Genaue slmgr-Meldung: Produkt wurde erfolgreich aktiviert.

Grobe Einordnung des Fehlercodes

Get-ActivationErrorCategory sucht in der slmgr-Ausgabe nach einem Fehlercode (0x........) und ordnet ihn einer von acht groben Kategorien zu, jeweils mit kurzem Hinweis zum nächsten Schritt — erscheint direkt unter der genauen Meldung, nur bei Fehlschlag. Quelle: Microsofts eigene Support-Dokumentation. Kategorien bewusst nach Relevanz für DUG-iT-Kunden-PCs gewichtet (Einzelplatz-Retail/OEM/Digital-Lizenz, keine Firmen-Volumenlizenz) — MAK/KMS-Host-spezifische Codes sind deshalb nur als eine Sammelkategorie drin.

Unbekannte, nicht in dieser Liste enthaltene Codes fallen auf einen generischen Hinweis mit Link zur Microsoft-Dokumentation zurück, statt stillschweigend nichts anzuzeigen.

2) Server-/Firewall-Erreichbarkeit prüfen

Reine Diagnose, unabhängig vom Reparaturversuch einzeln startbar (z. B. um gegenüber Kunde/IT ein Firewall-Problem konkret zu belegen). Prüft per Test-NetConnection auf Port 443, ob die für die Online-Aktivierung nötigen Microsoft-Server erreichbar sind:

• activation.sls.microsoft.com
• validation.sls.microsoft.com
• crl.microsoft.com (Zertifikatsprüfung — wird gerne übersehen, blockiert aber genauso die Aktivierung)

Ist mindestens einer nicht erreichbar, deutet das auf Firewall/Proxy/DNS als eigentliche Ursache für eine fehlgeschlagene Online-Aktivierung hin — unabhängig von einem eventuell vorhandenen, aber ungültigen Key.

3) Hinterlegten Key entfernen (Reset)

Verlangt zur Bestätigung die exakte, großgeschriebene Eingabe ENTFERNEN — ein einfaches J/n reicht bewusst nicht, „entfernen" kleingeschrieben ebenfalls nicht. Jede andere Eingabe bricht ohne jede Änderung ab. Wird nirgends automatisch aufgerufen, auch nicht vom Reparaturversuch. Auch hier zeigt Invoke-Slmgr die genaue Bestätigungsmeldung von slmgr /upk an (typischerweise „Product Key wurde erfolgreich deinstalliert.").

4) Windows Script Host sicherstellen

Minimaler Einzelzweck-Punkt, unabhängig von SEC01 (Kapitel 04) und vom vollen Reparaturversuch einzeln startbar: zeigt nur den aktuellen WSH-Status (aktiviert / deaktiviert / nicht gesetzt — Windows-Standard ist dabei aktiviert) und aktiviert bei Bedarf, ohne gleich eine komplette Aktivierung oder Aufgabe mitzustarten. Sinnvoll z. B. direkt nach einem manuellen slmgr-Aufruf, der noch fehlschlägt, oder um den Status schnell zu prüfen, ohne extra durch Punkt 1 zu gehen.