winutil: Windows einrichten, entbläten und reparieren per PowerShell

winutil nach der Windows-Installation: Installs, Tweaks, Updates

winutil ist ein in PowerShell geschriebenes Werkzeug von Chris Titus Tech, das typische Systemaufgaben an einem Ort sammelt. Das README nennt vier Felder: Programme installieren, mit Tweaks entbläten, über den Config-Bereich Probleme eingrenzen und die Windows-Update-Einstellungen setzen. Die intendierte Nutzung lautet ausdrücklich, das Werkzeug bei jeder neuen Windows-Installation frisch auszuführen. Es ist also als Einrichtungsschritt positioniert, nicht als Dauerwartung, die im Hintergrund mitläuft.

Die Reichweite des Instruments zeigt sich in den Metadaten: 61.361 Sterne, 3.572 Forks, 31 offene Issues, Lizenz MIT, kein Archiv-Status. Damit gehört das Repository zu den meistbeachteten PowerShell-Projekten überhaupt. Der Haupttext des README bleibt bei diesen vier Feldern bewusst knapp; was die Tweaks im Einzelnen anfassen, zeigt das README nicht selbst, sondern verweist auf die Preset-Datei im Repository und die externe Dokumentation.

irm https://christitus.com/win | iex als Administrator ausführen

Der Schnellstart ist ein Einzeiler, der an den Zwei-Editor-Stil von PowerShell erinnert: irm https://christitus.com/win | iex. irm steht für Invoke-RestMethod und lädt das Skript, iex führt es aus. Für den Entwicklungszweig lautet die Adresse christitus.com/windev. Das README verankert eine harte Voraussetzung: winutil muss als Administrator laufen, weil es systemweite Änderungen vornimmt. Dafür beschreibt es zwei Wege in eine Admin-Shell, Rechtsklick auf Start mit Windows PowerShell (Admin) beziehungsweise Terminal (Admin), oder die Suche nach PowerShell gefolgt von Strg+Umschalt+Enter.

Dieser Weg ist schnell, hat aber einen Preis, den man beim Namen nennen sollte: Code von einer fremden Domain wird ohne Cache und ohne Prüfung direkt in eine privilegierte Shell injiziert. Das README hält keine Prüfsumme und keinen Signature-Schritt dagegen. Wer das regelmäßig macht, lädt sich bei jedem Lauf den aktuellen Stand; wer das unangenehm findet, schaut sich den Quellcode im Repository an oder setzt die Preset-Automation erst nach eigener Durchsicht ein.

Presets Standard, Minimal und Advanced über den -Preset-Parameter

Für Abläufe ohne Klickmenü bietet winutil vordefinierte Konfigurationen. Das README zeigt den Aufruf in voller Länge: & ([ScriptBlock]::Create((irm https://christitus.com/win))) -Preset Standard. Das Konstrukt lädt das Skript, verwandelt es in einen ScriptBlock und übergibt dem Ergebnis den Parameter -Preset. Drei Stufen sind dokumentiert. Standard steht für ausgewogene Vorgaben für die meisten Nutzer, Minimal für möglichst kleine Eingriffe, die jeden Rechner vertragen sollen, Advanced für tiefe Eingriffe Richtung Power-User.

Diese Stufung ist die eigentliche Nutzentscheidung: Minimal verändert wenig genug, um es auf einem produktiven Rechner zu riskieren, Standard ist der Mittelweg, Advanced gehört auf Maschinen, die man neu aufsetzt und ohnehin kontrolliert. Das README selbst bewertet die Stufen nicht weiter, es überlässt die konkreten Wirkungen der Preset-Datei und damit dem Leser.

config/preset.json: nachlesen, was der Preset anfasst

Das README verlinkt für die Detailfrage die Datei preset.json im config-Ordner des Repositories, also config/preset.json auf dem main-Zweig. Diese Aufteilung ist ungewöhnlich ehrlich: Statt Marketingzeilen über Debloat-Effekte gibt es eine maschinenlesbare Datei, in der sich pro Preset ablesen lässt, welche Konfigurationspunkte gesetzt werden. Für Automatisierer ist das die relevante Anlaufstelle, denn dort kann man vor dem Lauf prüfen, ob etwa Telemetrie-Schalter, Update-Einstellungen oder App-Entfernungen in dem gewählten Preset enthalten sind.

Build- und Entwicklungsdetails liegen dagegen ausgelagert. Das README verweist für alles rund ums Bauen auf .github/CONTRIBUTING.md und wiederholt die Inhalte nicht. Wer winutil verändern oder selbst kompilieren will, liest diese Datei; wer nur nutzen will, braucht sie nicht.

Kalender-Releases 26.08.19, 26.08.04 und der windev-Zweig

Die Versionierung folgt einem Kalendermuster mit zweistelliger Jahreszahl: Die letzten drei Releases heißen 26.08.19, 26.08.04 und 26.07.28. Die Abstände zeigen ein kurzes Inkrement, gut zwei Wochen zwischen den letzten beiden Einträgen. Für Anwender bedeutet das Format eine schnell lesbare Frischekontrolle, es sagt aber nichts über die Größe der Änderung aus, weil Tag-Releases je nach Bedarf klein oder groß ausfallen können.

Der Entwicklungszweig ist separat erreichbar über christitus.com/windev, was experimentierfreudigen Nutzern einen Vorabzug erlaubt, ohne das Repository klonen zu müssen. Die Umkehrung davon ist: Wer Stabilität sucht, bleibt bei der stabilen Adresse und liest die Release-Notes zum jeweiligen Tag. Beide Adressen setzen, wie oben beschrieben, eine Admin-Shell voraus, der Unterschied liegt nur im Stand des geladenen Codes.

Known Issues, YouTube-Tutorial und die Dotnet-Variante im CTT Store

Das Support-Umfeld ist für ein README dieser Länge ungewöhnlich gut sortiert. Es listet die offizielle Dokumentation unter winutil.christitus.com, ein YouTube-Tutorial, einen Artikel auf christitus.com/windows-tool, eine eigene Seite für bekannte Probleme unter winutil.christitus.com/knownissues und den Issue-Tracker auf GitHub. Diese Seite für bekannte Probleme ist praktisch relevant, weil bei einem Werkzeug, das in privilegierte Systembereiche eingreift, bekannte Nebeneffekte vor dem Lauf gelesen werden sollten.

Zwei Wirtschaftsdetails runden das Bild ab. Unter den Sponsoren nennt das README monatliche Unterstützer, und im Support-Abschnitt bewirbt der Autor eine schnellere Dotnet-Implementierung als kostenpflichtiges Produkt im CTT Store unter cttstore.com/windows-toolbox. Das Open-Source-Skript bleibt frei, die kompilierte Variante ist ein separates Kaufprodukt. Die Lizenz ist MIT mit üblichem Haftungsausschluss; Aussagen zu Garantien, Support-Leveln oder Produktionsreife macht weder das README noch der Lizenztext.

Redaktionelles Fazit

winutil passt für Nutzer, die nach einer Windows-Neuinstallation schnell Programmgruppen installieren, vorinstallierte Apps entfernen und Update-Verhalten setzen wollen, ohne jedes Tool einzeln zu suchen. Es eignet sich weniger für Firmenumgebungen mit Change-Freigaben, denn das Skript greift systemweit ein und lädt seinen Code zur Laufzeit aus dem Netz. Vor dem Einsatz sollte man in config/preset.json nachlesen, welche Punkte der gewählte Preset verändert, und mit dem Minimal-Preset beginnen, bevor man Advanced auf einem Rechner ausprobiert, auf dem man arbeiten muss.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes