Zugriff aus Powershell via WMI auf System Center Configuration Manager
Donnerstag, 9. September 2010, 09:19
Abgelegt unter: Anleitungen | Tags: , , ,

Während den letzten Tagen habe ich mich etwas intensiver mit der Powershell 2.0 befasst und ich habe mich gefragt, ob und wie ich bestimmte Daten mit Hilfe eines Powershell-Skriptes aus SCCM auslesen kann. So habe ich mir vorgenommen, ein Skript zu schreiben, das mir eine Liste aller vorhanden Clients ausgibt und dabei die Info aus SCCM mitliefert, welcher Benutzer letztmals an diesem Client angemeldet war und wann die letzte Kommunikation des Agent mit dem SCCM-Site Server erfolgte.

Konkret interessierte ich mich also für folgende drei Feldwerte aus den Eigenschaften eines Computerobjektes:

  • Name
  • Last Logon User Name
  • Agent Time (neuester Eintrag)

Der erste Teil des Skriptes war einfacher zu realisieren, als ich dies zuerst vermutete:

$query = New-Object System.Management.ObjectQuery
$query.QueryString = "Select * from SMS_R_System order by Name" $searcher = New-Object`
System.Management.ManagementObjectSearcher($query)
$searcher.Scope.Path = "\\<siteserver>\root\sms\site_<sitecode>"
$result=$searcher.Get()

Ich verwende also die ObjectQuery-Klasse aus dem .NET-Framework, setze die entsprechende Query (die natürlich die gewünschten Felder zielgerichteter auslesen könnte, als mit dem simplen „Select *“), und benutze dann die ManagementObjectSearcher-Klasse, um die Abfrage der gewünschten Informationen basierend auf der definierten Query durchzuführen. Hierzu muss natürlich noch definiert werden, wo genau die Daten gelesen werden sollen, wozu in der vierten Zeile <siteserver> durch den Namen des entsprechenden SCCM-Siteservers und <sitecode> durch den dazu passenden Sitecode zu ersetzen ist. Nun noch die Suche gestartet, und schon stehen die gewünschten Daten in $result.

Bis ich nun die Daten als passend formatierte Tabelle in der Powershell lesen konnte, musste ich deutlich länger suchen (und einem Kollegen auf den Wecker gehen). Schlussendlich führte folgende Codezeile – man beachte die unzähligen Backticks „`“ für die Fortsetzung der Zeile auf einer neuen Linie – zum Ziel:


$result | `
format-table `
@{label="Computername";`
expression={$_.Name.tolower()};`
width=16},`
@{label="Letzter Benutzer";`
expression={$_.LastLogonUserName};`
width=20},`
@{label="Letzte Agent-Kommunikation";`
expression={(([WMI] "").ConvertToDateTime(`
$($_.AgentTime | Sort-Object | Select-Object -Last 1)`
)).tostring("dd.MM.yyyy HH:mm:ss")};`
width=20}

Der Anfang dieser Zeile – ja es ist eine einzige Zeile! – ist nicht besonders schwierig zu verstehen. Der Inhalt von $result wird an den Befehl format-table übergeben, der dann die drei Datenfelder formatiert ausgibt, wobei die Definition eines Datenfeldes jeweils beim @ beginnt.

Bei den beiden ersten Spalten sind keine grossen Besonderheiten zu finden: Ich setze jeweils die gewünschte Spaltenüberschrift (label) und gebe mit dem jeweiligen Ausdruck (expression) den aktuellen ($_) Inhalt des jeweiligen Feldes aus, wobei ich noch die gewünschte Breite der Spalte (width) festlege. Beim Computernamen verwende ich zusätzlich noch die Funktion tolower(), da ich eine Liste mit Computernamen in Kleinbuchstaben lesbarer finde.

Die Expression für das Datum der letzten Kommunikation ist jedoch nicht mehr ganz so trivial; Ursache dafür ist die Tatsache, dass alle Zeitstempel im Format „yyyymmddHHMMSS.mmmmmmsUUU“ geliefert werden. Ich benutze deshalb die Funktion ConvertToDateTime, um daraus eine „brauchbare“ Zeit zu machen, die dann mit tostring("dd.MM.yyyy HH:mm:ss") in die gewünschte Darstellung umgewandelt wird.

Bleibt also noch die Zeile „$($_.AgentTime | Sort-Object | Select-Object -Last 1)“ zu erläutern: In SCCM ist AgentTime ein mehrwertiges Feld, d.h. es werden mehrere Zeitstempel gespeichert, wann ein Client mit dem Server gesprochen hat. Die gespeicherten Werte werden deshalb per Pipe an den Sortierer geschickt und dann der letzte (d.h. der neueste) Wert ausgewählt.

Klar: Dieses Skript ist nichts besonderes; es gibt in SCCM vordefinierte Reports, welche dieselbe Informationen (und noch mehr dazu) mit Hilfe weniger Mausklicks liefern können. Doch dieses Skript zeigt exemplarisch, wie so eine Query in Powershell realisiert werden könnte, womit diese auch als Basis für komplexere Abfragen dienen könnte.

Komplette Skriptdatei: computersystems.ps1 (zip)



Installation der SCOM- und SCSM Konsole via Configuration Manager
Montag, 25. Januar 2010, 11:45
Abgelegt unter: Anleitungen | Tags: , , , ,

Bisher fehlten noch die Konsolen für den Operations Manager und den Service Manager auf meinem Arbeitsplatz-PC. Natürlich wäre es möglich, diese manuell zu installieren, doch für was hat man ja den Configuration Manager im Einsatz? Ich habe mich also gefragt, wie man die beiden Konsolen für den Service Manager und den Operations Manager mit Hilfe des Configuration Manager auf die PCs verteilen kann. Und die Antwort darauf ist erfreulich einfach…

Installation der Service-Manager-Konsole via SCCM

Die automatisierte Installation der Service-Manager-Konsole ist sehr einfach zu bewerkstelligen:

  • Man nehme die Datei „sm.msi“ aus dem Ordner „<Pfad zur SCSM-Software>\SMCDImage_x86\Setup\Server“ und lege sie in einem passenden Source-Ordner für den Configuration Manager bereit.
  • Man erstelle ein neues Anwendungspaket im SCCM, gebe den entsprechenden Source-Ordner an und lege das Paket auf die gewünschten Distribution Points.
  • Man erstelle ein neues Program in diesem Anwendungspaket und definiere darin das Requirement, dass man diese Paket nur auf x86-Systemen installieren dürfe. Die Kommandozeile für die Installation lautet (selbstverständlich ohne Zeilenumbruch) :


msiexec /i SM.msi INSTALL_SM_SERVER=0
INSTALL_SM_DATABASE=0 INSTALL_SM_CONSOLE=1
MGSERVER=<Service Manager Management Server> /qb-

  • Man advertise diese Program an die gewünschten Clients, z.B. auch an den eigenen PC.

Ist die Installation auf dem PC durchgelaufen, kann man die Konsole starten und muss dann beim ersten Start den Namen des Service Manager Management Servers angeben. Das wärs. Hat auf meinem Windows 7 x86 PC anstandslos funktioniert. Hat man x64-basierte PCs, dürfte das Vorgehen analog sein: SM.msi aus dem x64-Ordner nehmen, … Sollte man die Konsole wieder entfernen wollen, reicht das übliche „msiexec /x sm.msi“.

Installation der Operations-Manager-Konsole via SCCM

Auch die Installation der Operations Manager Konsole ist einfach:

  • Man nehme den Ordner „i386“ aus Ordner „Server“ im Installationspfad der Operations Manager 2007 R2 Software und lege diesen in einem passenden Source-Ordner für den Configuration Manager bereit.
  • Man erstelle ein neues Anwendungspaket im SCCM, gebe den entsprechenden Source-Ordner an und lege das Paket auf die gewünschten Distribution Points.
  • Man erstelle ein neues Program in diesem Anwendungspaket und definiere darin das Requirement, dass man diese Paket nur auf x86-Systemen installieren dürfe. Die Kommandozeile für die Installation lautet (selbstverständlich ohne Zeilenumbruch) :


msiexec /i MOM.msi /qb- ADDLOCAL=MOMUI
ROOT_MANAGEMENT_SERVER_DNS=<FQDN des Servers>

  • Man advertise diese Program an die gewünschten Clients, z.B. auch an den eigenen PC.

Ist die Installation auf dem PC durchgelaufen, kann man die Konsole starten. Auch dies hat auf meinem Windows 7 x86 PC anstandslos funktioniert. Hat man x64-basierte PCs, muss man einfach den Ordner „AMD64“ aus dem Ordner „Server“ kopieren und analog vorgehen. Zur Entfernung der Konsole reicht das einfache „msiexec /x MOM.msi“.

Beobachtungen

So weit, so gut. Spannender wird die Angelegenheit, wenn man beide Konsolen auf dasselbe System installiert:

  • Installiert man zuerst die Konsole für den SCOM 2007 R2 und dann erst die Konsole für den Service Manager Beta 2, ist alles bestens. Beide Konsolen funktionieren wunschgemäss.
  • Installiert man jedoch zuerst die Konsole für den Service Manager und dann erst diejenige für den Operations Manager, dann funktionieren zwar beide Konsolen, doch bringt dies (zumindest bei auf meinen Systemen, dies aber reproduzierbar) etwas ungewohnte Farbe in den Admin-Alltag…

Unerwartete Farbe in der SCOM-Konsole

Zudem: Deinstalliere ich die Service-Manager-Konsole, lässt sich die Operations-Manager-Konsole nicht mehr starten; diese crasht dann bei jedem weiteren Startversuch.

Fazit

Die Installation der beiden Konsolen via SCCM funktioniert grundsätzlich problemlos, nur sollte man

  • zuerst die Operations Manager Konsole und dann erst die Service Manager Konsole installieren
  • bei der Deinstallation der Service Manager Konsole darauf achten, dass man danach noch eine funktionierende Operations Manager Konsole vorfindet…


Installation MS System Center Service Manager – Teil 4 – „System Center Configuration Manager Connector“
Dienstag, 29. Dezember 2009, 17:46
Abgelegt unter: Anleitungen | Tags: , , ,

Nachdem gestern die Anbindung des Service Manager an das Active Directory problemlos geklappt hat, ist heute nun der System Center Configuration Manager an der Reihe.

Im SCSM-Blog der belgischen System Center User Group finde ich den Hinweis, dass das dafür benötigte Connector Account Mitglied der „smsdbrole_extract“ und der „db_datareader“ Gruppen der SMS-Datenbank sein müsse. Das sagt mir im Moment mal leider gar nichts, denn ich kenne keine entsprechenden Einträge in der SCCM-Konsole. Ich schaue deshalb mal mit dem „SQL Server Management Studio“ in die Site-Datenbank rein und werde tatsächlich fündig: In der Site-Datenbank finde ich die beiden Bezeichnungen unter „Security“ -> „Roles“ -> „Database Roles“.

Ich erstelle deshalb im Active Directory ein passendes Service Account. Dieses kann ich nun als erstes dem SQL Server bekannt machen, indem ich unter der entsprechenden Datenbankinstanz -> „Security“ -> „Logins“ ein neues Login mit dem entsprechenden AD-Loginnamen vom Typ „Windows Authentication“ anlege. Unter „Server Roles“ ist bereits „public“ vorgegeben, unter „Status“ ist die Erlaubnis für das Verbinden zur Datenbank erteilt und das Login ist aktiviert.

Als nächstes kann ich nun bei der Site-Datenbank als User definieren, indem ich in der Site-Datenbank unter „Security“ -> „Users“ einen neuen Benutzer anlege. Hier kann ich nun beim Feld „Login Name“ nach dem betreffenden Benutzer suchen; als „User Name“ verwende ich wieder denselben Wert wie er nun beim „Login-Name steht. Unten in der Liste „Database Role Membership“ kann ich nun die beiden gewünschten Rollen „smsdbrole_extract“ und „db_datareader“ aktivieren.

Da nun die Prerequisites erfüllt sein sollten, wechsle ich nun auf unseren Service Manager. In der Konsole finde ich im Bereich „Administration“ unter „Getting started“ im Kasten „Create Connectors“ den Link „Create a Configuration Manager connector“, den ich nun mal anklicke. Damit wird der „System Center Configuration Manager Connector Wizard“ gestartet, der mir seine Willkommensseite präsentiert. Nach einem ersten Klick auf „Next“ werde ich nach einem Namen und einer Beschreibung gefragt, die ich passend angebe und dann wieder auf „Next“ klicke.

Nun werde ich nach einem Management Pack gefragt, wo dieser Connector gespeichert werden soll. Die einzige Auswahlmöglichkeit ist das Management Pack „System Center COnfiguration Manager Connector Configuration“, das ich mit einem Klick auf „Next“ übernehme.

Nun wird es spannend: Auf der nächsten Seite des Wizard sind nun die Angaben zur Datenbank notwendig. Als „Database Server Name“ trage ich unsere Named Instance in der Form „<Servername>\<Instancename>“ ein, als „Database Name“ das übliche „SMS_<Sitecode>“. Im Bereich „Credentials“ klicke ich nun beim „Run as Account“ auf „New…“ und erstelle damit ein neues „Run As Account“. Als „Display Name“ wähle ich „SCCM Connector Account“, trage eine passende Beschreibung ein und ergänze die entsprechenden Angaben zum AD-Konto. Ein Klick auf „OK“ und schon ist das neuerstellte Konto als „Run As“-Konto definiert. Erleichtert lese ich nach dem Klick auf „Test Connection“: „The connection to the server was successful.“

Auf der nächsten Seite des Assistenten kann ich nun die zu synchronisierende Collection wählen. Dabei werden mir alle Collections angezeigt, die mindestens ein Mitglied besitzen. Erfreut stelle ich mit einem kurzen Seitenblick zur SCCM-Konsole fest, dass die angezeigten Zahlen der enthaltenen Computer den Angaben im SCCM entsprechen: Wenn das kein gutes Omen ist! Nachdem ich „All Systems“ ausgewählt habe, klicke ich auf „Next“.

Nun muss ich noch den Schedule definieren, wann dieser Connector ausgeführt werden soll. Zur Auswahl wird mir „Every Day“ oder ein expliziter Wochentag angeboten, was einer wöchentlichen Synchronisierung entsprechen würde. Als Zeitpunkt kann ich jeweils eine volle Stunde wählen. Ich entscheide mich für täglich abends um 23 Uhr. So sollten die Veränderungen eines Tages im Configuration Manager am nächsten Tag im Service Manager nachgeführt sein.

Nach dem nächsten „Next“ wird mir nun noch das Summary präsentiert, worauf ich auf „Create“ klicke. Wenige Sekunden später erhalte ich die Meldung, dass ich den Wizard erfolgreich abgeschlossen hätte, den ich nun mit einem Klick auf „Close“ schliesse.

Zurück in der Konsole, nagiviere ich zu den „Connectors“ und sehe dort den neu erstellten Connector. Ich wähle diesen aus und klicke auf „Synchronize Now“. Dies wird sogleich bestätigt mit einer Meldung, dass der entsprechende Request abgesetzt worden sei. Der Status wird des Connectors wird nun als „Running“ angezeigt, zudem kann ich mitverfolgen, wie der Wert „Percentage“ langsam aber sicher steigt.

Etliche Zeit später – die Synchronisation grosser Produktionsumgebungen kann offenbar durchaus Stunden dauern – kann ich nun lesen: Status „Finished Success“, Percentage „100%“. Ich wechsle deshalb in den Abschnitt „Configuration Items“. Und siehe da: Nun sind zu den von SCCM verwalteten Computern detaillierte Informationen vorhanden.

Wenn doch bloss immer alles so einfach wäre und so reibungslos funktionieren würde…



Bereitstellung von Gerätetreibern (Teil 3: Installation via „Apply Driver Package“)
Dienstag, 15. Dezember 2009, 22:25
Abgelegt unter: Anleitungen | Tags: , , , ,

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



Bereitstellung von Gerätetreibern (Teil 2: Bereitstellung der Treiber)
Dienstag, 8. Dezember 2009, 22:01
Abgelegt unter: Anleitungen | Tags: , , ,

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:

  1. Wir navigieren in der SCCM-Konsole zu „Computer Management“, „Operating System Deployment“, „Drivers“
  2. 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“).
  3. Darunter legen wir nun einen neuen Ordner mit dem Namen des Gerätemodelles an. (z.B. „DC7800“)
  4. Mit Rechtsklick auf den soeben angelegten Ordner, können wir nun den „Import“-Wizard starten.
  5. 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.
  6. 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“.
  7. 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>
  8. 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.
  9. 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.
  10. 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.



Bereitstellung von Gerätetreibern (Teil 1: Sammeln der Treiber)
Dienstag, 1. Dezember 2009, 18:14
Abgelegt unter: Anleitungen | Tags: , , ,

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:

  1. Feststellen und Sammeln der benötigten Gerätetreiber,
  2. Bereitstellung der Gerätetreiber in SCCM in Form von Treiber-Paketen,
  3. 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.



„Auto Apply Drivers“ versus „Apply Driver Package“
Montag, 23. November 2009, 12:15
Abgelegt unter: Erkenntnisse | Tags: , , ,

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.