Home - Blogs - Displaying items by tag: System Center
Displaying items by tag: System Center
Tuesday, 11 September 2012 10:39

System Center 2012 SP1 Beta vefügbar

Die Beta Version des Service Pack 1 für System Center 2012 ist verfügbar.

System Center 2012 SP1 beta unterstützt Windows Server 2012.

Informationen und Support können hier (http://technet.microsoft.com/en-us/library/jj628191) eingesehen und die einzelnen Komponenten hier (http://www.microsoft.com/en-us/download/details.aspx?id=34607) heruntergeladen werden.

Published in MS Allgemein

Das Update Rollup 2 für Microsoft System Center 2012 ist verfügbar. Details zu dem Update Rollup 2 for Microsoft System Center 2012 finden Sie in der Microsoft Technet (http://support.microsoft.com/kb/2706783/en-us).

Published in MS Allgemein

In der neusten Version des Basis Operating System Management Packs für den Operations Manager 2007 und 2012 gibt es einige wichtige Änderungen in Bezug auf die Plattenüberwachung.

Neben dem bisher existierenden Monitor, in dem sowohl der prozentuale wie auch der absolute Schwellwert erreicht werden musste bevor ein Alarm erzeugt wird, gibt es nun 2 neue Monitore:

 NewOSMP1

Diese sind "by Default" ausgeschaltet und müssen entsprechend durch einen Override aktiviert werden. Der bisher vorhandene Monitor sollte vorher ausgeschaltet werden, da sonst eine doppelte Überwachung stattfindet.

Neben den neue Monitoren werden in dem Management Pack nun 3 unterschiedliche Plattenarten erkannt und überwacht:

  • Logical Disks -> Platten die nicht in einem Cluster enthalten sind und einen Laufwerksbuchstaben haben oder nicht (werden dann als Mounted Disks angezeigt)
  • Cluster Disks -> sind shared Resourcen in einem MS Cluster
  • Shared Volumes -> spezielle Cluster Disks die von einem Hyper-V Cluster benutzt werden

 Nachdem ich die neue Version eingespielt und die beiden neuen Plattenplatz Monitore aktiviert hatte, erhielt ich Alarme für die 100MB Partitionen, die bei neueren Windows Server automatisch angelegt werden:

NewOSMP2

Diese Laufwerke waren zuvor schon in der Umgebung erkannt und ich wollte sie nun löschen. Unter SCOM 2007 benutzt man dazu das CMDLET Remove-DisabledMonitoringObject, unter 2012 Remove-DisabledClassInstance.

Obwohl der Discovery Job für die Mounted Disks by Default ausgeschaltet ist, wurden die Objekte aber nicht gelöscht:

NewOSMP3

Erst nachdem ich einen zusätzlichen Override auf diesen Discovery Job definiert hatte, wurden die Objekte erfolgreich gelöscht:

NewOSMP4

Weitere Infos findet man wie gewohnt bei Kevin Holman, das Management Pack kann hier runtergeladen werden.

Published in Operations Manager

In diesem Beitrag möchte ich ein paar Infos zum Thema Resource Pools im Bezug auf das Netzwerkmonitoring mit SCOM 2012 geben.

Es gibt eine klare Empfehlung seitens Microsoft, daß für das Netzwerkmonitoring ein eigener Resource Pool angelegt werden soll. In diesem Pool sollten nur Management Server bzw. Gateway Server enthalten sein, die keinem anderen Pool zugeordnet sind.

Das Erstellen eines neuen Pools ist sehr einfach:

WebInfosRPT2 bild1 

Die Server des neuen Pools sollten nun noch aus den anderen Resource Pools entfernt werden. Damit dies möglich ist, muss der entsprechende Pool auf "Manual Membership" umgestellt werden.
Dies geht für fast alle System Pools direkt in der Console:

WebInfosRPT2 bild2 

 

Lediglich für den "All Management Servers Resource Pool" ist das nicht möglich. Für diesen Pool kann man die Umstellung via Powershell Kommando durchführen:

Get-SCOMResourcePool –Name “All Management Servers Resource Pool” | Set-SCOMResourcePool –EnableAutomaticMembership $FALSE 

 

WICHTIG: Nach der Umstellung der Pools werden neu installierte Management Server nicht mehr automatisch den System Pools zugeordnet. Dies muss manual durch einen Administrator erfolgen.

 

Nachdem der Resource Pool erstellt wurde, wird eine entsprechende Discovery Rule erstellt. Dabei gilt:

  • Jedem Management oder Gateway Server kann genau eine Discovery Rule zugeordnet werden
  • Die Überwachung der Devices, die durch eine Rule gefunden werden, erfolgt durch den zur Rule angegebenen Resource Pool
  • Sollten mehr als eine Discovery Rule nötig sein, so sollte jeweils ein eigener Pool erstellt werden
  • Jedes Netzwerkdevice sollte nur von einem Pool überwacht werden. Ist dies nicht der Fall, kann das Gerät nicht aus dem Operations Manager entfernt werden

 

Weitere Infos über das Thema Resource Pools folgen ...

 

Published in Operations Manager
Wednesday, 25 April 2012 21:05

SCOM 2012 - Infos zu Resource Pools - Teil 1

Allgemein bekannt ist die Tatsache, das mit dem System Center Operations Manager 2012 der Root Management Server der Vergangenheit angehört. Für alle Monitore und Rules, die als Target den RMS hatten, gibt es nun die RMS Emulator Rolle.

Neu sind nun die Management Server Resource Pools, in denen verschiedene Management Server gleichberechtigt in einer Gruppe ihren Dienst erledigen. Ich möchte an dieser Stelle meine ersten Erfahrungen und Erkenntnissen mit den neuen Pools und deren Besonderheiten ansprechen.

Fakt 1: Obwohl nun auf allen Management Servern die vom RMS bekannten 3 Dienste laufen (Data Access, Management Configuration und System Center Management), bezieht sich aktuell die Pool-Funktionalität lediglich auf den Health Service.

Auswirkung 1: Eine Console verbindet sich nicht mit einem Pool, sondern per Zufall mit einem der SDK Dienste eines Management Servers. Will man hier einen Failover oder eine Lastverteilung einrichten, so ist das NLB (Network Load Balancer) Feature die Lösung. Damit kann man einen virtuellen Namen für die Consolen Anmeldung vergeben und dahinter verbergen sich die im Cluster eingetragenen Management Server.

NLB

Auswirkung 2: Auch die Agenten kann man nicht mit einem Pool verbinden. Diese werden wie unter SCOM 2007 R2 konfiguriert. Entweder über die Active Directory Integration oder mit einem primären MS und ein oder mehreren Failover Servern.

Auswirkung 3: Durch die verstärkte Kommunikation zwischen den Management Servern gibt es seitens der SCOM 2012 Produktgruppe die Vorgabe, dass die Latenz Zeit zwischen den MS Rechner maximal 5 ms betragen darf. Hat man im Moment in dezentralen Standorten einen MS stehen, so sollte dieser in das zentrale RZ umgezogen und durch ein Gateway ersetzt werden.

 

Weitere Infos über das Thema Resource Pools folgen ...

Published in Operations Manager

Bei der Aktualisierung meiner SCOM 2007 R2 Umgebungen bin ich beim Upgrade des RMS auf die folgende Fehlermeldung gelaufen:

UgradeFehlerSQLPort

 

Das Problem besteht darin, dass die Operationsmanager Datenbank wie auch die Datwarehouse Datenbank auf einem extra SQL Server liegen:

Server1: RMS
Server2: Default SQL Instanz -> OpsMgrDB - Port 11433
Server2: SCOMDW Instanz -> OpsMgrDW - Port 12433

Leider gibt es keine Möglichkeit, dem Update diese Informationen mitzugeben.

Ein Lösung besteht darin, für die beiden Datenbanken eine ODBC Verbindung mit den notwendigen Client Einstellungen auf dem RMS anzulegen:

 ODBC SCOMDB

ODBC SCOMDW

 Danach lief der Update auf 2012 RC ohne Probleme durch.

Published in Operations Manager

Mit der Installation eines SCOM 2012 Agenten wird auf einem System nun ebenfalls ein kleines grafisches Konfigurationstool installiert. Mit diesem Tool hat man die folgenden Möglichkeiten:

  • den Agenten zu einer weiteren Management Gruppe hinzufügen
  • den Agenten aus einer Management Gruppe entfernen
  • die Active Directory Integration ein- bzw. auszuschalten
  • den "Local Action Account" für den Agenten ändern

Zu finden ist das Tool nach einer Agenteninstallation unter "Systemsteuerung/System und Sicherheit" (bzw. "Control Panel/System and Security"):

OpertationsManagerAgent

 

Nach dem Start des erhält man eine Liste der Management Gruppen, mit denen der Agent verbunden ist:

AgentManagementGroups

Über Add / Remove kann eine weitere Management Gruppe hinzugefügt werden bzw. ein vorhandene gelöscht werden.

Wird eine Gruppe in der Liste markiert, so erhält man mit der Edit-Funktion einen Dialog, in dem der lokale Action Account eingestellt werden kann. Damit gibt es nun ein sehr schöne Möglichkeit für einen Systemadministrator, spezielle Benutzerdaten für den Agenten zu setzen, ohne auf die Hilfe der SCOM Administratoren angewiesen zu sein:

LocalActionAccount

Zusammenfassend bleibt zu sagen, dass dieses kleine Tool ein weiterer postiver Schritt in Punkto Benutzerfreundlichkeit darstellt.

 

Published in Operations Manager


scom_logo


Manchmal kommt es vor, dass man nicht alle Applikationen/Services auf einzelnen Systemen überwachen möchte. Um nicht alle Regeln und Monitore dieser Applikation per Override deaktivieren zu müssen, sollte man das Discovery auf diesen Systemen deaktivieren.

Zunächst muss man das Objekt Discovery der enstprechenden Applikation für das Zielobjekt  (oder einer Gruppe von Zielobjekten) per disable Override deaktivieren.

Was mache ich aber, wenn das Zielobjekt bereits discovered wurde?

In diesem Fall kann man per Powershell über das remove_disabledmonitoringobject Kommando die Objekte, für die das Discovery deaktiviert wurde, wieder löschen.

Syntax des Kommandos
http://technet.microsoft.com/en-us/library/gg132269.aspx

 

Published in Operations Manager
Thursday, 16 June 2011 17:45

Neue Begriffe in Orchestrator 2012

SCO_gross

Bei dem heutigen Kick-Off für das "Orchestrator 2012 Beta CEP"-Programm wurden weitere Details für den künftigen Opalis-Nachfolger veröffentlicht:

  • Installations-Dateien und VHDs der Orchestrator 2012 Beta werden ab 17.06.2011 verfügbar sein.
  • Die Workflows die Sie unter Opalis unter dem Namen "Policies" kennen, werden in Orchestrator als "Runbooks" bezeichnet
  • Die "Objects" von Opalis werden zu "Activities"  in Orchestrator.

Heute wurde wieder darauf hingewiesen, dass die Struktur und das Design von Workflows von Orchestrator gegenüber Opalis weitgehend gleich bleibt. Es wird zudem eine technische Upgrade-Möglichkeit Ihrer Opalis Policies zu Orchestrator Run Books geben.

Published in Orchestrator (Opalis)
vaserv_blogSystem Center Orchestrator ist der neue Name für Microsoft Opalis und fügt sich nun auch nahtlos in die System Center Namensgebung ein. Es sind mit dem neuen Namen auch neue Features und Funktionen inbegriffen, welche die vNext Version in der kommenden System Center 2012 Suite mit sich bringt. Die wichtigsten sind bereits im MS System Center Blog angekündigt worden:

  • IT Pro- Authoring, Debugging & Scripting
    The Opalis product will be rebranded to System Center Orchestrator. We are working very hard to ensure that your existing investments in Opalis are maintained.
    A new PowerShell provider to allow Orchestrator to be integrated into scripts and provide a mechanism for remote execution of runbooks.
  • Operator- Trigger, Monitor &Troubleshoot
    A new silverlight based dynamic web console to provide an easy way to start, monitor and investigate runbooks.
  • Developer- Application integration
    A new rich OData based web service that exposes Orchestrator functionality and information in a standards based way.
  • IT Business Manager- Report & Analyze A new mechanism for connecting your existing reporting investments to Orchestrator to extract, report and analyze what is happening inside Orchestrator.

In addition to the above investment areas, we are also completing a number of ‘housekeeping’ functions:

  • A new Installer experience
  • An Orchestrator Management Pack for Operations Manager
  • Globalization of the Orchestrator release (Localization will follow in a future release)
  • Updated versions of the Integration Packs, both for System Center as well as a number of the 3rd Party IP’s

(Quelle: System Center Blog)

Sehr spannend wird aus meiner Sicht die erweiterten Funktionalitäten und Features der System Center Integration Packs. Es sind einige Erweiterungen in diesem Bereich angekündigt worden. Warten wir ab...

Published in Orchestrator (Opalis)