Abgelegt unter: Erkenntnisse | Tags: Alert, ConsolidationRule, ManagementPack, SCCM, SCOM
Schon vor längerer Zeit habe ich einmal in unsere SCOM-Installation das „Microsoft System Center Configuration Manager 2007 SP2 Management Pack for Microsoft System Center Operations Manager 2007 R2“ (Version 6.0.6000.2) importiert, um damit unsere Configuration Manager Umgebung zu überwachen. Denn wieso soll ich z.B. regelmässig selber manuell den Site Status unserer Sites kontrollieren, wenn das der Operations Manager für mich tun kann?
Doch an diesem Management-Pack hatte ich keine Freude. Zwar funktionierte die Erkennung von Fehlern recht zuverlässig:
- Ein Paket konnte nicht auf einen Distribution Point bereitgestellt werden. Alert von SCOM!
- Ein Site Backup konnte nicht erstellt werden. Alert von SCOM!
- Der SMS Executive crashte auf einem Server. Alert von SCOM!
- usw.
Die entsprechenden Fehler wurden behoben und die Alerts geschlossen. Alles bestens, oder?
Nein, leider nicht ganz, denn kurz darauf:
- Alert von SCOM: Ein Paket konnte nicht auf einem Distribution Point bereitgestellt werden!
- Alert von SCOM: Ein Site Backup konnte nicht erstellt werden!
- Alert von SCOM: Der SMS Executive crashte auf einem Server!
- usw.
Was schon wieder? Tatsächlich: SCOM rapportierte dieselben Ereignisse nochmals. Ja, exakt „dieselben Ereignisse“ nochmals, obwohl der Fehler längst behoben war! Egal, wieviele Male man die betreffenden Alerts schloss, kurz darauf waren sie wieder erneut da. Dies natürlich immer mitsamt Generierung der entsprechenden Alert-Mails usw. Erst am Tag darauf kehrte wieder Ruhe ein.
Vor allem als uns etwa vor einem Monat die Verbindung zum Datenbankserver tauchte, herrschte nachher reger Mailverkehr in meiner Mailbox. Und die SCOM-Konsole war komplett unübersichtlich: Unzählige Alerts wurden da aufgelistet und man verlor völlig den Ãœberblick. Und egal wieviele Male man diese Alerts schloss, um wieder eine aufgeräumte Konsole zu erhalten, füllte sich diese innert weniger Minuten erneut. Und die Mailbox dazu…
Ich war kurz davor, das Management-Pack wegen „völliger Unbrauchbarkeit“ zu entsorgen. Und dann las ich den Blogbeitrag „Want to drastically quiet down your ConfigMgr 2007 MP?“ von Kevin Holman, publiziert am 1. September 2010.
Dieser Blogbeitrag beschreibt genau dieses Phänomen und nennt die Ursache dieser wiederholten Alarme. So schreibt Kevin Holman über die sog. „Consolidation Rules“, die noch von MOM 2005 her stammen:
„What happens is – this consolidation rule causes the alert to continuously repeat, even if the status message is no longer in the database! If you resolve the condition, close the alert, the alert will be regenerated within a few minutes from the Healthservice that loaded this converted consolidation rule. The purpose behind these consolidation rules was to control a burst of status messages that occur within a short period of time. However – they aren’t working as designed today, and furthermore are the cause of the massive repeat counts and re-alerting on old conditions.“
Kevin Holman nennt dann auch die simple Lösung für das Problem: „Consolidation Rules“ deaktivieren! Und netterweise liefert er auch mit seinem Beitrag noch ein „Addendum Management Pack“ mit, das genau diese Aufgabe übernimmt.
Tatsächlich: Seit ich dieses (in seinem Blogbeitrag verlinkte) „Addendum Management Pack“ importiert habe, funktioniert die Ãœberwachung genau so wie ich mir das vorstelle:
- Problem in SCCM, Alert in SCOM
- SCCM-Problem gefixt, SCOM-Alert geschlossen.
- Problem doch nicht erfolgreich gefixt, Alert wieder da…
- SCCM-Problem erfolgreich gefixt. Kein erneuter Alert mehr.
Mit dem „Addendum Management Pack“ von Kevin Holman wird das „SCCM 2007 SP2 Management Pack“ tatsächlich brauchbar!
Thank you very much, Mr. Holman!
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: 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: 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.