Abgelegt unter: Anleitungen | Tags: DateTime, PowerShell, SCCM, WMI
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)
Abgelegt unter: Anleitungen | Tags: Installation, Konsole, SCCM, SCOM, SCSM
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…
Abgelegt unter: Anleitungen | Tags: IIS, Konfiguration, SCSM, ServicePortal
Als letzter Teil der Installation des Service Managers möchte ich nun noch das Webportal installieren.
Voraussetzungen
Auch heute halte ich mich an einen Blogbeitrag aus Belgien, der die Voraussetzungen für die Installation des Webportals nennt. Da dieses auf dem IIS basiert, muss zuerst ein Standard-IIS eingerichtet werden, der folgende zusätzlichen Role Services benötigt:
- Asp.Net (und alle davon abhängigen Features)
- Windows Authentication
- IIS 6.0 Metabase Compatibility
Auf meinem Server ist der IIS zwar bereits installiert, doch die zusätzlichen Role Services fehlen noch, deshalb installiere ich diese als erstes nach.
Installation des Portals
Nun starte ich den Setup Wizard und wähle „Install the Service Manager Web Portals“. Als nächstes muss 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 Installationsort gefragt und darauf hingewiesen, dass 1 GB freier Diskplatz benötigt werde. Der Diskplatz ist vorhanden, zudem übernehme ich den vorgeschlagenen Pfad.
Danach werden diverse Checks durchgeführt: Beim Memory Check erhalte ich eine Warnung, dass das System nur über 2GB Memory verfüge, empfohlen wären 4GB. Da alle anderen Checks erfüllt sind, kann das Setup dennoch fortgesetzt werden.
Nun wird nach dem Namen und dem Port für die Website gefragt: Hier übernehme ich den vorgegebenen Namen „SCSMPortal“ und den Port 443. Eine Meldung weist daraufhin, dass das SSL-Certificate nicht automatisch hinzugefügt werde, wozu es im Deployment Guide zusätzliche Informationen gebe.
Als nächstes muss konfiguriert werden, wo die Service Manager Datenbank zu finden ist. Ich trage den Namen des Servers ein und erhalte umgehend die entsprechende Instanz angeboten. In dieser kann ich die Service Manager Datenbank bequem auswählen.
Nun muss ein Konto angegeben werden, mit welchem das Service Manager Portal auf die Datenbank zugreifen kann. Es wird verlangt, dass dieselben Credentials verwendet werden, wie bei der Installation des Management Servers. Ich trage die entsprechenden Angaben ein, klicke auf den Knopf „Test Credentials“ und erhalte die Bestätigung, dass die Angaben passen.
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. Es dauert nur wenige Sekunden, dann erhalte ich die Meldung: „Setup completed successfully“.
Der Setup-Vorgang hat zwei Portale eingerichtet:
- https://<Servername>:443/EndUser
- https://<Servername>:443/Analyst
Installation des SSL-Zertifikates
Ich starte nun den „Internet Information Services (IIS) Manager“, klicke unter Connections auf den Servernamen und öffne „Server Certificates“. Hier klicke ich auf „Create Domain Certificate“. Hier werden zuerst nach den Angaben zum „Distinguished Name“ gefragt. Hier muss als „Common Name“ der vollqualifizierte Servername eingetragen werden, die restlichen Felders sind geeignet auszufüllen.
Da wir eine eigene Certification Authority betreiben, kann ich diese im nächsten Schritt bequem auswählen. Noch ein passender „Friendly Name“ eingetragen und schon kann ich das Zertifikat mit dem Klick auf „Finish“ beziehen. Das neu ausgestellte Zertifikat wird nun in der Liste angezeigt.
Nun expandiere unter Connections dem Servernamen und „Sites“. Ich klicke mit der rechten Maustaste auf das SCSMPortal und wähle „Edit Bindings…“ In der Dialogbox „Site Bindings“ klicke ich auf Edit und kann nun das SSL-Zertifikate auswählen, danach schliesse ich den Dialog wieder.
Ein erster Test
Neugierig öffne ich nun die Adresse „https://<Servername>:443/EndUser“ im Browser. Und tatsächlich, ich erhalte eine Anmeldeaufforderung. Flugs die passenden Daten eingetragen und ich sehe erstmals das End-User-Portal vor mir. Es sieht zwar noch sehr hässlich aus, da das CSS-fehlt und auch noch die Icons durch ein rotes Kreuz ersetzt werden, aber immerhin.
Troubleshooting
Nun folgt eine lange Suche in den Abgründen des IIS, weshalb die Icons und das CSS fehlen; es ist unmöglich, hier zu beschreiben, wo ich überall gesucht habe. Doch als ich nochmals die Installation des IIS durchsehe, um das Logging zu aktivieren, stelle ich fest, dass schlicht und einfach die Role Services „Common HTTP Features“ mit allen Unterservices wie „Static Content“ etc. nicht installiert sind. Ich habe dies nachgeholt und siehe da: Keine Kreuzchen mehr, das CSS lädt wunschgemäss. Endlich habe ich die Seite so vor mir, wie ich sie mir etwa vorgestellt habe:
Service Manager EndUser Portal
Abschliessend folgt noch die Konfiguration der Kontakteinstellungen, dieich in der SCSM-Konsole vornehme. Hierzu navigiere ich in der Konsole zu „Administration“, „Portal“, „Settings“ und öffne dort die „End-user portal Contact IT settings“. Hier trage ich die passenden Informationen ein und kontrolliere nachher kurz im Portal, ob diese wunschgemäss angezeigt werden.
Persönliches Fazit zur Installation des Service Manager
Mit der Bereitstellung des Webportals ist meines Erachtens die grundsätzliche Installation des Service Manager abgeschlossen, womit auch diese Reihe von sieben Blogbeiträgen zu diesem Thema ihren Abschluss findet. Es ist mir absolut bewusst, dass nun erst der Anfang geschafft ist. Bis aus der vorliegenden Grundinstallation eine brauchbare Umgebung geworden wird , wird es noch viel Konfigurationsarbeit benötigen.
Die Installation selber lief in vielen Bereichen sehr problemlos ab. Doch wenn es mal klemmte, dann klemmte es gleich richtig. Die mitgelieferte Dokumentation konnte zwar etliche Fragen beantworten und auch einen Leitfaden darstellen, am meisten habe ich jedoch von den Beiträgen in den folgenden Blogs profitiert:
- System Center Service Manager: Communications from the Service Manager team
- System Center Service Manager: Blog about service manager aka scsm
- Mike’s Blog: Just stuff about System Center
Aber eben: Die Grundinstallation und die Grundkonfiguration ist gemacht, nun kann der Aufbau der Service Manager Umgebung erst richtig anfangen. Und auch dabei wird es sicher wieder weitere Erkenntnisse geben, die in zukünftige Blogbeiträge von mir einfliessen werden.
In diesem Sinne: Leicht verspätet die besten Wünsche zum neuen Jahr!
Euer Michael Hottinger
Abgelegt unter: Anleitungen | Tags: DataWarehouse, Konfiguration, PowerShell, SCSM
In der Konsole finde ich im Bereich „Administration“ unter „Getting started“ im Kasten „Register with Service Manager’s Data Warehouse den Link „Register with Service Manager Data Warehouse“, den ich nun mal anklicke.
Kaum begonnen, schon klemmt es ein erstes Mal…
Damit wird der „Data Warehouse Registration Wizard“ gestartet, der mir seine Willkommensseite präsentiert. Nach dem ich auf „Next“ geklickt habe, werde ich nach dem Servernamen des Data Warehouse Management Server gefragt, zudem werde ich darauf hingewiesen, dass der aktuelle Benutzer administrative Rechte für diesen Server haben müsse. Ich trage den entsprechenden Servernamen ein und klicke sogleich mal auf „Test Connection“. Die Antwort lässt längere Zeit auf sich warten und lautet dann leider: „Unable to connect to the data warehouse management server“.
Im Deployment-Guide finde ich den Hinweis, dass der Service Manager Management Server über den TCP-Port 5724 auf den Data Warehouse Management Server zugreifen will. In der Firewall des Data Warehouse Management Server finde ich jedoch keine derartige Regel, die diese Verbindung erlauben würde. Zuversichtlich, die Ursache des Verbindungsproblems gefunden zu haben, erstelle ich deshalb eine entsprechende Regel auf dem Data Warehouse Management Server. Beim anschliessenden erneuten Klick auf „Test Connection“ kommt die Antwort sehr viel schneller und lautet obendrein: „Your connection to the data warehouse management server was successful“.
Im nächsten Dialog müssen nun die Credentials angegeben werden, mit welchen das Data Warehouse auf den Service Manager zugreifen soll; dieses müsse administrative Rechte auf diesem Server haben. Vorgeschlagen wird ein „Run as“-Konto in der Form „<Management Group Name> SecureReference“, weitere Alternativen werden mir nicht angeboten. Mir sagt das mal wieder rein gar nichts, zudem ist in der Liste der „Run As Accounts“ (zu finden in der Konsole unter „Administration“, „Security“) kein derartiges Konto verzeichnet.
Einmal mehr zeichnet mir ein Blogbeitrag aus Belgien einen möglichen Weg auf, der sich später als unnötig herausstellt. Im von Mike geposteten Screenshot erkenne ich, dass er hierzu das „Operational System Account“ verwendet. Ich wundere mich, weshalb das „Operational System Account“ nicht sowieso in der Auswahlliste auftaucht, vermute dann aber, dass mir hier die Sicht des Data Warehouse Management Servers angezeigt wird, der dieses Konto möglicherweise nicht kennt. Also klicke ich auf „New…“ und erstelle ein neues „Operational System Account“, wobei ich hier unser dafür vorgesehenes AD-Konto angebe. Der Wizard akzeptiert diese Angaben problemlos, weshalb ich hier auf „Next“ klicke.
Danach folgt noch die Summary-Seite, ein Klick auf „Create“ und einige Sekunden später kann ich lesen: „The data warehouse registration succeded.“ War es das schon wieder?
Nein, zu früh gefreut, denn einen kurzen Moment später poppt folgende Meldung auf:
The report deployment process has not completed.
Diese Meldung ist jedoch laut dem Deployment Guide zu erwarten. Einige Minuten nach dem Schliessen des Data Warehouse Registration Wizards werde in der Konsole innerhalb der Navigation ein zusätzlicher Eintrag für das Data Warehouse erscheinen. Dies ist bei mir der Fall.
Überprüfung der Installation
Der Deployment-Guide empfiehlt nun, die Data Warehouse Registration zu validieren. Dazu solle man folgendermassen vorgehen:
- Auf dem Data Warehouse Management Server eine Windows PowerShell mit administrativen Rechten starten
- Zuerst das Kommando „Add-PSSnapIn SMCmdletSnapIn“ ausführen
- Dann das Kommando „Get-SCDWMgmtGroup“ ausführen. Dieses müsse eine Tabelle mit zwei Zeilen ausgegeben, dabei müsse in der ersten Spalte einmal der Name der „Service Manager Management Group“ und einmal derjenige der „Data Warehouse Management Group“ zu sehen sein.
Auch das ist bei mir so gegeben. Um nun herausfinden zu können, ob der Management Pack Deployment Prozess abgeschlossen worden ist, muss laut Deployment-Guide folgendermassen vorgegangen werden:
- Service Manager Konsole starten und den Abschnitt „Data Warehouse“ wählen.
- Navigieren zu „Data Warehouse“, „Data Warehouse Jobs“.
- Den „MPSyncJob“ auswählen und die Details anzeigen lassen.
- In der erscheinenden Ansicht solle man nach rechts scrollen und die Spalte „Status“ kontrollieren. Der Deployment Prozess sei dann abgeschlossen, wenn bei allen Management Packs entweder „Associated“ oder „Imported“ angezeigt werde. Es dürfe nirgends mehr „Pending Associations“ oder gar „Failed“ stehen.
Doch bei mir ist diese Liste schlicht und einfach leer. Es wird mir kein einziges Management Pack angezeigt. Was nun?
Troubleshooting
Die Suche im Internet fördert eine Diskussion in den MS Technet Foren zum Thema
„Service Manager Data Warehouse is registered and MPSync Job is running but has empty details“ zu Tage. In dieser Diskussion wird eingeräumt, dass es noch Probleme gebe mit der Globalisierung des Produktes. Kurz zusammengefasst lautet die Empfehlung dieser Diskussion, dass man das „Format“ und das „System Locale“ auf „English (United States)“ einstellen solle. Ich habe unsere Server zwar mit der englischen Sprachversion des Betriebssystems installiert, doch hier war wie bei uns üblich an beiden Orten „German (Switzerland)“ eingetragen. Ich passe deshalb bei beiden Servern die entsprechenden Einstellungen an und führe danach den notwendigen Neustart durch.
Nach dem Neustart öffne ich wieder die Konsole und navigiere wieder zu „Data Warehouse“, „Data Warehouse Jobs“ und öffne erneut die Details des „MPSyncJob“. Und tatsächlich: Jetzt ist die Liste der Management Packs lesbar, doch der Vorgang ist noch längst nicht abgeschlossen.
Mit der Zeit tauchen nun weitere Data Warehouse Jobs in der Konsole auf, doch es bleibt bei vier Einträgen, obwohl es laut Deployment-Guide deren fünf werden müssten: Der Eintrag in der Form „Extract_<Service Manager management group name>“ fehlt in der Liste. Wo klemmts jetzt schon wieder?
Nach längerem Suchen entdecke ich auf dem Data Warehouse Management Server im Event-Log des Operations Manager (ja genau: Operations Manager!) einige Error-Einträge: Beim näheren Studium der Fehlermeldungen klingelt die Glocke im Hinterkopf, als ich im länglichen Text eines Errorseintrages auf folgendes stosse: „Could not connect to net.tcp://<Service Manager Management Server>:5724/DispatcherService.“ Die Windows Firewall muss nicht nur auf dem Data Warehouse Management Server, sondern auch auf dem Service Manager Management Server den Zugang über den TCP-Port 5724 erlauben! Flugs habe ich auch auf diesem Server die entsprechende Regel definiert und nochmals den „MPSyncJob“ angestossen. Es dauert nicht lange, da taucht auch der fünfte, vermisste Data Warehouse Job in der Liste auf. Jetzt läuft auch der „MPSyncJob“ wieder deutlich länger, muss er doch – wie ein Blick auf die Details zeigt – nochmals eine weitere grosse Zahl an Management Packs verarbeiten.
Etliche Zeit später ist der Job endlich erfolgreich durchgelaufen. Ich schliesse die Konsole ein weiteres Mal und starte sie sogleich wieder. Erstmals bleibt nun die oben gezeigte Meldung aus, dafür findet sich in der Navigationsspalte nochmals ein weiterer Eintrag namens „Reporting“. Endlich sieht bei mir die Service Manager Konsole so aus, wie ich sie gemäss der Lektüre des Blogbeitrag von Mike aus Belgien erwartet habe. Bin ich nun endlich fertig?
Der Deployment-Guide meint: leider nein.
Es geht weiter…
Gemäss Deployment-Guide sind nämlich für die Extract, Transform und Load-Jobs die Schedules nicht noch aktiviert, was sich in der aktuellen Beta 2 noch nicht über die grafische Oberfläche bewerkstelligen lässt; dazu muss einmal mehr die Powershell herhalten. Zudem sei es noch nicht möglich, den Status eines bestimmten Jobs abzufragen: Wenn man den Status eines Jobs wissen müsse, dann solle man einfach den Befehl erteilen, diesen zu aktivieren.
Für die Aktivierung der Job-Schedules ist gemäss Deployment Guide folgendes Vorgehen nötig:
- Auf dem Data Warehouse Management Server eine Powershell mit administrativen Rechten starten:
- Zuerst das Kommando „Add-PSSnapIn SMCmdletSnapIn“ ausführen
- dann nötigenfalls das Kommando „Set-ExecutionPolicy RemoteSigned“ absetzen
- dann folgende 4 Befehle ausführen:
Enable-SCDWJobSchedule –JobName Extract_<data warehouse management group name>
Enable-SCDWJobSchedule –JobName Extract_<Service Manager management group name>
Enable-SCDWJobSchedule –JobName Transform
Enable-SCDWJobSchedule –JobName Load
Damit sind wir nun endlich durch und die Registration des Data Warehouse ist abgeschlossen.
Lessons learnt – Gelernte Lektionen
Zusammenfassend kann ich folgende Punkte festhalten, die man unbedingt beachten sollte, damit die Registration des Data Warehouse am Service Manager reibungslos ablaufen kann:
- Der TCP-Port 5724 muss in der Windows-Firewall auf allen beteiligten Service Manager Servern geöffnet sein, damit diese miteinander kommunizieren können.
- Das vorgeschlagene Konto „<Management Group Name> SecureReference“, das vom „Data Warehouse Registration Wizard“ vorgeschlagen wird, müsste grundsätzlich ausreichen. Denn als ich mal zufälligerweise auch in den Bereich „Data Warehouse“, „Security“, „Run As Accounts“ einen Blick riskierte, habe ich dort dieses Konto entdeckt: Es verwendet nämlich exakt dasselbe AD-Konto, welches ich im zusätzlich erstellten „Operational System Account“ angegeben habe. Da war der Wizard wieder mal schlauer als ich. 🙂
- Die Regional Settings und das „System Locale“ sollten (zumindest noch jetzt bei der Beta 2) auf „English (United States)“ gesetzt sein; dies kann eine Menge Probleme ersparen…
Abgelegt unter: Anleitungen | Tags: Alert, Connector, Konfiguration, SCOM, SCSM
Als erste Tat im neuen Jahr will ich nun den System Center Operations Manager an den Service Manager ankoppeln.
Notwendige Vorbereitungen
Einmal mehr hilft mir dabei ein Blogeintrag der belgischen System Center User Group. Sie weisen darauf hin, dass das benötigte Connector Account ein Domänenkonto sein muss, das Mitglied in der lokalen Gruppe „Users“ auf dem Service Management und zugleich ein Operations Manager Administrator sein müsse.
Ich erstelle deshalb zuerst einmal ein passendes Service Account im Active Directory, das ich sogleich zum Operations Manager Admin befördere und sogleich auch auf dem Service Manager Management Server in die Gruppe „Users“ aufnehme. Somit sollten die Prerequisites bereits erfüllt sein.
Erstellen des Connectors
Ich wechsle nun auf den Service Manager. In der Konsole navigiere ich unter „Administration“ zu „Connectors“ und klicke auf „Create Connector“ und wähle „Operations Manager Alert Connector“, worauf der entsprechende Wizard startet und mir seine Begrüssungsseite zeigt. 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 dem Namen des Operations Manager Servers gefragt, den ich passend eintrage. Im Bereich „Credentials“ klicke ich wieder – wie beim SCCM Connector – beim „Run as Account“ auf „New…“, um das passende „Run As Account“ zu erstellen. Als „Display Name“ wähle ich „SCOM Connector Account“, trage eine passende Beschreibung ein und ergänze die entsprechenden Angaben zum AD-Konto. Ein Klick auf „OK“ und auch dieses Konto ist als „Run As“-Konto definiert. Es folgt der übliche Klick auf „Test Connection“, der mit der erfreulichen Meldung „The connection to the server was successful“ bestätigt wird.
Auf der nächsten Seite des Assistenten muss ich nun die „Alert Routing Rules“ definieren. Auch hier hilft mir der Blogeintrag der belgischen System Center User Group weiter: Sie schreiben, dass hier nur Einstellungen gemacht werden müssen, wenn man spezifische Templates für bestimmte Alerts haben will; ansonsten könne man hier die Liste leer lassen, dann würden alle Alarme das standardmässige „Operations Manager Incident Template“ benutzen. Das tönt doch schon mal gut; also ein Klick auf „Next“.
Die nächste Seite des Wizards widmet sich dem „Schedule“. Standardmässig wird vorgeschlagen, dass Alarmmeldungen alle 30 Sekunden abgeholt werden sollen. Da ich im Moment keinen Grund sehe, weshalb das eine völlig unpassende Voreinstellung sein sollte, übernehme ich diese mal direkt. Die beiden Checkboxen „Close alerts in Operations Manager when incidents are resolved or closed“ und „Resolve incidents automatically when the alerts in Operations Manager are closed“ hingegen finde ich noch sehr interessant. Da ich der Meinung bin, dass es jeweils im anderen System nachgeführt werden soll, wenn im einen System ein Problem als gelöst bezeichnet wird, aktiviere ich mal beide Checkboxen und klicke ein weiteres Mal auf „Next“.
Nun wird mir noch die Summary-Seite angezeigt; hier klicke ich sogleich auf „Create“. Mit der Bestätigung, dass der Wizard erfolgreich abgeschlossen wurde, ist der erste Teil der Erstellung des Connectors zu SCOM nun abgeschlossen.
Aktivierung der Subskription
Der nächste Teil muss nun mit der Operations Manager Konsole für den Root Management Server durchgeführt werden. Hier öffne ich den Abschnitt „Administration“ und navigiere zu „Product Connectors“, „Internal Connectors“. Hier finde ich in der Liste den soeben erstellten Connector. Ich wähle diesen aus und klicke ihn mit der rechten Maustaste an, um den Dialog „Properties“ zu öffnen.
Die Liste der Subscription ist noch leer, deshalb klicke ich auf „Add“, womit sich der „Product Connector Subscription Wizard“ öffnet. Dieser fragt zuerst mal nach einem Subscription-Namen und einer Beschreibung, die ich passend eintrage und dann auf „Next“ klicke. Im nächsten Dialogfenster kann ich wählen, für welche Operations Manager Gruppen die Alarme an den Service Manager übermittelt werden sollen. Ich wähle mal hier die Voreinstellung, dass ich alle Alarme übermittelt haben möchte. Im nächsten Schritt kann ich nun noch angeben, von welchen Targets die Alarme übermittelt werden sollen; auch hier wähle ich die Voreinstellungen, dass alle Alarme übermittelt werden sollen, auch diejenigen von Targets von Management Packs, welche erst in Zukunft importiert werden. Im letzten Schritt dieses Wizards können noch Kriterien definiert werden: Auch hier entscheide ich mich mal für die Vorgabewerte: Nur „Errors“, aber keine „Warnings“ oder „Informations“, nur die Prioritäten „High“ und „Medium“, aber nicht „Low“, sowie alle „Resolution States“ und alle Kategorien. Mit dem abschliessenden Klick auf „Create“ wird die Subskription erstellt.
Da die neu erstellte Subscription nun in der Liste erscheint, kann der „Properties“-Dialog wieder geschlossen werden, womit die notwendigen Konfigurationsarbeiten in der SCOM-Konsole abgeschlossen sind.
Überprüfung in der Service Manager Konsole
In der Service Manager Konsole navigiere ich nun zu „Work Items“, „Incident Management“, „All Open OM Incidents“. Die dortige Liste ist leer. Aber auch im Operations Manager sind keine Alarme zu finden.
Ich wage daher einen kurzen Test, für den ein Domänenkontroller herhalten muss, dessen DNS-Service nicht von unseren Clients her verwendet wird. Kurzerhand stoppe ich den DNS-Server-Dienst auf diesem Server, was wenige Sekunden später entsprechende SCOM-Alarme zur Folge hat. Gespannt schaue ich auf die Service Manager Konsole. Tatsächlich: nach wenigen Sekunden werden auch dort die entsprechenden Alarme aufgelistet.
Operations Manager Alarm in der SCSM-Konsole
Erfreut darüber, dass auch dies wunschgemäss funktioniert, starte ich den DNS-Server-Dienst auf dem Domänenkontroller wieder, worauf kurz darauf SCOM die entsprechenden Alarme schliesst. Kurze Zeit verschwinden auch im Service Manager die beiden Incidents aus der Ansicht „All Open OM Incidents“. Ich wechsle auf die Ansicht „All Incidents“; hier sind die beiden Incidents wieder zu sehen, allerdings mit dem Status „Resolved“. Wenn das kein gelungener Start ins neue Jahr ist…
Abgelegt unter: Anleitungen | Tags: Connector, Installation, SCCM, SCSM
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…
Abgelegt unter: Anleitungen | Tags: AD, Connector, Konfiguration, SCSM
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.
Abgelegt unter: Anleitungen | Tags: Installation, Reporting Services, SCOM, SCSM, SQL Server
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.
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.
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