Mostly Anything

1 SCOM 2007R2 Agent meldet nach der Agent installation ein Problem. Die Installation war durch, aber der Agent blieb auf „Not Monitored“. Das Event Log von der betreffenden Maschine meldete 2 verschiedene Events:

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

Heute habe ich weitere Agents in einer SCOM2007 implementiert. Die meisten davon virtuelle Maschinen, die auf VMware laufen. Der Kunde hat bei diesen Maschinen ein P-Laufwerk, auf dem das Page File ist. Die grösse des Page Files ist fix und das Drive so voll, dass der normale Monitor von SCOM einen Alert absetzt.
Ich musste nun alle diese P-Laufwerke aus dem Monitoring ausnehmen. Das ging relativ einfach:

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.

Kürzlich musste ich die LVM Root Partition (ext3 FileSystem) einer CentOS 5.5 VM vergrössern. Geht nicht im laufenden Betrieb. Folgendes Procedure hat geholfen, nachdem die virtuelle Disk in VMWare vergrössert wurde:

1. Mit der CentOS 5.5 LiveCD Booten
2. Die entsprechende Partition mit fdisk entfernen. Bei mir war die LVM Partition die 2. Partition
* fdisk /dev/sda
* d // Löschen
* 2 // Partition 2
* n // Neue Partition
* p // Primary
* 2 // Partition 2
* // Default Werte für Start und Stop Zylinder, damit der ganze freie Bereich genommen wird
*
* t // System ID ändern
* 2 // Partition 2
* 8e // Typ ist Linux LVM
* w // Schreiben
* q // Beenden
3. Reboot falls die Meldung kommt, dass das System noch die alte Partition Table verwendet (Natürlich wieder die LiveCD booten falls ein Neustart durchgeführt wird)
4. pvscan
5. pvresize /dev/sda2
6. pvdisplay - Die freien PEs aufschreiben
7. vgscan
8. lvscan
9. lvextent -l +xx /dev/VolumeGroup00/LogVol00 - xx sind die freien PEs im PV
10. fsck.ext3 -f /dev/VolumeGroup00/LogVol00 - falls die Partition gemountet ist zuerst umounten
11. resize2fs /dev/VolumeGroup00/LogVol00
12. reboot

Nun kann die VM ganz normal gestartet werden und die Root Partition hat die neue Grösse.

Beim Versuch eines Restores einer Mail von einem Exchange 2007 Backup mit GRT (Granual Recovery Technology) bekam ich einen Fehler:

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.

Hatte gerade einen Anruf, dass ein User Mails (per POP3) nicht mehr abholen kann. Ein Blick ins Logfile zeigte folgende Fehlermeldung:

Error indexing mbox file /var/mail/xxx: LF not found where expected

Nun, die Datei ist wie es sich für Linux/Unix gehört eine Textdatei und mit vi bewaffnet (und sehr viel Zeit) wäre diese mbox Datei sicherlich zu reparieren gewesen. Als fauler Admin geht das aber auch schneller.
Zuerst schaue ich wieviele Mails es eigentlich im mbox File hat:

grep -c "^From: "

gibt mir 17 Mails. Dann mit formail die Datei reparieren:

mv /var/mail/user01/var/mail/user01.bkp
formail -ds >/var/mail/user01

Nun kann der Benutzer die Mails wieder abrufen und er kriegt 17 neue Mails. Also sind alle wieder da. Keine weitere Suche notwendig.