Update-Recipient
Viele Firmen nutzen Drittprodukte, um ihre Benutzer im Active Directory zu verwalten. Dazu greifen allerdings viele Programme direkt per LDAP auf das Active Directory zu und verändern Werte. Wer über den Weg nun Exchange-Einstellungen von Benutzer, Verteilern oder Kontakten pflegen will, muss allerdings die richtigen Dinge richtig machen. In Exchange 2000 und 2003 war es allerdings noch der Exchange RUS, der die ein oder anderen Fehler ausgemerzt hat. Seit Exchange 2007 gibt es den aber nicht mehr und die Programmen sollten sich doch bitte der PowerShell bedienen. Das haben aber bei weitem noch nicht alle Programme umgesetzt, so dass Microsoft mit Exchange 2007 schon den Hilfsparameter "ApplyMandatoryProperties" für Postfächer eingeführt hat. Ein Administrator konnte über den Weg fehlende Einstellungen zurecht rücken. Kontakte, Verteiler etc. konnten mit den entsprechenden "SET*"-Commandlets versorgt werden. Siehe dazu auch E2K7:RUS.
Seit Exchange 2010 gibt es für diesen Zweck nun ein eigenes Commandlet, welches die verschiedenen Empfängerobjekte mit einem Befehl aktualisieren kann
- Update-Recipient
http://technet.microsoft.com/de-de/library/bb738148.aspx
Use the Update-Recipient cmdlet to add Microsoft Exchange Server 2010 attributes to recipient objects created by the global address list (GAL) synchronization management agent in Identity Lifecycle Manager (ILM) 2007. The recipient objects you modify using this cmdlet must reside on a server running Exchange 2010
Das funktioniert natürlich auch mit anderen Produkten und Lösungen und nicht nur mit dem Microsoft Metadirectory.
Wenn Sie per Identity Management schon PowerShell-Skripte aufrufen können, dann sollten Sie ernsthaft überlegen, generell auf die "Enable-*"-Commandlets mit passender Parametrisierung zu setzen anstatt per LDAP Werte zu setzenz und dann Update-Recipient zu nutzen.
Die die erforderlichen Felder, um die Objekte dann mit Update-Recipient zu aktivieren.
| Objekt | Erforderliche Felder | Beschreibung |
|---|---|---|
UserMailbox |
MailNickName |
Für die Anlage einer Mailbox ist es erforderlich, dass der MailNickName und die Datenbank gesetzt wird. Leider muss auch der msExchHomeServer eingetragen werden, obwohl dies Exchange eigentlich anhand der Datenbank selbst ermitteln könnte. |
MailUser |
MailNickname |
Dieser Fall ist speziell in Cross-Org-Migrationen, MischUmgebungen mit Exchange Online oder für externe Personen oft der Fall. Ein Benutzer hat sein Postfach in einem anderen System, aber hat trotzdem ein Anmeldekonto. |
Kontakt |
MailNickname |
Reine Kontakte werden z.B. über einen Verzeichnisabgleich gerne genutzt, um mehrere Organisationen zu verbinden. Wäre eine Anmeldung erforderlich, dann kann dazu ein Trust dienen. |
Gruppe |
MailNickName |
Hier reicht es komplett aus, der Gruppe einfach einen "Mailnickname" zu geben, damit Exchange diese Gruppe soweit akzeptiert, um per Update-Recipient die passenden Felder zu addieren |
MailNickName |
Wenn zusätzlich zu den Feldern einer Mailbox auch noch die msExchMasterAccountSid mit der SID eines Kontos aus einer vertrauten Domain gefüllt wird, dann wird darauf eine "Linked Mailbox". |
|
Room |
nicht möglich ? |
Mir ist es bislang nicht gelungen, ein Objekt so vorzubereien, dass Update-Recipient daraus eine Ressourcenmailbox macht. |
Achtung
Update-Recipient wendet die Empfängerrichtlinien an, d.h. auch
ProxyAddresses werden zurecht gerückt, wenn ihre Provisioning-Anwendung
dort andere Werte eingetragen hat.
Wenn Sie also z.B.: bei Gruppen oder Postfächern "andere" abweichende Mailadressen benötigen, dann müssen Sie nach der Verarbeitung von Update-Recipient dann die Anwendung der Empfängerrichtlinien deaktivieren und die gewünschte Adresse setzen.
AD-Replikation
Bedenken Sie, dass speziell beim Einsatz mehrerer DCs eine Änderung per
LDAP auf einem DC nicht immer sofort auf dem DC ist, der durch das
Exchange Commandlet angesprochen wird. Entweder warten Sie die
Replikation ab oder sie geben in allen Fällen den gleichen DC an.
Massenverarbeitung
Dank PowerShell und Pipeline ist es sehr einfach, eine bestimmte Gruppe von Objekten auf einen Schlag zu aktualisieren: Das ist besonders interessant, wenn der Update-Recipient nicht durch ihre Anwendung aufgerufen wird und damit von ihnen regelmäßig gestartet werden soll.
Get-MailContact -OrganizationalUnit "msxfaq.de/Mailkontakte" | Update-Recipient
Dies ist aber auch hilfreich, wenn Sie aus anderer Quelle (z.B. LDIF-Datei) eine Menge Objekte als Kontakte angelegt haben und diese nun alle auch für Exchange "korrekt" konfigurieren wollen.
Triggered Update - ADPT
Auch wenn das Commandlet und Active Directory nur die Felder ändern und replizieren, die zu ändern sind, so ist die müssenverarbeitung dennoch nicht ganz so Ressourcenschonend, wie es sein könnte. Besser wäre es, wenn z.B. anhand der Active Directory USN nur die seit dem letzten Aufruf geänderten Objekte verarbeitet werden oder gleich zeitnah bei ObjektÄnderungen die notwendigen Aktionen veranlasst werden.
Über das PowerShell-Skript E2K7:RUS habe ich schon so etwas realisiert. Das Skript fragt regelmäßig beim DC die geänderten Objekte an, um basierend darauf dann Aktionen auszuführen. Mittlerweile entwickle ich ein Script, welches über die DirSyncAPI sogar Änderungen auf Feldebene ermittelt und noch granularer Aktionen auslösen kann.
Beide Skripte sind aufgrund ihrer Komplexität nicht öffentlich Verfügbar. Eine ausführlichere Erklärung finden Sie auf nicht public.
