Beim System Center Configuration Manager gibt es zwei Varianten, wie Windows-Installationen im Rahmen von Tasksequenzen mit Geräte-Treibern versorgt werden können:

• Ãœber den Tasksequenzschritt „Auto Apply Drivers“ wird auf dem Zielsystem die Hardware überprüft und die Plug-and-Play-IDs aller auf dem System vorhandenen Geräte ermittelt. Danach wird untersucht, für welche dieser Geräte kompatible Treiber im Repository bereitgestellt sind; dies erfolgt unabhängig davon, in welchem Treiberpaket sich diese befinden. Dabei lässt sich ggf. mit Kategorien einschränken, welche Treiber in Betracht gezogen werden, ebenso werden Treiber, die als „deaktiviert“ gekennzeichnet sind, nicht berücksichtigt. Dann wählt der SCCM-Client für jedes Gerät den geeignetsten der verfügbaren Treiber aus, lädt diesen herunter und installiert diesen auf dem Zielsystem.
• Ãœber den Tasksequenzschritt „Apply Driver Package“ hingegen werden alle Treiber, die im betreffenden Treiberpaket enthalten sind, heruntergeladen und dem Windows-Betriebssystem zur Verfügung gestellt.

Die erste Variante scheint auf Anhieb viel bequemer zu sein, muss doch der Administrator einfach alle Treiber in SCCM bereitstellen, die von irgendeinem Gerät benötigt werden, und das zu installierende System sucht sich dann die von ihm benötigten Treiber per Plug-and-Play selber zusammen. Bei der zweiten Variante hingegen muss der Administrator selber dafür besorgt sein, dass jeweils das passende Treiberpaket auf dem Zielsystem landet.

Doch die automatische Variante mit „Auto Apply Drivers“ hat auch ihre Tücken. So hatten wir letzte Woche in unserer Umgebung das Problem, dass bestimmte Gerätetypen nicht mehr installiert werden konnten: Nach dem Start der Tasksequenz wurde die Festplatte partitioniert und formatiert, das Image ausgepackt und die Treiber hinzugefügt. Dann startete das System neu, die Geräte wurden installiert und die System Settings wurden angewendet. Soweit, so gut. Doch nach dem anschliessenden Neustart wurden wir mit einem Bluescreen „STOP: 0x0000000A“ (IRQL_NOT_LESS_OR_EQUAL) beglückt.

Es deutete alles daraufhin, dass sich das betreffende System einen Treiber aus dem Repository ausgesucht hat, der diesem nicht gut bekommen ist. Denn nachdem wir den Tasksequenzschritt „Auto Apply Drivers“ für dieses Gerätemodell deaktiviert hatten, lief die Installation wieder problemlos durch.

Die Problematik liegt also hier darin, dass ein bestimmter Gerätetyp anfangs problemlos installiert werden kann, dann aber eines Tages jedoch eine Installation eines Gerätes desselben Typs scheitert, weil inzwischen dem Repository ein Treiber (für ein x-beliebiges anderes Gerät) hinzugefügt wurde, der jedoch für das betreffende Gerät problematisch ist. Wenn zwischen der letzten erfolgreichen Installation des Gerätes und dem ersten Crash zudem etliche Zeit verstrichen ist, währenddessen mehrere Administratoren zusammen unzählige weitere Treiber für weitere Geräte ins Repository geladen haben, dann wünsche ich viel Spass und Erfolg beim Suchen…

Von dem her dürfte die zweite Variante, gezielt einzelne Treiberpakete für bestimmte Gerätetypen zur Verfügung zu stellen, zwar aufwendiger aber unter dem Strich deutlich zuverlässiger sein, da hier detailliert kontrolliert werden kann,  welche Treiber ein bestimmtes Gerätemodell zu installieren hat. Ebenso werden hier ungeahnte Nebenwirkungen später hinzugefügter Treiber vermieden.