ADMIN

2020

12

2020-11-29T12:00:00

Applikationsmanagement

SCHWERPUNKT

063

Applikationsmangement

Windows-Image

Windows-Images anpassen

Ganz nach Geschmack

von Mark Heitbrink

Veröffentlicht in Ausgabe 12/2020 - SCHWERPUNKT

Das Verteilen von angepassten Windows-Installationen auf neue Rechner bietet viele Vorteile. So ist das Betriebssystem schon beim Rollout auf dem neuesten Patch-Stand und verfügt zudem über die passenden Treiber. Andererseits lassen sich unerwünschte Apps und Funktionen von vornherein bändigen. In diesem Workshop zeigen wir drei Wege auf, um ein Windows-Image zu manipulieren: die PowerShell, das etablierte Tool NTLite und den Newcomer WIMWitch.

Ein bekanntes Tool zum Anpassen von Windows-Images ist nLite [1]. Es wurde mit Windows 2000 veröffentlicht und hat den Namen unter Vista zu vLite gewechselt. Ab Windows 7 aufwärts heißt es NTLite. Die Gemeinsamkeit der Varianten des Tools liegt darin, dass Administratoren die Installationsquelle des Betriebssystems schon vor dem Setup den eigenen Bedürfnissen anpassen und eine Antwortdatei generieren können, damit die Installation ohne weiteren Zugriff durchlaufen kann.
Mit Windows Vista hat Microsoft die Art der Installation grundlegend verändert: War sie bis Windows XP und 2003 noch dateibasiert, hat Microsoft mit Vista mit dem WIM-File ein Festplatten-Image eingeführt. Die "set­up.exe" des Installationsmediums funktioniert dabei wie ein Acronis- oder Ghost-Festplattenabbild. Microsoft hat hierfür eine virtuelle Maschine mit Sys-prep behandelt, heruntergefahren und den Zustand der Festplatte in ein Image-File geschrieben. Das Microsoft Deployment Toolkit (MDT) kann den Prozess der Installation, des Sysprep und des Speicherns mittels Skripten ebenfalls leisten, der Vorgang heißt "Sysprep and Capture". Zum MDT gab es im IT-Administrator Februar und März 2020 [2] eine Artikelserie.
Jedes der genannten Werkzeuge bedient sich der Schnittstellen, die Microsoft mit dem OS ausliefert. Das WIM kann und darf vor der Installation offline geändert werden. Der Begriff "offline" ist der Hinweis auf ein nicht aktuell laufendes System. Auf der Installations-CD finden Sie unter ".\sources" die Datei "install.wim". Das ist das Windows-Image, das das zu installierende Betriebssystem enthält. Dieses dürfen Sie gegen ein angepasstes WIM austauschen, was ein offiziell unterstützter Prozess [3] ist. Der spannende Punkt beginnt bei der Frage: Wie können Sie das WIM-File editieren und was ist alles möglich?
Ein bekanntes Tool zum Anpassen von Windows-Images ist nLite [1]. Es wurde mit Windows 2000 veröffentlicht und hat den Namen unter Vista zu vLite gewechselt. Ab Windows 7 aufwärts heißt es NTLite. Die Gemeinsamkeit der Varianten des Tools liegt darin, dass Administratoren die Installationsquelle des Betriebssystems schon vor dem Setup den eigenen Bedürfnissen anpassen und eine Antwortdatei generieren können, damit die Installation ohne weiteren Zugriff durchlaufen kann.
Mit Windows Vista hat Microsoft die Art der Installation grundlegend verändert: War sie bis Windows XP und 2003 noch dateibasiert, hat Microsoft mit Vista mit dem WIM-File ein Festplatten-Image eingeführt. Die "set­up.exe" des Installationsmediums funktioniert dabei wie ein Acronis- oder Ghost-Festplattenabbild. Microsoft hat hierfür eine virtuelle Maschine mit Sys-prep behandelt, heruntergefahren und den Zustand der Festplatte in ein Image-File geschrieben. Das Microsoft Deployment Toolkit (MDT) kann den Prozess der Installation, des Sysprep und des Speicherns mittels Skripten ebenfalls leisten, der Vorgang heißt "Sysprep and Capture". Zum MDT gab es im IT-Administrator Februar und März 2020 [2] eine Artikelserie.
Jedes der genannten Werkzeuge bedient sich der Schnittstellen, die Microsoft mit dem OS ausliefert. Das WIM kann und darf vor der Installation offline geändert werden. Der Begriff "offline" ist der Hinweis auf ein nicht aktuell laufendes System. Auf der Installations-CD finden Sie unter ".\sources" die Datei "install.wim". Das ist das Windows-Image, das das zu installierende Betriebssystem enthält. Dieses dürfen Sie gegen ein angepasstes WIM austauschen, was ein offiziell unterstützter Prozess [3] ist. Der spannende Punkt beginnt bei der Frage: Wie können Sie das WIM-File editieren und was ist alles möglich?
Windows-Image editieren
Microsoft liefert zwei Möglichkeiten für das Editieren des WIM: Die Kommandozeile und dort das "Schweizer Taschenmesser" DISM (Deployment Image Servicing and Management). DISM wurde mittlerweile in PowerShell-Cmdlets übersetzt – wie so oft bei der PowerShell leider nicht vollständig. So fehlen für bestimmte DISM-Funktionen die PowerShell-Entsprechungen. Da DISM das ältere und damit bekanntere Tool ist, finden Sie hierzu im Netz wesentlich mehr Hilfen, Beispiele und komplette Anleitungen als für die PowerShell. Des Weiteren ist DISM nur ein Befehl mit vielen Möglichkeiten, wohingegen das Pendant PowerShell aus vielen einzelnen Cmdlets besteht.
Die Kommandosyntax erhalten Sie mit dism.exe /?. Das Cmdlet Get-Command -Module dism liefert Ihnen derweil für die PowerShell die entsprechende Liste. Eine komplette Betrachtung der Werkzeuge sprengt den Rahmen unseres Artikels, wir schauen auf die vier vielleicht meistgewünschten Änderungsanforderungen an eine Windows-10-Installation. Die PowerShell ist inzwischen die präferierte Skriptsprache unter Admins und wir versuchen deshalb, ohne Legacy-Verfahren auszukommen. Die Pfade in den Listings sind beispielhaft und müssen entsprechend angepasst werden. Das Erstellen der Pfade ist ebenfalls nicht Bestandteil der folgenden Beispiele. Die vier meistgeforderten Anpassungen bei Windows-Images sind:
1. Updates: Installation mit aktuellem Patchlevel.
2. Treiber: Installation auf unterschiedlicher Hardware.
3. Windows-Apps entfernen.
4. Windows-Feature hinzufügen oder entfernen.
Das Deaktivieren diverser Windows-Dienste oder bestimmte Registry-Hacks integrieren sind zwei weitere Punkte auf der Liste.
Passendes Image herunterladen
Zunächst benötigen Sie eine Windows-10-Installations-CD aus einer validen Quelle [4] und kopieren den Inhalt auf Ihre Festplatte. Würden Sie versuchen, die Datei aus dem ISO-Image direkt zu bearbeiten, scheitern Sie an den fehlenden Schreibrechten, denn das Image ist nur lesend verfügbar. Am einfachsten gelingt der Download aus dem Volumen-Lizenz-Portal (Volume Licensing Service Center, VLSC). Das MediaCreation-Toolkit liefert derweil eine ISO-Datei, in der ein ESD-File enthalten ist. Dies spart zwar Volumen, der Nachteil ist allerdings, dass diese nicht direkt editierbar ist.
Die ESD-Datei müssen Sie zuerst in ein WIM konvertieren, wohingegen das VLSC von Microsoft direkt ein Install-WIM in ihren ISO-Dateien ausliefert. Der Hintergrund ist, dass Enterprise-Kunden mit dem MDT, dem SCCM (System Center Configuration Manager) oder ähnlichen Werkzeugen arbeiten, die nur WIM-Dateien verteilen können, keine ESD. Die "setup.exe" auf der CD wiederum unterstützt ESD, diese kommt bei MDT und SCCM aber nicht zum Einsatz. MDT und SCCM nutzen ein Windows-PE und schreiben das Image mit Bordmitteln auf die Festplatte.
Nun mounten Sie das Offline-Image, um es zu editieren. Es lässt sich immer nur eine Edition des Images (Stock Keeping Unit, SKU) laden. Sie benötigen daher den Index der enthaltenen Betriebssysteme. Die Installationsdatei enthält nämlich mehr als eine SKU. So besteht etwa die Wahl zwischen der Enterprise- und der Professional-Version. Der Administrator benötigt zur Installation den passenden Produkt-Key zur SKU. Bei einem WIM können Sie die gemountete Version über den Index definieren. Im Fall der ESD-Datei exportieren Sie diese zuerst in ein WIM-File, aus dem Sie dann das Image laden. Der Export einer ESD-Datei erfolgt immer nur für eine Edition. Den Index lesen Sie mit folgendem Befehl aus:
Get-WindowsImage -ImagePath C:\Image\install.wim
In unserem Beispiel hat Windows 10 Professional den Index 5 in der WIM-Datei. Um eine ESD-Datei zu konvertieren, verwenden Sie
Export-WindowsImage -SourceImagePath e:\sources\install.esd -SourceIndex 5 -DestinationImagePath C:\Image\install.wim -DestinationName "Windows 10 Pro" -CheckIntegrity -CompressionType max
Nun mounten Sie die WIM-Datei:
Mount-WindowsImage -ImagePath C:\Image\install.wim -Index 5 -Path C:\Mount
Bild 1: Um Treiber in Ihr Windows-Image zu integrieren, können Sie diese per PowerShell von einem bestehenden System exportieren.
Updates integrieren
Für Windows 10 können wir die Updates als einzelne Pakete aus dem Microsoft Update Catalog [5] herunterladen. Die Liste fehlender Updates müssen Sie jedoch selbst erstellen. Wer einen laufenden Rechner hat, kann sich hier den Updateverlauf anzeigen lassen. Dem Rechner entnehmen Sie die KB-Artikel, die über die Suche des Catalogs zu finden sind. Ohne Rechner, auf dem Sie nachsehen können, hilft der Suchbegriff "kumulatives update" auf der Catalog-Seite von Microsoft. Es erscheinen die monatlichen Vollupdates für das Betriebssystem und das .NET-Framework. Die notwendigen MSU-Dateien speichern Sie in einem Ordner, auf den Sie anschließend in der PowerShell verweisen:
Add-WindowsPackage -Path C:\Mount -PackagePath C:\Image\Updates
Treiber einspielen
Die Treiber müssen entpackt vorliegen, sodass Zugriff auf die INF-Datei besteht, oder alternativ als CAB-Datei. Entweder erhalten Sie die Treiber durch den Hersteller als Download oder Sie verwenden einen schon installierten Rechner und lesen von diesem die Treiber aus. Die Hersteller fertiger Computersysteme liefern meist eine vorgefertigte OS-Installation aus, die bereits alle notwendigen Treiber enthält, die der Rechner benötigt. Oft stellen die OEM-Hersteller auch ein Tool bereit, um die Systeme auf aktuellen Stand zu halten. Der Export-Befehl in der PowerShell ist zum Glück intelligent genug, um nur die Drittanbieter-Treiber zu exportieren, die zusätzlich ins System integriert wurden. Der Export der Treiber von einem laufenden System gelingt mit
Export-WindowsDriver -Online -Destination C:\Drivers
Nun fügen Sie die Treiber dem WIM hinzu. Durch die Option "-Recurse" werden alle Treiber integriert, die in dem Verzeichnis liegen:
Add-WindowsDriver -Path C:\Mount -Driver C:\Drivers -Recurse
Windows-Apps entfernen
Windows 10 kommt mit zahlreichen vorinstallierten und meist nicht notwendigen Apps daher. Um diese auszusortieren, lesen Sie zunächst die Liste der vorhandenen Apps aus. Anschließend entfernen Sie die provisionierten Apps, sodass sie bei einer Anmeldung am System nicht mehr bereitgestellt werden. An dieser Stelle empfehlen wir, den Store im System zu erhalten. Es gibt immer wieder Fälle, in denen eine bestimmte Anwendung nur noch als App zur Verfügung steht. Haben Sie den Store entfernt, gibt es keine einfache Möglichkeit mehr, eine fehlende App in das System zu integrieren, sofern der Hersteller die Quellen nicht als Download bereitstellt.
"Lenovo Vantage" mag hier als Beispiel gelten: Das Update-Tool von Lenovo ist mittlerweile eine App, die aus dem Store zu beziehen ist, auch wenn Lenovo im Moment noch einen vollständigen Download des Werkzeugs ermöglicht. Wer keinen Store verwenden möchte, greift besser zu Softwareeinschränkungen in Form von Gruppenrichtlinien zurück. Der Store bleibt damit im System, darf aber nicht verwendet werden und lässt sich über die Steuerung der Richtlinien kontrollieren [6]. Eine Liste der Apps erhalten Sie mit
(Get-AppProvisionedPackage -Path C:\Mount).Packagename
Eine App entfernen Sie beispielsweise mit
Remove-AppxProvisionedPackage -Path C:\Mount -PackageName Microsoft.BingWeather_4.25.20211.0_neutral_~_8wekyb3d8bbwe
Dieser Befehl erfolgt pro App, die nicht mehr in der Installation vorhanden sein soll. Die "PackageNames" sind versioniert, sodass es hier im Skript etwas Optimierungsbedarf gibt. Jeder neue Build von Windows 10 erfordert an dieser Stelle des Skripts Anpassungen. Wir wechseln deshalb vom PackageName auf den Displayname, da dieser unversioniert ist und von Build zu Build erhalten bleibt. In den Versionen 1809 bis 2004 hat sich die Liste der in der ISO-Datei enthaltenen Apps nicht mehr verändert, erst mit 20H2 kommt Edge auf Chromium-Basis hinzu
(Get-AppProvisionedPackage -Path C:\Mount).Displayname
Get-AppProvisionedPackage -Path C:\Mount | where {$_.Displayname -eq "Microsoft.WindowsMaps"} | Remove-AppxProvisionedPackage -path C:\Mount
Bild 2: NTLite ist ein etabliertes und leistungsfähiges Werkzeug für das Anpassen von Windows-Setups.
Windows-Features anpassen
Wie gehabt, erstellen Sie auch in dem Fall zuerst die Liste und passen diese nach Ihren Wünschen an. In unserem Beispiel entfernen wir den Internet Explorer und fügen das .NET-Framework 3.5 hinzu, da es von vielen älteren Produkten explizit angefordert wird. Die Ressource für .NET liegt auf der CD unter ".\Sources\sxs" und ist Build-spezifisch. Sie passt nur zu der "Install.wim", auf der sie bereitgestellt ist. Die .NET-Dateien kopieren Sie nun auf Ihren Rechner. Eine Liste der Windows-Features erhalten Sie anschließend mit
Get-WindowsOptionalFeature -Path C:\Mount | ft FeatureName,State
Nun entfernen wir den Internet Explorer und fügen im zweiten Befehl das .NET-Framework 3 hinzu. Beachten Sie bei Letzterem den lokalen Pfad zu den .NET-Dateien:
Disable-WindowsOptionalFeature -Path C:\Mount -FeatureName Internet-Explorer-Optional-amd64
 
Enable-WindowsOptionalFeature -Path C:\Mount -FeatureName NetFx3 -All -LimitAccess -Source C:\Image\sxs\
Im Ordner "C:\Mount", in den wir das Image geladen haben, sehen Sie die normalen Pfade, wie auch vom Laufwerk C: bekannt, wenn das System neu installiert wurde. Wir haben an dieser Stelle Zugriff auf das Dateisystem, als ob der Rechner laufen würde. Es lassen sich weitere Anpassungen vornehmen: Sie können Dateien in das System kopieren oder entfernen, ebenso laden und editieren Sie bei Bedarf die Registry.
Dienste über die Registry konfigurieren
Auf unserer Aufgabenliste für diesen Workshop stehen Windows-Dienste und die Registry. Das gewohnte Dienste-MMC-Snap-in einer laufenden Maschine steht offline nicht zur Verfügung. Der Weg führt über die Registry. Für die Dienste laden Sie den "HKLM\System"-Hive des Offlinesystems. Für Software ist es eine andere Datei und für Anpassungen am Benutzerprofil wieder eine andere. Die Speicherpfade der Registry lauten:
- C:\Users\Default\ntuser.dat: Eine Kopie der Datei wird zum HKCU eines neuen Benutzerprofiles.
- C:\Windows\System32\config\SYSTEM: der "HKLM\System"-Zweig.
- C:\Windows\System32\config\SOFTWARE: der "HKLM\Software"-Zweig.
Die PowerShell bietet kein natives Werkzeug, um Offline-Registry-Zweige zu laden. Hierfür bleibt es bei dem altbekannten "REG LOAD"-Befehl:
reg load HKU\OFF-USER C:\Mount\Users\Default\ntuser.dat
 
reg load HKLM\OFF-SYS C:\Mount\Windows\System32\config\SYSTEM
 
reg load HKLM\OFF-SOFT C:\Mount\Windows\System32\config\SOFTWARE
Das DWord des "Start"-Eintrages eines Dienstes lässt sich nun verändern: 0 = Bootzeitpunkt, 1 = Systemstart, 2 = Automatisch, 3 = Manuel, 4 = Deaktiviert. Ein Beispiel für das Abschalten der Windows-Telemetrie lautet dementsprechend:
reg add " HKLM\OFF-SYS\ControlSet001\Services\DiagTrack " /v "Start" /t REG_DWORD /d 4 /f
Mit dem nachfolgenden Befehl zeigen Sie für alle Benutzer die Dateiendungen an:
reg add "HKCU\OFF-USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v HideFileExt /t REG_DWORD /d 0 /f
Nachdem alle Dienste konfiguriert und alle zusätzlich gewünschten Registry-Werte gesetzt sind, muss der geladene Registry-Teil wieder "entladen" werden:
reg unload HKU\OFF-USER
 
reg unload HKLM\OFF-SYS
 
reg unload HKLM\OFF-SOFT
Sind alle Änderungen abgeschlossen, können Sie auch das Image entladen und die Anpassungen in die Datei "Install.wim" schreiben:
Dismount-WindowsImage -Path C:\Mount -Save
Nun legen Sie das Image in der ISO-Struktur unter ".\Sources" ab und ersetzen die vorhandene "install.wim".
Bild 3: Keine allzugroße Hilfe ist WIMWitch, das wie auch die PowerShell viel Handarbeit verlangt.
Antwortdatei für unbeaufsichtigte Installation
Zu diesem Zeitpunkt haben wir eine Installationsquelle, die über die Microsoft-eigene "setup.exe" unser selbsterstelltes Image installiert. Allerdings erfolgt die Installation immer noch Assistenten-basiert. Soll die Installation "unattended" erfolgen, also ohne Benutzereingriff, fehlt noch eine Antwortdatei. Es handelt sich um ein XML-File, in dem die wichtigsten Antworten auf Fragen gegeben werden, die während der Installation auftauchen.
Diese XML-Datei möchte vermutlich kein Admin bei null beginnend mit dem Notepad erzeugen. Hierfür würden wir das Windows-ADK herunterladen und sie mit dem WSIM (Windows System Image Manager) bauen [7]. Die Zeit können wir uns jedoch sparen, indem wir auf Ressourcen im Internet zurückgreifen. Dort gibt es den "Windows Answer File Generator Inspired by Windows System Image Manager" [8]. Diese Webschnittstelle erzeugt die nötige XML-Datei zum Download. Diese legen Sie als "Autounattend.xml" im Root der CD ab, also im gleichen Verzeichnis wie "setup.exe". Das Setup-File prüft beim Start, ob es eine Datei mit genau diesem Namen gibt, und wenn ja, wird diese verwendet.
Der Ordner "C:\Image", in dem die Ressourcen liegen, lässt sich jetzt auf einen bootfähigen USB-Stick übertragen. Der leichteste Weg besteht darin, den Stick mit Rufus [9] aus der originalen ISO-Datei zu erzeugen. Anschließend ersetzen Sie die "install.wim" auf dem Stick und kopieren die Antwortdatei in das Root-Verzeichnis.
Wer eine ISO-Datei benötigt, steht grundsätzlich vor mehreren Herausforderungen. Die erste liegt sicherlich in der Dateigröße. Das eigene "Install.wim"-Image sprengt sehr schnell die 5-GByte-Grenze. Praktisch in dem Moment, wo Sie Patches integrieren, ist das Dateivolumen für eine DVD zu groß. Spätestens zusätzliche Treiber sorgen für die Überschreitung der Größenlimitierung. 1 GByte pro Treiberpaket ist keine Seltenheit, da Grafikkarten heutzutage gerne schon 400 MByte und mehr benötigen. Blue-Rays können im Gegensatz zu DVDs mit der Größe umgehen, aber die wenigsten Systeme, die kein USB-Boot unterstützen, haben ein Blue-Ray-Laufwerk an Bord, sondern wenn dann nur ein CD/DVD-Laufwerk.
Wir benötigen für das abschließende Erstellen einer ISO-Datei das Windows-ADK. Darin enthalten ist die Datei "oscdimg.exe" (Operating System CD Image.exe). Starten Sie diese mit folgenden Parametern:
"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\ Oscdimg\oscdimg.exe" -b c:\Image\efi\microsoft\boot\ efisys.bin -pEF -u1 -udfver102 c:\image c:\Drivers\Windows10Pro.iso
Einfacher dank Tools
Der Weg über die PowerShell hin zu angepassten Installations-Images ist müßig. Das Praktische daran ist zumindest, dass sich die Schritte dank Skripten automatisieren lassen. Doch selbst Firmen, die ein Interesse an der Nutzung von Skripten haben, dürften selten zu dieser Variante greifen. Sie verwenden ein Werkzeug, das von vornherein massen-installationstauglich ist. Selbst für den ambitionierten Heimanwender ist diese beschriebene Art der Image-Manipulation ein Overkill.
Unsere dargestellte Lösung umfasst nur die Kernthemen und wirklich ansehnlich ist sie nicht. Vor allen Dingen ist sie nicht so leicht dynamisch erweiterbar, wenn sich Bedingungen ändern. Speziell bei den Apps und den Windows-Features muss umständlich nach den Namen gesucht werden. Dienste, Registry-Keys et cetera bedürfen mühsamer Kleinarbeit und weiterer Werkzeuge. Die Aufgabe, ein Installations-Image nur mit Bordmitteln zu bauen, fühlt sich denn auch eher nach einer Aufgabe für den Lehrling an. Es erklärt viel und beleuchtet die Hintergründe des Systems. Zu Schulungszwecken ist das sehr gut geeignet, aber produktiv arbeiten lässt sich damit nicht. Zum Glück gibt es wesentlich effektivere Mittel, sogar kostenfrei.
NTLite genießt in diesem Markt den Vorteil der Bekanntheit und ist ein etabliertes Werkzeug, jedoch mittlerweile nicht mehr kostenlos. Es trumpft mit einer übersichtlichen Oberfläche auf, wie es sich für ein modernes Windows-Programm gehört. Die "install.wim" und die gewünschte SKU mounten Sie direkt per Doppelklick. Die Menüleiste erklärt sich von alleine und die Auswahlpunkte haben sprechende Namen. Die enthaltenen Dienste, Apps und Windows-Features finden Sie übersichtlich aufgelistet vor. Auch der Gerätemanager ist sichtbar und zeigt die in der Windows-10-ISO fehlenden Treiber, die dann wie beim PowerShell-Beispiel hinzugefügt werden, indem Sie den Pfad zum Treiberverzeichnis angeben. NTLite kann anschließend das Image schreiben und auch eine ISO-Datei erstellen.
Das Programm ist ausgereift und bedarf kaum einer lange Erklärung und Einführung, sofern der Prozess generell verstanden wurde. Die Bedienbarkeit mit ihrer Übersichtlichkeit und Bequemlichkeit kostet zu Recht Geld. Die Frage, die es zu beantworten gilt, lautet: Ab welcher Rechneranzahl sollte ein Deployment-Tool zum Einsatz kommen, das die Manipulationen nicht im Image vornimmt, sondern zur Laufzeit der Installation, um Flexibilität abzubilden? Auch eine Kombination der Werkzeuge ist denkbar, wenn es beispielsweise um Updates geht. Einige Tools bieten hier keine Offline-Integration über ihre Oberfläche und die Treiberintegration im Image spart Installationszeit.
Als weiteren Kandidaten stellen wir WIMWitch [10] vor. Das PowerShell-basierte Projekt unterliegt zurzeit noch recht häufigen Updates. Es ist noch nicht so ausgereift wie NTLite. Die großen Vorteile: Es nutzt die vorhandene PowerShell mit dem DISM-Modul und ist keine proprietäre Entwicklung. Dadurch haben Sie Einblick in den Code. Der Nachteil: Es ist PowerShell. PowerShell und schöne Bedienoberflächen sind ein Widerspruch in sich.
Link-Codes
[8] Windows Answer File Generator: https://www.windowsafg.com/win10x86_x64_uefi.html/
Bild 4: Zu entfernende Apps lesen Sie per PowerShell aus und lassen sie über eine Gridview anzeigen.
Im Feature-Vergleich zu NTLite hinkt WIMWitch weit hinterher und hier erkennen Sie, warum ein Werkzeug wie NTLite keine Freeware sein kann – es steckt viel Arbeit drin. Prozessfortschritte beziehungsweise die Ausgaben der Aktionen, die Sie ausführen, erhalten Sie bei WIMWitch im PowerShell-Fenster angezeigt.
Leider offenbaren sich schon bei den ersten Gehversuchen Schwächen: WIMWitch kann Updates zwar selbstständig integrieren, aber nur dann, wenn es dafür einen internen WSUS- oder einen ConfigMgr-Server ansprechen kann. Das Anpassen von Dateiverknüpfungen (Öffnen mit) ist ebenso möglich wie das Ändern des Startmenülayouts. Doch erwarten sie hier keine Wunder, es handelt sich um den Import von XML-Dateien, die in Handarbeit erzeugt werden müssen. Das Erstellen der Dateizuordnungen funktioniert mit
Dism /Online /Export-DefaultAppAssociations:"AktuelleListe.xml"
Ein Startmenüvorschlag richten Sie mit dem folgenden Cmdlet ein:
Export-StartLayout .\Layout.xml
Beide XML-Dateien könnten in der beschriebenen händischen Manipulation zum Einsatz kommen, es gibt zu beiden Befehlen Importoptionen. Dafür lassen sich REG-Dateien, die an ein System exportiert wurden, direkt integrieren. Das spart den Aufwand des Ladens und Entladens der Registry-Hives. Damit Sie die Apps per Klick und UI auswählen können, muss vorher sichergestellt sein, dass auf dem Reiter "Source WIM" das importierte WIM File und die passende Edition ausgewählt sind. Andernfalls sehen Sie nur ein freies Textfeld und der "Select"-Button verweigert den Dienst. Die zu deinstallierenden Apps lesen Sie praktisch mit dem Get-AppProvisionedPackage-Cmdlet aus und erhalten diese über eine Gridview dargestellt. Aus dieser wählen Sie eine bestimmte oder alle Apps aus.
Für die Treiber geben Sie die Ressourcen-Ordner an, bis zu vier Pfade sind erlaubt. Auch Language Packs, Local Experience Packs und Features on Demand lassen sich integrieren. Doch der kurze Moment, in dem das Herz eines KMU-Administrators vor Glück schneller schlägt, ist rasch vorbei. WIMWitch entstand als Projekt aus dem ConfigMgr. Dieser kommt bei Enterprise-Kunden zum Einsatz und nur diesen Kunden bietet Microsoft die Quellen als DVD/ISO im Volumen-Lizenz-Portal zum Download an. Werkzeuge wie das RSAT (Remote Server Administration Tool) sind derweil ein Feature on Demand (FOD) seit Windows 10 1809. Das RSAT erhalten Sie über den Store. Das ist einer der Gründe, warum Sie den Store auf den Rechnern erhalten sollten. Dafür kann WIMWitch wiederum ISO-Dateien erzeugen, sofern Sie diese brauchen.
Fazit
Im Vergleich der drei Werkzeuge PowerShell, NTLite und WIMWitch ist NT­Lite unser Favorit. Das Tool ist selbsterklärend und die Benutzeroberfläche sehr gut gemacht. Zwischen WIMWitch und einer komplett manuellen Anpassung wiederum besteht kein großer Unterschied. Es gibt ein paar Kleinigkeiten, die automatisiert sind, aber am Ende bleibt immer noch Handarbeit und da mag ein eigenes Skript, in dem nur das drin ist, was der Admin selbst wirklich benötigt, dann doch die Nase vorn haben. Die Handhabung von WIMWitch und die am Ende doch geringe Funktionalität überzeugen hingegen für diesen Anwendungsfall nicht.
(dr)