Nachdem wir in der letzten Zeit problemlos unzählige neue Geräte via SCCM installieren konnten, erreichte mich heute morgen der Hilferuf eines Kollegen: „Was gestern noch ging, wolle heute nimmer funktionieren…“ Er erhalte folgende Fehlermeldung, kurz nachdem die zu installierende Maschine das WindowsPE gestartet habe:
The certificate associated with this media has expired!
„Aber ich benutze doch gar kein Medium, sondern habe via PXE gebootet“, fügte dann der Kollege noch hinzu. So machte ich mich auf die Fehlersuche und warf zuerst mal einen Blick in den Site Status, wo sich der Component Status des „SMS_PXE_SERVICE_POINT“ tief rot zeigte:
Komponente "SMS_PXE_SERVICE_POINT" meldet Errors!
Ein Blick in die dazugehörenden Status Messages zeigte dann sofort, dass es offenbar ein Problem mit dem entsprechenden PXE-Zertifikat gibt:
The SMS PXE Certificate used for PXE clients is not valid. Please provide a valid certificate.
Ich schaute mir dann das entsprechende Zertifikat an und siehe da:
Der 30. November 2011 war gestern!
Die Ursache der Fehlermeldung war nun sonnenklar. Das bisherige Zertifikat war genau bis gestern abend um 22:30 Uhr gültig. Kein Wunder also, dass heute entsprechende Fehlermeldungen generiert werden. Aber wie erneuert man das PXE-Zertifikat? Mir schwante böses: seitenlange Technet-Artikel mit unzähligen vorzunehmenden Schritten, …
Doch nein: Nichts dergleichen war nötig. Ein kurzer Blick in die Eigenschaften des „ConfigMgr PXE service point“ zeigte mir den Ablaufzeitpunkt des Zertifikates von gestern abend:
Eigenschaften von "ConfigMgr PXE service Point"
„Da könnte man doch einfach mal probieren, ein neues Datum zu setzen…“, war mein erster Gedanke, was ich sogleich machte: Und siehe da:
Ein neues Zertifikat wurde erstellt!
Das bisherige Zertifikat wurde auf „blocked“ gesetzt, daneben wird nun ein neues Zertifikat aufgelistet. Und schon funktionieren auch die Installationen via PXE wieder… Hoffentlich weiss ich Anfangs 2012 noch, was zu tun ist, wenn dasselbe „Problem“ wieder auftaucht…
Abgelegt unter: Anleitungen | Tags: Driver, OSD, PowerShell, SCCM, TaskSequence
Damit nun das neue Treiberpaket gezielt nur auf bestimmte Systeme installiert werden kann, müssen wir noch herausfinden, wie die genauen Werte lauten, welche wir für die entsprechende Condition verwenden können. Dies lässt sich natürlich über den „Ressource Explorer“ in der SCCM-Konsole herausfinden, aber dank der Powershell geht das noch viel einfacher: Einfach auf dem betreffenden Gerät eine Powershell öffnen und das Kommando
get-WMIObject Win32_ComputerSystem
ausführen. Die Ausgabe umfasst dann etwa ein halbes Dutzend Zeilen, doch die beiden Werte für „Manufacturer“ und „Model“ interessieren uns besonders. Hier zwei Beispiele:
Manufacturer : Hewlett-Packard
Model : HP Compaq dc7800 Convertible Minitower
Manufacturer : IBM
Model : 1869CNG
Hier sehen wir also sehr gut, dass wir problemlos erkennen können, ob wir nun einen HP DC7800 Minitower oder ein älteres IBM-Notebook vor uns haben. Diese Information können wir nun für die Formulierung der Condition für die Installation des jeweiligen Treiberpaketes verwenden.
Somit können wir nun in der SCCM-Konsole die Tasksequenz erweitern, welche zur Installation des betreffenden Gerätes verwendet wird. Hier lohnt es sich, zuerst einen Ordner „Apply Drivers“ zu definieren, in welchem alle Tasksequenzschritte für die Installation von Treiberpaketen gesammelt werden können. In diesem Ordner können wir nun einen zusätzlichen Schritt vom Typ „Apply Driver Package“ hinzufügen; als dessen Name setzen wir jeweils die Kombination von „Manufacturer“ und „Model“, damit wir eine übersichtliche Liste der Tasksequenz-Schritte für die Installation von Treiberpaketen für die verschiedenen Gerätetypen erhalten.
Als „Driver Package“ wählen wir nun das neue Treiberpaket, das wir gemäss dem letzten Blogbeitrag erstellt haben. Unter „Options“ empfiehlt es sich, gleich mal das Häckchen bei „Continue on Error“ zu setzen, dann können wir eine sog. „WMI-Query“ hinzufügen, der dazu benötigte WMI-Namespace ist „root\cimv2“. Hierzu wieder zwei Beispiele:
SELECT * FROM Win32_ComputerSystem
WHERE Manufacturer = "Hewlett-Packard"
AND Model = "HP Compaq dc7800 Convertible Minitower"
SELECT * FROM Win32_ComputerSystem
WHERE Manufacturer = "IBM"
AND Model = "1869CNG"
Wie unschwer zu erkennen ist, sind in der Query genau die beiden Werte für Manufacturer und Model einzutragen, die der eingangs beschriebene Powershell-Befehl ausgegeben hat. Auf diese Weise wird bei der ersten Query das Treiberpaket nur auf dem HP DC7800 und beim zweiten Beispiel nur auf dem älteren IBM-Notebook installiert. Haben wir die Tasksequenz auf diese Weise ergänzt, kann nun damit das Gerät nochmals neu installiert werden; dabei sollte nun das neue Treiberpaket bei den passenden Geräten mitinstalliert werden.
Damit haben wir nun unser Ziel erreicht, gezielt einzelne Treiberpakete für bestimmte Gerätetypen zur Verfügung zu stellen. Wir können nun genau definieren, welche Treiber ein bestimmtes Gerätemodell zu installieren hat, und vermeiden somit unerwartete Nebeneffekte, die ein „Auto Apply Drivers“ auslösen kann.
Wer nun allerdings befürchtet, nun den neuen Tasksequenzschritt vom Typ „Apply Driver Package“ in unzähligen verschiedenen Tasksequenzen einpflegen zu müssen, liegt leider nicht ganz falsch. Ich habe auch noch keinen Weg gefunden, wie man dies komplett vermeiden kann. Immerhin hat jedoch kürzlich einer meiner Kollegen zufälligerweise entdeckt, dass man einzelne Tasksequenzschritte (bzw. ganze Ordner von Tasksequenzschritten) wunderbar per „Drag and Drop“ (mit gedrückter CTRL-Taste!) von einem Tasksequence-Editorfenster zum anderen kopieren kann. Somit entfällt wenigstens das mehrfache Erstellen desselben Tasksequenzschrittes in verschiedenen Tasksequenzen; einmal erstellen reicht, dann kann wenigstens kopiert werden. Diesen kleinen Tipp zum Schluss dieser dreiteiligen Reihe wollte ich Euch nicht vorenthalten.
Frohe Festtage
Euer Michael Hottinger
Abgelegt unter: Anleitungen | Tags: Driver, OSD, SCCM, TaskSequence
Am Rahmen des letzten Beitrages haben wir einen Ordner C:\Drivers zusammengestellt, der alle benötigten Treiber für das neue Gerät enthält, welche wir nun in SCCM importieren können.
Doch hier kann sich ein unerwartetes Problem in den Weg stellen: SCCM lässt es nicht zu, dass derselbe Treiber mehrfach importiert wird! Dies macht es auf Anhieb unmöglich, Treiberpakete zu erstellen, die alle Treiber für einen bestimmten Gerätetyp enthalten, wenn es mehrere Gerätetypen gibt, welche dieselben Treiber verwenden. Doch zum Glück gibt es hier eine einfache Abhilfe!
Es reicht nämlich aus, wenn man bei jedem Treiberordner eine zusätzliche Textdatei hinzufügt, die z.B. den Namen des Gerätetyps (z.B. HP DC7800) im Dateinamen (z.B „HP DC7800.txt“) enthält. Diese Datei könnte sogar leer sein, es spricht jedoch nichts dagegen, hier zusätzliche Informationen z.B. zur Quelle des Treibers und dessen Bereitstellung zu dokumentieren. Diese Textdatei sorgt dafür, dass beim Importieren des Gerätetreibers ein anderer Hashwert generiert wird, womit derselbe Treiber mehrfach importiert werden kann.
Ein weiteres Punkt, den es bei der Bereitstellung von Gerätetreibern zu beachten gilt, ist folgender: Der sog. „Source“-Ordner des Treiber-Paketes ist derjenige, von welchem aus SCCM die Treiber auf die Distribution Points verteilen wird und das ist somit nicht derjenige Ordner auf unserem neuen Gerät, der die gesammelten Treiber enthält: Der „Source“-Ordner für das Treiberpaket wird an der passenden Stelle auf dem Fileserver angelegt, z.B. unter „\\<server>\source$\Drivers\<Manufacturer>\<Model>“, die von uns gesammelten und mit Hilfe der zusätzlichen Textdatei individualisierten Gerätetreiber liegen jedoch noch auf dem neuen Gerät unter C:\Drivers.
Der Importvorgang läuft nun sehr problemlos ab:
- Wir navigieren in der SCCM-Konsole zu „Computer Management“, „Operating System Deployment“, „Drivers“
- Falls noch nicht bereits andere Geräte desselben Herstellers im Einsatz sind, legen wir dort einen neuen Ordner mit dem Namen des Herstellers an (z.B. „HP“).
- Darunter legen wir nun einen neuen Ordner mit dem Namen des Gerätemodelles an. (z.B. „DC7800“)
- Mit Rechtsklick auf den soeben angelegten Ordner, können wir nun den „Import“-Wizard starten.
- Nun müssen wir angeben, welche Gerätetreiber wir importieren wollen. Ist auch unser neues Gerätemodell bereits Mitglied in der AD-Domäne, können wir hier einfach den UNC-Pfad zum Treiberordner auf unserem neuen Gerät angeben, also irgendwas in der Form „\\<neuerPC>\c$\Drivers“. Da wir dort ja genau die benötigten Treiber zusammengestellt haben, können wir gleich in einem Rutsch alle Treiber importieren lassen, die sich an diesem Ort befinden.
- Im nächsten Dialog-Fenster „Driver Details“ können wir nochmals sehen, welche Treiber importiert werden; gleichzeitig lassen sich hier noch Kategorien vergeben. Hier halten wir üblicherweise fest, für welches Betriebssystem gerade Treiber importiert werden, wir vergeben hier z.B. die Kategorie „Win7 x86 EN“.
- Im nächsten Dialog-Fenster „Add Driver to Packages“ müssen wir nun angeben, in welchem Treiberpaket die Treiber gespeichert werden sollen. Auch hier erstellen wir ein neues Treiberpaket, das wir mit dem Präfix „DRIVERS“ kennzeichen, damit wir die Gerätetreiber-Pakete einfach in der Paketliste erkennen können. Wir taufen unser Paket somit z.B: „DRIVERS HP DC7800“. Hier müssen wir nun den passenden Source-Ordner auf dem Fileserver definieren, wo SCCM die importierten Treiber hinpacken soll, also z.B. etwas in der Form: \\<server>\source$\Drivers\<Manufacturer>\<Model>
- Im nächsten Schritt „Add Driver to Boot Images“ lassen sich nötigenfalls Treiber auch gleich in das Bootimage einpacken. Dies wäre genau dann nötig, wenn es sich z.B. um Netzwerk- oder Disktreiber handelt, die zwingend für die Betriebssysteminstallation und somit für den Ablauf der Tasksequenz notwendig sind.
- SCCM legt das neue Treiberpaket zuoberst in der Hierarchie der „Driver Packages“an, falls gewünscht, kann dieses anschliessend noch passend einsortiert werden. Nun sind noch die letzten Schritte des Wizards zu durchlaufen, dann werden die Treiber importiert.
- Sind die Treiber erfolgreich importiert und damit auch dass entsprechende Treiberpaket erstellt worden, muss dieses noch auf an die passenden Distribution Points verteilt werden; danach sind die Treiber zur Installation auf den Geräten bereit.
Auf diese Weise lässt sich nun für jedes Gerätemodell ein separates Treiberpaket anlegen, was wir normalerweise in einer schlanken Hierarchie „Hersteller -> Gerätemodell“ bewerkstelligen. Diese Treiberpakete enthalten nun alle benötigten Gerätetreiber für ein bestimmtes Gerätemodell ohne jegliche Abhängigkeiten von anderen Treiberpaketen. So kann dieses Paket auch eines Tages wieder problemlos gelöscht werden, wenn das letzte Exemplar dieses Gerätetyps auf den Schrott gewandert ist.
Nun muss einfach noch sichergestellt werden, dass die so erstellten Gerätetreiber-Pakete nur genau auf denjenigen Geräten installiert werden, für die diese bestimmt sind, doch dies wird das Thema des nächsten Beitrages sein.
Abgelegt unter: Anleitungen | Tags: Driver, OSD, SCCM, TaskSequence
Wie ich in meinem letzten Beitrag geschrieben habe, hat die Installation von Gerätetreibern via „Auto Apply Drivers“ seine Tücken, da irgendwelche unliebsamen Ãœberraschungen nicht ausgeschlossen sind. Wer auf Nummer sicher gehen will, der muss den Weg über „Apply Driver Package“ wählen.
Ich möchte deshalb mit einer Serie von drei Beiträgen aufzeigen, wie man vorgehen kann, um Gerätetreiber über den Tasksequenz-Schritt „Apply Driver Package“ bereitzustellen. Diese drei Beiträge werden folgende drei Schritte behandeln:
- Feststellen und Sammeln der benötigten Gerätetreiber,
- Bereitstellung der Gerätetreiber in SCCM in Form von Treiber-Paketen,
- Installation der Treiber-Pakete auf die Clients über den Tasksequenz-Schritt „Apply Driver Package“.
Wenn wir ein neues Gerätemodell in den von uns unterstützten Gerätepark aufnehmen wollen, dann versuchen wir zuerst einmal, dieses einfach zu installieren, indem wir unsere „altbewährte“ Tasksequenz auf dem neuen Gerät ausführen, was in den meisten Fällen recht problemlos klappt. Es muss jedoch damit gerechnet werden, dass allenfalls auch das WinPE unter Umständen zusätzliche Treiber benötigt, wenn z.B. die Hardware über sehr spezielle oder komplett neue, noch nicht vom Betriebssystem unterstützte Hardwarekomponenten verfügt; diesen Fall wollen wir in der aktuellen Betrachtung jedoch mal ausschliessen.
Es muss unbedingt darauf geachtet werden, dass in dieser Tasksequenz keinesfalls der Schritt „Auto Apply Drivers“ aktiviert ist, denn wir möchten ja nicht, dass sich das neu in die Gerätepalette aufzunehmende Gerät per Plug-and-Play mit bereits importierten Treibern bedient, sondern wir wollen feststellen, ob (und vor allem welche) Treiber neben den original von Microsoft mit dem Betriebssystem gelieferten Treibern zusätzlich benötigt werden.
Ist die Tasksequenz erstmals durchgelaufen, folgt nach dem Anmelden am System sogleich ein schüchtener Blick in den Geräte-Manager. Sind dort keine Fragezeichen zu sehen und es funktionieren bereits alle Geräte einwandfrei, sind wir schon fertig, da in diesem Fall keine zusätzlichen Treiber benötigt werden. Ansonsten geht die Suche nach zusätzlichen Treibern für die unbekannten Geräte los, zudem dürfte es durchaus gewünscht sein, allfällige Standard-Treiber (Stichwort „Standard-VGA-Grafikkarte“) durch spezialisierte, leistungsfähigere Treiber (Stichwort „Aero“) zu ersetzen.
Mein erster Schritt führt mich zumeist zu Windows Update, welches ich nach Updates suchen lasse. Aber Achtung: Ich lasse mir von Windows Update nur anzeigen, welche Treiber über Windows Update zur Verfügung stehen würden. Doch installieren lasse ich diese keinesfalls, schliesslich will ich diese nicht nur auf diesem Gerät installieren, sondern in einem Treiberpaket über SCCM bereitstellen.
Dafür bietet sich der Microsoft Update Katalog an. Nach der Installation des benötigten ActiveX-Steuerelementes kann im Katalog nach den entsprechenden Updates gesucht werden, welche von Windows Update angeboten werden. Diese können dann in Form einer Cab-Datei heruntergeladen werden, welche z.B. mit 7-zip entpackt werden kann.
Nun versuche ich als nächstes, den heruntergeladenen Treiber zu installieren. Dazu wähle ich die Variante mit manueller Suche resp. Installation des Treibers und weise dabei den Assistenten an, in dem soeben ausgepackten Treiberordner nach einem passenden Treiber zu suchen.
Hat die Installation des Treibers wunschgemäss geklappt, verschiebe ich den Ordner mit dem ausgepackten Treiber in einen Sammelordner (bei mir normalerweise C:\Drivers) für die nachfolgende Bereitstellung in SCCM. Schliesslich wissen wir ja inzwischen, dass dies der passende Treiber ist.
Wenn Microsoft nicht alle benötigten Treiber bereithält, geht die Suche auf der Herstellerseite weiter, bis alle benötigten und passenden Treiber beisammen sind. Dabei versuche ich immer, allfälligen Wartungsapplikationen der Hersteller aus dem Weg zu gehen und mir die benötigten Treiber manuell zu organisieren.
Auf diese Weise sammeln sich in C:\Drivers mit der Zeit alle benötigten Treiber, die wir dann in einem Rutsch bequem in SCCM importieren können. Aber das soll ja das Thema des nächsten Beitrages sein.
Abgelegt unter: Erkenntnisse | Tags: Driver, OSD, SCCM, TaskSequence
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.