Exchange 2000/2003 RUS

Das Prinzip der Richtlinien und des RUS hat sich mit Exchange 2007/2010 geändert. Siehe E2K7 Empfängermanagement. Der RUS ist z.B. gar nicht mehr vorhanden.

Weitere Seiten zum Thema

Eine wichtige Komponente von Exchange 2000/2003 ist der Recipient Update Service oder auch RUS genannt. Dieser Prozess sorgt dafür, dass die Objekte im Active Directory unter anderem auch die passenden Exchange Mailadressen erhalten.

Der RUS versorgt alle Empfänger mit gültigen Adressen entsprechend der Empfängerrichtlinien. Das kann speziell bei Migrationen auch zur Änderung der primären SMTP-Adresse führen. Es ist daher ratsam, vor der Migration diese Information zu sichern, z.B. durch einen Export im Exchange Administrator oder durch ein Skript, welches diese Adresse in ein benutzerdefiniertes Feld übernimmt. Siehe auch SMTPBackupRestore

Der RUS löscht normalerweise keine Adressen, sondern fügt immer nur neue Adressen hinzu bzw. setzt die primäre Adresse neu. Nur wenn Sie in der Management Konsole auf der Karteikarte "Allgemein" die Mailadresse ändern, ersetzt die MMC die alte Adresse durch die neue. Besser ist es hier dann in den Exchange Mailadressen die neue Adresse hinzu zu fügen und als Primär zu kennzeichnen.

Der RUS löscht jedoch Adresstypen, d.h. wenn Sie in einer Empfängerichtlinie z.B. MS-Mail aktiviert hatten und diesen Adresstyp dann deaktiviere, dann wird die Mailadresse auch bei den Empfängern entfernt.

Die Funktion des RUS ist bei Exchange 2007 komplett entfallen. Die Einstellungen werden nun direkt durch die MMC bzw. Commmandlets durchgeführt. Details siehe
http://blogs.technet.com/b/exchange/archive/2006/10/02/429053.aspx

Aufgrund der Arbeitsweise und Bedeutung des RUS habe ich einige Skripte entwickelt:

Der RUS orientiert sich dabei an Empfängerrichtlinien, welche basierend auf den Empfängerrichtlinien für jedes Objekt genau eine Bildungsregel für die Mailadressen herangezogen wird. Der RUS arbeitet Exchange 2000 übergreifend, d.h. wird nicht durch administrative Gruppen oder Routinggruppen beschränkt. Die Empfängerrichtlinien sind immer organisationsweit. Es gibt im Im Gegensatz zu Exchange 5.5, eben nicht je Standort/Site eine so genannte "Standortadressierung" (Siteadressing).

Die Empfängerrichtlinien sind vom Administrator der Organisation zu definieren und werden im Active Directory hinterlegt. Insofern ist auch hier der Zeitbedarf für die Replikation dieser Konfigurationsinformation zu beachten, ehe die RUS-Dienste die Änderungen übernehmen.

Starten Sie dazu den Systemmanager und unter Empfänger finden Sie dort die Empfängerrichtlinien. Bei der Migration von Exchange 5.5. wird hier die Standortadressierung automatisch übernommen. Diese kann auch nicht gelöscht werden, solange Exchange 5.5 Systeme in der Organisation sind.

Was tut der RUS und warum sind meine Benutzer nicht im Adressbuch sichtbar ?

Oft kommt die Frage, warum ein Anwender nicht im globalen Adressbuch auftaucht oder Outlook kein Profil anlegen kann, obwohl doch alles richtig gemacht wurde. Aber das ist nur die halbe Wahrheit:

Also zwischen User anlegen und User in Outlook nutzbar können einige Minuten oder länger vergehen. Wenn bei all diesen ineinander greifenden Prozessen natürlich "der Wurm" drin ist, dann dauert es noch länger bzw. niemals. Getreu dem Motto:

Daher sollten sie nach einiger Wartezeit die Funktion des Active Directory und des RUS kontrollieren:

Fehler bei der RUS Konfiguration sind relativ einfach zu finden, aber Fehler bei der Funktion sehr aufwändig zu debuggen. Später dazu mehr. Mehr Details, in welchen Schritten aus einem Benutzer ein Postfach wird, finden Sie auch auf Neues Postfach wird angelegt.

Konfiguration des RUS

Der RUS besteht aus mehreren Teilen, die manuell zu konfigurieren sind. Zwar richtet das Exchange Setup zwei RUS-Einträge automatisch ein, um mit dem Enterprise RUS die Systemobjekte zu aktualisieren und die Benutzer der ersten Domäne, aber als Administrator muss ich selbst weiterer RUS-Einträge für jede Domäne vornehmen. Jede Domäne im Active Directory Forrest, die Exchange Objekte enthält. Also auch Domänen mit Exchange 5.5 Postfächer die per ADC mit dem AD repliziert werden und in der gleichen Exchange Organisation verbunden sind, müssen Sie einen RUS explizit einrichten.

Auch hierbei ist ähnlich wie beim ADC zu überlegen, welche Server im LAN den RUS-Dienst aufführen, da der RUS aktiv mit dem entsprechendem Domaincontrollern per LDAP interagiert und Änderungen an Benutzern, Verteilern und öffentlichen Ordnern vornimmt. Diese werden über das Active Directory natürlich auch wieder zwischen allen DCs der Domäne und auf die Globalen Katalogserver repliziert.

Der RUS verrichtet eigentlich seine Dienste problemlos, allerdings heißt es auch hier "Geduld" zu haben, da Änderungen selten "sofort" durchgeführt werden, und wenn, dann nur auf einem Domain Controller die Änderungen erfolgen, so dass die Änderungen noch das Replikationsintervall des Active Directory durchlaufen müssen.

Auch wenn Sie im Exchange 2003 ESM auch einen Exchange 2007 Server als "RUS-Server" eintragen können, so ändern Sie dies nicht. Der Exchange 2007 Server bietet keinen RUS an.

Die automatische Funktion des RUS

Der Empfängeraktualisierungsdienst arbeitet permanent, es sei denn Sie steuern das Verhalten über die Eigenschaften des jeweiligen Empfängeraktualisierungsdiensts.

Allerdings gibt es nur sehr selten den Bedarf hier den RUS einzugrenzen. Sie verzögern damit nur die Aktivierung von Mailboxen.

Die Einstellung "Immer Ausführen" ist etwas missverständlich. Natürlich kann der RUS nicht permanent den DC auf geänderte Objekte abfragen. in Intervall von 5 Minuten kann aber schon zu lange sein. Wenn Sie bei Exchange 2003 das Diagnoseprotokoll auf dem Server für MSExchangeAL - Adresslistensynchronisierung aktivieren, dann tauchen im Eventlog alle ca. 30 Sekunden die Meldungen auf, dass der RUS eine Überprüfung der USN startet. Insofern können wir davon ausgehen, dass der RUS sehr schnell arbeitet und eher die Replikation im Active Directory zu Verzögerungen führt.

Sobald der RUS über den regelmäßigen Lauf oder über ein "Update Now" gestartet führt er die folgenden Aktionen aus:

Der kleine aber wichtige Unterschied ist, ob Sie nach der Änderung der Richtlinie die Frage nach "Jetzt Anwenden" mit Ja oder Nein beantworten. Nur wenn Sie die Frage mit "Ja" beantworten, wird ein etwaiger Löschbefehl in ein Feld "GatewayProxy" aufgenommen und die Adressen eines Typs entfernt und primäre Adressen neu generiert.

Das heißt in verkürzter Form:

Aktion RUS Reaktion
Neuer Benutzer angelegt RUS erkennt die Änderung anhand des Felds "uSNChanged" und wenn die relevanten Exchange Eigenschaften vorhanden sind, ergänzt der RUS die Mailadressen, Aktiviert die Anzeige im Adressbuch und andere Felder. Siehe auch  auf Neues Postfach wird angelegt.
User in Gruppe hinzugefügt oder andere Änderungen die nicht den RUS betreffen RUS erkennt die Änderung anhand des Felds "uSNChanged" beim Anwender, aber erkennt auch, dass er nichts tun muss, weil sich an der Adresse nichts geändert hat
Benutzer Vorname oder Name umbenannt (z.B. Heirat) Der RUS erkennt die Änderung und wenn durch diese Änderung eine andere Richtlinie angewendet werden müsste, aktualisiert er auch das Feld "msExchPoliciesIncluded". Aber die neue oder weiterhin gültige Richtlinie wird NICHT neu angewendet !!
Wenn Sie daher ein "Umbenennen" erreichen wollen, müssen Sie ein "Apply Now" auf der Richtlinie durchführen. Wem dies zu viel Last erzeugt, muss mit eigenen Scripten die Adressen anpassen lassen.
Feld beim Benutzer geändert, so dass der Benutzer zu einer anderen Richtlinie gehört Der RUS erkennt dies und ändert den Inhalt von "msExchPoliciesIncluded". Aber die Mailadressen selbst werden nicht anhand der neuen Richtlinie angewendet. Wenn Sie daher ein Anwenden erreichen wollen, müssen Sie ein "Apply Now" auf der zugehörigen Richtlinie durchführen. Wem dies zu viel Last erzeugt, muss mit eigenen Scripten die Adressen anpassen lassen.
LDAP-Filter: der Richtlinie geändert - User gehört zu der neuen Richtlinie Wird der Filter einer Empfängerrichtlinie geändert, so dass ein Objekt nun zu einer anderen Richtlinie gehört, dann sucht der RUS beim nächsten geplanten Durchlauf nach genau diesen Objekten, die zum früher zur alten und zur neuen Richtlinie gehören. Der RUS aktualisiert dann das Feld "msExchPoliciesIncluded" um die neue Richtlinie zuzuweisen. Allerdings werden die Adressen NICHT sofort generiert. Sie müssen daher die Richtlinie, zu der der Benutzer nun gehört mit "Jetzt anwenden" aktivieren. Dann regeneriert der RUS für die Empfänger dieser Richtlinie die Adressen frisch.
Mailadresse in der Richtlinie geändert Der RUS erkennt die Änderungen und aktualisiert die "msExchPoliciesIncluded" Felder bei den Objekten aber NICHT die Mailadressen selbst. Um dies zu erreichen müssen Sie auf der Richtlinie "Jetzt anwenden" auswählen. Hierbei werden entfernte Adresstypen auch entfernt. Wurden Adresstypen geändert, dann bleiben die alten Adressen aber bestehen.
Andere Mailadresse manuell eingetragen Der RUS erkennt die Änderung beim Objekt als solches, aber ändert nichts sondern zählt nur seinen USN-Counter hoch.
Andere Mailadresse "primär" gesetzt Der RUS erkennt die Änderung beim Objekt als solches, aber ändert nichts sondern zählt nur seinen USN-Counter hoch.
Mailadresse gelöscht Der RUS erkennt die Änderung beim Objekt als solches, aber ändert nichts sondern zählt nur seinen USN-Counter hoch.

Noch mal in vereinfachter Form:

Im Zweifel sollten Sie also nach der Änderung von Richtlinien zur Durchsetzung der Einstellungen jede Richtlinie mit "Jetzt Anwenden" forcieren.

Ob der RUS ein Objekt bereits bearbeitet hat, erkennen Sie am besten daran, wenn Sie das Feld "uSNChanged" des Benutzers mit dem Feld "msExchServer1HighestUSN" beim RUS vergleichen. Ist der Wert im Feld des Objekts höher, dann hat der RUS dieses Objekt noch nicht bearbeitet.

RUS manuell starten

Der RUS läuft normalerweise regelmäßig im Hintergrund und erfragt vom Globalen Katalog die aktuelle USN. Ändert sich diese, so sucht der RUS nach Elementen, die sich geändert haben, um diese zu aktualisieren und mit einer Mailadresse zu stempeln. Aber manchmal dauert es einfach etwas länger, bis der RUS aktiv wird. Dies kann der Administrator über den Exchange 2000 System Manager beschleunigen. Herbei kann der jeweilige RUS mit der rechten Maustaste angewählt werden und entweder die Funktion "Update Now" oder "Rebuild" aufgerufen werden.

 Was ist nun der Unterschied ?

Ein "UpdateNow" macht eigentlich nichts anderes, als was der RUS auch alleine machen würde. Nur wenn Sie den RUS z.B. über einen Zeitplan nur nachts ausführen lassen, kann können Sie so die Ausführung jetzt anfordern. Normalerweise steht der Zeitplan des RUS aber auch "immer" und das ist auch in den meisten Fällen gut so.

Eine Situation, in der sie ein "Rebuild" brauchen, ist folgende:
Sie legen eine OU an und "schützen" diese, indem Sie die Vererbung von Berechtigungen deaktivieren und nur besondere Personen und Gruppen darauf berechtigen. Solche eine Situation kann z.B. die Geschäftsführung, die Entwicklung oder auch ein Betriebsrat sein. Leider "vergessen" Sie bei den Berechtigungen den Exchange Server. Die nun darin angelegten Benutzer können von RUS nicht aktualisiert werden.
Nun erkennen Sie ihren Fehler und korrigieren die Rechte. Der RUS wird das Objekt nun trotzdem nicht verarbeiten, da er mit einer USN schon daran vorbei ist und sich das Objekt ja nicht geändert hat. Sie können nun jedes der Objekte einfach kurz ändern oder eben einen "Rebuild Now" machen.

Diese Funktion ist insofern gefährlich, da dann die Richtlinie wirklich für alle Objekte, die im Feld "msExchangePoliciesIncluded" diese Richtlinie haben, auch zwangsweise aktualisiert werden. Dies kann manuelle Änderungen der primären Adresse wieder rückgängig machen.

Bei allen drei Änderungen können umfangreiche Veränderungen an Empfängern passieren. Sie sollten sehr genau wissen was passiert oder die Protokollierung der Aktionen aktivieren. (Siehe RUSMon)

Mit ADSIEDIT können Sie die entsprechenden Felder lokalisieren:

Eine ausführlichere Beschreibung der verschiedenen Ergebnisse finden Sie auch in:

Denken Sie aber immer daran, dass Änderungen an Benutzern auch im Active Directory repliziert werden und zum einen eine Replikationsbelastung bedeutet und ebenso verzögert überall aktualisiert werden. Bei Aktualisieren nutzt der RUS die Informationen aus dem Feld "msExchServer1HighestUSN" des entsprechenden Empfängeraktualisierungsdienstes um basierend darauf alle neueren Elemente zu suchen. Das Feld können Sie mit ADSIEdit einsehen.

Damit spart der RUS Zeit und Datenvolumen. Es ist nur in Ausnahmefällen erforderlich, alle Objekte neu zu versorgen.

Wie viele RUS-Einträge brauche ich ?

Standardmäßig sind immer zwei Empfängeraktualisierungsdienste aktiv.

Sie brauchen mindestens einen RUS für jede Domäne in ihrem Forest, auch wenn dort keine Empfänger sind, da ansonsten Exchange die DCs dieser Domänen nicht verwenden kann. Siehe auch http://weblogs.asp.net/exchange/archive/2004/02/27/81133.aspx

Ohne die weiteren Einträge werden Sie diese Personen mit der Managementkonsole zwar "Exchange enablen" können, aber Sie werden nicht als Postfach nutzbar werden.

Nun können Sie in der Management Konsole aber auch mehrere RUS-Dienste einrichten. Sie können also in einer Domäne mehrere Instanzen konfigurieren, die unterschiedliche Domänen Controller nutzen. Der Einsatz mehrere Instanzen erfolgt zum einen mit dem Ziel, die Aktivierung als Postfach zu beschleunigen, weil Latenzzeiten der Replikation umgangen werden und als zweite Funktion eine höhere Verfügbarkeit beim Ausfall eines Servers oder Domänen Controllers.

Beispiel:

Sie haben eine Domäne, die sich über viele Standorte erstreckt. Die ist mit dem Active Directory problemlos möglich. Nun kann es aber sein, dass für ihre Domäne "firma.de" z.B. einen DC in Deutschland und ein anderer in Frankreich steht. in beiden Standorten steht auch je ein Exchange Server der gleichen Organisation. Nach dem Standard Setup gibt es einen RUS für diese Domäne.

Wird nun ein Anwender in Frankreich angelegt und für Exchange aktiviert, dann kann dieser das Postfach erst nutzen, wenn folgende drei Schritt abgelaufen sind

  1. Benutzer wird angelegt
  2. Replikation nach Deutschland (nach ca. 15 Minuten)
  3. RUS bearbeitet das Konto (nach einigen Sekunden)
  4. Replikation nach Frankreich (nach ca. 15 Minuten)
  5. Benutzer kann arbeiten

Beim Einsatz eines Standortconnectors im AD ist die kürzeste Zeit 15 Minuten, so dass die Aktivierung 30 Minuten und länger dauert. Wird nun ein zweiter RUS in Frankreich konfiguriert, dann verkürzt sich diese Einstellunge

  1. Benutzer wird angelegt
  2. RUS bearbeitet das Konto (nach einigen Sekunden)
  3. Benutzer kann in Frankreich schon arbeiten
  4. Replikation nach Deutschland (nach ca. 15 Minuten)

D.h. die Arbeit vor Ort ist sehr schnell möglich und es wird sogar noch die Replikationslast reduziert. Wird die Mail aber dann doch über Deutschland gesendet und empfangen, dann dauert es eine Replikation, ehe auch die hiesigen Server den Benutzer kennen. Ein weiterer Vorteil ist natürlich die Ausfallsicherheit.

Da beide RUS-Dienste auf das gleiche Ergebnis kommen, ist selbst im Konfliktfall fast nie eine Kollision zu erwarten. Auch Microsoft empfiehlt mehrere RUS-Einträge:

Because of replication latency, we recommend that you have at least one domain Recipient Update Service for each Windows site. This can be especially helpful when the connections between sites are slow. You can create up to one domain Recipient Update Service per domain controller. The best number of Recipient Update Services for an installation depends on individual factors such as the number of domain controllers per site and the bandwidth.

Aber der Betrieb mehrerer RUS-Instanzen erfordert auch etwas Umsicht bei größeren Änderungen an den Empfängerrichtlinien.

Important When you make global changes to recipients, such as adding a new SMTP address on a recipient policy, make sure that only a few or only one Recipient Update Service is active. If many active Recipient Update Services try to update all users with a new SMTP address, this may cause significant Active Directory replication overhead.

Siehe auch

Wenn Sie aber nur einen Exchange Server betreiben und die Domäne auf einen Ort beschränkt ist, dann sollten Sie mit einem RUS für ihre Domäne und einem Enterprise RUS problemlos arbeiten können. Denn selbst die Option der Ausfallsicherheit bringt ihnen nicht viel, ohne entsprechende Überwachung. Denn ein RUS-Ausfall hat immer eine Ursache und wenn diese z.B.: auf dem Domänencontroller liegt, dann sind alle RUS-Dienste gestört.

Fehlersuche mit Diagnoseprotokoll

Der RUS ist nicht ganz so einfach zu diagnostizieren, da er nicht als eigenständiger Prozess oder Dienst sichtbar ist. Aber mit den passenden Einstellungen im Eventlog können Sie auch hier weiter kommen. Folgende drei Diagnoseeinstellungen auf dem Server sind sinnvoll:

Allerdings sollten Sie nicht nach der Aktivierung der Einstellungen gleich ein "jetzt neu aufbauen" auswählen, da dann das Eventlog schnell überläuft. Bei der Fehlersuche ist es vielmehr sinnvoll, einzelne Objekte zu analysieren und mit der Funktion "Auf Update prüfen" den RUS anzuweisen, nach geänderten Objekten zu suchen.

Wenn der RUS dann anläuft, sucht er nach geänderten Objekten. Sie finden diesen Vorgang anhand der EventlogID 8011 und einer Suche im Text nach "Base 'DC". Am Ende der Verarbeitung findet man die Abschlussmeldung mit den letzten verarbeiteten USNs.

Hier erkennen Sie, welche USNs der RUS gerade bearbeiten würde. Hat ihr fragliches Objekt eine kleinere USN, dann ist der RUS schon daran vorbei. Ist der vom RUS abgefragte USN-Bereich aber sehr viel tiefer, dann dürfte eher ein "Rebuild" die Ursache sein, bei dem der RUS wieder bei USN=1 anfängt. Nur in sehr großen Umgebungen mit vielen Änderungen in kurzer Zeit kann es sein, dass der RUS etwas hinterher hinkt. Finden Sie jedoch keine 8011 Meldung, dann könnte der RUS an einer früheren LDAP-Anfrage hängen. Bis zu welcher USN der RUs bereits gearbeitet hat, finden Sie mit ADSIEDIT im Feld "MSexchangeHighestUSN" beim entsprechenden Objekt des Aktualisierungsdiensts.

Beachten Sie dazu auch das Tool RUSMon - Überwachen der wichtigen Eventlogs per VBScript

Eine andere Variante zur Diagnose des RUS ist folgende Einstellung:

Nach diesen Einstellungen finden sich im Eventlog mehrere Meldungen, wenn der RUS eine vollständige Aktualisierung durchführt:

Ereignistyp: Informationen
Ereignisquelle: MSExchangeAL
Ereigniskategorie: Adresslistensynchronisierung

Eventlog Beschreibung
8259 Die Replikation für Adressliste 'Recipient Update Service (MSXFAQ)' wurde angehalten.

Ehe der RUS eine komplette Aktualisierung vornimmt, wird die Regelfunktion angehalten.
8329 Der Empfängeraktualisierungsdienst startet eine vollständige Neuerstellung von DC=msxfaq,DC=de
8332 Der Empfängeraktualisierungsdienst hat mit dem Export eines Blocks von Einträgen von DC=msxfaq,DC=de, angefangen bei USN 1, begonnen. Die Verarbeitung des Verzeichnisses wird beendet, wenn USN 16253 erreicht wird.

Hier ist gut zu sehen, dass der RUS bei der USN=1 anfängt und die höchste USN in diesem Active Directory bei 16253 liegt.
8330 Der Empfängeraktualisierungsdienst hat die Neuerstellung von DC=msxfaq,DC=de abgeschlossen.

Ab jetzt kann der RUS wieder die normale inkrementelle Aktualisierung vornehmen.

Wenn Sie die Protokollierung auf "Maximum" stellen, dann sind auch inkrementelle Aktualisierungen im Eventlog zu analysieren. Die folgenden Meldungen sind allein auf die Aktivierung eines einzelnen Benutzers mit einer Exchange Mailbox aufgelaufen

Ereignistyp: Informationen
Ereignisquelle: MSExchangeAL
Ereigniskategorie: Adresslistensynchronisierung

Eventlog Beschreibung
8159 Thread #7a8: Überprüfung für nächste gesteuerte Ausführung.
8158 Thread #7a8: Dienst wird ausgeführt.
8258 Replikation für Adressliste 'Recipient Update Service (MSXFAQ)' wird gestartet.
8175 Änderung von 'CN=test,CN=Users,DC=msxfaq,DC=de' wird bearbeitet.
8134 Verarbeitungsaufforderung für 'CN=test,CN=Users,DC=msxfaq,DC=de' in Warteschlange eingesetzt.
8163 Thread #66c: nächste Adresslistentransaktion empfangen. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))'. DC=msxfaq,DC=de
8130 'CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de' wurde 'CN=test,CN=Users,DC=msxfaq,DC=de' hinzugefügt. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=All Groups,CN=All Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(& (mailnickname=*) (| (objectCategory=group) ))'. DC=msxfaq,DC=de
8129 Adressliste 'CN=All Contacts,CN=All Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=contact)) ))'. DC=msxfaq,DC=de
8129 Adressliste 'CN=Öffentliche Ordner,CN=All Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(& (mailnickname=*) (| (objectCategory=publicFolder) ))'. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=Globale Standardadressliste,CN=All Global Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=group)(objectCategory=publicFolder) ))'. DC=msxfaq,DC=de
8130 'CN=Globale Standardadressliste,CN=All Global Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de' wurde 'CN=test,CN=Users,DC=msxfaq,DC=de' hinzugefügt. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=Default Policy,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(mailnickname=*)'. DC=msxfaq,DC=de
8130 'CN=Default Policy,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de' wurde 'CN=test,CN=Users,DC=msxfaq,DC=de' hinzugefügt. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=Site-A,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(&(mailNickname=*)(legacyExchangeDN=/O=MSXFAQ/OU=Site-A/*))'. DC=msxfaq,DC=de
8130 Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de' wurde 'CN=test,CN=Users,DC=msxfaq,DC=de' hinzugefügt. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=Site-B,CN=Recipient Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(&(mailNickname=*)(legacyExchangeDN=/O=MSXFAQ/OU=Site-B/*))'. DC=msxfaq,DC=de
8129 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=Hidden DL Membership,CN=System Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(&(objectCategory=group)(hideDLMembership=TRUE))'. DC=msxfaq,DC=de
8129 Auswertendes Verzeichnisobjekt 'CN=test,CN=Users,DC=msxfaq,DC=de' festgestellt anhand von Adressliste 'CN=Mail Enable Recipient,CN=System Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de', Regel '(|(&(objectCategory=person)(objectClass=user)(mailnickname=*)(targetAddress=*))(&(objectCategory=person)(objectClass=contact)(mailnickname=*)(targetAddress=*))(&(objectCategory=group)(mailnickname=*))(&(objectCategory=publicFolder)(mailnickname=*)))'. DC=msxfaq,DC=de
8129 (msExchHomeServerName=*))(&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*))(&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMta=*)))'. DC=msxfaq,DC=de
8130 'CN=Mailbox Enable User,CN=System Policies,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de' wurde 'CN=test,CN=Users,DC=msxfaq,DC=de' hinzugefügt. DC=msxfaq,DC=de
8169 Alle Verzeichnisänderungen wurden abgerufen unter: 'DC=msxfaq,DC=de'.
8157 Thread #7a8: Warten auf nächste gesteuerte Ausführung.
8039 Transaktion wurde abgeschlossen...
dn: <GUID=118BD14627CDF746A737E1036B06C830>
changetype: Modify
showInAddressBook:add:CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=MSXFAQ,CN=Micros...
: CN=Globale Standardadressliste,CN=All Global Address Lists,CN=Address Lists Cont...
mail:test@Site-A.MSXFAQ.com
textEncodedORAddress:c=DE;a= ;p=MSXFAQ;o=Site-A;s=test;
proxyAddresses:X400:c=DE;a= ;p=MSXFAQ;o=Site-A;s=test;
: SMTP:test@Site-A.MSXFAQ.com
msExchPoliciesIncluded:add:{169BBC5E-94CB-446A-9077-2C421DBF5688},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}
msExchALObjectVersion:80
objectGUID:118BD14627CDF746A737E1036B06C830
-
DC=msxfaq,DC=de
8035 Der Eintrag 'CN=test,CN=Users,DC=msxfaq,DC=de' im Verzeichnis E2KA.msxfaq.de wurde erfolgreich geändert. DC=msxfaq,DC=de
8167 Geändertes Objekt: 'CN=test,CN=Users,DC=msxfaq,DC=de'. DC=msxfaq,DC=de
8133 Berechnungen abgeschlossen auf 'CN=test,CN=Users,DC=msxfaq,DC=de'. DC=msxfaq,DC=de
8162 Thread #66c: Warten auf nächste Adresslistentransaktion. DC=msxfaq,DC=de

Es ist durchaus eine interessante Option, dieses Diagnoseprotokoll aktiviert zu lassen und die Events zu überwachen bzw. beim Ausbleiben dieser Events Alarm zu schlagen.

GUID der Richtlinien

Jede Empfängerrichtlinie und Mailboxrichtlinie hat eine GUID. Diese können Sie mit ADSIEDIT einsehen.

Diese GUID werden wichtig, wenn Sie sich die Felder msExchPoliciesIncluded und msExchPoliciesExcluded auf der Seite Empfängerrichtlinien betrachten.

DC verändert sich

Der RUS ist auf einem Exchange 2000 Server konfiguriert und nutzt dabei einen Domaincontroller zum Durchführen der Änderungen. Damit ist dies ein "Single Point of Failure", denn wenn der Domain Controller nicht "online" ist oder Sie durch eine Umkonfiguration diesen DC komplett deinstalliert haben, dann wird der RUS keine Adressaktualisierungen mehr durchführen können. Sie müssen dann in den Eigenschaften des RUS den Server einfach ändern. Der Fehler wir auch im Eventlog gemeldet.

3rd Party Adressgeneratoren

Oftmals gibt es in einer Exchange Organisation neben SMTP, X400 und EX noch weitere Adressen wie GSM, FAX, TELEX, SMS etc. Wird eine Empfängerrichtlinie mit solchen Adressen erstellt oder bei der Migration von Exchange 5.5 mit übernommen, so muss der RUS natürlich auch für diese Adressen die notwendigen DLL's haben, um erfolgreich die Adressen erstellen zu können.

Fehlen diese DLL's, so erstellt der RUS "keine" Adressen für neue Anwender. Um dies zu lösen, müssen Sie auf dem Exchange 5.5 Server in der Freigabe "ADDRESS" die entsprechenden Unterverzeichnisse damit den DLL's einfach auf den Exchange 2000 Server in das Verzeichnis ADDRESS kopieren, auf dem der RUS ausgeführt wird.

Welche DLL's ihnen fehlen, erhalten Sie, wenn Sie auch hier das Diagnoseprotokoll des Exchange SA auf dem Server hoch setzen und im Eventlog schauen. Alternativ können Sie per LDAP auch die DLLs finden. Suchen Sie einfach nach dem Eintrag "proxyGeneratorDLL" in dem im Bild angezeigten Pfad.

Diese Stelle ist auch wichtig, wenn Sie z.B. einen Connector eines Drittherstellers deinstallieren und dieser diesen Eintrag nicht löscht, oder wenn Sie von Exchange 5.5 migrieren. Dann wird dieser Liste auch durch das ConfigCA bzw. bei der Installation des ersten Exchange 2000/2003-Servers übernommen und kann danach nicht mehr gelöscht werden.

Wenn Sie daher den Adresstyp aus den Empfängerrichtlinien und bei allen Empfängern (z.B. mit ADModify) entfernt haben, dann sollte das entfernen des kompletten Eintrags keine Gefahr darstellen. Leider gibt es bislang keinen KB-Artikel oder andere Quelle, die dies auch bestätigen.

Programme für Mailadressen

Wenn Sie die Mailadressen nicht nur durch den RUS, sondern manuell oder über ein Programm anpassen wollen, dann sollten Sie folgendes wissen:

Sonderfall Neuaktivierung: Wenn Sie einen Empfänger noch nicht für Exchange aktiviert haben, aber dann schon mit einem Skript das Feld "ProxyAddresses" im Active Directory oder das Feld "Mail" füllen, werden diese ohne Rücksicht geleert, wenn Sie den Benutzer dann mit der MMC "Exchange aktivieren". Insofern dürfen Programme, die außerhalb von Exchange ein Postfach anlegen erst nach der Ablauf des RUS auch die Mailadressen anpassen.

RUS und Connectoren

Eine weitere Rolle des RUS kommt beim Einsatz von Connectoren für Notes und GroupWise zum Einsatz. Diese Connectoren haben die Funktion, Benutzer des anderen Mailsystems im Active Directory als "Kontakt" anzulegen. Auch diese Kontakte haben eine SMTP-Adresse und entsprechende Exchange Eigenschaften. Auch hier ist der RUS zuständig dafür, die vom Verzeichnisabgleich (Dirsync) des Connectors angelegten Kontakte mit diesen Werten zu versehen.

Funktioniert dies nicht, dann kann es sein, dass die Kontakte zwar im Active Directory sichtbar sind, aber nicht im Outlook Adressbuch erscheinen. In extremen Fällen kann es sein, dass eingehende Mails über diesen Connector nicht zugestellt werden, da der Connector den Kontakt findet aber ohne die erweiterten Attribute nicht verarbeiten kann.

RUS und WINS

Auch wenn es immer wieder behauptet wird, so benötigt auch Exchange 2003 SP1 und alle früheren Versionen immer noch eine funktionierende Namensauflösung mit WINS. Oft wird das Fehlen eines WINS-Servers nicht einmal auffallen, da Broadcasts und kleine Netzwerke mit einer Domäne und einem Standort das Problem erst gar nicht auftauchen lassen, aber je größer ihre Umgebung wird, desto wichtiger ist die Namensauflösung mittels WINS:

Wörtlich steht hier:

This issue may occur if Domain Name System (DNS) name resolution between the Exchange 2000 server that is running the Recipient Update Service and the target domain controller that is in the remote domain is malfunctioning. Additionally, this issue may occur if the Short Name for the remote domain DC is not resolvable, even if the FQDN can be resolved. (The Short Name is the NetBIOS name.) The Recipient Update Service may not be able to process users in the remote Windows 2000 domain.

Weitere Aufgaben des RUS

Der RUS ist aber nicht nur für die Pflege und Aktualisierung der Mailadressen bei den Empfängern zuständig, sondern auch für andere Einstellungen. So sorgt der RUS unter anderem auch dafür dass die globale Gruppe "Exchange Domain Servers" in jede lokale Gruppe "Exchange Enterprise Servers" jeder Domäne hinzugefügt wird.

RUS und Cluster

Der RUS funktioniert im Gegensatz zum Exchange SRS und einigen anderen Diensten problemlos auf einem Clusterknoten. Zwar gibt es hin und wieder Berichte, dass das Diagnoseprotokolle (MSExchangeAL) nicht geschrieben werden würde, aber das konnte ich bei mir bislang nicht nachvollziehen. Häufig sind die Probleme beim SRS in der Namensauflösung oder bei der Berechtigung zu suchen.

Der Dienst "RUS"

Der RUS ist kein Dienst im klassischen Sinn, sondern läuft als Teil der Exchange Systemaufsicht, die Sie als MAD.EXE im Taskmanager sehen. Die Funktion des RUS ist genauer in der DLL "abv_dg.dll" codiert, die von der Systemaufsicht beim Start geladen wird. Die Systemaufsicht macht noch einige andere Dinge, wie Amanda Langowski auf http://msexchangeteam.com//archive/2005/06/09/406137.aspx beschreibt.

Weitere Links

Weitere Links in der Knowledgebase finden Sie mit dem Suchbegriff "RUS" in der Exchange 2000 Produktauswahl.

Keywords:RUS Empfängerrichtlinien Policies