Linked Mailbox

Beachten Sie dazu auch die Seiten Ressourceforest, Disabled Account, Ressourceforest und Gruppenrechte und ADSync Funktion.

Achtung mit Office 365
User mit einer Linked Mailbox werden per Default nicht in die Cloud synchronisiert. ADSync geht davon aus, dass dies keine Anmeldekonten sind und wartet auf das Anmeldekonto
Siehe dazu auch Office 365:DirSync Check, Office 365:DirSync mit Exchange und Hybrid Ressource Forest.

Was unter Exchange 2000/2003 der Disabled Account war, wurde unter Exchange 2007/2010 die Linked Mailbox. Sie dient dazu, in einer Konfiguration von Exchange als Ressourceforest einen Benutzer ein Postfach bereit zu stellen, obwohl das Anmeldekonto nicht im gleichen Forest ist, in dem auch Exchange installiert ist. Dies kann bei Migrationen hilfreich sein, wenn das Postfach unabhängig vom Anmeldekonto im Rahmen einer Migration Org2Org umgestellt  wird. Es kann aber bei Firmen zum Einsatz kommen, bei denen Exchange eben in einem separaten Forest betrieben wird.

Grundlegende Funktion

Technisch handelt es sich wie bei Exchange 2000/2003 mit Disabled Account um ein Active Directory Benutzer mit einem Postfach. Auch dieser Benutzer ist per Default deaktiviert. Allerdings ist dies für Exchange 2007/2010 nicht mehr der entscheidende Faktor. Exchange 2007/2010 hat das neue Feld msExchRecipientTypeDetails, um die Postfächer genauer zu bezeichnen. Die Postfächer erscheinen auch einfach in der Liste wie alle anderen Postfächer auch.

Eine Linked Mailbox kann auch einfach über die GUI angelegt werden.

Der Assistent entspricht anfangs noch der Anlage einer normalen Mailbox. nur nach der Konfiguration der Policies kommt ein neuer Dialog, im dem die Verbindung zum Anmeldekonto hergestellt wird:

Allerdings ist es natürlich bei einer größeren Anzahl von Benutzern und Postfächern schon einfacher, dies per Skript auszuführen.

Die Mailboxen selbst lassen sich auch per PowerShell mit "Get-User" oder "Get-maibox" recht einfach ausgeben.

Wenn Sie wie hier das Feld "LinkedMasterAccount" mit einer SID angezeigt bekommen, dann war während der Abfrage der DC der Anmeldedomäne nicht verfügbar. Exchange versucht natürlich schon die SID in einen Anmeldenamen (Domäne\SamAccountname) umzuwanden. Hinter den Kulissen ist aber nichts neues zu sehen, da wie bei Exchange 2000/2003 auch die gleichen Felder zur Speicherung genutzt werden.

Postfachberechtigungen

Auch bei den Berechtigungen auf das Postfach gibt es keine Überraschungen.

Hinweis:
Auch diese Bilder wurden absichtlich mit nicht erreichbarem Anmelde-DC gemacht, um die SID anzuzeigen. In einer produktiven Umgebung sollte hier immer der Anmeldename stehen. Beachten Sie aber, dass die Anzeige des Anmeldenamens nur korrekt ist, solange das Anmeldekonto nicht z.B. perADMT mit SIDHistory bereits migriert wurde. Dann würde irrtümlich der lokale Benutzer angezeigt.

Entgegen einem "Normalen Postfach" hat die Linked Mailbox zusätzlich das Anmeldekonto in den ACLs für die Postfachrechte und die SendAs-Rechte, wie hier gut zu sehen ist:

Soweit ist die Funktion noch einfach erklärt.

Hinweis: Es gibt aber noch Besonderheiten bei Verteilern, Gruppen und Berechtigungen. Siehe dazu Ressource Forest

Es gab mit Exchang 2012 hier sogar mal einen Fehler, dessen Korrektur im Exchange 2013 CU10 erfolgte. Die Beschreibung zeigt aber gut, dass der Benutzer im Account-Forest berechtigt werden muss

Assume that you deploy a linked mailbox in a Microsoft Exchange Server 2013 forest, and the linked mailbox is associated with a disabled user account that's in a trusted account forest. When you run the Add-MailboxPermission cmdlet to grant permissions for the linked mailbox, the permissions are granted to the wrong account in the Exchange Server 2013 forest instead of the account in the account forest.
Quelle https://support.microsoft.com/en-us/topic/permissions-for-a-linked-mailbox-are-added-to-an-account-in-the-wrong-forest-in-an-exchange-server-2013-environment-7efff06d-113e-050e-5aea-c53a0e73f31d

Anforderungen an die Quelldomain

Habe ich auf Exchange 2000 mit Windows NT4 noch geschrieben, wie NT4-Anwender in den Genuss von Exchange 2000+ kommen, so ist ab Exchange 2010 als Mindestvoraussetzung ein Windows 2003 SP1 DC in der Account-Domain erforderlich. Ansonsten können Sie keinen LinkedAccount konfigurieren. Ansonsten sehen Sie z.B.: folgende Fehlermeldung:

[PS] C:\>Connect-Mailbox
    -Identity test 
    -Database "mb1" 
    -LinkedDomainController dc2.logondomain.tld
    -LinkedMasterAccount test
Failed to resolve the linked master account and verify it exists in a forest different from the one hosting 
Exchange. The error messasge is :
 
The operating system version of the domain controller 'dc2.logontomain.tld' is 5.0 (2195) Service Pack 4.
 The minimum version required is 5.2 (3790) Service Pack 1.
    
 CategoryInfo          : NotSpecified: (:) [], TaskInvalidOperationException
    + FullyQualifiedErrorId : CA9E8C4C

Damit folgt Microsoft seinen üblichen Maßstäben, dass Sie immer die aktuelle (Windows 2008R2) und die beiden vorherigen Version (Windows 2008/2003) unterstützen.

Anforderungen an Autodiscover

Nun ist es aber so, dass sowohl beim Betrieb als Ressourceforest als auch als bei der Migration der Anmeldebenutzer und der Arbeitsplatz in einem anderen Forest sein können. In dem anderen Forest kann Exchange installiert sein, muss aber nicht. In beiden Fällen muss natürlich Outlook einen Weg zu seinem Exchange Server finden. Outlook 2007 und höher nutzen dazu Autodiscover und suchen zuerst per LDAP im Active Directory nach den CAS-Servern zu suchen.

In einer reinen Umgebung mit einem Anmeldeforest ohne Exchange wird Outlook natürlich erst mal nichts finden. Entsprechend müssen Sie über die DNS-Auflösung (autodiscover.<maildomain>) mit passenden Zertifikaten gehen oder die SCPs des Exchange Forest in den Anmeldeforest kopieren.

Konvertierung von Linked Mailbox zu User Mailbox

Ein häufiger Fall bei Migrationen ist die getrennte Umstellung von Benutzerkonten (mit ADMT) und der Exchange Postfächern. In dem Fall wird Exchange dann zumindest für eine Übergangszeit als Ressourceforest betrieben, d.h. der Benutzer meldet sich noch in der alten Umgebung an während das Postfach schon in die neue ZielUmgebung migriert wurde. In der ZielUmgebung ist dann das Platzhalterkonto "deaktiviert" und hat ein "Externes zugewiesenes Konto, welches später aktiviert wird. Wird das Anmeldekonto zuerst migriert, dann wird der Quellbenutzer entsprechend "deaktiviert" und zu einer Linked Mailbox, bis die Inhalte übertragen wurden.

Es gibt also einen Bedarf, ein Postfach in die ein oder andere Richtung zu konvertieren. Dies wird von Microsoft in der TechNet als auch von einigen anderen Autoren beschrieben. leider gibt es derer mittlerweile drei verschiedene Wege, die je nach Version gangbar ist.

Seit Exchange 2010 SP1 gibt es mit "Set-User" ein passendes Commandlet:

Dies ist mein empfohlener Weg, der aber nur mit Exchange 2010 genutzt werden kann. Exchange 2007 kennt diese Parameter noch nicht, so dass die Administratoren die zweite oder dritte Option wählen müssen.

Seit Exchange 2010 ist es sehr einfach möglich, über das Commandlet "Set-User" aus einer Linked Mailbox eine Usermailbox und umgekehrt zu machen. Es gibt aber keine GUI-Version davon, so dass Sie mit der PowerShell arbeiten müssen:

# Linked mailbox in Usermailbox verwandeln
Set-User User1 -LinkedMasterAccount $null

Danach ist aus der Linked-Mailbox  eine Benutzermailbox geworden. Leider macht Set-User aber nur die Einstellungen bezüglich Exchange. Folgende Dinge sollten Sie beachten

  • Konto wird nicht aktiviert
    Damit der Anwender nun mit dem neuen Konto sich auch anmelden kann, müssen Sie das Konto aktivieren. Per Default sind die AD-Benutzer für "Linked- Maiboxen" deaktiviert. Denken Sie auch an das Kennwort etc.
  • Send-As-Rechte entfernen (Senden als)
    Durch die Konvertierung wird das Send-As-Recht für den "LinkedAccount" nicht entfernt !. Damit keine Missbrauchslücke offenbleibt, sollten Sie diese Berechtigungen dem früheren Anmeldekonto wegnehmen, z.B. mit:
Get-ADPermission `
   -identtiy User1 `
   -User w2003\User1 `
| Remove-ADPermission `
   -Confirm:$false
  • Full Mailboxaccess entfernen
    Das Konto der früheren Anmeldedomäne hat auch noch volle Zugriffsrechte auf das Postfach, welche nach der Aktivierung des Postfachs ebenfalls überflüssig sind. Auch diese können Sie nicht nur mit der GUI, sondern auch per PowerShell anpassen:
Get-MailboxPermission `
   -identity User1 `
   -User w2003\User1 `
| Remove-MailboxPermission `
   -Confirm:$false

Das Management und die Konvertierung wird natürlich noch einfacher, wenn Sie die Benutzer und ihre Anmeldekonten vorher als Liste extrahiert haben oder gleich ein kleines Skript schreiben.

Konvertierung von User Mailbox zu Linked Mailbox

Auch in die Gegenrichtung kann die Mailbox konvertiert werden. Seit Exchange 2010 SP1 gibt es mit Set-User ein passendes Commandlet.

Achtung:
Dieser Befehl deaktiviert das Windows Benutzerkonto, an dem die Postfachinformationen gespeichert sind!

Aber hier sind etwas mehr Parameter zu füllen, das Sie ja nun den LinkedAccount, einen DC der Anmeldedomain und Anmeldedaten für die Anmeldedomain mitgeben müssen.

# UserMailbox in LinkedMailbox verwandeln. Anmeldedaten für Accountdomain
$cred = Get-Credential
Set-User User1 `
             -LinkedMasterAccount W2003\User1 `
             -LinkedDomainController dc2003.w2003.dom `
             -LinkedCredential $cred

So schnell und einfach wird aus einer User-Mailbox dann wieder eine "Linked-Mailbox". Aber auch hier ist dies nur der erste Teil, da auch hier Set-User eine ganze Menge Einstellungen nicht durchführt, die Sie noch nachholen müssen.

Hinweis:
Anscheinend hat Microsoft gelernt und zumindest bei Exchange 2010 SP3 scheint Set-User auch die Rechte auf das Postfach zu setzen. Eine Kontrolle der folgenden Schritte ist dennoch ratsam.

Wie bei der Gegenrichtung sind dies:

  • Vollzugriff auf die Mailbox für das Anmeldekonto
    Das neue Anmeldekonto muss natürlich Vollzugriff auf das Postfach erhalten. Allein über den Eintrag der MasterAccountSID bekommt der Anwender keine Rechte
Get-MailboxPermission User1 `
| Add-MailboxPermission `
     -User w2003\User1 `
     -AccessRights FullAccess
  • SendAs für das Anmeldekonto (Senden als)
    Das gleiche gilt für die Berechtigung, mit dem Postfach aus zu senden. Ich habe schon gesehen, dass diese Recht automatisch mit "Set-User" auch mit gesetzt wird. Sie sollten die Berechtigung aber zumindest prüfen.
Add-ADPermission `
   -identity User1 `
   -User w2003\User1 `
   -Extendedrights "Send As"
  • Deaktivieren des Kontos
    Das Konto wurde schon durch Set-User deaktiviert. Aber vielleicht wollen Sie das ja gar nicht, dass das Postfachkonto deaktiviert ist. Wenn der Anwender für eine Übergangszeit mit beiden Konten arbeiten soll, dann müssen Sie das Konto umgehend wieder aktivieren.

Ich finde diesen Weg eigentlich den elegantesten Ansatz, da keine Daten verloren gehen. Allerdings benötigen Sie dazu Exchange 2010 SP1.

Der Vollständigkeit halber möchte ich auch die beiden anderen Wege noch aufführen:

Mailbox Disconnect und Reconnect

Dieses Verfahren kann ich nicht empfehlen, da durch den Disconnect beim Benutzer alle Exchange Properties entfernt werden. Auch wenn der Reconnect sehr schnell erfolgt, müssten also Proxyadressen, ActiveSync-Richtlinien, Archivpostfächer und vieles mehr neu eingerichtet werden.

Dies aber leider der Weg, der sowohl bei Microsoft als auch vielen Blogs beschrieben wird. Bei Exchange 2007 ist lange Zeit gar nichts anderes möglich gewesen, zumindest wenn man nicht selbst direkt per LDAP an den AD-Attributen rumschreiben wollte.

Hier der Vollständigkeit halber die Links zu den entsprechenden Seiten

Unschön bei dieser Umsetzung ist nur, dass alle Beschreibungen erst ein "Disconnect" der Mailbox mit einem späteren "Connect" vorsehen. Ein Disconnect löscht aber auch sehr viele andere Exchange Eigenschaften (z.B. Quota, Policies und vor allem ProxyAdressen), die vorher kopiert werden müssten.

"Update Recipient" Commandlet

Diesen Weg habe ich eher Zufällig bei der Umsetzung mit einem Identity-Projekt entdeckt. Hierfür hat Microsoft mit "Update-Recipient" einen Weg geschaffen, die MIIS und andere Produkte per LDAP bestimmte Werte "vorgeben" können und Exchange dann mit Update-Recipient" die erforderlichen sonstigen Eintragungen vornimmt.

Seit Exchange 2010 gibt es mit "Update-Recipient" ein neues Commandlet, welches eigentlich für den Einsatz mit Identity Management Systemen gedacht ist.

Genau dieses Tool wandelt aber ohne Probleme Postfächer in LinkedMailboxen und zurück. Man muss nur das Feld "msExchMasterAccoundSID" entsprechend setzen oder löschen und einmal "Update-Recipient" aufrufen.

Ein Versuch dies per Set-Mailbox zu erreichen, war zumindest in meinen TestUmgebungen nicht möglich.

Linked Remote Mailbox mit Office 365

Ein Sonderfall ist nun natürlich der Betrieb mit Office 365. Der ADSync unterstützt auch diese Kombination, da er das lokale Anmeldekonto und die Linked Mailbox zusammenführt und als eine Mailbox in der Cloud verwaltet. Bei einer Migration in die Cloud wird aus der Linked Mailbox im Exchange Ressource Forest natürlich technische ein MailUser bzw. aus Sicht von Exchange eine "Remote Mailbox". Sie muss aber weiterhin mit dem eigentlichen Anmeldekonto verknüpft sein. Das ist über das Feld "msexchMasterAccountSID" auch gewährleistet. Allerdings "sehen" sie das nicht mehr in der lokalen Exchange Konsole. Es gibt keinen Typ "Linked Remote Mailbox"

Bei der Neuanlage eines Postfachs in der Cloud müssen wir nun aber auch eine bestimmte Reihenfolge einhalten, die zudem zeitnah erfolgen muss, damit ADSync die Verbindung der Objekte versteht.

  1. ADSync anhalten
    Wir möchten nicht, dass noch während des Provisioning ADSync die halbfertigen Objekte sieht. Problematisch wäre es, wenn ADSync das Anmeldekonto ohne Exchange Linked Mailbox findet, in der Cloud anlegt und durch eine Lizenz sogar ein Postfach angelegt würde.
  2. Anmeldekonto anlegen
    Zuerst legen wir das Konto an, welches der Anwender zur Authentifizierung nutzt. Es hat also den passenden UPN für die Cloud und muss später ja als "Linked Account" gefunden werden
  3. Neue Remote Mailbox anlegen
    Über die Exchange PowerShell legen wir nun eine normale "Remote Mailbox" an. Wir sollten uns nun aber beeilen, da sonst ADSync das Konto als separates Konto betrachtet und wir dann zwei Konten in AzureAD haben.
  4. "LinkedMasterAccount" setzen
    Daher ist es ratsam im gleichen Zug auch die Verbindung zum Anmeldekonto für Exchange zu setzen. Das geht leider nicht per Exchange PowerShell, sondern per AD-PowerShell.
  5. ADSync wieder starten
    Nun darf ADSync beide Quellen importieren, die Benutzer "mergen" und ein passendes Objekt in Exchange Online anlegen.

Der letzte Schritt ist zusätzlich erforderlich.

# Remote Mailbox anlegen
Enable-RemoteMailbox `
   -Name "User1" `
   -UserPrincipalName "user1@resourceforest.tld" `
   -Password (ConvertTo-SecureString -String "SuperGeheim4me!" -AsPlainText -Force) `
   -RemoteRoutingAddress user@uclabor.mail.onmicrosoft.com

# LinkedMasterAccount Feld setzen

cred = Get-Credential [ 

Set-User `
   -Identity user1@exchange.uclabor.de
   -LinkedCredential $AccountsCred `
   -LinkedDomainController ACCDC01.accounts.local `
   -LinkedMasterAccount "exchangedom\user1"

Daraus resultiert dann auch der passende Eintrag in msExchRecipientTypeDetails in msExchRecipientDisplayType

Wichtig ist, dass die Zuordnung zeitnah erfolgt. Sie können auch vorab schon mit Set-User das Feld füllen, denn der "Enable-RemoteMailbox" scheint das Feld msexchMasterAccountSID nicht zu überschreiben. Das sollten Sie aber auf jeden Fall noch mal kontrollieren. Wenn Sie das Postfach aber mit "New-RemoteMailbox" anlegen, dann setzen Sie den LinkedMasterAccount direkt im Anschluss. In so einem Fall sollten Sie bei allen Commandlets den gleichen Domain Controller nutzen, um die AD-Replikation zu umgehen.

Wenn Sie ADSync nicht anhalten können aber die Unsicherheit verhindert werden muss, dann können Sie die Objekte in einem "Staging-Bereich" anlegen, den ADSync nicht sieht. Das kann per LDAP-Filter oder eine ausgeschlossene OU sein. Erst wenn dann alle Properties gesetzt sind, verschieben Sie zuerst das Exchange Objekt und im Anschluss das Anmeldekonto in den Sichtbereich von ADSync.

Linked Mailbox mit ADSIEDIT

Mit Exchange 2003 war die Verwandlung einer Mailbox in eine LinkedMailbox relativ einfach. Das Konto wurde einfach deaktiviert und schon war im Kontextmenü von Exchange die Funktion, ein externes Konto zuzuweisen. Das ist mit Exchange 2007 so nicht mehr, weil eben die Information nicht mehr an dem Status "deaktiviert" sondern an den msExchRecipientTypeDetails fest gemacht wird. Und da ich noch kein "Native Commandlet" für Exchange 2007 gefunden haben, bleibt eben ADSIEDIT oder andere Tools.

Selbst ein Set-Mailbox kann nicht nachträglich den Linked Account eintragen:

[PS] C:\>Set-Mailbox User -LinkedMasterAccount logon\User -LinkedDomainController dc.logon.de -LinkedCredential $cred 

Set-Mailbox : 'LinkedMasterAccount' kann nicht für Benutzer-, Raum-, Geräte- oder freigegebene Postfächer festgelegt werden.
Bei Zeile:1 Zeichen:12

Der Fehler ist auf einem Exchange 2007 vorhanden, selbst wenn das Postfach eine "LinkedMailbox" ist. Insofern bleibt nur der Weg "von Hand". Folgende Eintragungen sind relevant

  • msExchRecipientTypeDetails = 2
    Damit wird aus der Mailbox eine "Linked Mailbox"
  • msExchMasterAccountSID setzen
    Hierbei müssen Sie das Feld "ObjectSID" der Quell in das Ziel kopieren.
  • Berechtigungen anpassen
    SendAs und Full Mailbox Access
    Neben dem Konto "Selbst" hat auch das externe Konto die entsprechenden Rechte. In Exchange 2010 wird das SendAs-Recht allerdings über Add-ADPermission addiert.
Add-MailboxPermission -Identity mbUser -User logon\User -AccessRights fullacccess
Add-MailboxPermission -Identity mbUser -User logon\User -AccessRights SendAs
  • Konto deaktivieren
    Ziel ist es ja ein "Single SignOn" zu betreiben. Wenn es ein primäres Anmeldekonto gibt, dann ist es nur mehr als logisch, das Exchange Postfachkonto zu deaktivieren.

Das ganze sollte man natürlich als Skript machen, denn ADSIEDIT ist auf Dauer zu fehleranfällig.

Weitere Links