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:

  • RUSMon
    Überwachung der Tätigkeit des RUS.
  • SMTPBackupRestore
    Sichern, prüfen und wieder herstellen der ursprünglichen primären SMTP-Adresse, z.B. nach der umschaltung in den Native Mode oder Änderungen an den Empfängerrichtlinien.

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:

  • Ein Benutzer oder eine Gruppe wird mit der Management Konsole anlegt und "Exchange aktiviert". Die Änderungen werden im AD repliziert und landen nach einiger Zeit auch auf allen GCs
  • Der RUS überwacht nun seinerseits einen GC auf Änderungen an Objekten. Wenn nun ein neuer User "Exchange enabled" sein soll, dann muss der RUS dem die ganzen SMTP-Adressen verpassen, aber zudem auch einige weitere Felder im AD aktualisieren (ACLs, etc.) Diese Änderungen schreibt der RUS wieder auf den angegebenen DC in das AD zurück.
  • Auch diese Änderung muss nun erst wieder repliziert werden. Erst dann kann der DSACCESS und das NSPI-Interface der GC-Server diese Informationen an den Outlook Client liefern.
  • Der Store berechnet beim ersten Zugriff des Benutzers auf das Postfach die Mailboxrechte und schreibt diese in das AD. Auch diese werden dann erst wieder repliziert.

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:

  • 70% aller Exchange Fehler sind eigentlich Active Directory Probleme
  • 70% aller Active Directory Probleme sind DNS-Probleme oder Fehlkonfigurationen.

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

  • Prüfen Sie, ob die AD Replikation funktioniert (REPLMON, DSASTAT)
  • Kontrollieren Sie den RUS. Ist der angegebene Domain Controller und Exchange Server noch vorhanden oder haben Sie die Konfiguration verändert ?. Es gibt hier kein "Plug and Play"
  • Funktioniert die Namensauflösung

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 RUS fragt das Active Directory nach allen Objekten, die nach dem letzten Durchlauf bearbeitet wurden. Dazu nutzt der RUS zum einen das Feld USNChanged und das bei der Konfiguration des RUS abgespeicherte Feld msExchServer1HighestUSN. So findet der RUS heraus, welche Objekte sich geändert haben.
  • Für jedes Objekt prüft der RUS dann, welche Richtlinie dazu gehört. Dazu arbeitet er die Empfängerrichtlinien nach der Priorität ab und nimmt die dann zuerst passende, die aber nicht durch das Feld "msExchPoliciesExclude" ausgeschlossen worden ist. Die so gefundene GUID der Richtlinie wird beim Benutzer in msExchPoliciesIncluded geschrieben.
  • Hatte der Empfänger bislang keine Mailadresse, dann ist die Richtlinie neu und die Mailadressen werden generiert und eingetragen.
    Ansonsten wird die primäre Adresse der Richtlinie gesetzt und eine eventuell früher vorhandene primäre Adresse zur sekundären Adresse. Sind weitere sekundäre Adressen der Richtlinie vorhanden und fehlen diese beim Objekt, werden sie ebenfalls addiert. Ist ein kompletter Adresstyp auf "entfernen" gesetzt, dann werden die Adressen entfernt.
  • Wurde in der Empfängerrichtlinie nur ein neuer Adresstyp hinzugefügt und dieser ist noch nicht beim Objekt vorhanden, wird er addiert. weitere sekundäre Adressen werden jedoch nicht hinzugefügt.

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:

  • Der RUS versieht Objekte mit Mailadressen, wenn diese bislang keine Mailadressen haben, d.h. neu angelegt wurden.
  • Der RUS versieht bestehende Objekte nur dann mit den Adressen eine neuen oder geänderten Richtlinie, wenn diese Richtlinie "Angewendet" wird (Siehe 328738 XADM: How the Recipient Update Service Applies Recipient Policies). Dann kann es auch sein, dass eine bestehende primäre Adresse zur sekundären Adresse wird.
  • Wird eine primäre Adresse aus den Empfängerrichtlinien deaktiviert, dann wird der RUS neue Objekte nicht mehr damit versehen. Bestehende Objekte werden nicht geändert. Wenn Sie aber dann später ein "Jetzt Anwenden" durchführen, werden diese Adressen bei den Benutzern gelöscht.
  • Mailadressen eines Typs werden nur dann gelöscht, wenn alle Adressen des gleichen Typs in der Empfängerrichtlinie deaktiviert werden. Ansonsten arbeitet der RUS immer additiv.
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:

  • Der RUS merkt sich bei jedem User die zuletzt angewendete Richtlinie. Wenn sich ein User "ändert" dann merkt das der RUS und prüfen den User erneut. Dabei prüft er aber nur, ob sich die Bedingungen für die Richtlinie geändert haben, d.h. ob nun eine andere Richtlinie greift oder vorher noch keine angewendet war. Nur dann macht er was. Ansonsten lässt er den User unangetastet.
  • ändert sich der LDAP-Filter einer Empfängerrichtlinie, dann bemerkt dies auch der RUS aber tut nur etwas, wenn die Richtlinie beim Speichern auch "angewendet" wird. Ansonsten wird die neue Richtlinie bei den Objekten zwar eingetragen aber erst durch ein "jetzt anwenden" werden die Änderungen durchgeführt
  • ändert sich der Inhalt einer Richtlinie, dann wird diese auch nur eingetragen aber erst durch ein "Jetzt Anwenden" werden die Objekte auch gestempelt. Hierbei sind auch Löschungen möglich, wenn Sie einen Adresstyp komplett deaktivieren

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 ?

  • Update/Aktualisieren
    Diese Funktion triggert den RUS an, seine normale Tätigkeit JETZT zu machen. Der RUS such nach geänderten Objekten und vergibt Mailadressen. Damit können Sie die normale Funktion beschleunigen, die der RUS ansonsten anhand seines Zeitplans, der unter den Eigenschaften einstellbar ist, durchführen würde.
    Im Hintergrund setzt die MMC dabei das Feld " msExchReplicateNow" auf TRUE, d.h. der RUS wird indirekt angewiesen etwas zu tun. Setzt die MMC den Eintrag auf dem "falschen" DC. dann kann es eine AD-Replikation dauern, bis der RUS aktiv wird. Der RUS setzt das Feld nach wieder auf FALSE zurück.

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.

  • Rebuild/Neu bilden
    Hierbei werden alle Adressen anhand der Richtlinien neu gebildet. Auch Objekte, die in der Zwischenzeit nicht geändert wurden, werden neu gestempelt. Dies bedeutet mehr Aufwand, mehr Zeit, mehr Belastung und sollte nur in Ausnahmefällen durchgeführt werden, z.B.: wenn umfangreiche Änderungen an den Empfängerrichtlinien einen Neuaufbau sinnvoll machen.
    Auch hier wird im Hintergrund nun das Feld "msExchDoFullReplication" aus TRUE gesetzt. Eventuell dauert es durch die AD-Replikation etwas, bis der RUS dies erkennt, startet und das Feld wieder auf "FALSE" setzt.

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.

  • Apply Now/Eine spezielle Richtlinie Aktualisieren.
    Zusätzlich können Sie aber auch auf einer Richtlinie selbst diese aktualisieren. Dieser Prozess ist aber etwas umfangreicher, da sich der RUS nun die bisherigen Adressen zwischenspeichert (ToDo-List) und alle Objekte (nicht nur die geänderten) durchgeht, um die Richtlinie anzuwenden.
     

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:

  • Q328738 XADM: How the Recipient Update Service Applies Recipient Policies

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.

  • Enterprise RUS
    Der Enterprise RUS sorgt für die allgemeine Aktualisierung der Exchange Systemobjekte
  • Domain RUS
    Der Domain RUS für die Aktualisierung der Empfänger einer Domäne.
  • weitere Domain RUS
    Je weiterer Domäne ist manuell ein weiterer RUS einzurichten, damit auch diese Empfänger dort mit Mailadressen versehen werden. Dazu ist ein DOMAINPREP in der entsprechenden Domäne notwendig, damit der RUS die Rechte auf die Objekte hat.

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 können. 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 für 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 für 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

  • 294792 Multiple recipient Update services in a single domain

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:

  • MSExchangeAL\LDAP Operations
  • MSExchangeAL\Address List Synchronization
  • MSExchangeSA\Proxy Generation (Nur Exchange 2003)

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:

  • Alle anderen Diagnoseeinstellungen auf "kein"
  • MSexchangeAL/Address List Synchronisation auf Mittel

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.

  • RUSMon
    Überwachen der wichtigen Eventlogs per VBScript

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:

  • Der RUS ergänzt immer nur Adressen. Bestehende Adressen werde nicht entfernt, d.h. auch von ihnen manuell vergebene Adressen werden nicht entfernt oder bearbeitet
  • Der RUS vergibt nur Mailadressen, die es noch nicht gibt. Dazu prüft er im AD die Adressen. Er zählt dann einer weiter hoch (admin1@firma.de etc.
  • Den RUS können Sie komplett deaktivieren.  Dies ist aber nicht ratsam. Sie können auch pro Benutzer den RUS ausnehmen.

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:

  • 837391 Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution für full functionality
  • 294222 Recipient Update Service does not process Users in remote Windows 2000 domains

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 für 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.

  • TechNet Support WebCast: How to Troubleshoot the Recipient Update Service
    http://support.Microsoft.com/default.aspx?kbid=897548 Thursday, May 26, 2005: 10:00 AM
  • Management von Empfängern mit Exchange 2000
    http://www.Microsoft.com/exchange/techinfo/administration/2000/recipmanage.asp
    http://www.Microsoft.com/exchange/techinfo/administration/2000/Recipient_Mgmt.doc
    http://www.Microsoft.com/exchange/using/tips/Sec_RUS.asp
  • Recipient Update Service and Exchange Server 2003
    http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3AdminGuide/bf704ad5-e211-41ce-835f-59b558b6ccca.mspx
  • Interessant, dass Microsoft auch solche Detailinfos mittlerweile bereitstellt. Meine INfos durfte ich vor ein paar Jahren noch selbst "herausfinden"
    http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3TechRef/a75e48d7-64bb-4040-9b6a-2c9f2c02b565.mspx
  • 153270  XFOR: Internet Mail Connector Proxy Generator Options
  • Q246127 XADM: How to Check the Progress of the Recipient Update Service
  • Q249299 XADM: How to Configure Recipient Policies in Exchange 2000
  • Q251395 XADM: Summary of the Exchange 2000 Recipient Update Service
  • 251770 Tasks performed by the Exchange Recipient Update Service
  • Q251943 XADM: Proxy Addresses Do Not Appear on Mailboxes Immediately
  • Q252395 XADM: Creating Recipient Policies Based on Administrative Group
  • Q253770 XADM: Tasks Performed by the Recipient Update Service
  • Q253827 XADM: How Exchange Hides Group Membership in Active Directory
  • Q253828 XADM: How the Recipient Update Service Populates Address Lists
  • Q253838 XADM: How the Recipient Update Service Applies System Policies
  • 254030 Missing permissions cause the Recipient Update Service not to process accounts in Exchange 2000 Server and Exchange Server 2003
  • 255719 XADM: Description of Exchange 2000 Server Recipient Update Service
  • Q258705 XADM: Site Addressing Is Generating Incorrect SMTP Address für "%g.%s.%m"
  • Q261185 XADM: Errors Logged When RUS Can't Update Certain User Objects
  • Q271339 XADM: Cannot Mount Database and Event ID 9546 Occurs
  • Q274301 XADM: Public Folder ist not Successful
  • Q275294 XADM: Recipient Update Service Is Not Created Automatically
  • Q278838 XCON: Cannot Send Mail to SMTP Domain That Is the Same as the Local Exchange Organization Domain
  • Q283134 XADM: Recipient Update Service Does Not Create Proxy Addresses
  • Q285136 XADM: How to Customize the SMTP E-mail Address Generators Through Recipient
  • Q285355 XADM: How to Modify Recipient Polices to Customize SMTP E-mail Addresses
  • Q286356 XADM: Recipient Update Service Does Not Stamp Proxy Addresses
  • Q288175 XCON: Recipient Policy Cannot Match the FQDN of Any Server in the Organization, 5.4.8 NDRs
  • Q291842 XIMS: SMTP Proxy Addresses Are Deleted für All Users
  • Q294222 XADM: Recipient Update Service Does Not Process Users in Remote Windows 2000 Domains
  • Q294792 XADM: Multiple Recipient Update Services in a Single Domain
  • Q296479 XADM: Requirements für Disabling the Recipient Update Service
  • Q297124 XADM: Recipient Update Service Does Not Stamp Users and No Error Is Logged
  • Q297987 XADM: RUS Creates Duplicate Secondary SMTP Addresses
  • Q306866 HOWTO: Start the RUS Programmatically
  • Q309723 Recipient Update Service does not stamp contacts with new primäry SMTP address
  • Q315591 XCON: Authoritative and Non-Authoritative Domains in Exchange 2000
  • Q316350 XADM: The Recipient Update Service Does Not Work in an Environment That Contains More Than 800 Domain Controllers
  • Q316886 HOWTO: Migrate from Exchange Server 5.5 to Exchange 2000 Server
  • Und weitere Artikel mit dem Suchbegriff "RUS" in der Exchange 2000 Knowledgebase
  • Q319065 HOW TO: Work with the Recipient Update Service in Exchange 2000
  • Q321721 XCON: Sharing SMTP Address Spaces in Exchange 2000
  • 319065 How to work with the Exchange Recipient Update Service
  • 328223 HOW TO: Make Sure That There Are Correct Permissions in Recipient Update Service
  • Q328738 XADM: How the Recipient Update Service applies recipient policies
  • Q820381 The secondary SMTP proxy e-mail address is not stamped on migrated objects
  • 821743 XADM: The gatewayProxy attribute on the Recipient Update Service object is not cleared
  • 821908 How To Verify That the Recipient Update Service Is Working Correctly
  • 823153 HOW TO: Work with the Recipient Update Service in Exchange Server 2003
  • 822794 How to troubleshoot the Recipient Update Service by using the Application log in Exchange 2000 Server or in Exchange Server 2003
  • Q831809 Exchange 2000 Recipient Update Service does not replicate changes successfully in forest functional level 1 or 2 in Windows Server 2003 Active Directory
  • 873059 The Recipient Update Service does not Update objects correctly when Exchange 2000 Server is running in a Windows Server 2003 forest
  • 924102 The Recipient Update Service seems to slow down when you perform a rebuild operation in Exchange Server
  • Troubleshooting the Recipient Update Service (RUS) using Event Logs
    Part 1 http://blogs.msdn.com/exchange/archive/2004/07/07/175444.aspx
    Part 2 http://blogs.msdn.com/exchange/archive/2004/07/15/184356.aspx
    Part 3 http://blogs.msdn.com/exchange/archive/2004/07/22/191513.aspx
    Part 4 http://blogs.msdn.com/exchange/archive/2004/07/27/198662.aspx
  • Good bye RUS
    http://blogs.technet.com/b/exchange/archive/2006/10/02/429053.aspx
  • The Recipient Update Service and Exchange 2007
    http://telnetport25.wordpress.com/2008/08/04/the-recipient-update-service-and-exchange-2007-it-broke-a-bit-event-ids-8270-8315/