In meinem letzten Beitrag habe ich beschrieben, wie man am einfachsten bestimmte SCCM-Logfiles finden kann. Wenn man derartige Logfiles mit dem Editor (notepad.exe) öffnet, dann schaut das ganze schon ziemlich übersichtlich aus:
Protokollausschnitt, angezeigt mit notepad.exe
Zum Glück gibt es jedoch ein äusserst hilfreiches Werkzeug namens „trace32.exe“, das jedem SCCM-Administrator bekannt sein sollte. Trace32.exe ist Bestandteil des „System Center Configuration Manager 2007 Toolkit„. Damit wird das Logfile schon deutlich lesbarer:
Derselbe Protokollausschnitt, angezeigt mit Trace32.exe
Wie das Bild zeigt, lassen sich mit Trace32 mit der Funktion „Highlight“ beliebige Texte hervorheben. Es reicht dazu aus, den gewünschten Suchtext im Dialogfenster einzutragen und schon werden auch in einer langen Protokolldatei alle Zeilen hervorgehoben, welche den entsprechenden Suchtext enthalten. Ob nun nach irgendeinem Fehlercode, einer bestimmten Paketnummer oder einer sonstigen Zeichenkette gesucht werden soll, bleibt den Bedürfnissen des Administrators überlassen.
Ebenso können im Öffnen von Protokolldateien mehrere Protokolle auf einmal gewählt werden und diese dann mit der Option „Merge selected files“ zusammengeführt werden. Das ist inbesondere dann hilfreich, wenn z.B. an einem Vorgang mehrere SCCM-Komponenten beteiligt sind und man so eine konsolidierte Ansicht erhalten kann.
Mit Trace32.exe können jedoch nicht nur nachträglich irgendwelche Protokolle angeschaut werden. Da Trace32.exe die Ansicht nachführt, sobald neue Protokolleinträge geschrieben werden, wird es auch möglich, Vorgänge in Echtzeit mitzuverfolgen. Wer sich also schon immer gefragt hat, was sein SCCM-Siteserver zur Zeit gerade macht, kann die entsprechenden Protokolle mit trace32.exe öffnen. So erhält man sofort einen guten Einblick, ob beispielsweise das Paket LAB0013C nun tatsächlich auf die Distribution Points verteilt wird, oder ob dies – wie im obigen Beispiel ersichtlich – immer noch fehlschlägt, ohne dass gewartet werden muss, bis die entsprechende Fehlermeldung in der Konsole sichtbar wird.
Sieht man nun eine entsprechenden Eintrag im Protokoll, für den man sich besonders interessiert, und klickt diesen an, um diesen in voller Länge im unteren Detailfenster lesen zu können, hält die automatische Verfolgung sogleich an. Gerade wenn die betreffende Komponente sehr aktiv ist, kann man dann schön sehen, wie der Scrollbalken am rechten Fensterrand immer weiter nach oben rutscht, da unten immer weitere Einträge hinzugefügt werden.
Hat man den Detaileintrag fertig gelesen (und vielleicht auch wegkopiert), möchte man vielleicht gerne wieder ans Ende des Protokolles springen und vor allem auch die automatische Verfolgung wieder aktivieren. Klar: man kann den Scrollbalken nach unten ziehen und sieht dann den neuesten Eintrag, doch die Nachverfolgung wird so nicht wieder aktiviert. Doch einen entsprechenden Menübefehl sucht man vergebens…
Dabei ist es so einfach: Tastenkombination „Ctrl-End“ drücken und schon läuft die Anzeige wieder weiter!
Wenn ich mit dem System Center Configuration Manager arbeite, werfe ich immer mal wieder einen Blick in den „Site Status“. Und leider kommt es immer wieder vor, dass ich dort nicht nur grüne Häckchen, sondern auch gelbe Ausrufezeichen oder sogar rote Kreuze bei einer oder mehreren Komponenten sehe.
Werde ich aus den entsprechenden Status Messages nicht gleich schlau, möchte ich mal schnell einen Blick in die dazugehörende Protokolldatei werfen. Doch welches der unzähligen Logfiles gehört nun tatsächlich zur betreffenden Komponente? Hinter welchem kryptischen Dateinamen verbirgt sich das gesuchte Protokoll? Ist das nun ciamgr.log oder aikbmgr.log oder gar cscnfsvc.log? Und wo ist das gesuchte Protokoll auf dem betroffenen Server noch gleich zu finden?
Hier gibts einen kleinen Trick, den mir vor einiger Zeit mal ein Microsoft Premier Field Engineer gezeigt hat:
- Klappe den untersten Punkt „Tools“ in der SCCM-Konsole auf
- Starte den „ConfigMgr Service Manager“
- Suche die betroffene Komponente in der Liste
- Klicke diese mit der rechten Maustaste an und wähle „Logging…“
Und siehe da: hier steht der komplette Pfad mitsamt Name der gesuchten Protokolldatei!
Abgelegt unter: Tipps & Tricks | Tags: ActiveDirectory, AD, MMC, Organisationseinheit, OU
Heute meldete sich ein Administrator-Kollege bei mir mit dem Problem, dass er eine OU verschieben möchte, dabei aber immer folgende Fehlermeldung erhalte:
Active Directory-Domänendienste:
Das Objekt <Name der OU> konnte aufgrund folgenden Problems nicht verschoben werden:
Zugriff verweigert
„Ich habe wohl nicht alle benötigten Rechte dazu“, meinte er lakonisch. Doch auch als ich als Domänen- (bzw. sogar Enterprise-)Administrator die OU verschieben wollte, durfte ich dieselbe Fehlermeldung auf meinem Bildschirm bewundern…
Dabei ist des Rätsels Lösung ganz einfach: Zum Verschieben einer OU benötigt man das Löschrecht am Ausgangsort und das Schreibrecht am Zielort.
Seit dem Windows Server 2008 existiert die Option „Objekt vor zufälligem Löschen schützen“ (engl: „Protect object from accidental deletion“), die in der Management-Konsole „Active Directory Benutzer und -Computer“ erst dann sichtbar wird, wenn die Option „Erweiterte Features“ (zu finden im Menü „Ansicht“) aktiviert wurde. Diese Option wird standardmässig auf Organisationseinheiten gesetzt und bewirkt nichts anderes, als dass in den Sicherheitseinstellungen das Recht „Löschen“ der Gruppe „Jeder“ verweigert wird. Da eine explizite „Verweigerung“ eines Rechtes alle erteilten Zugriffsrechte wirkungslos macht, kann auch ein Domänen-Administrator eine so geschützte OU nicht löschen, bis er das entsprechende Häckchen entfernt.
Und nun müsste auch klar sein, weshalb sich eine OU nicht einfach so verschieben lässt: Das benötigte Löschrecht am Ausgangsort fehlt, da dieses von der Option „Objekt vor zufälligem Löschen schützen“ verweigert wird.
Und so muss das Häckchen bei „Objekt vor zufälligem Löschen schützen“ auch dann entfernt werden, wenn die OU verschoben werden soll.
Mit Vorteil setzt man das besagte Häckchen nach erfolgter Verschiebung am Zielort wieder neu, damit der Schutz vor versehentlichem Löschen wieder gegeben ist.
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: 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: Der gelöste Fall | Tags: Acer, AirportExpress, Apple, AR5007EG, Aspire, Atheros, Netzwerkproblem
Kürzlich wurde ich mit einem weiteren skurrilen Problem konfrontiert. Dabei handelte sich sich um ein Acer Aspire 5100 Notebook, das die Internetverbindung per Wireless LAN über einen Apple Airport Express herstellen sollte.
Am Anfang klappte alles wunschgemäss: Das gewünschte WLAN wurde in der Suche nach Drahtlosnetzwerken angezeigt und nach dem Klick auf „Verbinden“ wurde nach dem notwendigen WPA2-Preshared-Key gefragt. Der Key wurde problemlos akzeptiert und kurz darauf wurde auch bestätigt, dass die Verbindung erfolgreich hergestellt werden konnte.
Doch was sollte denn das? Das auf diesem Notebook installierte Vista behauptete stur, es hätte nur lokalen Netzwerkzugriff! Internetzugriff? Weit gefehlt…
Die Netzwerkdiagnose von Windows hatte einzig zu vermelden, dass ein „Problem mit dem Netzwerkrouter oder Breitbandmodem“ die Internetverbindung möglicherweise verhindere. Doch dass der Apple Airport Express einwandfrei konfiguriert war und problemlos funktionierte, bewies ein weiterer Zugriffsversuch mit einem anderen Notebook und einem iPhone.
Als ich dann das übliche „ipconfig /all“ in einem CMD-Fenster ausführte, schien alles in Ordnung zu sein: Das Adresse bezog eine passende IP-Adresse per DHCP, DNS-Server und Standardgateway waren ebenfalls i.O. Der Ping auf die eigene IP-Adresse wurde einwandfrei beantwortet und der Ping auf den Airport… ähhh „Destination host unreachable“?
Da kommunizierte also das Gerät „einwandfrei“ mit der Airport-Basisstation und bezog per DHCP eine passende IP-Adresse mitsamt den korrekten übrigen Settings und wollte daraufhin trotzdem nicht mehr kommunizieren?
Nun ja: „Skurrile Probleme“ rund um die Hardware schreien üblicherweise danach, dass man mal den entsprechenden Treiber unter die Lupe nimmt. So besuchte ich die Acer Webseite und lud von dort den für das Acer Aspire 5100 angebotenen „Atheros Wireless LAN Treiber“ 7.1.0.90 (vom 05.12.2008) herunter und installierte diesen. Leider Fehlanzeige… Auch der neue Treiber brachte keinerlei Verbesserung.
Da das betreffende WLAN-Modul von Atheros stammte, suchte ich im Internet nach diesem Hersteller. Und siehe da: Auf dessen Webseite http://www.atheros.cz/ fand ich einen weiteren, neuen Treiber (Version 7.7.0.331 vom 12.06.2009) für das von Acer verbaute Modul Atheros AR5007EG.
Ich lud diesen Treiber herunter und startete dessen Installation. Ergebnis: Da ich auf dem Notebook das vom Apple Airport Express bereitgestellte WLAN bereits als bevorzugtes Netzwerk konfiguriert hatte, war das Gerät schneller online als die Treiberinstallation Erfolg vermelden konnte.
Fazit: Neue Treiber können etliche Probleme beseitigen. Doch nicht immer findet man diese auf der Webseite des Herstellers des PC/Notebook. Es kann sich lohnen, auch direkt beim Hersteller der jeweigen Gerätekomponenten nach Treibern zu suchen…
Abgelegt unter: Der gelöste Fall | Tags: AAWService.exe, AdAware, CPULoad, ProcessExplorer, Sysinternals
Kürzlich wurde ich mit einem Notebook konfrontiert, dessen Besitzer am Verzweifeln war: „Das Notebook sei schlicht und einfach nicht mehr benutzbar“, lautete der lapidare Hilferuf. Obwohl ich derart schwammige Problemmeldungen keineswegs schätze, habe ich mir das betroffene Gerät angeschaut:
Nach dem Einschalten des Notebooks startete das installierte Vista Home Premium im gewohnten Tempo und der Benutzer meldete sich an, sobald der Anmeldedialog erschien. Soweit war noch alles in Ordnung. Doch unmittelbar nach dem Erscheinen des Desktops wurde das System unerträglich langsam und fror nahezu ein. Es gelang mir noch, den Taskmanager zu starten; dieser zeigte 100% CPU-Auslastung an. Kurz darauf wurde das System dermassen langsam, dass im Taskmanager nicht einmal mehr die Prozesslisten, geschweige denn die Grafiken zum Verlauf der CPU-Auslastung aktualisiert wurden. Zudem lief der Lüfter des Gerätes auf vollen Touren.
Nach etlichen Minuten Wartezeit wurde der Taskmanager zwar wieder etwas lebendig und begann seine Ansicht wieder zu aktualisieren, aber unter einer „benutzbaren Applikation“ stelle ich mir etwas anderes vor. Die CPU-Last blieb unverändert bei 100%.
In der Benutzer-Ansicht des Taskmanager waren nur Prozesse zu sehen, die kaum CPU-Last produzierten. Die Ursache für die hohe CPU-Last musste deshalb anderswo liegen, weshalb ich auf den Knopf „Prozesse aller Benutzer anzeigen“ klickte. Es dauerte weitere vier bis fünf Minuten, bis sich die Anzeige dunkel verfärbte und nochmals geraume Zeit, bis ich den Dialog der Benutzerkontensteuerung (UAC) abnicken konnte. Doch trotz weiterer unzähliger Minuten Wartezeit erschien der Taskmanager mit der Ansicht aller Prozesse nicht.
Es gelang mir aber, von einem USB-Stick den „Process Explorer“ der Sysinternals-Suite zu starten. Hier konnte ich sogleich in der Anzeige erkennen, dass ein Prozess namens „AAWService.exe“ für die immense CPU-Last verantwortlich war. Der Rechtsklick auf den entsprechenden Eintrag mit anschliessendem „Kill Process“ wurde jedoch sogleich mit „Zugriff verweigert“ quittiert.
Eine kurze Recherche bei Google förderte zu Tage, dass es sich bei AAWService.exe um den Dienst der Software „Ad-Aware“ von Lavasoft handelt. Ich öffnete deshalb die Konsole der Dienste-Verwaltung und suchte dort nach dem Dienst „Lavasoft Ad-Aware Service“. Und siehe da: Dessen Status war auch noch nach weit über 30 Minuten nach dem Systemstart immer noch auf „wird gestartet“. Mit viel Geduld gelang es mir, den Starttyp des Dienstes auf „manuell“ zu setzen, worauf ich das Gerät neu startete.
Nach dem Neustart reagierte das System wieder in normaler Geschwindigkeit, weshalb ich anschliessend – in Rücksprache mit dem Benutzer – die Ad-Aware-Software komplett deinstallierte. Auch der Task-Manager liess sich dann wieder wie gewohnt in die Ansicht „Prozesse aller Benutzer anzeigen“ umschalten…
Weshalb die Ad-Aware-Software Amok lief, ist mir nicht bekannt; für eine Suche nach der tieferen Ursache dieses Problems fehlt mir sowohl die Zeit als auch die Lust.
Fazit: Sündenbock dank „Process Explorer“ gefunden. Herzlichen Dank an Mark Russinovich für die Sysinternals-Tools!
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…