Exchange 2000/2003 Empfängerrichtlinien

Das Prinzip der Richtlinien und des RIS hat sich mit Exchange 2007 geändert. Siehe E2K7 Empfängermanagement

In der Exchange 5.5 Welt war alles etwas einfacher. Wenn der Administrator einen Benutzer in Exchange angelegt hat, dann hat das Verwaltungsprogramm auch gleich eine Mailadresse anhand einer Vorgabe in der Standortadressierung angelegt und gespeichert. Exchange 2000 und höher ist nun aber im Active Directory integriert und damit nicht mehr alleine für das Anlegen von Benutzern zuständig. Auch andere Prozesse können Benutzer verwalten.

Damit wändert die Zuständigkeit, einem Benutzer eine Mailadresse zu geben weg von der ausführenden Person hin zum System selbst. Sobald ein Benutzer für Exchange aktiviert wird, muss der Dienst zu Empfängeraktualisierung (Recipient Update Service = RUS tätig werden und die Mailadressen eintragen. Was er wie einzutragen hat, konfiguriert der Administrator über die Empfängerrichtlinien für die gesamte Organisation. Sie können mehrere Richtlinien eintragen und

  • Empfängerrichtlinien
    Mit diesen Einstellungen steuern Sie die Generierung von Mailadressen bei den Empfängern ihrer Exchange Organisation. Diese Richtlinien werden hier im folgenden genauer beschrieben
  • Mailboxrichtlinien und Mailbox Manager
    Hiermit steuern Sie die Einstellungen über die Mailboxinhalte, z.B.: wie groß bestimmte Ordner im Postfach sein dürfen. Der Mailbox Manager löscht dann ältere Inhalte anhand dieser Richtlinien
  • Serverrichtlinien
    In Exchange können Sie auch als Administrator unabhängig von den Empfänger Richtlinien auf Server vorgeben. Damit können Sie z.B. bestimmte Servereinstellungen vorgeben und auf mehrere Server anwenden.
    Serverrichtlinien

Hier werden im weiteren die Empfängerrichtlinien für die Steuerung des RUS besprochen.

Grundlagen

Das Prinzip der Empfängerrichtlinien basiert darauf, dass der RUS über LDAP-Abfragen eine Menge an Empfängern ermittelt und diesen die vorgegebenen Adressen vergibt. Dazu arbeitet der RUS alle Richtlinien von oben herab ab. Sobald ein Empfänger in ein Richtlinie fällt, wird diese angewendet und keine weiteren Richtlinien mehr für diese Objekt angewendet. Damit wird je Objekt immer nur genau eine Richtlinie angewendet und zwar die höchste der Reihenfolge.

An der höchsten Stelle stehen die Richtlinien, welche durch die Migration und Koexistenz von Exchange 5.5 übernommen werden und die Funktion der Standortortadressierung von Exchange 5.5. übernehmen. Diese Richtlinien können nicht geändert werden. Solange die Exchange 2000 Organisation im Mixed mode läuft. Erst wenn in einer Administrativen Gruppe kein Exchange 5.5 Server mehr ist, kann die Richtlinien für diese Administrative Gruppe entfallen und die volle Flexibilität genutzt werden. D.h. solange eine administrative Gruppen einen Exchange 5.5 Empfänger enthält, erhalten alle Empfänger in dieser administrativen Gruppe IMMER die Adressen der Exchange 5.5 Richtlinie. Zusätzliche Richtlinien greifen NICHT. !! Dies gilt solange in der administrativen Gruppe noch mindestens ein Exchange 5.5 Server vorhanden ist.

Für alle anderen Empfänger kann der Administrator selbst Richtlinien anlegen, welche in der Reihenfolge abgearbeitet werden. Dazu durchläuft der RUS regelmäßig alle Objekte im globalen Katalog und prüft, ob Anpassungen notwendig sind. Dazu evaluiert er die Eigenschaften des Objekt gegen die Filterkriterien der Empfängerrichtlinien und wendet diese an. Geeignete Filter sind z.B. die Bezeichnung der Felder "Abteilung" oder "Ort" bei den Anwendern, was natürlich eine saubere Pflege dieser Felder erfordert.

Bitte verwenden Sie NICHT das Feld "HomeMDB" für die Erstellung von Filtern einer Richtlinie. Wenn ein Benutzer "Exchange Enabled" wird, dann werden durch den Exchange System Manager alle Felder gefüllt. Bei der Replikation zu anderen DCs kann es aber passieren, dass diese Feld nicht sofort mit repliziert wird. Der Rus wird dann auf diesem DC einen neuen Benutzer erkennen aber die falsche Richtlinie anwenden. Kommt dann das Feld etwas später nach, dann werden die Richtlinien nicht mehr geändert. Diese "Fehlkonfiguration" meldet ihnen auch ExBPA.

Bildungsregeln für die Adressen

Der RUS orientiert sich an den Einträgen in den Empfängerrichtlinien. Dabei übernimmt der RUS die Einträge der zum Empfänger gehörenden Richtlinie und bildet daraus die Adressen. Sie können in einer Richtlinie mehrere Adressen definieren. Eine Adresse pro Typ ist dabei die primäre Adresse:

Die Bildungsregel können Sie durch Platzhalter in gewisser Weise steuern. Hier eine Auswahl:

  • %g Vorname
  • %s Nachname
  • %i Initialen
  • %m Alias bzw. Anmeldename
  • %d Anzeigename
  • %rxy ersetzt das Zeichen X durch Y.
    Wenn x und y gleich sind, wird das Zeichen gelöscht. Exchange muss auf jeden Fall sicher stellen, dass die Mailadressen konform zur RFC 821/822 sind.

Kombinieren Sie daher z.B. %g.%s@firma.de, so werden die Mailadressen danach aus Vorname.Nachname@firma.de bestehen. Umlaute werden umgesetzt. Die Nutzung der Variablen kann noch angepasst werden, z.B. mit "%1g.%s@firma.de" wird der erste Buchstaben des Vornahmen und der Nachname kombiniert. Das Ergebnis wäre dann z. B. f.carius@firma.de

Zeichen in den Quelldaten Zeichen in der SMTP-Mailadresse

Leerzeichen

Bindestrich

A-Z bzw. a-z

A-Z bzw. a-z

ä, ö, Ü bzw. ä, ö, ü, ß

Ae, Oe, ue bzw. ae, oe, ue, ss

áàâ bzw. ÁÀÂ

a bzw. A

éèê bzw. ÉÈÊ

e bzw. E

íìî bzw. ÍÌÎ

i bzw. I

óòô bzw. ÓÒÔ

o bzw. O

úùû bzw. ÚÙÛ

u bzw. U

§
μ

S
M

Andere Sonderzeichen

Werden übernommen, wenn RFC konform

" ( ) ´ [ ] : . < > , ;

Entfallen komplett

Großbuchstaben werden als Anfangsbuchstaben des Vor- und Nachnamens übernommen.

Abweichend hiervon werden bei den X.400 Adressen gebildet, die aber für die Funktion von Exchange 2000/2003 eigentlich nicht mehr erforderlich sind. Nur bei der Anbindung an ein X.400 MTA-System (kommen z.B.: noch bei Banken, öffentlichen Verwaltungen etc. vor) ist die Adresse von Belang. Sie muss allerdings generiert und vorhanden sind.

Die Änderungen können aber etwas dauern, bis alle Mailadressen umgestellt sind. Der RUS muss dazu alle Empfänger auf den das Filterkriterium zutrifft anpassen. Diese Änderungen im AD müssen wieder repliziert werden in im Globalen Katalog auftauchen. Den RUS kann man antriggern, damit zumindest der erste Schritt schneller gestartet wird. für das AD kann man mit REPLMON nachhelfen.

Ehe er die Adressen dann zurück schreibt, prüft der RUS natürlich die Eindeutigkeit mit Hilfe des globalen Katalogs. Dies kann manchmal nicht funktionieren, wenn das AD nicht synchron ist oder zwei RUS-Dienste an verschiedenen Standorten gleichzeitig den gleichen Benutzer oder gleichnamige Benutzer bearbeiten. Dann passiert es tatsächlich, dass zwei Objekte die gleiche Mailadresse haben. Ein entsprechender Eintrag im Eventlog weist darauf hin, wenn eine Mail an die Adresse empfangen wird.

Beachten Sie unbedingt die Details beim MSXFAQ.DE - Exchange RUS, wann Anderungen an der Richtlinie aktiv werden und welche Objekte geändert werden.

Bedeutung der Default Policy

Es gibt immer eine "Default Recipient Policy", welche ganz unten steht und damit nur dann auf ein Objekt angewendet wird, wenn keine andere Richtlinie greift. Bitte ändern Sie diese Richtlinie nie, da es jede Menge Objekte im Exchange 2000 System gibt, welche eine Mailadresse benötigen (z.B. Systemaufsicht etc.), und ohne deren Funktion die Probleme eher größer werden. (Siehe auch Q271339 XADM: Cannot Mount Database and Event ID 9546 Occurs).  Wenn Sie allen Benutzern, Verteilern und Ordnern neue Adressen geben wollen, dann sollten Sie eine neue Richtlinie anlegen, welche alle Empfänger als Filter nutzt.

Der „Default Policy“ kommt dabei die besondere Rolle zu, dass die primäre SMTP-Domäne dieser Richtlinie an mehreren Stellen des Systems verwendet wird, und wie sich eine Änderung auswirkt:

  •  OWA/OMA-Zuordnung
    Jeder Anwender benötigt zum Zugriff auf die Default URLs (/Exchange und /OMA) eine Mailadresse der Default Richtlinie.

Update: Seit Exchange 2003 SP2 scheint dies nicht mehr erforderlich zu sein. Hier kann jeder OWA nutzen, wenn er sich erfolgreich anmelden kann, auch wenn er keine Mailadresse der default Policy mehr hat.

  • DirSync-Nachrichten des SRS (servername-SRS@smtpdomain.tld)
    Spätere Änderungen setzen die Replikation mit Exchange 5.5 Servern für einige Zeit außer Kraft, da der Exchange 2003 Server z.B.: schon die neue Adresse des Gegenüber nutzt, aber dieser die Änderung noch nicht mitbekommen hat (AD-Replikation und Caching), so dass DirSync Nachrichten etwas stocken bzw. für einige Zeit verzögert ablaufen. In der Regel fängt sich Exchange wieder.
  • Public Folder Replikationnachrichten zwischen des Informationsspeichern.
    Spätere Änderungen setzen die Replikation für einige Zeit außer Kraft, da auch der Public Folder Speicher eine Mailadresse hat, die sich ändert. Ein Store kann daher die Mails schon an einen anderen Server mit der neuen Adresse senden, die der andere Server noch nicht eingelesen hat. Die Replikation berücksichtigt solche Aussetzer und sendet die nicht zugestellten Nachrichten erneut. (siehe auch öffentliche Ordner)
  • M:-Laufwerk (Exchange 2000)
    Programmatische Zugriffe auf den WebStore können zum Teil die SMTP-Domäne referenzieren. Eine nachträgliche Änderung kann daher solche Anwendungen stören.
  • Und einige weitere Systemobjekte

Aufgrund dieser engen Verzahnung ist es zwingend erforderlich, dass die primäre SMTP-Domäne der Default Richtlinie immer autoritativ ist. Dazu weiter untern mehr. Eine Änderung der SMTP-Adresse ist möglich, bedeutet aber eine höhere Belastung, da der RUS nach der Änderung alle Einträge der Server aktualisiert.

Eine wichtige Sache sollten Sie noch wissen:

Nutzen Sie NICHT SMTP-Adressen der Form "*@servername.firma.de" oder ähnliches. In vielen Unix-Umgebungen werden häufig Servernamen als Mailadresse verwendet, wenn ein Benutzer auf einem Mailserver sein Postfach hat anstatt dem MX-Eintrag. Bei gemischten Systemen wird häufig auch diese Adressierung genutzt, um Mails weiter zu leiten. All dies wird bei Exchange zu Problemen führen, da der SMTP-Server diese Mails an den Server zustellt, auch wenn das Postfach nicht dort liegt. Daher ist der Name eines SMTP bzw. Exchange Servers in einer Mailadresse eine sehr schlechte Idee, es sei denn sie können für immer sicherstellen, dass das Postfach auch auf diesem Server liegt. (Das schaffen Sie NIE !)
Siehe auch Q288175 XCON: Recipient Policy Cannot Match the FQDN of Any Server in the Organization, 5.4.8 NDRs

Empfängerrichtlinien und SMTP

Die Einstellungen in den Empfängerrichtlinien sind auch für die Kommunikation über SMTP essentiell wichtig. Alle SMTP-Server einer Exchange Organisation lesen die Liste der Empfängerrichtlinien aus, fassen alle dort angegebenen SMTP-Domänen zusammen und werten diese bei eingehenden Nachrichten aus.

Die Exchange Server nehmen per Default nur Nachrichten für die SMTP-Domänen an, die in den Empfängerrichtlinien definiert sind. Wenn Sie also manuell einem Benutzer intern eine zusätzliche SMTP-Adresse vergeben, dann ist diese trotzdem nicht zu erreichen. Um solche Mails trotzdem anzunehmen, reicht es aus, diese SMTP-Domäne in eine Empfängerrichtlinie mit aufzunehmen. Allerdings bedeutet das auch, dass alle Personen, die durch diese Richtlinie versorgt werden, eben diese SMTP-Domäne zusätzlich bekommen. Um dies zu verhindern ist es besser, eine neue Empfängerrichtlinie anzulegen und dort diese SMTP-Domäne zu hinterlegen. Über einen geeigneten LDAP-Filter können Sie sicherstellen, dass es keine Empfänger für diese Richtlinie gibt, z.B.:

(&
  (&
    (&
      (& (mailnickname=*) 
         (| 
           (&
             (objectCategory=person)
             (objectClass=User)
             (|
               (homeMDB=*)
               (msExchHomeServerName=*)
             )
           )
         )
       )
     )
   (objectCategory=User)(samAccountName=DonaldDuck*)
   )
)

So können Sie Exchange dann mitteilen, dass er Mails für diese Domain annehmen soll aber Sie manuell die Mailadressen bei den Empfängern pflegen. Bedenken Sie aber, dass eine Richtlinie immer für die Objekte angewendet wird.

Wenn Sie jedoch Exchange dazu nutzen möchten, Mails für eine bestimmte Domäne einfach nur als Relay weiter zu leiten oder per ETRN zur Abholung bereit zu halten, dann ist hierzu ein eigener SMTP-Connector zu konfigurieren, der diese Domäne als Adressraum hat und die Option "relay Erlauben" aktiviert ist.

Das ist der bessere Weg eine Domain über Exchange als Relay anzubinden.

  • Q260973 XCON: SMTP Domains für Inbound and Relay in Exchange 2000

Ich habe schon Probleme gesehen, wenn sie nun einfach eine Richtlinie mit %s.%g@firma.tld eingesetzt haben, dass Exchange sich nicht zuständig gefühlt hat. Insofern sollten sie immer SMTP:@firma.tld mit aktiviert lassen.

Eine kleine Besonderheit gibt es hier in Verbindung mit der Konfiguration als Relay zu vermelden. Wenn Sie auf dem virtuellen SMTP-Server einer IP-Adresse erlauben,  dass dieses System ihr Exchange als Relay verwenden darf, dann werden die Mails von diesem System auch angenommen, wenn die Zieldomäne nicht durch Empfängerrichtlinien vorgegeben ist.
Wurde die Mail aber schon mal angenommen, dann stellt Exchange die Nachricht intern zu, wenn es einen Empfänger in der Organisation findet. Dies der einzige Fall, bei dem ein Postfach mit einer manuell vergebenen fremden SMTP-Adresse auch unter dieser Adresse zu erreichen ist.
Dies ist aber keine dokumentierte Verwendung und soll Sie nicht davon abhalten, die intern verwendeten SMTP-Adressen in den Richtlinien zu konfigurieren.

Autoritativ oder nicht ?

Nun kann es aber sein, dass es Empfänger in ihrer Organisation und einem anderen System gibt, die die gleiche SMTP-Domäne nutzen. Dann ist eine Lösung gefragt, wie Exchange mit dem anderen System die Adressen teilen kann. Und genau hier kommt der Begriff "autoritativ" ins Gespräch. Damit wird Exchange mitgeteilt, ob er alleine für diese Domäne zuständig ist, oder nicht. Dies wird bei der SMTP-Domäne in der Empfängerrichtlinie eingestellt:

Dies bedeutet:

  • Autoritativ
    Die Exchange Organisation ist alleine zuständig für die Nachrichten an diese Domäne. Jede Mail, die von Exchange Empfangen wird, wird intern zugestellt. Ist der Empfänger nicht für Exchange bekannt, ist die Mail unzustellbar. Es ist nicht möglich, solche Nachrichten einfach an ein anderes System, weiter zu geben.

  • Nicht autoritativ
    Exchange ist nicht alleine für diesen Adressraum zuständig und Nachrichten an Empfänger, die nicht innerhalb der Organisation aufgelöst werden können, können an ein anderes System weitergegeben werden.

Dabei gilt es zu beachten:

Exchange 2000 must always be authoritative für the primäry SMTP address
(the one in bold) on the default recipient policy. Otherwise, local mail
flow may not occur

Dazu zählen dann auch folgende TechNet Artikel:

  • Q278838 XCON: Cannot Send Mail to SMTP Domain That Is the Same as the Local Exchange Organization Domain
  • Q315511 XADM: How to Set up Centralized SMTP Domain Sharing in Exchange 2000 Server für Independent Organizations
  • Q315591 XCON: Authoritative and Non-Authoritative Domains in Exchange 2000
  • Q321721 XCON: Sharing SMTP Address Spaces in Exchange 2000
  • Q319759 XADM: How to Configure Exchange 2000 Server to Forward Messages to a Foreign Messaging System That Shares the Same SMTP Domain Name Space

Daher ist es eventuell sinnvoll, eine eigene Empfängerrichtlinie für die normalen Empfänger vor die "Default"- Richtlinie zu konfigurieren, damit die Benutzer eine passende Mailadresse erhalten während die Systemkonten (Systemaufsicht etc.) auch eine gültige Adresse erhalten.

  Firma.de         1     SMTP:%s.%g@firma.de         Filter: User/DL/PF
  Default Policy lowest  SMTP:%s.%g@exchange.intern  Filter: none

So sollten alle Benutzer, Verteiler (DL) und öffentlichen Ordner (PF) eine Mailadresse in der Art "Vorname.Nachname@firma.de" erhalten und alle anderen Objekte (unter anderem auch die Exchange Systemobjekte) die "local-Adresse". Dann können Sie auch problemlos Mails weiterleiten.

Hierbei gibt es dann nur das Problem, dass auch der "Postmaster" die "Default Policy" nutzt und damit alle unzustellbarkeitquittungen mit eben dieser Mailadressen versendet werden. Wenn diese Domäne nicht gültig ist, dann bedeutet dies, dass die Quittung in den meisten Spamfiltern und vielen Mailservern nicht angenommen wird. Insofern ist es abzuwägen, wenn ihre primäre Maildomäne nicht exklusiv für Exchange genutzt wird, und eine Weiterleitung erforderlich ist, nicht eine zweite Domäne für sonstige Dinge genutzt wird.

Eine kurze Übersicht soll ihnen die einzelnen unterschiede, Vor- und Nachteile erläutern, wenn die Default Policy eine Hilfsdomäne oder ihre produktive SMTP-Domäne ist. Folgende drei Ansätze werden gegenüber gestellt:

  • Die eigene SMTP-Domäne ist autoritativ und primär
    Es gibt keine weitere Hilfsdomäne.
  • Eine Hilfsdomäne ist autoritativ aber NICHT primär
    Die eigene SMTP-Domäne ist autoritativ und primär
    Als autoritative Domäne für die interne Verwendung wird eine private Domäne genutzt.
  • Eine Hilfsdomäne ist autoritativ und primär
    Die eigene SMTP-Domäne ist NICHT autoritativ und nicht primär.
    Als autoritative Domäne für die interne Verwendung wird eine private Domäne genutzt.

Hinweis: firma.tld steht für die eigentliche Mailadresse, firma.local steht für eine fiktive interne Adresse, SMTP bezeichnet die primäre, „smtp“ eine sekundäre Adresse. Autoritative Domänen sind mit einem "A-" gekennzeichnet

  A-SMTP: firma.tld A-SMTP firma.local
A-smtp firma.tld
A-SMTP firma.local
smtp firma.tld

Interne Übermittlung

Ja

Ja

Ja

Externe Empfänger über Kontakte

indirekt über Hilfsadresse

indirekt über Hilfsadresse

indirekt über Hilfsadresse

Externe Empfänger direkt per SMTP firma.tld

NEIN

NEIN

JA

Externe Empfänger direkt per SMTP

User@hostname o.ä.

User@hostname o.ä.

User@hostname o.ä.

AddressSharing

NEIN

NEIN

Ja

Risiko von Mailschleifen

NEIN

NEIN

Ja

Ungültige Adressen ablehnen (REJECT)

Ja

Ja

NEIN

Sicherheit

Hoch

Hoch

Externem System muss vertraut werden

Alle im Adressbuch

Ja

Ja

Nicht zwingend

Export an DMZ

Ja

Ja

Exchange und Nachfolgesysteme

OWA-Zugriff über /Exchange

Alle Empfänger müssen eine firma.de haben

 

Alle mit firma.local

Alle mit firma.local

 

Firmenadresse für unsichere Personen

Ja, wenn OWA mit /Exchange genutzt werden muss etc

Firma.local reicht

Firma.local reicht

M:-Laufwerk

firma.tld in BaseDir

firma.local in BaseDir

firma.local in BaseDir

Spätere Änderung der Mailadresse zu firma.tld

Kurzfristige Störungen zu erwarten

Kein Einfluss

Kein Einfluss

Lesen Sie passend dazu auch Informationen über das Routing in Exchange unter Exchange 2000 MTA und Routing.

Wird eine SMTP-Domäne in mehreren Richtlinien genutzt, und eine ist davon als autoritativ gekennzeichnet, während eine andere Richtlinie die gleiche Adresse als „nicht autoritativ“ gekennzeichnet hat, dann ist die Domäne für die gesamte Organisation als autoritativ zu zählen.

Richtlinien für Kontakte

Sehr oft werden im Active Directory neben Benutzern mit Postfächern auch Kontakte angelegt. Werden diese Kontakte auch für Exchange aktiviert, dann werden diese auch vom RUS verarbeitet. Und damit bekommen diese Kontakte auch eventuell eine Mailadresse in ihrer Domäne. Gerade bei größeren Firmen kann es dann natürlich passieren, dass ein Kontakt den gleichen Namen hat, wie ein später dann eingestellter Mitarbeiter. Die Mailadresse ist natürlich dann schon durch den Kontakt belegt. Daher kann es sinnvoll sein, eine Richtlinie anzulegen, die für Kontakte eine ganz andere Mailadresse vergibt, z.B. mit einem Prefix oder sogar einer abweichenden SMTP-Domain. Diese hat ja nichts mit der Zieladresse des Kontakts zu tun.

Empfängerrichtlinien und Exchange 5.5

Empfängerrichtlinien sind bei einer neuen Exchange 2000/2003 Installation sehr einfach anzuwenden. Allerdings werden viele Exchange Organisationen über einen gemischten Modus migriert. In diesem Fall muss eins Zusammenarbeit der Empfängerrichtlinien unter Exchange 2000/2003 und der Standortadressierung unter Exchange 5.5 gefunden werden. Und genau das macht das Exchange Setup bei der Installation automatisch. In diesem Beispiel haben wir eine Exchange 5.5. Standortadressierung:

Innerhalb von Exchange 5.5 kann es nur genau eine SMTP-Adresse pro Standort geben. Zudem muss sichergestellt sein, dass die Adressen der Exchange 5.5 Empfänger, die Exchange 5.5 vergibt auch nicht in Konflikt mit Exchange 2000/2003 stehen. Der ADC ist natürlich dafür zuständig, dass die Informationen in das Active Directory repliziert werden. Aber trotzdem kann auch der Exchange 2000/2003 RUS diese Objekte sehen und anfassen. Spätestens wenn so ein Anwender dann nach Exchange 2000/2003 migriert wurde, muss der RUS diese Zuständigkeit übernehmen. Damit im gemischten Betrieb keine Probleme auftreten, legt das Exchange Setup für jeden Exchange 5.5 Standort eine entsprechende Empfängerrichtlinie mit der "höchsten Priorität" an:

Diese Richtlinie muss bestehen bleiben, solange in dieser administrativen Gruppe noch ein Exchange 5.5 Server, bzw. ein Exchange SRS vorhanden ist. Seit Exchange 2003 ist es aber erstmals möglich, diese Empfängerrichtlinie zu ändern. Dies ist auch wichtig, da  z.B. migrierte Anwender weiterhin von dieser Richtlinien bedient werden und es damit ansonsten nicht einfach möglich ist, zusätzliche Adressen zu vergeben. Das ist z.B. auch für OWA notwendig. Daher können Sie Seit Exchange 2003 zusätzliche SMTP-Adressen hinzufügen. Allerdings werden diese Änderungen dann NICHT nach Exchange 5.5 zurück repliziert. Der Exchange System Manager warnt daher auch noch einmal explizit bei dieser Änderung:

Sie können dann aber problemlos sekundäre SMTP-Adressen hinzufügen. Das GUI lässt sogar die Änderung der primären SMTP-Adresse zu. Hiervon rate ich ab, da nur wenige Personen wirklich die Auswirkungen und Effekte genau können. Nur soviel sei gesagt: Die Änderung wird in die Exchange 5.5 Standortadressierung übernommen!

Wurde über diesen Weg eine weitere SMTP-Adresse in einer höchste Empfängerrichtlinie bei Exchange 2003 hinzu gefügt, so werden die auch die Exchange 5.5 Empfänger im Active Directory mit dieser neuen zusätzlichen Adresse versehen und der ADC sorgt dafür, dass diese Adresse dann auch nach Exchange 5.5 repliziert wird.

Die Exchange 5.5 Einstellungen bei den Empfängern folgen also der Exchange 2003 Einstellung. Bei Exchange 2000 war dies noch nicht so, aber könnte ab einem bestimmten Servicepack verfügbar werden.

Es ist also gut zu sehen, dass der RUS auch Objekte anfasst, die eigentlich durch die Exchange 5.5 Standortadressierung mit Adressen versehen werden. Daher ist auch hier eine Bidirektionale ADC-Replikation für die Funktion wichtig. Das wird um so mehr deutlich, wenn Sie einen Benutzer mit der MMC unter Windows 200x anlegen und für Exchange aktivieren und dabei einen Exchange 5.5 Server auswählen. Der ADC repliziert den Eintrag schon nach Exchange 5.5, selbst wenn der RUS das neue Konto noch nicht bearbeitet hat. Das Konto hat unter Exchange 5.5 dann schon die Standortadressierung. Es kann dann durchaus passieren, dass der RUS im nachhinein die Mailadressen beim Active Directory Objekt vergibt und hier auch die sekundäre SMTP-Adresse einträgt. Bei einer weiteren Replikation wird diese Änderung ebenfalls nach Exchange 5.5 repliziert. Sie sehen also dass auch hier der RUS und die Exchange 5.5 Standortadressierung Hand in Hand arbeiten.

Wenn Sie am Ende der Migration dann alle Exchange 5.5 Server und SRS-Server deinstalliert haben, dann können Sie die Empfängerrichtlinien wieder wie gewohnt sehr frei und flexibel konfigurieren. Wenn Sie dann aber diese Exchange 5.5 Richtlinien entfernen möchten, dann sollten Sie schon sehr sicher sein, dass die nachfolgenden Richtlinien die Mailadressen der Anwender nicht in unvorhergesehener Weise verändern. Zwar verliert ein Anwender niemals eine Mailadresse, aber es reicht schon, wenn die primäre Adresse des Anwenders geändert wird. Ein "was wäre wenn" Simulator gibt es hierzu leider nicht.

Best Practice

Es gibt eigentlich keine wirkliche "Best Practice" für Empfängerrichtlinien, da jede Firma individuelle Anforderungen hat. Aber einige Punkte kann man schon empfehlen:

Kleine Firma

  • Eine Default Richtlinie
    Passen Sie am besten die Standardrichtlinie so an, dass sie ihrer SMTP-Adresse entspricht.

Mittlere Firma

  • Eine Default Richtlinie
    Passen Sie am besten die Standardrichtlinie an, dass
  • Weitere Richtlinien
    Für Benutzer und feinere Einstellungen weiterer SMTP-Adressen können Sie weitere Richtlinien anlegen. Achten Sie aber immer darauf, dass auch die SMTP-Domäne der Default-Richtlinie dabei ist, damit OWA/OMA funktioniert

Große Firma/Hoster

  • exchange.system als Default
    Vermeiden Sie die Nutzung einer echten SMTP-Domäne, die sie vielleicht später einmal nicht autoritativ nutzen möchten und für OWA sollten Sie auch eine private SMTP-Domäne andenken
  • "MailDomains"-Policy
    Legen Sie vielleicht eine zweite Richtlinie an, in der sie einfach alle Domains, für die Sie zuständig sind, eintragen. Damit sind Sie sicher, dass ihr Exchange SMTP-Server wirklich Mails an diese Domains annehmen
  • UserDomains mit LDAP Filter
    Für das eigentliche Management der Benutzer sollten Sie dann einzelne Richtlinien mit entsprechenden Filtern, z.B. auf den Firmennamen oder ähnliches. Alternativ können Sie natürlich eine eigene Provisioning Anwendung einsetzen.

Richtlinien begrenzen

Der Administrator kann aber auch pro Benutzer abschalten dass der RUS die Adressen anpasst. Dazu kann er auf der Kartekarte "Exchange E-Mail Adressen" die Checkbox für den RUS deaktivieren. dann bleibt es dem Administrator, einem Skript oder anderen Diensten (z.B.: Microsoft Meta Directory) überlassen, die Mailadressen zu pflegen.

Es gibt Umfelder, in denen der RUS für die Domänen komplett abgeschaltet wird, und der Administrator durch andere Methoden die korrekte Einstellung für die Mailadressen sicherstellt. Allerdings sollte der Enterprise RUS nicht abgeschaltet werden und zudem ein genaues Verständnis der Thematik vorliegen, ehe Sie sich dafür entscheiden, den RUS abzuschalten.

Alternativ können Sie bestimmte RUS-Regeln auf Gruppen beschränken.

  • 252395 XADM: Creating Recipient Policies Based on Administrative Group

Empfängerrichtlinien ändern - was passiert

Werden Richtlinien geändert und trifft diese durch die geänderten Filter nicht mehr für bestimmte Objekte zu, so werden die Adressen nicht sofort angepasst, sondern erst, wenn der RUS diesen Benutzer kontrolliert. Dies kann der Administrator auch manuell anstoßen. In der Regel ist dies ein "Update", d.h. der RUS prüft auf neue Objekte in den Domains um diese anhand der Regeln zu konfigurieren.

Neue Richtlinien werden nicht an die Anwender zugewiesen, wenn diese vorher durch eine andere Richtlinie mit einer Adresse versehen wurden. Dies liegt daran, dass sich das Benutzerobjekt durch die neue Richtlinie nicht geändert hat und der RUS daher keine Updates durchführt. Die Richtlinie gilt für alle ab dann geänderten Objekte. Es ist ratsam, in diesem Fall manuell einen Neuaufbau anzufordern. Hierbei werden dann alle Objekte neu "gestempelt". Nur so werden auch alte Objekte, welche sich nicht geändert haben, entsprechend der aktuellen Regeln mit Adressen versehen.

Richtlinien ändern und löschen

Bislang wissen Sie, dass Richtlinien in der Reihenfolge der Priorität verarbeitet werden und beim zutreffen einer Richtlinie nur diese eine angewendet werden. Wenn Sie nun eine Richtlinie ändern, dann würden Sie erwarten, dass Exchange diese neuen Adressregeln auf alle betroffenen Empfänger anwendet. Das tut Exchange auch, wenn Sie die entsprechende Rückfrage bestätigen:

Wenn Sie aber den Filter selbst ändern, dann kann die Situation entstehen, dass Benutzer, die bisher von diese Richtlinie bedient wurden, aus dem Filter heraus fallen. Zwar werden alle Objekte versorgt, die in den Filter fallen, aber Exchange startet nicht einen kompletten Durchlauf über alle Objekte, um diese durch andere Richtlinien zu verwalten. Darauf werden Sie auch explizit hingewiesen:

Sie müssen also schon selbst wissen, welche Objekte durch welche nach geordnete Richtlinie bedient werden. Im Zweifel sollten Sie die nachfolgenden Richtlinien einmal ausführen lassen.

Ein ähnlicher Fall tritt ein, wenn Sie eine Richtlinie komplett entfernen. Auch in diesem Fall wird eine andere Richtlinie die betroffenen Objekte definieren. Auch darauf weißt Sie Exchange hin:

Auch hier müssen Sie selbst die neue Richtlinie ausführen lassen. Diese Aktion führt aber dazu, dass alle Objekte dieser Richtlinie neu angefasst werden. Das kann je nach Anzahl der Objekte und Größe ihrer Installation einige Zeit dauern. Weiter unten finden Sie Hinweise, wie dies zu kontrollieren ist.

Wenn Sie in einer Richtlinie eine Vorlage ändern, deaktivieren, entfernen oder die gesamte Vorlage deaktivieren, so werden die Adressen bei den Benutzern, die bereits vergeben waren NICHT gelöscht. Sie können generell sagen, dass Mailadressen nie wieder durch den RUS gelöscht werden sondern nur neue Adressen hinzugefügt werden.

Exchange 5.5 Standort Adressierung ändern

Wird Exchange in einer gemischten Umgebung betrieben, dann sind zwei Komponenten für die Vergabe von SMTP-Adressen zu ständig:

  • Exchange 5.5 Admin
    Hier können Sie die Standortadressierung ändern, welche der Exchange 5.5 Admin dann auf alle Objekte in diesem Standort anwendet.
  • Exchange 2000/2003 RUS
    Siehe Exchange RUS

Das Problem hierbei ist, dass der ADC die beiden Verzeichnisse "Synchron" halten muss und dies auch tut. Der ADC gleicht aber auch die Konfiguration (ConfigCA) ab und so kann folgendes passieren:

  • Schritt 1
    Sie ändern die Standortadressierung in Exchange 5.5
  • Aktion 2
    Der ADC repliziert diese Änderung in die entsprechende Richtlinie
  • Schritt 3
    Diese Änderung ändert nun alle Mailadressen der betroffenen Objekte.  Zwar geht keine Mailadresse verloren, aber die Einstellung der primären Adresse kann wieder zurück gestellt worden sein
  • Schritt 4
    Der ADC repliziert diese Änderungen natürlich wieder zurück nach Exchange 5.5
  • Schritt 5
    Die Änderungen werden über den Exchange 5.5. DirSync zu allen anderen Exchange 5.5. Servern repliziert

Eine kleine Änderung im Exchange 5.5 Admin kann daher ihre bisherige primäre Mailadresse bei verschiedenen Empfängern ganz schön durcheinander bringen.

msExchPoliciesIncluded und msExchPoliciesExcluded

Bei jedem Objekt, welches durch den RUS bedient wird, werden zwei Felder gepflegt. Sie finden diese z.B. mit ADSIEDIT oder Softerra LDAP. Die Bedeutung der Felder ist schnell erklärt:

  • msExchPoliciesIncluded
    Diese Richtlinien werden gerade auf das Objekt angewendet
  • msExchPoliciesExcluded
    Diese Richtlinien werden nicht angewendet bzw. dürfen nicht angewendet werden

Über diesen Eintrag können Sie schnell erkennen, anhand welcher Richtlinie das Objekt die entsprechenden Einstellungen erhalten hat. Richtlinien gibt es übrigens nicht nur für Mailadressen, sondern auch für den Mailbox Manager. Hier zwei Einstellungen

  • Standardeinträge für einen Benutzer
    msExchPoliciesExcluded ist leer
    msExchPoliciesIncluded: {26491CFC-9E50-4857-861B-0CB8DF22B5D7} und eine GUID der angewendeten Richtlinien (Kommagetrennt)
  • Einträge für einen Benutzer, bei dem der RUS deaktiviert ist (Checkbox unter den Mailadressen):
    msExchPoliciesExcluded={26491CFC-9E50-4857-861B-0CB8DF22B5D7}
    msExchPoliciesIncluded={26491CFC-9E50-4857-861B-0CB8DF22B5D7}

Diese Einträge sind für den RUS auch wichtig um Objekte wieder zu finden. Wenn Sie z.B.: auf einer Richtlinie die Funktion aktivieren "Jetzt Anwenden", dann kann der RUS mit einer passenden LDAP-Anfrage gleich die Objekte suchen, auf die diese Richtlinien bislang angewendet wurden. Die Richtlinie mit der GUID "{26491CFC-9E50-4857-861B-0CB8DF22B5D7}" hingegen gibt  es nicht, sondern diese Wert steht eben für die Eigenschaft, ob das jeweilige Objekt überhaupt durch den RUS aktualisiert werden darf oder nicht. Wenn Sie die GUID {3B6813EC-CE89-42BA-9442-D87D4AA30DBC} finden, dann ist zusätzlich auch eine Richtlinie des Mailboxmanagers eingetragen worden.

Die GUID der entsprechenden Empfängerrichtlinie finden Sie mit ADSIEDIT dann im Feld objectGUID.

Die gleiche GUID in einer etwas anderen Schreibweise finden Sie dann auch beim Benutzer im Feld "msExchangePolciesIncluded".

Nur ist die Schreibweise eine anderen, d.h. die Ziffernfolge 0x7f 0x37 0x3e 0x24 müssen Sie rückwärts lesen, um den Anfang von 243E377F zu erhalten.

GatewayProxy oder wie erzwinge ich die Anwendung einer Richtlinie.

Auf der Seite Exchange RUS haben Sie vielleicht schon gelesen, dass der Aktualisierungsdienst über die Optionen "Jetzt aktualisieren" und "Neu erstellen" beeinflusst werden kann, um neue und geänderte Objekte zu erkennen und entsprechend der Einstellungen der Richtlinien die passende Richtlinie zuzuweisen. Aber der RUS erstellt nur bei neuen Objekten die Adressen. Bereits durch den RUS versorgte Objekte erhalten zwar die neue Richtlinie zugewiesen aber Sie wird nicht aktuell angewendet. Dies beschreibt der Exchange System Manager auch, wenn Sie eine Richtlinie ändern mit folgender Meldung:

Um nun alle Objekte, denen eine bestimmte Richtlinie zugeordnet ist, entsprechend dieser Richtlinie auch zu konfigurieren, können Sie auf der Richtlinie selbst die Option "Diese Richtlinie jetzt anwenden" aktivieren.

Der Exchange System Manager vergewissert sich noch einmal, ob Sie dies wirklich tun wollen. Dann nämlich werden alle Objekte, denen diese Richtlinie zugewiesen ist, neu durch den RUS gestempelt. Wenn Sie eine Empfängerrichtlinie daher derart geändert haben, dass bestimmte Benutzer durch diese Richtlinie neu betroffen sind, dann werden die Änderungen erst aktiv, wenn eben diese Richtlinie explizit angewendet wurde. Wenn hingegen durch die Änderung bestimmte Empfänger nicht mehr unter diese Richtlinie fallen, dann können Sie die Änderungen durch die Anwendung der anderen nun zutreffenden Richtlinien durchführen lassen.

Die Aktivierung dieser Funktion zeigt sich mittels ADSIEDIT, dass beim Empfängeraktualisierungsdienst im Attribut "gatewayProxy" die Adressen der Richtlinie aufgenommen werden, die durch den RUS zu verändern sind.

Über die Kontrolle dieses Feldes sehen Sie sehr schnell, welche Richtlinie gerade den Status "Apply" haben. Diese Funktion ist besonders wichtig, wenn Sie nach einer Exchange 5.5 nach 200x Migration die Richtlinien der Exchange 5.5 Standorte, die als "höchste Richtlinie" vorhanden sind, entfernen oder neu umsortieren. Sie können nur dann sicher sein, dass die Adressen entsprechend ihrer Richtlinien vergeben sind, wenn Sie die Richtlinien über diese Funktion auch explizit anwenden.

Diese Aktion kann aber auch manuell gepflegte primäre Adressen wieder zu sekundären Adressen machen.

Dies ist zudem der einzige Fall, bei denen der RUS auch Adressen entfernen könnte. Wenn ein Benutzer durch eine Richtlinie einen bestimmte Adresstyp überhaupt nicht mehr erhält, dann löscht der RUS diese Adressen, auch wenn diese manuell gepflegt sind.

Sie können diese Verhaltung für bestimmte besonders kritische Postfächer dadurch außer Kraft setzen, dass Sie bei diesen Postfächern die Option deaktivieren, dass diese durch den RUS gepflegt werden

Bei größeren Änderungen mit den Empfängerrichtlinien rate ich dazu, die aktuellen Mailadressen vorab zu exportieren um Änderungen erkennen und bei Bedarf auch rückgängig machen zu können. Ich habe dazu selbst zwei Scripte, die mir bei Einsätzen dabei helfen:

  • RUSMon
    Überwacht und protokolliert die Änderungen , die der RUS durchführt
  • SMTP Backup Restore
    Sichert die Mailadressen in ein Benutzerdefiniertes Feld und kann diese später wieder vergleichen bzw. restaurieren.

Richtlinien und LDAP

Eine normale Empfängerrichtlinie beschränkt sich natürlich auf Objekte, die auch "Exchange aktiviert" sind. Allerdings können Sie mit der MMC auch Richtlinien anlegen, die einen anderen LDAP Filter nutzen. Gut ist z.B.

(&
  (&
    (&
      (& 
        (mailnickname=*)
        (| 
          (&
            (objectCategory=person)
            (objectClass=User)
            (|
              (homeMDB=*)
              (msExchHomeServerName=*)
            )
           )
         )
        )
      )
    (objectCategory=User)
    (samAccountName=DonaldDuck*)
  )
)

Probleme kann es aber mit einem verkürzten Filter geben:

(objectCategory=User)

Hier gilt die Richtlinie dann für alle User. Das bedeutet aber, dass der RUS aber wirklich ALLE Objekte vom Typ "User" mit Mailadressen versieht. Selbst wenn diese weder ein Postfach haben noch Mailaktiviert sind. Solche "halb fertigen" Objekte können sie z.B. mit meinem Tool CheckExObjects finden, welche eine Warnung erzeugt.

Weitere Links

  • RUS löscht Adressen
  • CheckExObjects
  • Exchange RUS.
    Informationen zum Empfängeraktualisierungsdienst
  • Neues Postfach wird angelegt.
    Mehr Details, in welchen Schritten aus einem Benutzer ein Postfach wird, finden Sie auch auf
  • RUS löscht Adressen
    Wann der RUS Adressen löscht
  • RUSMon
    Überwachung, wie die Richtlinien angewendet werden
  • DumpRecipientPolicies
  • CheckRUS
  • DumpRUSUser
  • E2K7:RUS
  • 318072 XADM: Update E-Mail Addresses Based on Recipient Policy
  • http://hellomate.typepad.com/exchange/2004/06/troubleshooting.html
  • http://www.exchangefaq.org/faq/Exchange-2003/Administration/sectionID/1031
  • 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
  • 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
  • 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
  • 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
  • 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 Domain Recipient Update Service
  • 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
  • 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
  • 911145 An event is logged every 15 minutes on the computer that is running the Exchange Management Pack für Management Operations Manager 2005. Anmeldug schlägt fehlt, weil primäry SMTP des MOM mailbox access account nicht der Default Policy entspricht.