Benutzermanagement

Exchange 2007 SP1 erforderlich wenn Richtlinien anhand von "memberof" vergeben werden
http://blogs.technet.com/evand/archive/2007/02/13/using-memberof-with-recipientfilter.aspx

Mit Exchange 2007 hat sich auch die Verwaltung der Benutzer und anderen Empfänger umfangreich geändert. In Kürze:

  • Empfängerrichtlinien
    Die Empfängerrichtlinien sind weiterhin vorhanden, aber dienen z.B.: nicht mehr zur Steuerung der eingehenden Domains.
  • RUS entfällt
    Die Vergabe von Mailadressen wird nicht mehr durch den RUS auf dem Server asynchron durchgeführt, sondern synchron durch Sie als Administrator bzw. die PowerShell Commandlets. Natürlich orientiert sich dieser Code an den konfigurierten Richtlinien. Zur Rückwärtskompatibilität können Sie die Funktion des RUS manuell starten (PowerShell Commandlet) bzw. per Taskplaner auch regelmäßig laufen lassen. Das ist besonders dann erforderlich, wenn Sie Exchange 2000/2003 und 2007 gemischt betreiben und Objekte auf Exchange 2003 durch Anwendungen erstellen lassen, die auf die Nacharbeiten des RUS vertrauen.
  • ActiveSync Policies
    In Exchange 2003 konnten Sie nur global die Einstellungen für ActiveSync vorgeben. Mit Exchange 2007 können Sie nun mehrere Richtlinien anlegen und den Benutzern jeweils eine Richtlinie zuweisen
  • Unified Messaging
    Auch für die Verwendung von Unified Messaging gibt es Richtlinien, welche dann auf den Anwender angewendet werden.

Gestern und Heute

Vergleichen wir einfach einmal die verschiedenen Schritte einer Benutzerverwaltung zwischen Exchange 5.5, 2000/2003 und 2007

Exchange
Version
Bild Beschreibung

4.0
5.0
5.5

Ex55 Provisioning

Lange ist es her, dass Sie mit dem NT4 Benutzermanager für Domänen ein Konto angelegt und dann mit dem Exchange 5.5 Administrator ein Postfach erzeugt und das NT4 Konto als Besitzer zugeordnet haben. Es gab keinen RUS und auch sonst waren kaum weitere Komponenten beteiligt:

Fremde Produkte mussten also direkt per LDAP die passenden Felder anlegen und ändern. Die meisten Tools haben letztlich eine CSV-Datei geschrieben und mit ADMIN.EXE (Das war der Name der Exchange 5.5. Verwaltung) importiert.

2000
2003

Exchange 2000/2003

Mit Exchange 2000 kam das Active Directory und die Trennung von Benutzerverwaltung und Serververwaltung. Über die MMC wurden nicht nur die Benutzer angelegt, sondern auch Einstellungen bezüglich Exchange vorgenommen. Sie konnten hier auch einen Benutzer mit einem Postfach versehen aber das ist nur die halbe Wahrheit.

Der Exchange RUS musste noch die Mailadressen und andere Felder schreiben und beim ersten Zugriff auf das Postfach ordnete der Informationsspeicher (Store.exe) dem Benutzer eine MailboxGUID und den Mailbox Security Descriptor zu. Zudem pflegt er msexchPoliciesIncluded und msexchPoliciesexcluded und ebenso die Adresslisten, in denen der Benutzer erscheint. Und den LegacyExchangeDN

2007

Exchange 2007

Mit Exchange 2007 gibt es keine AddOns für die MMC für Benutzer und Computer mehr, weil die komplette Verwaltung per Exchange MMC und PowerShell erfolgt.

Es gibt keinen RUS mehr und auch der Store erwartet, dass alle Felder vorhanden sind.

Ansonsten gibt es seltsame Effekte, z.B. dass der Benutzer sich nicht per OWA anmelden kann.

2010

 

Bei Exchange 2010 ist nun zwischen den Admin und den Einstellungen die Remote PowerShell und die RBAC-basierte Überprüfung gekommen. Über "RBAC" werden die Änderungswünsche an den Exchange Server übermittelt, welcher dann die Einträge vornimmt.

Insofern ähnelt Exchange 2007 eher Exchange 5.5, da die Administrationssoftware alle Einstellungen durchführt.

Probleme Exchange 2003 Admin in Exchange 2007 Umgebung

Solange Sie noch einen Exchange RUS in ihrer Umgebung haben, können Sie sogar mit dem Exchange 2003 Administrator Empfänger anlegen, die sich auf Exchange 2007 befinden. Allerdings werden die Benutzer nicht "komplett" sein, da der Exchange 2007 weitere Felder benötigt. Diese Fehler kann z.B. E2K7:RUS automatisch beseitigen. Sie werden sehr schnell auf Probleme stoßen, wenn sie weiter mit der MMC für Benutzer und Computer in einer Exchange 2007-Umgebung arbeiten.

  • RUS Wegfall
    Wird ein Benutzer mit den Exchange 2003 Tools verwaltet, obwohl kein RUS mehr da ist, dann bleiben Benutzer nur "halb" eingerichtet bestehen. Es gibt keinen Prozess, der diesen halbfertigen Postfächern eine Mailadresse vergibt.
  • Mailbox GUID
    Der Exchange 2007 Store erwartet, dass das Feld "MailboxGUID" gefüllt wird, was die PowerShell Commandlets normalerweise tun. Die Exchange 2003 Tools legen das Feld aber nicht an, so dass der Exchange 2007 Store auch hiermit nicht zurecht kommt. (Siehe auch Fix-MailboxGuid)
  • "Legacy Mailbox"
    Per Exchange 2003 Tools aktivierte Benutzer sind keine vollen Postfächer, weil einige Attribute fehlen. Das wirkt sich nicht nur kosmetisch aus, sondern verhindert z.B. dass die Benutzer per OWA2007 arbeiten.
  • HidefromAD
    ändert man mit der alten MMC die Sichtbarkeit, dann wirkt dies erst, wenn auch das Feld "AddressListMembership" aktualisiert wird. Auch das macht normal der RUS und wird daher erst greifen, wenn Exchange 2007 Commandlets dazu gelaufen sind.
[PS] C:\>Get-Mailbox | set-mailbox -Verbose
VERBOSE: Set-Mailbox : Beginning processing.
VERBOSE: Setting mailbox "test2007.msxfaq.de/Users/Administrator".
VERBOSE: Set-Mailbox : The properties changed are: "{ AddressListMembership={
} }".
VERBOSE: Set-Mailbox : Saving object "test2007.msxfaq.de/Users/Administrator"
of type "ADUser" and state "Changed".
VERBOSE: Set-Mailbox : Ending processing.

Es ist also zwingend erforderlich, in einer gemischten Umgebung die Exchange 2007 Benutzer mit den neuen Verwaltungstools zu bearbeiten und den RUS weiter zu betreiben, während in einer Umgebung ohne Exchange 2003 Server (und damit ohne RUS) die Exchange 2003 Verwaltungswerkzeuge nicht verwendet werden dürfen.

Das ist aber nur zum Teil richtig. Wenn Sie die Korrekten vornehmen, die den Exchange 2003 Tools fehlen, dann können Sie weiter mit den Exchange 2003 Addins arbeiten. Siehe auch E2K7:RUS

Best Practice in "Mixed Mode" Umgebungen (2000/2003/2007/2010)

Größter unterschied einer reinen Exchange 2007 Umgebung zu Exchange 2003 ist aber, dass die Verwaltung der Empfänger nicht mehr mit der MMC für Benutzer und Computer erfolgen sollte. Es gibt von Exchange 2007 hierfür kein Snap-In mehr, um die Exchange Eigenschaften anzuzeigen. Die komplette Verwaltung muss also mit den Exchange 2007 Management Tools erfolgen. Das kann also die MMC von Exchange 2007 sein oder eben die PowerShell.

Das Exchange 2003 Setup verhindert leider nicht die Installation der Active Directory users & Computers Snapins, so dass Sie als Betreiber nicht sicher sein können, dass

Tipp:
Exchange 2007 nutzt die gleichen LDAP-Felder wie Exchange 2000/2003 und auch der Mischbetrieb ist offiziell ja erlaubt. Insofern kann man die Exchange 2000/2003 Admintools auch alleine installieren (nur nicht auf dem Exchange 2007 x64 Server) und sogar nutzen. Man muss nur beachten, dass es eben keinen RUS gibt, d.h. wenn man damit Benutzer pflegt und ändert, muss man wissen, wie man dies per Powerhell nachholt.

Für die Neuanlage von Exchange 2007/2010 Postfächern hat sich daher folgende Vorgehensweise bewährt:

Schritt Konsole Tätigkeit

1

MMC für Benutzer und Computer

  • Anlegen des Benutzers oder Gruppe
  • Pflege zusätzlicher Felder wie
    Firma, Straße, Ort, Rufnummer, Abteilung

2

Exchange Management Console - Assistent

  • Neues Postfach mit bestehendem Benutzer anlegen
  • neuer Verteiler mit bestehendem Verteiler anlegen
  • Daten konfigurieren

3

Exchange Management Console - Interaktiv

  • Konfiguration POP3,IMAP-Einstellungen
  • Konfiguration Quota und Empfangsbeschränkungen
  • Konfiguration Stellvertreter, Weiterleitung, SendAs etc.

Da diese Vorgehensweise natürlich mühsam und fehleranfällig ist, kann man sich überlegen, über Skripte diesen Prozess zu automatisieren. So bietet es sich z.B. an, den Firmennamen anhand der OU gleich einzutragen oder die Quota-Eeinstellungen z.B. über Gruppenmitgliedschaften zu steuern.

Pflege von Richtlinien und RUS-Emulation per Taskplaner

Wenn Sie heute noch eine Anwendung betreiben, die Empfänger im Active Directory anlegt und auf die Mitarbeit des Exchange Servers vertraut, dann können Sie diese Anwendungen weiter betreiben, wenn Sie folgende Befehle eben regelmäßig aufrufen.

# Aus falsch angelegten legacyMailboxen userMailboxen machen
Get-Mailbox | Set-Mailbox -applymandantoryproperties

# Adressrichtlinien anwenden, da es ja keinen RUS gibt
Get-EmailAddressPolicy | Update-EmailAddressPolicy

# Adresslisten generieren
Get-AddressList | Update-AddressList

# GAL aufbauen
Get-GlobalAddressList | Update-GlobalAddressList

Dazu eignet sich der Taskplaner. Allerdings wird man diese Skripte sicher nicht alle 5 Sekunden ausführen, wie der RUS dies bislang gemacht hat, sondern eher einmal am Tag. Prüfen Sie daher vielleicht, ob Sie ihre Anwendung, die eben diese Objekte im AD anlegt nicht derart umbauen können, dass diese die Objekte gleich mit den Exchange Commandlets (new-mailbox etc.) anlegt und pflegt oder am Ende eben das Update anstößt.

Exchange Addresslist-Service

Mit der Änderung der Verarbeitung kommen auch neue Probleme ans Tageslicht. Auch wenn es den Exchange RUS in der Form nicht mehr gibt, so bieten die Exchange Server denoch weiter Dienste an, die von den Commandlets auch genutzt werden, z.B.: um die Gültigkeit einer Mailadresse zu überprüfen. Nicht ungewöhnlich ist ein Fehler wie der folgende: 

Warning: Failed to Update recipient "msxfaq.net/Administratoren/adm-fcarius". The following exception occurred: Exchange Server 2007 srv01.msxfaq.net returned an error -2147023286 from the Address List Service..

The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error

Warning: Failed to Update recipient "msxfaq.net/Abteilung/Verteiler". The following exception occurred: A proxy generator DLL on server server.domain.local could not be found or failed to initialize.  Proxy addresses für the current recipient cannot be calculated.  Please ensure that all the proxy address generator DLLs have been installed on the target server..

Hierfür gibt es mehrere Gründe:

  • Keine Rechte auf das userobjekt
    Ein häufiger Grund ist die Auswirkung von AdminSDHolder. Wenn das Problem nicht auf allen sondern nur auf einigen Postfächern auftritt, dann prüfen Sie einmal, ob der Benutzer zufällig Administrator ist. Dann nämlich haben die Exchange Konten in der Regel gar keine Berechtigungen mehr
  • Keine Verbindung zum Server, Keine Rechte auf dem Server
    Firewalls o.ä. können verhindern, dass der Prozess mit dem Server kommunizieren kann. Bei Exchange 207 war es für die Verbindung noch erforderlich, Administrator auf dem Exchange Server zu sein. Gerade in Umgebungen mit vielen Domänen und verteilten Exchange Servern ist dies nicht immer möglich.
  • Empfängerrichtlinien
    Mit der Umstellung von Exchange 2000/2003 nach Exchange 2007/2010 müssen auch die Empfängerrichtlinien konvertiert werden. Wer dies noch nicht gemacht hat oder dabei Filter eingesetzt werden, die Exchange 2007/2010 nicht unterstützt, muss umbauen.#
  • Proxy-DLLs
    Früher war es üblich, dass Connectoren zu fremden Systemen auch eigene DLLs zur Adressgenerierung für Exchange beigesteuert haben, (z.B.: Fax, MRS, SAP, CCMail etc). Diese DLLs gibt es unter Exchange 2007/2010 nicht mehr, so dass die Generierung dieser Adressen in den Richtlinien entfernt werden muss.
  • Leerer Vorname/Nachname
    Wenn Sie in der Richtlinie mit Variablen wie %g und %s etc. arbeiten, dann stören "leere" Fehler die Generierung, da ein Konto ohne Vorname zu einem ".nachname@firma.tld" führt, was nun mal keine gültige Mailadresse ist.

Ich habe sicher noch nicht alle möglichen Fehler aufgeführt. Sobald ich wieder eine neue Quelle bei einem Support Call gefunden und gelöst habe, wird die Liste erweitert.

Weitere Links