Die Ausgangslage - alle fünf Minuten tauchte im Ereignisprotokoll des SCOM folgende Fehlermeldung auf:
Ereignisquelle: Health Service Script
Beschreibung:
AD Replication Monitoring : encountered a runtime error.
Failed to obtain the InfrastructureMaster using a well known GUID.
The error returned was: 'Failed to get the 'fSMORoleOwner' attribute from the object 'LDAP://DC1.domain.local/ <WKGUID=2fbac1870ade11d297c400c04fd8d5cd, DC=DomainDnsZones,DC=domain,DC=local>'.
The error returned was: 'Ein solches Objekt ist auf dem Server nicht vorhanden.' (0x80072030)' (0x80072030)
Nun dann gleich mal Google in Gang bringen und suchen lassen - das Ergebniss fiel allerdings mehr als dürftig aus. Natürlich waren dort nur allgemeine Dinge zu WKGUID usw. zu finden, auch die Änderung der Suchbegriffe brachte da nicht viel.
Ok, erstmal Kaffee kochen und eine neue Schachtel Zigarette bereitlegen - was will uns diese Fehlermeldung nun sagen?
Der SCOM such per Script im Active Directory nach einer FSMO mit dem Namen InfrastructurMaster, ist doch klar oder? Der einfachste Weg das zu überprüfen ist das MMC-SnapIn dsa.msc (AD Benutzer und Computer), rechtsklick auf die Domäne und dann Betriebsmaster auswählen. Geht natürlich auch über ntdsutil, dann eben nur in schwarz-weiß.
Mein erster Gedanke war, ok irgendwo in den Weiten der AD-Datenbank steckt ein Fehler, der vielleicht durch das Übertragen des Betriebsmasters aufgelöst werden kann. Hat leider nicht geklappt - ok dann weitersuchen. Nächste Frage, was ist eigentlich diese WKGUID - eine Suche bei Microsoft bringt mich dann auch nicht wirklich weiter. Zumindest weiß ich jetzt, dasss die WKGUID in etwa vergleichbar mit den Standart-SID sind. Das heißt in jedem AD gibt es bestimmte Container wie z, B. fSMORoleOwner oder lostAndFound, sich dann über die GUID suchen lassen.
So und nun ist erstmal ldp.exe aus den Supporttools dran, und darüber kann ich dann auch den entsprechenden Eintrag ermitteln.
Nach dem Aufruf von ldp dann zuerst eine connection -> connect... dc1.domain.local und noch ein bind unter connection -> bind benutzername, kennwort, dann mit view -> tree <WKGUID=2fbac1870ade11d297c400c04fd8d5cd, DC=DomainDnsZones, DC=domain,DC=local>.
LDP bringt dann einen Eintrag wie folgt:
Expanding base '<WKGUID=2fbac1870ade11d297c400c04fd8d5cd, DC=DomainDnsZones, DC=domain,DC=local>'...Result <0>: (null)Matched DNs: Getting 1 entries:>> Dn: CN=Infrastructure,DC=DomainDnsZones,DC=domain,DC=local
2> objectClass: top; infrastructureUpdate;
1> cn: Infrastructure;
1> distinguishedName: CN=Infrastructure,DC=DomainDnsZones,DC=domain,DC=local;
1> instanceType: 0x4 = ( IT_WRITE );
1> whenCreated: 06/03/2006 20:54:26 Mitteleuropäische Zeit Mitteleuropäische Sommerzeit ;
1> whenChanged: 06/08/2006 21:54:08 Mitteleuropäische Zeit Mitteleuropäische Sommerzeit ;
1> uSNCreated: 12394;
1> uSNChanged: 12394;
1> showInAdvancedViewOnly: TRUE;
1> name: Infrastructure;
1> objectGUID: cc84fb75-2211-4a88-ac5c-131bd5376675;
1> fSMORoleOwner: CN=NTDS Settings \0ADEL:d6c403ec-8da1-4e04-917a-01c6f42a68b1, CN=RBSERVER2K3\0ADEL:1e65ac88-4601-421c-a310-7d10f8fccc1f, CN=Servers, CN=Standort1,CN=Sites, CN=Configuration, DC=domain,DC=local;
1> systemFlags: 0x8C000000 = ( FLAG_DISALLOW_DELETE | FLAG_DOMAIN_DISALLOW_RENAME | FLAG_DOMAIN_DISALLOW_MOVE );
1> objectCategory: CN=Infrastructure-Update,CN=Schema,CN=Configuration,DC=domain,DC=local;
1> isCriticalSystemObject: TRUE; -----------
Eine Zeile fängt dann an mit: fSMORoleOwner: CN=NTDS Settings\0ADEL.....(oben grün markiert), und wenn ich mir dann noch den Zeitstempel anschaue, oh mann diesen Eintrag gibt es offensichtlich schon eine ganze Weile. Nun gut, mit ADSIEdit.msc dann in den entsprechenden Kontext und den Eintag im Attribut fSMORoleOwner des Objektes CN=Infratructure geändert. Im richtigen Leben würde ich natürlich nie zugeben, dass mich die ganze Suche mehrere Stunden Zeit gekostet hat *grins*, deshalb schreibe ich es lieber. Zumindest weiß ich jetzt wieder eine ganze Menge mehr über AD und mien SCOM2007 hat nun endlich seinen Eintag. Warum dieser Eintrag eigentlich so lange in der Datenbank des AD überleben konnte ist mir noch nicht ganz klar, ich denke es hängt wohl mit meiner Bereinigung des AD von verwaisten Metadaten zusammen - Stichwort ntdsutil. Aber das ist schon wieder eine ganz andere Geschichte.
