Wenn man in der DSM-Welt unterwegs ist – und ich nehme stark an, dass praktisch alle Leser dieses Blogs irgendwelche Berührungspunkte mit DSM haben – kommt man hin und wieder bestimmt in die Situation, dass man neue Hardware in die Umgebung einbinden muss. Das heißt, es müssen Treiber für das jeweilige Ziel-Betriebssystem paketiert werden, insbesondere für die Hardware-Komponten, für die Windows keine Treiber an Bord hat. Manchen Kunden möchten sogar, dass alle vom Hardware-Hersteller gelieferten Treiber paketiert und in DSM eingebunden werden.

Es gibt nun mehrere Möglichkeiten, wie man hier vorgehen kann. Und insbesondere seit Windows 8.1 und für die bevorstehenden Windows 10 Rollouts gibt es nun noch die Option, hier mit PowerShell aktiv zu werden, was mich im Endeffekt veranlasst hat, diesen Blog-Artikel zu schreiben...

Grundsätzlich bin ich ein großer Freund davon, die benötigten Treiber von einem bereits mit dem Ziel-Betriebssystem (vor-)installierten Client abzuziehen. Man kann dann davon ausgehen, alle Treiber zu "erwischen" und ist auf der sicheren Seite, dass es die passenden Treiber sind.

Um solche Treiber zu extrahieren, gibt es mehrere Möglichkeiten. Der naheliegendste und von mir in der Vergangenheit in den meisten Fällen auch praktizierte Ansatz besteht darin, die DSM Console auf einem solchen Rechner zu starten und dann über den Treiber-Paketierungs-Assistenten die Treiber für ein Gerät nach dem anderen abzuziehen.

Der Vorteil darin liegt unter anderem darin, dass nur diese eine Plug-And-Play ID, nämlich genau die des gewählten Devices, dem Treiberpaket zugeordnet ist und damit eine maximale "Passgenauigkeit" des Treiberpakets zu dem Gerät gewährleistet wird. Obwohl der Treiber eventuell auch für andere Geräte derselben Klasse passend und gültig ist, wurde das nicht getestet und soll daher auch nicht automatisch zugewiesen werden.

Ein Nachteil der Paketierung über die DSMC ist, dass man nicht direkt sieht, bei welchen Treibern es sich um 3rd Party Treiber handelt und welche von Microsoft stammen und mit dem Betriebssystem mitgeliefert werden. Dies lässt sich (auch ohne die Eigenschaften jedes Treibers im Gerätemanager zu öffnen und manuell zu kontrollieren) einfach mit einer Freeware lösen - dem "Driver Magician Lite". Dieser ist auch in einer Portable-Version verfügbar, sodass er ohne Installation direkt ausgeführt werden kann. Das Tool kann unter http://www.drivermagician.com/Lite.htm heruntergeladen werden.

Im Screenshot unten sieht man, welche Treiber von einem anderen Hersteller (Spalte "Provider") als Microsoft stammen. Außerdem ist die Schrift der Nicht-Microsoft Treiber rot, sodass auch hier direkt zu sehen ist, welche Treiber von Interesse sind.

Driver Magician bietet auch die Möglichkeit, alle markierten Treiber über die Schaltfläche "Start Backup" zu extrahieren und in einer Verzeichnisstruktur zu sichern. Diese könnte dann als Quelle für die Paketierung per DSM fungieren. Nachteil bei diesem Ansatz ist aber meines Erachtens, dass es einerseits nicht die definierte Zuordnung zwischen Treiber und der eindeutigen PnP-ID gibt. Des weiteren extrahiert Driver Magician die INF-Files mit ihrem OEM-Namen (beispielsweise "OEM55.INF"), was vielleicht nur ein Schönheitsfehler ist, bei einer eventuell späteren Aktualisierung des Treiber-Pakets aber die Identifizierung des Treibers erschwert. Und schließlich habe ich die Erfahrung gemacht, dass manchmal nicht alle Treiberfiles erfasst und exportiert werden, sodass die daraus erstellten Pakete fehlschlagen (während die über die DSMC abgezogenen Pakete für dieselben Geräte funktionierten).

Wie oben schon angesprochen, habe ich nun kürzlich noch eine mir bis dato unbekannte – und von Microsoft supportete – Möglichkeit gefunden, Treiber zu exportieren. Dabei gibt es sowohl die Option, die Treiber von einem laufenden System abzuziehen, als auch die Treiber aus einem gemounteten WIM-Image zu extrahieren.

Über das PowerShell-Cmdlet Export-WindowsDriver wird der Export gestartet. Wird der Schalter -Online angegeben, so werden alle OEM-Treiber in eine Verzeichnisstruktur unterhalb des im Parameter -Destination angegebenen Pfades exportiert.

Wird der Export einer PowerShell-Variablen zugewiesen, so lassen sich auch Details wie Hersteller, Treiber-Version und auch für welche Geräteklasse der Treiber gedacht ist, ausgeben:

Die so erstellte Verzeichnisstruktur kann dann als Grundlage für die Erstellung von Plug-And-Play Paketen in DSM dienen.

Am Ende noch ein kurzer Ausblick auf die kommende Version DSM 2015.2: Dort wird es möglich sein, mehrere PnP-Pakete in einem Schritt zur erzeugen, in dem die neue Option zur Erzeugung mehrerer Treiberpakete aus einer Treiberbibliothek genutzt wird. Dabei kann natürlich genau die auf die genannte Art und Weise erzeugte Bibliothek verwendet werden.