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…



Installation MS System Center Service Manager – Teil 3 – „Active Directory Connector“ und „User Roles“
Montag, 28. Dezember 2009, 14:31
Abgelegt unter: Anleitungen | Tags: , , ,

Heute will ich den System Center Service Manager ans Active Directory anbinden. Die Konsole ist geladen und zeigt mir an, was ich für das „Getting started“ noch alles tun sollte. Im Kasten „Import User Accounts“ sehe ich den Link „Import user accounts with the Active Directory Connector“, den ich nun mal anklicke. Der sog. „Active Directory Connector Wizard“ startet und zeigt mir seine Begrüssungsseite, die ich sogleich mit einem Klick auf „Next“ wieder verlasse.

Als erstes muss ich nun einen Namen und eine Beschreibung für den einzurichtenden Connektor eingeben; da das Häckchen bei „Enable this connector“ schon gesetzt ist, klicke ich anschliessend auf „Next“.

Auf der nächsten Seite „Select a domain or organizational unit“ schlägt mir der Wizard automatisch vor, die ganze Domäne, welcher der Service Manager Server angehört, anzubinden; ich hätte jedoch auch die Möglichkeit, eine andere Domäne oder auch nur eine einzelne Organisationseinheit zu wählen. Ebenso muss ich hier das Konto angeben, welches für den Zugriff auf das Active Directory verwendet werden soll. Die entsprechende Auswahl enthält bereits das „Operational System Account“ und das „Workflow Account“, der Knopf daneben bietet mir an, ein weiteres Konto für den Service Manager zu definieren. Ich wähle allerdings der Einfachheit halber das vorgeschlagene „Operational System Account“, über den Knopf „Test Connection“ kann ich sogleich überprüfen, ob der Zugriff ins Active Directory klappt: „The connection to the server was successful“, darf ich lesen; klappt perfekt!

Auf der nächsten Seite „Select Objects“ muss ich nun auswählen, ob ich alle Computer, Drucker, Benutzer und Benutzergruppen übernehmen will, oder ob ich gezielter auswählen möchte. Ich bin mit dem vorgeschlagenen „All…“ einverstanden und klicke wiederum auf „Next“.

Schon erhalte ich die Summary-Seite, die mir nochmals meine getätigten Angaben präsentiert. Sieht alles gut aus, also klicke ich auf „Create“. Wenige Sekunden später erhalte ich die Meldung, dass der Active Directory Connector erfolgreich erstellt worden sei und schliesse den Wizard mit „Close“.

Nun wechsle ich wieder zurück in die Service Manager Console in den Abschnitt „Administration“ und navigiere zu „Connectors“. Siehe da, einen Moment später kann ich bereits lesen, dass der Status „Finished Success“ sei.

Ich wechsle deshalb in den Abschnitt „Configuration Items“ und stöbere dort etwas herum. Tatsächlich: alle Userobjekte, alle Printqueues und alle Computerobjekte sind im Service Manager angekommen.

Nun habe ich mich noch gefragt, ob ich noch einen Zeitplan definieren muss, wie häufig dieser AD-Connector synchronisieren soll. Doch in einem Blog-Post des Service Manager Teams finde ich rasch die Information, dass ein aktivierter AD-Connector automatisch jede Stunde gestartet wird, um allfällige Änderungen an Objekten im AD zu übernehmen. Wird mal schneller eine Synchronisation benötigt, kann die jederzeit über „Synchronize now“ gestartet werden.

Das lief ja mal wieder wie am Schnürchen, also schaue ich mal noch gleich, was mir angeboten wird, wenn ich im Kasten „Import User Accounts“ auf der Administration-Seite auf den Link „Create and assign user roles“ klicke. Wie ich feststelle, navigiere ich damit zu „Administration“ -> „Security“ -> „User Roles“. Hier finde ich standardmässig angebotene Rollen wie „Authors“, „End Users“, „Problem Analysts“, „Incident Resolvers“ usw.

Also schaue ich mir diese Rollen mal kurz durch und finde bei den folgenden drei Rollen bereits Mitgliedschaften (alle übrigen Rollen enthalten noch keine Mitglieder):

  • Mitglieder der Rolle „Administrators“ haben volle Zugriffsrechte auf alle Operationen und auf alle Objekte im System; als standardmässige Mitglieder finde ich hier mein Account, unter welchem ich den Service Manager installiert habe, das „Operational System Account“ sowie diejenige AD-Gruppe, die ich bei der Installation angegeben habe, als ich nach einer Gruppe gefragt wurde, welche Administrative Rechte für diese Management Gruppe erhalten soll. Passt!
  • Mitglieder der Rolle „End Users“ dürfen laut Beschreibung auf das Self-Service-Portal zugreifen, Incidents anlegen, die Installation von Software verlangen, Announcements lesen und in der Knowledge Base suchen; standardmässig ist hier „Authenticated Users“ eingetragen, was meiner Meinung nach ebenfalls Sinn macht.
  • In der Rolle „Workflow“ finde ich das „Workflow Account“ wieder. Workflows werden laut Beschreibung automatisch durch den Service Manager gestartet und können beliebige Configuration und/oder Work Items erstellen. Auch das macht Sinn.

Somit denke ich, dass die Aktivität „Import User Accounts“ für den Moment abgeschlossen ist und mache somit Schluss für heute.



Installation MS System Center Service Manager – Teil 2 – Installation „Service Manager Data Warehouse Management Server“
Donnerstag, 24. Dezember 2009, 09:46
Abgelegt unter: Anleitungen | Tags: , , , ,

Nachdem ich – wie im letzten Beitrag beschrieben – erfolgreich den „Service Manager Management Server“ auf dem ersten Server installieren konnte, möchte ich nun auf dem zweiten Server den „Service Manager Data Warehouse Management Server“ installieren. Da ich herausgefunden habe, dass sich eine Service Manager Installation und ein bereits vorhandener Operations Manager Agent gegenseitig in die Quere kommen, entferne ich zuerst auch beim zweiten Server den SCOM-Agent über die SCOM-Konsole, danach logge ich auf diesem Server ein. Als erstes installiere ich sogleich via Server Manager das Feature „Microsoft .NET Framework 3.5.1“ mitsamt allen Dependencies.

Der erste Installationsversuch des „Service Manager Data Warehouse Management Server“ schlägt sehr schnell fehl, es fehlen die SQL Reporting Services, die zuerst noch installiert werden müssen.

Also habe ich flugs die SQL Server 2008 Scheibe eingelegt und darauf Setup gestartet. Im „SQL Server Installation Center“ muss nun links in der Navigation auf „Installation“ geklickt werden, dann kann der Installationswizard über den Link „New SQL Server stand-alone installation or add features to an existing installation“ gestartet werden. Darauf musste ich zuerst auch einmal kommen, denn wenn man als Nicht-SQL-Profi nur die Reporting Services installieren will, kommt man nicht unbedingt auf die Idee, dass man dazu die Installation eines neuen „SQL Server stand-alone“ starten muss.

Als erstes werden nun die „Setup Support Files“ installiert. Dabei wird zuerst das System auf mögliche Probleme abgeklopft, die bei der Installation auftreten könnten, als nächstes muss der Product Key für den SQL-Server eingegeben und der Lizenzvertrag abgenickt werden, danach werden die Setup Support Files installiert; das Ergebnis wird danach angezeigt.

Nun startet das eigentliche SQL Server 2008 Setup. Hier habe ich einzig das Feature „Reporting Services“ angewählt und dann auf Next geklickt. Als nächstes muss man sich entscheiden, ob man die „Default instance“ oder eine „Named instance“ verwenden will. Hier bin bei der „Default instance“ geblieben und habe alle Vorgabewerte übernommen. Im nächsten Schritt werden die „Disk Space Requirements“ angezeigt, die bei mir erfüllt sind, dann muss ich angeben, unter welchem Service Account die Reporting Services laufen sollen, somit folgt hier das übliche Prozedere: Ein neues, passendes Konto im AD generieren und hier dann sogleich eintragen.

Nun folgt der Schritt „Reporting Services Configuration“. Die ersten zwei Auswahlmöglichkeiten sind ausgegraut, die einzige verfügbare dritte Auswahl lautet „Install, but do not configure the report server“. Im Text dazu wird erwähnt, dass man nach abgeschlossener Installation das „Reporting Services Configuration Tool“ verwenden müsse, um den Report-Server zu konfigurieren. Gut, muss ich mir merken.

Nun folgen die üblichen Auswahlen zum „Error und Usage Reporting“, die ich hier mal deaktiviert lasse. Nachdem dann die „Installation Rules“ erfolgreich überprüft worden sind, erhalte ich nun das „Ready to install“. Noch ein kurzer Blick auf das Summary, dann folgt der Klick auf den Knopf „Install“. Zwei Minuten später lese ich „Setup process complete, Reporting Services -> Success“. Es folgt eine letzte Dialogseite, die mir nochmals bestätigt, dass meine „SQL Server 2008 Installation“ erfolgreich abgeschlossen wurde, dann wird der Assistent geschlossen.

Ok, die Reporting Services sind installiert, also zurück zum Service Manager. Halt! Da war doch noch was. Stimmt, die Reporting Services müssen ja noch konfiguriert werden: Der „Reporting Services Configuration Manager“ ist im Startmenü rasch gefunden und gestartet. Dieser will sich nun mit einer Serverinstanz verbinden, die angegebenen Vorgabewerte passen; also „Connect“. In der ersten Ansicht wird mir nun bestätigt, dass der Report Service läuft, zudem sind verschiedene Angaben zur Instanz und SQL-Serverversion aufgelistet. In der Navigationsspalte sind verschiedene Punkte aufgelistet, die mir im Moment noch nicht viel sagen, also sehe ich diese mal der Reihe nach durch:

  • „Service Account“: Hier sehe ich die Infos zum bei der Installation angegebenen Service Account und könnte diese nötigenfalls ändern.
  • „Web Service URL“: Ich sehe eine Warnung, dass der „Report Server Web Service“ nicht konfiguriert sei, aber es wurden netterweise Defaultwerte bereitgestellt, die ich mit „Apply“ übernehmen kann.
  • „Database“: Die Angaben zur „Current Report Server Database“ sind leer. Also klicke ich auf „Change Database“, worauf mir angeboten wird, eine neue Datenbank zu erstellen. Hier trage ich wieder mal den Namen unseres SQL 2008 Clusters ein und teste die Verbindung mit dem vorgeschlagenen „Authentication Type: Current User – Integrated Security“. Funktioniert! Nun erstelle ich eine neue Datenbank im Native Mode, auf die mit den „Service Credentials“ zugegriffen werden soll. Das klappt auf Anhieb, die Angaben zur Datenbank und den Credentials erscheinen danach im „Reporting Services Configuration Manager. Noch ein kurzer Klick auf Apply, dann ist auch dieser Schritt durch.
  • „Report Manager URL“: Hier wird ebenfalls eine Warnung angezeigt, dass das „Report Manager Virtual Directory“ nicht konfiguriert sei. Doch der vorgeschlagene Defaultwert „Reports“ lässt sich mit einem Klick auf Apply übernehmen.
  • „E-mail Settings“: Hier trage ich die Emailadresse ein, die für den Versand verwendet werden soll, und konfiguriere unseren SMTP-Server.
  • „Execution Account“: Hier liesse sich ein zusätzliches Konto definieren, das für den Zugriff auf weitere Datenquellen oder Server verwendet könnte. Ich vermute, dass wir das im Moment nicht benötigen und lasse das mal leer.
  • „Encryption Keys“: Hier lassen sich die Schlüssel verwalten, die zur Verschlüsselung sensibler Daten wie Credentials, Connection Strings usw. verwendet werden.
  • „Scale-out-Deployment“: Hier liessen sich weitere Server hinzufügen, die ihre Daten in derselben Datenbank speichern sollen.

Da ich nun mal alle Punkte in der Navigation durchgegangen bin und nirgends mehr eine Warnung sehe, gehe ich nun davon aus, dass die Reporting Services konfiguriert sind; also klicke ich nun auf Exit.

Nun kann ich mich wieder dem „Service Manager Data Warehouse Management Server“ zuwenden: Beim nächsten Installationsversuch kann ich nun den Namen und die Organisation eingeben und den Lizenzvertrag abnicken. Auch bei diesem Server bleibt das Feld für den Product-Key leer, da für die Beta-Version noch kein Product-Key benötigt wird.

Im nächsten Dialogfenster wird nach dem Installationspfad gefragt; genügend Diskplatz (verlangt wird 1 GB) ist vorhanden. Auch bei diesem Server erhalte ich eine „Memory-Check“-Warnung: Für den Data Warehouse-Server werden ganze 8 GB RAM empfohlen! Auch dieser Server hat nur 2GB Arbeitsspeicher, dennoch lässt sich das Setup fortsetzen.

Nun wird nach den benötigten Datenbanken gefragt. Hier trage ich den Namen unseres SQL2008-Clusters ein und erhalte wenige Augenblicke später die entsprechende Instanz angeboten. Für die Datenbanken ‚Staging and Configuration‘ (DWStagingAndConfig) und ‚Repository‘ (DWRepository) werden sogleich sinnvolle Werte angezeigt; bei der Datenbank ‚Data Mart‘ ist noch ein rotes Kreuz zu sehen. Auch hier kann ich nochmals unseren SQL2008-Cluster angegeben und erhalte umgehend brauchbare Werte. Offenbar liesse sich diese Datenbank problemlos auf einem anderen Server hosten, doch einen zweiten SQL-Server haben wir nicht zur Verfügung. Somit habe ich wiederum die Default Werte übernommen.

Nun wird im nächsten Dialogfeld wiederum nach einem „Management Group Name“ gefragt, wobei explizit ausgeschlossen wird, dass man einen bereits verwendeten Wert erneut wählt. Somit habe ich hier unser offizielles Kürzel, ergänzt durch ‚-DW‘ eingetragen, da ich unser offizielles Kürzel bereits für die Management Group beim Management Server verwendet habe. Zudem wird noch nach einem Benutzer bzw. einer Gruppe gefragt, die als Administrator für diese Management Gruppe amtieren darf; hier habe ich dieselbe Gruppe wiederverwendet, die ich schon bei der Installation des Management-Servers eingetragen habe.

Im nächsten Schritt muss nun der Reporting Server für das Data Warehouse konfiguriert werden. Erfreut stelle ich fest, dass der vorhin installierte Reporting Server erkannt wird und dessen URL als gültig akzeptiert wird.

Nun müssen noch zwei Konti konfiguriert werden: Als Konto für die „Service Manager Services“ habe ich dasselbe Konto verwendet, das ich auch schon bei der Installation des Management Servers angegeben habe; dieses muss lokale Administratorenrechte besitzen, was ich sogleich noch im Computermanagement“ konfiguriere. Für das „Reporting Account“ habe ich wieder einmal flugs ein neues, passendes AD-Konto erstellt und eingetragen.

Jetzt folgen noch die Fragen zum „Customer Experience Improvemend Program“ und zum „Error Reporting“; auch hier wähle ich zweimal „Yes“. Nun wird noch das Summary angezeigt, danach startet die Installation.

Bereits wenige Minuten später heisst es: „Finished. Setup completed successfully.“

Somit sind der „Service Manager Management Server“ und der „Service Manager Data Warehouse Management Server“ installiert. Nun geht es an die Konfiguration des Service Managers, aber das ist etwas für die nächsten Beiträge.



Installation MS System Center Service Manager – Teil 1 – Installation „Service Manager Management Server“
Montag, 21. Dezember 2009, 21:01
Abgelegt unter: Anleitungen | Tags: , ,

Heute habe ich versucht, in unserer Umgebung den System Center Service Manager (öffentliche Beta 2) zu installieren. Hierzu stehen mir zwei Server zu Verfügung, die mit Server 2008 R2 installiert sind. Wie für alle unsere Server üblich, ist darauf bereits McAfee Virusscan 8.7 Patch 2 inkl. ePolicyOrchestrator-Agent installiert. Ebenso ist darauf der SCCM-Client und der SCOM-Agent zu finden.

Den ersten Server will ich als Service Manager Management Server benutzen. Somit logge ich mich auf diesem Server ein und starte das Setup des Service Manager. Sogleich wird angezeigt, dass das „Microsoft .NET Framework 3.5 inkl. SP1“ benötigt werde. Beim Server 2008 R2 lässt sich dieses als Feature hinzufügen, somit hole ich das über den Server Manager sogleich nach, wobei ich alle Dependencies zum Feature mitinstalliere.

Auch der nächste Versuch zur Installation des „Service Manager Management Server“ schlägt fehl, da ein Operations Manager Agent auf diesem Server drauf ist.

Fehlermeldung: SCOM agent is installed.

Ich deinstalliere deshalb den SCOM-Agent über die SCOM-Konsole. Beim nächsten Installationsversuch kann ich nun den Namen und die Organisation eingeben und den Lizenzvertrag abnicken. Das Feld für den Product-Key bleibt leer, da für die Beta-Version noch kein Product-Key benötigt wird. Im nächsten Dialogfenster wird nach dem Installationspfad gefragt und darauf hingewiesen, dass 1 GB freier Diskplatz benötigt werde. Dieser ist glücklicherweise vorhanden. Beim anschliessenden Memory-Check wird bemängelt, dass der Server nur 2GB Arbeitsspeicher habe; empfohlen wären 4 GB. Die Prozessorgeschwindigkeit wird als ok beurteilt. Trotz der „Memory Check“-Warnung lässt sich das Setup fortsetzen.

Nun wird nach der Service Manager Datenbank gefragt. Hier trage ich den Namen unseres SQL2008-Clusters ein und erhalte wenige Augenblicke später die entsprechende Instanz angeboten. Als Database Name wird „ServiceManager“, als Grösse 2000MB vorgeschlagen. Auch die vorgeschlagenen Pfade für den Data- und den Log-File-Ordner passen. Somit akzeptiere ich die Werte und fahre weiter.

Im nächsten Dialogfeld wird nach dem „Management Group Name“ gefragt, für den ich unsere offizielle Abkürzung wähle. Zudem wird noch nach einem Benutzer bzw. einer Gruppe gefragt, die als Administrator für diese Management Gruppe amtieren darf. Flugs erstelle ich eine passende Gruppe im Active Directory und wähle diese dann anschliessend aus.

Nun wird nach einem Domain Account gefragt, unter welchem der System Center Service Manager laufen soll. Dieses muss lokale Administratorenrechte für den gerade zu installierenden Server haben. Auch hier richte ich kurzerhand ein passendes Konto ein und befördere dieses zum lokalen Admin. Danach wird noch nach einem Service Manager Workflow Account gefragt, welches ich ebenfalls im AD definiere und dann angebe.

Jetzt folgen noch die Fragen zum „Customer Experience Improvemend Program“ und zum „Error Reporting“. Da wir hier eine Beta-Version einsetzen, bejahe ich mal beides. Nun wird noch das Summary angezeigt, danach startet die Installation.

Bereits wenige Minuten später lacht mich folgende Meldung an: „Finished. Setup completed successfully.“ Ist das bereits alles? Scheint so, denn unten wird bereits eine Checkbox angeboten: „Open the Service Manager Console when Setup closes“. Na dann: Probieren geht über studieren! Tatsächlich: Kurz nach dem Klick auf „Close“ sehe ich erstmals die Konsole des System Center Service Manager.

Erster Blick auf die Service Manager Konsole

„Getting started“ heisst nun das Motto. So gibt es diverse „required configuration tasks“, die durchlaufen werden müssen, bevor der Service Manager tatsächlich benutzt werden kann. Aber das ist definitiv etwas für den nächsten Beitrag.



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.