MailForestContact

Ich bin ziemlich sicher, das die meisten Administratoren noch nichts von diesem Objekt gehört haben. Es ist aber sehr interessant, wenn Sie mehrere Exchange Topologien miteinander verbinden und die Empfänger untereinander abgleichen. Auf der Seite Verzeichnisabgleich für Exchange habe ich weitere Informationen zum generellen Abgleich von Empfängern zwischen Exchange Organisationen bereitgestellt.

In den meisten Fällen werden Empfänger einer Quelle auf der anderen Seite als "MailContact" angelegt, da ein Kontakt kein vollwertiges AD-Konto ist und sich daher nie anmelden kann und vermutlich auch nicht bei Lizenzzählungen berücksichtigt wird. Das Risiko eines manuell angelegten Kontakts ist natürlich immer, dass ein Exchange Administrator dieses Objekt ebenfalls per Exchange PowerShell oder Exchange Control Panel sieht und verändert. Microsoft kennt daher neben dem normalen "MailContact" auch einen MailForestContact.

Ansicht in Exchange Admin Tools

Wenn Sie so ein Objekt in ihrem Forest anlegen, dann erscheint dieser als eigener Kontakt-Typ in den Exchange Verwaltungswerkzeugen.

Auch in der Exchange PowerShell ist dies ein eigener Typ:

Allerdings kann ich dieses Objekt nicht mit den Exchange Admin Tools bearbeiten

Exchange verhindert oder erschwert zumindest die Veränderungen durch einen Administrator.

Damit ist dieses Objekt optimal dafür geeignet, durch automatische Prozesse angelegt und verwaltet zu werden. So beschreibt es Microsoft sogar selbst

Mail forest contacts are read-only recipient objects that are updated only through MIIS or similar custom synchronization. You can't use the EAC or the Shell to remove or modify a mail forest contact.
Quelle: Recipients - Exchange recipient types
https://docs.microsoft.com/en-us/exchange/recipients-exchange-2013-help#exchange-recipient-types

Provisionierung

Allerdings schreibt Microsoft nicht, wie so ein Objekt genau zu provisionieren ist. Aber es ist im Grund ja auch wieder nur ein normaler "Exchange MailContact" und damit ist klar, dass das Objekt die gleichen Properties haben sollte, die auch ein MailContact hat. Dazu zählen:

  • MailNickname
  • DisplayName
  • Mail
  • ProxyAddresses
  • TargetAddress
  • Recipienttype und Recipienttypedetails

Der einzige Unterschied, den ich bei einem Kunden zum normalen Kontakt gefunden habe, war der msExchRecipientTypeDetails=32768.

Der msExchRecipientType ist hier ein "6" für den normalen MailContact. Allerdings kann ich genau den Wert nicht per "Set-MailContact" oder anderen Exchange Commandlets setzen. Anscheinend muss ich entweder mit New-MailContact das Objekte anlegen und dann den msExchRecipientTypeDetails per LDAP ändern oder ich verwalte gleich alle Felder per LDAP direkt.

Get-AdUser <UserMailbox's Identity> `
| Set-AdObject -Replace @{msExchRecipientDisplay=32768}

Allerdings sind direkte Änderungen an den Exchange Properties laut Microsoft nicht supportet.

Siehe dazu auch Benutzermanagement und ADSync mit Ex Online Only

Umgekehrt bedeutet dies, dass MIM und die anderen Prozesse sich wohl nicht an die eigenen Support-Statements von Microsoft halten.

Exchange Online und ADSync

Nachdem ich den MailForestContact angelegt habe, hat natürlich einige Minuten später mein ADSync das Objekt erkannt und ebenfalls in meinen Tenant repliziert. Es wurde dort auch hin repliziert aber der Empfänger ist nur als MailContact angekommen.

PS C:\> Get-Recipient mailforestcontact@msxfaq.de | fl Re*


ResourceType         :
RecipientType        : MailContact
RecipientTypeDetails : MailContact
RetentionPolicy      :

Die Cloud scheint diesen "besonderen Typ" nicht zu unterscheiden Allerdings ist das auch kein echtes Problem, da ein per ADSync verwaltetes Objekt in Exchange Online ja sowieso "ReadOnly" ist und vom Exchange Administrator sowieso nicht bearbeitet werden können.

Ansicht auf dem Client

Der MailForestContact ist nur ein Untertyp des MailContact und daher hat es mich auch nicht weiter überrascht, dass die Anzeige beim Anwender in OWA oder Outlook sich nicht von einem normalen MailContact unterscheidet:

  • Ansicht in OWA
  • Ansicht in Outlook

Einschätzung

Da es keine Option gibt, diese Objekte mit Exchange Bordmitteln zu erstellen und zu verwalten, dürften nur ganz wenige Firmen diese Objekte in ihrem Active Directory finden. Anscheinend ist auch nur der Microsoft Identity Manager in der Lage, solche Objekte im Rahmen eines Cross Forest DirSync zu erstellen und zu verwalten. Dennoch finde ich den Objekt-Untertyp durchaus auch für andere DirSync-Produkte und eigene Skripte wie CSV2EX interessant, da wir damit eine irrtümliche Veränderung durch Exchange Administratoren erschweren können.

Weitere Links