Das MP kann hier runtergeladen werden.

Was ist neu?

• BPA (Best Practice Analyzer) Rules sind nun per Default disabled
• Korrekte SQL Server Stored Procedure Berechtigungen für Reporting Services (kein manueller Eingriff mehr nötig)
• Updated Knowledge für Logical Disks
• Updated Overrides für Logical Disks
• % idle Time sorting funktioniert nun

Das ganze können wir folgendermassen lösen. Wir erstellen einen Notification Command Channel, erstellen einen Subscriber und eine Subscription (nur für neue Alerts) und führen dann ein Powershell Script aus, dass den entsprechenden Resolution Code setzt.

Das Script sieht folgendermassen aus:

Param (
	[string]$RMS = "RootManagementServer"
)
# Start the OpsMgr PSSnapin
Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
New-ManagementGroupConnection -ConnectionString:$RMS -ErrorVariable errSnapin ;
set-location $RMS -ErrorVariable errSnapin ;

# Get all new (0) alerts where the MonitoringObjectFullName starts with Microsoft.SQLServer
$alerts = Get-Alert | ?{$_.ResolutionState -eq "0" -and $_.MonitoringObjectFullName -like "Microsoft.SQLServer*"}

foreach($alert in $alerts) {
	#Set the resolution state to DBA Group (15)
	$alert.ResolutionState = "15"
	$alert.Update("")
}

# Remove the OpsMgr PSSnapin
Remove-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client

Wir verbinden uns zuerst mit dem RMS und holen alle Alerts mit Resolutio State von 0 (NEW). Wir können hier auch noch dem MonitoringObjectFullName filtern, der mit Microsoft.SQLServer beginnt (alle Alerts vom SQL Server MP).
Bei diesen Alerts setzen wir den Resolution State dann auf die gewüschte Zahl.

Jetzt müssen wir SCOM noch so konfigurieren, dass dieses Script bei den neuen Alerts ausgeführt wird:

Neuen Notification Channel erstellen: Administration – Notifications – Channels – New Channel Namen und Beschreibung ausfüllen. Unter Settings bei Full Path den Pfad zur Powershell angeben. Bei Command Line Parameters das eigentliche Script aufführen
Dann einen Subscriber erstellen mit dem Channel Type “Command” und useren Channel, den wir vorher erstellt haben.
Nun mit einer Subscription das ganze zusammenfügen. Wir wählen unter Criteria nur die Alerts mit Resolution State 0 aus. Wir wollen ja, dass nur neue Alerts bearbeitet werden.
Als Subscriber und Channel die vorher erstellten auswählen und ohne Alert Aging erstellen

Nun wird bei jedem neuen Alert das Script ausgeführt und falls es ein Alert vom SQL MP ist der entsprechende Resolution State gesetzt. Natürlich können wir im Script auch noch weitere States für andere MPs setzen.

Die DBAs bekommen dann noch eine neue Alert View, bei der nur die Alerts mit dem State 15 angezeigt werden und sind happy, da sie die restlichen Alerts, die sie nicht interessieren nicht sehen.

Error Could not determine the FSMO role holder

Der Active Directory Verantwortliche war etwas nervös. Es hat sich aber gezeigt, dass es kein AD Problem war sondern ein Konfigurations Problem auf den Servern. Das Active Directory Management Pack benutzt die Windows Support Tools. Diese müssen in %PROGRAMFILES%\Support Tools\ installiert sein. Auf den entsprechenden Servern waren sie aber in %PROGRAMFILES%\Support\Support Tools\ installiert. Korrigiert und MP läuft jetzt ohne Probleme.

Event 21041.
Operations Manager has received a bad configuration file for management group mgmtgroup which could not be parsed. Configuration has been re-requested. A copy of the bad configuration file will be placed in C:\Program Files\System Center Operations Manager 2007\Health Service State\Connector Configuration Cache\mgmtgroup\OpsMgrConnector.Config.Error.xml

Event 21027
OpsMgr has received configuration for management group mgmtgroup from the Configuration Service, but failed to process the configuration. Configuration will be re-requested. The current state cookie is “” (State cookie may be empty if there is no active configuration)

Die Konfiguration funktioniert aber auf allen anderen Agents. Das Problem ist eine Fehlerhafte Installation von MSXML6 XML Parser.

Die Lösung:
Reinstallation des MSXML6 Parsers. Dazu einfach das MSXML6.msi aus dem AgentManagement Orders des SCOM Servers auf der betreffenden Maschine ausführen (natürlich die richtige Version – 32 oder 64bit). Dann noch den System Center Management Service neustartet und der Fehler ist behoben

1. Gruppe mit allen P-Laufwerken erstellen
2. Override auf dieser Gruppe erstellen

Also fix die neue Gruppe erstellen

und unter Dynamic Members eine Rule erstellen. Als Class habe ich hier “Windows Server 2003 Logical Disk” genommen. Ich hab dann noch eine weitere Gruppe für 2008 und eine Gruppe für beide Server, mit diesen 2 Subgroups genommen. Das weil ich für 2003 und 2008 eigente MPs habe und ich das so getrennt halte.
Dann kann ich das Property “Display Name” auswählen und eine Prüfung machen ob der Name gleich P: ist.

Dann erstelle ich einen Override für diese Gruppe. Ich habe den Alarm für diese Gruppe komplett abgestellt. Natürlich kann man auch einfach andere Schwellwerte setzten.

Final error: 0xe000848c - Unable to attach to a resource. Make sure that all selected resources exist and are online, and then try again.
Final error category: Resource Errors

Eine Suche bei Symantec ergab zuerst viele Hinweise auf diesen Fehler. Man müsse sicherstellen, dass der BackupExec Service Account für den Restore eine Mailbox hat, die auch aktiviert und benutzbar ist. Das war der Fehler. Weitere Hinweise gingen Richtung Permissions, der Service Account hatte aber die richtigen Berechtigungen. Das Backup ging auch ohne Probleme.

Irgendwann bin ich dann auf diesen Artikel gestossen:

http://www.symantec.com/business/support/index?page=content&id=TECH61406

Ein Problem mit IPv6. Der DSProxy Service (Port 6004) auf dem Exchange Server horcht nur auf IPv4 und NICHT auf IPv6. Der Exchange Server läuft aber auf einem Windows Server 2008. Dieser versucht per default zuerst eine Verbindung per IPv6 und dann erst per IPv4. Der Server selber hat keine IPv6 Adresse, auch keine LinkLocal. Aber in der hosts Datei (%WINDOWS%\system32\drivers\etc\hosts) ist ein Eintrag fuer die IPv6 Loopback Adresse ::1

Als Workaround kann dieser Eintrag auskommentiert werden. Dann den BackupExec Agent neustarten und es geht.

Übel, aber momentan wird noch kein IPv6 in der Umgebung verwendet. Mal sehen ob dies mit einem der nächsten Patches behoben wird.

c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

mit riesigen Logfiles um die 512MB gefüllt. Wenn man sich die Logfiles genauer anschaut, sieht man, dass viele Einträge informeller Natur sind und keine Fehlermeldungen. Ich benötige bei dem Server aber nur die Fehlermeldungen und Errors. Also kurz den LoggingLevel von General umstellen. Dies geht mit

stsadm -o setlogginglevel -category "general" -tracelevel none

Dadurch werden General Meldungen nicht mehr geloggt und die Logfiles sind wieder auf einem erträglichen Mass.

In /etc/postfix/main.cf fügen wir folgende Zeile hinzu:

relayhost = smarthost.firma.zz:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
smtp_sasl_security_options = noanonymous

Dann erstellen wir die Datein /etc/postfix/smtp_auth mit folgenden Angaben:

smarthost.firma.zz       senduser:supersecret

Aus der erstellen Datei müssen wir noch eine “lookup table” erstellen. Dies geht ganz einfach mit

postmap /etc/postfix/smtp_auth

Die Datei /etc/postfix/smtp_auth.db wird dadurch erstellt. Wenn wir in Zukunft änderungen an der Datei smtp_auth machen, müssen wir auch den entsprechenden postmap Befehl ausführen. Ansonsten bekommt Postfix die Änderungen nicht mit.

Nun Postfix mit

/etc/init.d/postfix reload

die neue Konfiguration laden lassen und das wars auch schon.