RUSMon

RUSMON in dieser Version funktioniert NUR mit Exchange 2003 und höher, da nur Exchange 2003 die zur Auswertung benötigten Events schreibt.

Alle Skripte sind Muster ohne jede Gewährleistung oder Funktionsgarantie. für Schäden bin ich nicht verantwortlich. Achten Sie auf Zeilenumbrüche bei der Übernahme.

VBScript und 64Bit !
Viele 32bit COM-Objekte lassen sich auf einem 64bit System nur instanziieren, wenn die 32bit Version von CSCRIPT/WSCRIPT genutzt wird, welcher unter C:\Windows\SysWOW64\cscript.exe liegt.

Wozu dient RUSMON

Der Empfängeraktualisierungsdienst ist ein sehr launischer Geselle. Bei den meisten Exchange Installationen ist der RUS für die Vergabe und die Pflege der Mailadressen zuständig. Allerdings gibt es kein ausführliches Protokoll über die Arbeit des RUS. Dies wäre aber wichtig, um die Änderungen , die der RUS durchführt auch nachvollziehen zu können.

Die Aktivierung einer Protokollierung des RUS ab Exchange 2003 erlaubt eine Protokollierung im Eventlog aber ergibt immer noch keine einfach auswertbare Datenquelle der Arbeit des RUS. Hier kommt RUSMon auf den Plan. RUSMon liest die EVENTLOG-Einträge und überträgt die Änderungen in eine XML-Datei zur weiteren Auswertung. Natürlich kann das Skript angepasst werden, um die Daten auch an andere Ziele zu senden.

Protokollierung des RUS

Zwar schreibt der RUS keine Textdateien und sendet auch keine SNMP-Traps, aber wenn Sie das Diagnoseprotokoll des Servers einstellen, dann protokolliert der RUS verschiedene Änderungen im Anwendung-Eventlog.

Leider müssen Sie die "Proxyerstellung" ganz auf Maximum stellen, ehe der RUS im Eventlog die gewünschten Informationen hinterlässt. Zuerst müssen Sie den Exchange Server bestimmten, auf dem die Empfängerrichtlinien ausgewertet und umgesetzt werden. Dies ist im Exchange System Manager am einfachsten zu sehen.

Auf diesem Server ist das Diagnoseprotokoll zu aktivieren und das Eventlog zu überwachen. Das Eventlog kann zwar auch remote überwacht werden, aber sinnvoll ist die Überwachung durch ein Programm auf dem Server selbst. Im Eventlog selbst stehen dann jedoch viel mehr Informationen, als benötigt werden.

Eventlog für einen neu angelegten Benutzer

Ereignistyp:	Informationen
Ereignisquelle:	MSExchangeSA
Ereigniskategorie:	Proxyerstellung 
Ereigniskennung:	3006
Datum:		20.04.2005
Zeit:		22:44:08
Benutzer:		Nicht zutreffend
Computer:	SRV01
Beschreibung:
Die Instanz des Richtlinienanbieters verarbeitet einen Empfänger. 
Empfänger-DN: CN=Frank Carius,CN=Users,DC=msxfaq,DC=local 
Aktuelle Empfängerproxys:  
Anwendbare Richtlinien: 
	CN=Default Policy,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange
		,CN=Services,CN=Configuration,DC=msxfaq,DC=local
	CN=test,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,
		CN=Configuration,DC=msxfaq,DC=local
	CN=Richtlinie1,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,
		CN=Services,CN=Configuration,DC=msxfaq,DC=local 
Ausgewählte Richtlinie: CN=test,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange
	,CN=Services,CN=Configuration,DC=msxfaq,DC=local 
Proxys der ausgewählten Richtlinie: 
	SMTP:@msxfaqtest.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange; 
Proxys in Änderungsliste:  
Zu erzeugende Proxys: 
	SMTP:@msxfaqtest.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange; 
Konflikte während der Erzeugung:  
Erzeugte Proxys: 
	SMTP:fcarius@msxfaqtest.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=Carius;g=Frank; für den Empfänger geschriebene Proxys: 
	SMTP:fcarius@msxfaqtest.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=Carius;g=Frank;
Weitere Informationen über die Hilfe- und Supportdienste erhalten 
	Sie unter http://go.Microsoft.com/fwlink/events.asp.

Eventlog einer Änderung

Ereignistyp:	Informationen
Ereignisquelle:	MSExchangeSA
Ereigniskategorie:	Proxyerstellung 
Ereigniskennung:	3006
Datum:		20.04.2005
Zeit:		23:18:19
Benutzer:		Nicht zutreffend
Computer:	SRV01
Beschreibung:
Die Instanz des Richtlinienanbieters verarbeitet einen Empfänger. 
Empfänger-DN: CN=Frank Carius,OU=Abteilung,DC=msxfaq,DC=local 
Aktuelle Empfängerproxys: 
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=Carius;g=Frank;
	SMTP:fcarius@msxfaqtest.local 
Anwendbare Richtlinien: 
	CN=Default Policy,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,
		CN=Services,CN=Configuration,DC=msxfaq,DC=local
	CN=test,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,
		CN=Configuration,DC=msxfaq,DC=local
	CN=Richtlinie1,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,
		CN=Services,CN=Configuration,DC=msxfaq,DC=local 
Ausgewählte Richtlinie: CN=Richtlinie1,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange
	,CN=Services,CN=Configuration,DC=msxfaq,DC=local 
Proxys der ausgewählten Richtlinie: 
	SMTP:%g.%s@msxfaq1.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange; 
Proxys in Änderungsliste: 
	MS:
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;
	SMTP:%g.%s@msxfaq1.local 
Zu erzeugende Proxys: 
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;
	SMTP:%g.%s@msxfaq1.local 
Konflikte während der Erzeugung:  
Erzeugte Proxys: 
	SMTP:Frank.Carius@msxfaq1.local
	smtp:fcarius@msxfaqtest.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=Carius;g=Frank; für den Empfänger geschriebene Proxys: 
	SMTP:Frank.Carius@msxfaq1.local
	smtp:fcarius@msxfaqtest.local
	X400:c=DE;a= ;p=MSXFAQ;o=Exchange;s=Carius;g=Frank;
Weitere Informationen über die Hilfe- und Supportdienste erhalten
	Sie unter http://go.Microsoft.com/fwlink/events.asp.

In der Form ist aber das Eventlog natürlich nicht sonderlich hilfreich. Zwar ist wunderbar zu sehen, welche Adressen ein Eintrag hat, welche Richtlinien es gibt und welche davon ausgewählt wird, aber die wichtigen Einträge sind nur ein Teil dieser Textausgabe. Also gilt es, diese Ausgaben in eine geeignete Form zu bringen. Durch die Überwachung dieses Eventlog ist nebenbei auch gut zu erkennen, wann der RUS einen Benutzer erneut bearbeitet.

Zielformat

Für eine Protokollierung und kleine Revision der Änderung ist es ausreichend ist, in einer Protokolldatei nur die Veränderungen aufzuzeichnen, die der RUS durchführt. RUSMon schreibt seit der Version 1.3 nun eine XML-Datei.

<?xml-stylesheet type="text/xsl" href="rusmon.xsl"?>
<rusmon>
    <starttime>10/20/2006 10:20:10 PM</starttime>
    <mode>monitor</mode>
    <object>
        <date>10/20/2006 10:20:36 PM</date>
        <dn>CN=test,OU=Recipients,DC=msxfaq,DC=de</dn>
        <mail>SMTP:test@example.com</mail>
    </object>
</rusmon>

Da der RUS eigentlich keine Mailadressen entfernt, ist es ausreichend einfach die hinzugefügten Adressen auszuführen. Bestehende Adressen werden dann zu sekundären Mailadressen. So ist aber gut zu erkennen, wann ein Objekt durch den RUS das letzte Mal angefasst wurde und welche Adressen hinzu gefügt wurden. Sie können das Skript oder auch diese Ausgabedatei problemlos für eine weitere Verarbeitung verwenden z.B. Alarm schlagen, wenn bestimmte Adressen verändert oder neu vergeben werden oder der RUS einfach nicht mehr arbeitet.

Eine Erweiterung um die Erkennung von entfernten Adressen ist später einmal geplant

Das Skript

Das VBScript führt folgende Aufgaben aus:

  • Eventlog überwachen bzw. einlesen
    Mittels WMI kann das Eventlog auf den gewünschten EVENT gezielt überwacht werden, so dass das Skript bei Inaktivität ohne Belastung auf den nächsten Event warten kann.
  • Eintrag auswerten
    Trifft ein Event ein, so muss das Skript aus der Beschreibung des Eintrags die gewünschten Informationen extrahieren
  • Ausgabe schreiben
    Zuletzt werden diese Änderungen in die Ausgabedatei, in das Eventlog und den Bildschirm geschrieben geschrieben.

Dazu müssen Sie das Script natürlich erst auf dem Server ablegen und mit ausreichenden Rechten starten.

rusmon.1.3.vbs
Vergessen Sie nicht, die Erweiterung wieder in VBS zu ändern.

In meinen TestUmgebungen und bei Kunden hat dieses Script bislang problemlos funktioniert. Trotzdem kann es sein, dass das Script unerwartet abbricht. Dies liegt oft an Sonderzeichen oder Inhalten im AD, die ich noch nicht abgefangen habe. Bitte setzen Sie dann das Debugging auf 6 und senden Sie mir die letzten Zeilen der Protokolldatei und die Zeilennummer des Fehlers des Scripting Hosts. -> Kontakt

Nach dem Download sind folgende Schritte zu tun:

  • Ablegen des Skripts auf dem Server mit Exchange
  • Exchange Diagnoseprotokoll für den RUS auch Maximum stellen
  • Suchstring an die Sprache anpassen
    Leider ist die Meldung im Eventlog abhängig von der Sprache und keine generische Information. Im VBScript es dazu zwei Konstanten (conNewProxy und conOldProxy), die sie entsprechend anpassen müssen. Die deutschen Meldungen sind per Default aktiv. Auf einem englischen Server müssen Sie die deutschen Meldungen auskommentieren und die englischen Meldungen aktivieren
  • Protokolldatei
    Das VBScript schreibt eine Protokolldatei und in das Eventlog. Zumindest den Pfad für die Protokolldatei sollten Sie ihren Bedürfnissen anpassen. Sie können die Datei mit TAIL o.ä. überwachen. Zusätzlich schreibt das VBScript ein Eventlog
  • Starten des Script
    Zuletzt müssen Sie das Script noch aufrufen. Hierbei gibt es zwei Optionen:
    M = Monitor, d.h. das Skript läuft endlos und überwacht in Echtzeit das Eventlog
    S = Scan, d.h. das Script durchsucht das aktuell vorhandene Eventlog, schreibt die Ergebnisse und beendet sich.

Die Betriebsart "Monitor" ist sicher die beste Variante um keine Meldung zu verpassen und sofort in die Textdatei zu schreiben. Allerdings muss dazu das Skript gestartet bleiben. Wenn Sie das mal verpasst haben, dann können Sie mit der SCAN-Funktion zumindest die Meldungen noch extrahieren, die noch im Anwendungseventlog liegen.

Einschränkungen

  • Größe des Eventlogs und Performance
    Durch die Aktivierung des Diagnoseprotokolls schreibt Exchange sehr viel Einträge, die zum einen das Eventlog mit vielen nicht benötigten Informationen auffüllen und natürlich auch etwas Performance kosten.
  • Eventlogfunktion
    Kritischer ist aber die Tatsache, dass das Eventlog nicht endlos wachsen kann und in der Menge der Informationen durch den RUS eventuelle andere Fehler beim ersten Blick auf das Eventlog nicht mehr zu sehen sind. Der Einsatz des Diagnoseprotokolls für RUSMON im Dauerbetrieb ist daher nur sinnvoll, wenn Sie andere Programme nutzen, um die sonstigen Events nicht zu verpassen, z.B. MOM2005. o.ä. Siehe auch Überwachung von Exchange - Eventlog
  • Sprachabhängigkeit
    Das Skript muss die Beschreibung des Events analysieren. Damit ist die Funktion natürlich von der verwendeten Sprach abhängig. Sie müssen daher das Skript anpassen, wenn die Meldungen im Eventlog anders aussehen.
  • Entfernen von Adresse
    RUSMON erkennt aktuell nicht, wen der RUS Mailadressen eines Adresstyps entfernt !!

Natürlich ist das VBScript nur eine Basis. Sie können das Skript anpassen, und z.B. auch entfernte Server überwachen. Auch die regelmäßige Kontrolle auf andere Meldungen des RUS als Funktionskontrolle ist sicher interessant. Wobei sie bald an die Grenzen des Eventlogs und VBScript stoßen werden. Besser ist es dann Produkte wie MOM2005 einzusetzen, und damit die Events zu sammeln und beim Ausbleiben auch alarmieren.

mögliche Erweiterungen: Aktiver Check

Die Kontrolle des Eventlogs ist Natürlich nur eine indirekte Kontrolle der Funktion des RUS. Besser wäre Natürlich eine aktive Überwachung des RUS, indem eine Testroutine z.B.: einen Benutzer anlegt und nach vielleicht 10 Minuten kontrolliert, ob der RUS dieses Objekt auch aktiviert hat. Damit würden auch diese Fehler erkannte werden, die nicht im Eventlog stehen, z.B. fehlende Berechtigungen.

Allerdings würde das zusätzliche Last bedeuten, da der Benutzer immer wieder in Adressbücher aufgenommen und wieder entfernt werden würde. Das ist besonders nervig, wenn Offline Anwender ein Offline Adressbuch herunter laden. Daher ist hierbei der Nutzen abzuwägen.

Es w�re ebenso denkbar, einfach bei einem nicht sichtbaren Testobjekt die Mailadressen immer wieder zu löschen, so dass der RUS auch hier von einem neuen Objekt ausgeht und dieses mit einer Mailadresse versieht. Also in der Art:

Set contact= GetObject("LDAP://cn=testuser,OU=test,DC=msxfaq,DC=net")

do  'Endlosschleife
    wscript.echo "PRUEFE auf Proxy Addresses"
    If contact.proxyaddresses = "" then
        wscript.echo "ALARM: RUS arbeitet nicht. ProxyAddresses leer"
    else
        wscript.echo "Ok. User hat Mailadressen bekommen."
        contact.maildisable
        contact.setinfo
        wscript.echo "DONE: user wurde Mail disabled"
        contact.targetAddresse = "kontakt1@example.com"
        contact.MailNickName = kontakt1
        contact.setinfo
        wscript.echo "DONE: user wurde Mail enabled. Warte..."
        wscript.Sleep(900000)
    end if
loop

Wenn die Maildressen "leer" sind, dann warnt das Skript über eine Bildschirmausgabe. Sind Mailadressen vorhanden, dann werden diese entfernt und 15 Minuten gewartet, ehe die Prüfung wiederholt wird. In dieser Zeit sollte der RUS erkannt haben, dass diesem Objekt die Mailadressen fehlen und diese wieder vergeben haben. Bedenken Sie dabei eventuelle Verzögerungen bei mehreren Domänen Controllern.

Siehe auch VBS:MakeContact

Ohne die Endlosschleife könnte das Skript dann per MOM z.B. alle 10 Minuten gestartet. Mit der Endlosschleife werden nur Meldungen ausgegeben zeigt sehr schnell, ob der RUS die Objekte mit einer Mailadresse versieht. Das ist dann ein aktiver Test.

mögliche Erweiterungen: USN-Kontrolle

Ein anderer semiaktiver Test ist der Vergleich und Kontrolle der USNs. Der RUS prüft regelmäßig die HighestUSN der Domäne und vergleich diese mit dem Stand seit dem letzten Durchlauf. So kann der RUS sehr schnell die geänderten Objekte finden und verarbeiten. Ein Testprogramm kann zwei Kriterien für einen Test heranziehen:

  • Differenz zwischen den USN-Werten
    Durch einen Vergleich des aktuellen Werts der Domäne mit dem Wert des RUS kann ermittelt werden, wie weit der RUS "hinten dran" hängt. Je nach Menge der Änderungen im Active Directory ist die USN der Domäne immer einige Stellen höher als der gespeicherte Wert beim RUS. Es ist sogar möglich eine Liste der Objekte zu generieren, die der RUS noch nicht verarbeitet hat.
  • Ansteigen des USN-Wert
    In der Regel ändert sich immer etwas in einer Domäne. Insofern muss der RUS bei jedem Lauf sein Feld "msExchServer1HighestUSN" aktualisieren. Wenn der RUS nun alle 5 Minuten Objekte prüft, dann sollte dieses Feld immer wieder erhöht werden.

Fast hätte ich ein entsprechendes VBScript geschrieben, aber dann habe ich doch noch gefunden, dass das Programm ExBPA diese Funktion schon eingebaut hat.

Allerdings kann es trotzdem hilfreich sein, ein eigenes Script mit auf ihre Umgebung angepasste Parameter zu erstellen. Dieses Script steht mittlerweile unter CheckRUS zur Verfügung.

Weitere Links

  • Auditing
  • CheckRUS
  • 246127 How to check the progress of the Exchange Recipient Update Service)
  • 328738 XADM: How the Recipient Update Service Applies Recipient Policies
  • 822794 How to troubleshoot the Recipient Update Service by using the Application log in Exchange 2000 Server or in Exchange Server 2003