ADSync und Public Folder

Bei der Nutzung von Email-aktivierten öffentlichen Ordnern mit Exchange Hybrid gibt es einige Stolperfallen zu beachten. Beim Betrieb von Exchange Hybrid werden die öffentlichen Ordner meist zuletzt umgestellt. Wenn Sie öffentliche Ordner "Mailenabled" haben, dann gibt es zu dem Ordner im lokalen Active Directory auch ein AD-Objekt. Damit die Benutzer mit einem Postfach in der Cloud diese Empfänger auch sehen und erreichen können, muss ADSync die Objekte in der Cloud anlegen.

Übersicht

Wenn Sie noch am Anfang der Migration stehen, dann starten Sie ja mit Postfächern auf ihrem lokalen Exchange Server und auch die öffentlichen Ordner sind erst mal noch lokal. Sie migrieren dann nach und nach die Postfächer in die Cloud und zum Schluss werden meist die noch verbliebenen öffentlichen Ordner in die Cloud übertragen. Solange aber Benutzer schon in der Cloud sind können diese bei passender Konfiguration weiterhin auf die lokalen öffentlichen Ordner zugreifen.

Ein Sonderfall sind aber "Mailaktivierte öffentliche Ordner", die lokal auch im Adressbuch erscheinen. On-Premises gib es dazu extra die "MailFolder" im lokalen Active Directory, die über die TargetAddress (EXPF:<guid>) einen Verweis auf den Ordner in der Datenbank haben.

Die Benutzer und auch der SMTP-Service in Exchange Online nutzen allerdings nicht das lokale AD, sondern ihre lokale Wissensbasis, die idealerweise durch ADSync verwaltet wird. In Office 365 gibt es aber nicht nur einen AD-Forests sondern gleich mehrere Umgebungen, in denen Objekte abgelegt werden.

Die Grenzen von ADSync

Eine Schlüsselkomponente ist hier natürlich ADSync, der aus dem lokalen Active Directory die Objekte natürlich lesen und im Ziel anlegt. Wer aber die erste Mailbox in die Cloud übertragen hat, wird feststellen, dass dort die Mailadressen der öffentlichen Ordner der On-Premises Server noch nicht angekommen sind. Sie können die Ordner auch nicht per manueller Eingabe der SMTP-Adresse erreichen, da die Cloud zurecht behauptet, dass es die internen Empfänger nicht gibt. Aus den Quellen ergibt sich ein durchwachsenes Bild. (Stand Nov 2019)


Azure AD Connect sync: Attributes synchronized to Azure Active Directory : Public Folder
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized#exchange-mail-public-folder

ADSync repliziert also schon "etwas". Eine zweite Quelle ist die Versionsgeschichte von ADSync, die alle Änderungen aufzeigt:

Hier finden sich gleich mehrere Einträge:

Version Anmerkungen

1.3.20.0

Exchange Mail Public Folders feature goes GA
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-version-history#13200

When Azure AD Connect wizard creates the AD Connector account required to synchronize changes from On-Premises Active Directory, it does not correctly assign the account the permission required to read PublicFolder objects. This issue affects both Express installation and Custom installation. This change fixes the issue.
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-version-history#116470

1.1.524

Azure AD Connect now supports synchronizing Mail-Enabled Public Folder objects from On-Premises AD to Azure AD. You can enable the feature using Azure AD Connect wizard under Optional Features. To find out more about this feature, refer to article Office 365 Directory Based Edge Blocking support for On-Premises Mail Enabled Public Folders.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-version-history#115240

Anscheinend hat erst Version 1.1.524 vom Mai 2017 überhaupt angefangen, die entsprechenden Objekte in die Cloud zu replizieren. Allerdings landen die Elemente nur im AzureAD, welches z.B. von Exchange Online Protection zur Prüfung der Zieladressen herangezogen wird.

Damit erscheinen aber die Objekte immer noch nicht in Exchange Online. Ich habe dennoch erst einmal mit dem Synchronization Service Manager im Metaverse geschaut, was aktuell repliziert wird. Zuerst gehe ich auch "Metaverse Search" und filtere dann auf "PublicFolder". Wenn ich einen Ordner auswähle, sehe ich die Connectoren, über welche das Metaverse-Objekt verbunden ist und die Details.

ich sehe auch, dass der Connector zu Office 365 ein paar Felder auch dort hin schreibt. Interessanterweise sind die SMTP-Adressen damit schon mal im AzureAD aber das Feld "TargetAddress" macht so eigentlich keinen Sinn. Da hätte die Exchange SMTP-Adresse der Ordners stehen müssen. Aber das Objekt erscheint damit dennoch nicht im Exchange Online Adressbuch.

ADSync und Filter

Sollten Sie noch nicht einmal diese Objekte sehen, dann sollten Sie die Synchronisationseinstellungen in ADSync kontrollieren. Zum einen müssen sie die Replikation der MailPublicFolder explizit aktivieren.

Und dann sollten sie zusätzlich prüfen, dass Sie den Ordner "Microsoft Exchange System Objects" nicht über Filter ausgeschlossen haben.

Danach sollten aber alle öffentlichen Ordner mit einer Mailadresse auch im AzureAD angelegt werden. Dieser Eintrag scheint für Exchange Online dann aber auszureichen.

Use Directory Based Edge Blocking to reject messages sent to invalid recipients
https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/use-directory-based-edge-blocking

Leider ist es mir noch nicht gelungen dies auch zu prüfen, denn weder ein Get-AzureADUser, Get-AzureADGroup o.ä. liefert diese Objekte. Es gibt kein Get-AzureAD-Publicfolder.

Exchange Online?

Irritieren ist aber, dass aber auch ein "Get-Recipient" in Exchange Online immer noch keine Objekte anzeigt werden. Weder im Adressbuch noch in der PowerShell oder der Webverwaltung. Da muss also noch etwas fehlt. Ein erster Hinweis gibt aber schon Microsoft.

Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay. Once the domain type has been changed to Authoritative, DBEB is designed to allow any SMTP address that has been added to the service (except for mail-enabled public folders)
Quelle: Use Directory Based Edge Blocking to reject messages sent to invalid recipients
https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/use-directory-based-edge-blocking

Noch deutlicher ist der folgende Blog-Eintrag:

If DBEB is enabled, any mails sent to Mail Enabled Public Folders (MEPF) will be dropped at the service network perimeter. This is because, DBEB queries Azure Active Directory (AAD) to find out if a given mail address is valid or not. Because Mail Enabled Public Folders (MEPF) are not synced to Azure Active Directory, all MEPF address are considered as invalid by DBEB. 
Quelle: Office 365 Directory Based Edge Blocking support for On-Premises Mail Enabled Public Folders
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Office-365-Directory-Based-Edge-Blocking-support-for-On-Premises/ba-p/606740

Die Korrekturen von Microsoft hinsichtlich ADSync lösen also nur die Probleme mit dem Spamfilter aus der Cloud, der bislang öffentliche Ordner nicht als Empfänger erkannt hat.

Mailrouting

Für die Erreichbarkeit von öffentlichen Ordnern, die auf einem lokalen Exchange Server liegen, müssen wird auf jeden Fall das "Mailrouting" sicherstellen. Ich möchte z.B. nicht, dass Office 365 die Mails von Office 365 Anwendern über das Internet ohne Verschlüsselung zum lokalen Server und dort noch durch den Spamfilter müssen. Einen direkten Weg haben wir aber in der Regel durch das "Hybrid-Setup" schon realisiert. Über einen entsprechenden "Outbound Connector" in der Cloud werden alle Mails an meine eigenen Domains gesichert zur lokalen Exchange Installation geroutet.

Get-OutboundConnector

Name                RecipientDomains   SmartHosts
----                ----------------   ----------
Outbound to <guid>  {msxfaq.de}        {hybrid.ms...

Aber das alleine hilft noch nicht, denn per Default sind die Domänen in Office 365 "Autoritativ".

Get-AcceptedDomain | ft -AutoSize

Name                        DomainName                   DomainType      Default
----                        ----------                   ----------      -------
msxfaq.de                   msxfaq.de                    Authoritative   False
msxfaq.mail.onmicrosoft.com msxfaq.mail.onmicrosoft.com  Authoritative   False
msxfaq.onmicrosoft.com      msxfaq.onmicrosoft.com       InternalRelay   True
lyncfaq.de                  lyncfaq.de                   Authoritative   False

In dem Fall "muss" es entsprechende Kontakte geben, damit die Mails an einen Empfänger außerhalb von Exchange Online auch erreicht werden können. Als Zieladresse für diese Kontakte bietet sich dann die "<tenantname>.mail.onmicrosoft.com"-Domain an, die als "InternalRelay" konfiguriert ist.

Sie können natürlich auch andere Domains auf "InternalRelay" umstellen. Damit würde Exchange Online dann Nachrichten an "unbekannte" Empfänger immer zum lokalen Exchange Server weiter leiten.

set-AcceptedDomain msxfaq.de -DomainType internalRelay

Allerdings rate ich davon ab, da so Loops einfach möglich sind und vor allem ein Spamfilter nicht frühzeitig ungültige Adressen blockieren kann. In ihrer Hoheit sollten Sie dafür sorgen, dass alle System genaue alle gültigen Empfänger samt ihrem finalen Ziel kennen.

Public Folder Kontakte manuell

Damit kommen wir dann wieder zu den fehlenden Kontakten, die ADSync anscheinend nicht anlegt. Also habe ich in Exchange Online direkt einen Kontakt angelegt, der als Zieladresse die Mailadresse des öffentlichen Ordners "On-Premises" hat.

New-MailContact `
   -Name Faxeingang `
   -ExternalEmailAddress SMTP:faxeingang@msxfaq.mail.onmicrosoft.com

Name                Alias                RecipientType
----                -----                -------------
Faxeingang          Faxeingang           MailContact

Exchange Online legt dann einen kompletten Kontakt an

get-MailContact Faxeingang | fl

ExternalEmailAddress                   : SMTP:faxeingang@msxfaq.mail.onmicrosoft.com
MaxRecipientPerMessage                 : Unlimited
UseMapiRichTextFormat                  : Never
UsePreferMessageFormat                 : False
MessageFormat                          : Mime
MessageBodyFormat                      : TextAndHtml
MacAttachmentFormat                    : BinHex
UserCertificate                        : {}
UserSMimeCertificate                   : {}
Extensions                             : {}
HasPicture                             : False
HasSpokenName                          : False
IsDirSynced                            : False
AcceptMessagesOnlyFrom                 : {}
AcceptMessagesOnlyFromDLMembers        : {}
AcceptMessagesOnlyFromSendersOrMembers : {}
AddressListMembership                  : {\Default Global Address List, \All Contacts, \Offline Global Address List,
                                         \All Recipients(VLV)...}
AdministrativeUnits                    : {}
Alias                                  : Faxeingang
ArbitrationMailbox                     :
BypassModerationFromSendersOrMembers   : {}
OrganizationalUnit                     : eurpr04a003.prod.outlook.com/Microsoft Exchange Hosted
                                         Organizations/msxfaq.onmicrosoft.com
CustomAttribute1                       :
CustomAttribute10                      :
CustomAttribute11                      :
CustomAttribute12                      :
CustomAttribute13                      :
CustomAttribute14                      :
CustomAttribute15                      :
CustomAttribute2                       :
CustomAttribute3                       :
CustomAttribute4                       :
CustomAttribute5                       :
CustomAttribute6                       :
CustomAttribute7                       :
CustomAttribute8                       :
CustomAttribute9                       :
ExtensionCustomAttribute1              : {}
ExtensionCustomAttribute2              : {}
ExtensionCustomAttribute3              : {}
ExtensionCustomAttribute4              : {}
ExtensionCustomAttribute5              : {}
DisplayName                            : Faxeingang
EmailAddresses                         : {SMTP:faxeingang@msxfaq.mail.onmicrosoft.com}
GrantSendOnBehalfTo                    : {}
ExternalDirectoryObjectId              : 3ed1906c-64e6-4fd7-8a8f-688b719c2bf7
HiddenFromAddressListsEnabled          : False
LastExchangeChangedTime                :
LegacyExchangeDN                       : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipi
                                         ents/cn=d16795270d2745ac98695d02bc860013-Faxeingang
MaxSendSize                            : Unlimited
MaxReceiveSize                         : Unlimited
ModeratedBy                            : {}
ModerationEnabled                      : False
PoliciesIncluded                       : {}
PoliciesExcluded                       : {{26491cfc-9e50-4857-861b-0cb8df22b5d7}}
EmailAddressPolicyEnabled              : False
PrimarySmtpAddress                     : faxeingang@msxfaq.mail.onmicrosoft.com
RecipientType                          : MailContact
RecipientTypeDetails                   : MailContact
RejectMessagesFrom                     : {}
RejectMessagesFromDLMembers            : {}
RejectMessagesFromSendersOrMembers     : {}
RequireSenderAuthenticationEnabled     : False
SimpleDisplayName                      :
SendModerationNotifications            : Always
UMDtmfMap                              : {emailAddress:3293464264, lastNameFirstName:3293464264,
                                         firstNameLastName:3293464264}
WindowsEmailAddress                    : faxeingang@msxfaq.mail.onmicrosoft.com
MailTip                                :
MailTipTranslations                    : {}
Identity                               : Faxeingang
Id                                     : Faxeingang
IsValid                                : True
ExchangeVersion                        : 0.20 (15.0.0.0)
Name                                   : Faxeingang
DistinguishedName                      : CN=Faxeingang,OU=netatwork.onmicrosoft.com,OU=Microsoft Exchange Hosted
                                         Organizations,DC=EURPR04A003,DC=prod,DC=outlook,DC=com
ObjectCategory                         : EURPR04A003.prod.outlook.com/Configuration/Schema/Person
ObjectClass                            : {top, person, organizationalPerson, contact}
WhenChanged                            : 01.12.2019 14:51:38
WhenCreated                            : 01.12.2019 14:51:38
WhenChangedUTC                         : 01.12.2019 13:51:38
WhenCreatedUTC                         : 01.12.2019 13:51:38
ExchangeObjectId                       : fd0fca74-5894-43a2-82bd-74ff7dbffac9
OrganizationId                         : EURPR04A003.prod.outlook.com/Microsoft Exchange Hosted
                                         Organizations/msxfaq.onmicrosoft.com - EURPR04A003.prod.outlook.com/Confi
                                         gurationUnits/msxfaq.onmicrosoft.com/Configuration
Guid                                   : fd0fca74-5894-43a2-82bd-74ff7dbffac9
OriginatingServer                      : AM6PR04A03DC001.EURPR04A003.prod.outlook.com
ObjectState                            : Changed

Interessant finde ich, dass der Kontakt nach kurzer Zeit auch als "Contact" im AzureAD landet und sogar die Mailadresse als "ProxyAddresses" hinterlegt ist. Es gibt also entweder eine Replikation von EXODS zum AzureAD oder das Exchange Online Commandlet legt auch einen Kontakt an:

PS C:\> Get-AzureADContact -ObjectId 3ed1906c-64e6-4fd7-8a8f-688b719c2bf7 | select *

DeletionTimestamp          :
ObjectId                   : 3ed1906c-64e6-4fd7-8a8f-688b719c2bf7
ObjectType                 : Contact
City                       :
CompanyName                :
Country                    :
Department                 :
DirSyncEnabled             :
DisplayName                : Faxeingang
FacsimileTelephoneNumber   :
GivenName                  :
JobTitle                   :
LastDirSyncTime            :
Mail                       : faxeingang@msxfaq.mail.onmicrosoft.com
MailNickName               : Faxeingang
Mobile                     :
PhysicalDeliveryOfficeName :
PostalCode                 :
ProvisioningErrors         : {}
ProxyAddresses             : {SMTP:faxeingang@msxfaq.mail.onmicrosoft.c
                             om}
SipProxyAddress            :
State                      :
StreetAddress              :
Surname                    :
TelephoneNumber            :

Ein "New-AzureADContact" gibt es ja leider nicht.

Hier gibt es eine weiter Unstimmigkeit, denn in dem Tenant hat ADSync ja schon ein Objekte mit der gleichen Mailadresse angelegt.

Wenn ADSync sich schon nicht darum kümmert, die Objekte in der Cloud für lokal vorhandene mailaktivierte öffentliche Ordner zu verwalten, dann muss ich das wohl selbst machen. Ich habe daher zuerst das AzureAD-Objekt mit folgendem Commandlet entfernt.

Remove-AzureADContact -ObjectId 5455959b-df06-419e-8f0c-a78f4870ac77

Es hat ein paar Sekunden gedauert aber dann war auch das Objekt in Exchange verschwunden. Auch hier kann ich aber nicht zu 100% sagen, ob das "Remove-AzureADContact" zeitgleich auch im EXODS das Objekt entfernt hat und meine Verzögerung bei "Get-MailContact" einfach durch eine interne Replikation begründet ist oder ob ein Backend-Prozess die Änderungen im AzureAD dann nach Exchange Online überträgt.s

Public Folder mit Skript

Die Verwaltung von mailaktivierten öffentlichen Ordnern auf lokalen Exchange Servern in der Cloud ist bislang also noch kein automatischer Prozess, sondern erfordert manuelle Eingriffe durch den Administrator, damit die die Ordner auch für Office 365 Absender oder externe Absender über Exchange Online Protection erreichbar sind. Wer dazu nicht die Domains als "Internal Relay" öffnen will, muss entsprechende Kontakte pflegen. Sie könnten nun erklären, dass das alles nicht so schlimm ist und öffentliche Ordner sowieso in Zeiten von Teams und SharePoint quasi abgelöst werden sollten. Bestimmte Prozesse dauern aber eben etwas länger und solange es die Funktion auch in der Cloud gibt, sollten Sie während der Migration die gleiche Funktion bereit stellen.

Ehe Sie sich nun frisch ans Werk machen, sollte man als Administrator erst mal schauen, ob es da nicht schon etwas gibt. In dem Fall hat sogar Microsoft ein PowerShell-Skript bereit gestellt, welches ihnen hier die Arbeit abnehmen kann

Mail-enabled Public Folders - directory sync script
https://www.microsoft.com/en-us/download/details.aspx?id=46381

Dieses Skript können Sie immer dann als Administrator starten, wenn Sie mal wieder einen öffentlichen Ordner für den Empfang von Mails aktiviert oder deaktiviert haben. Es liest mit einem "Get-MailPublicFolder" aus der lokalen Installation alle Ordner aus, die für den Empfang von Mails aktiviert sind und pflegt entsprechenden Kontakte in Exchange Online. Microsoft schreibt dazu:

The Directory Synchronization service doesn't synchronize mail-enabled public folders. Running the following script will synchronize the mail-enabled public folders across premises and Office 365. Special permissions assigned to mail-enabled public folders will need to be recreated in the cloud since cross-premise permission are not supported in Hybrid Deployment scenarios

Synchronized mail-enabled public folders will appear as mail contact objects for mail flow purposes and will not be viewable in the Exchange admin center. See the Get-MailPublicFolder command. To recreate the SendAs permissions in the cloud, use the Add-RecipientPermission command.
Quelle: https://docs.microsoft.com/de-de/exchange/collaboration-exo/public-folders/set-up-modern-hybrid-public-folders

Microsoft hat die Funktion relativ gut dokumentiert und da das Skript ja im Sourcecode vorliegt und damit lesbar ist, beschränke ich mich auf den Aufruf:

Sync-MailPublicFolders.ps1 -Credential (Get-Credential) -CsvSummaryFile "<sync_summary.csv>"

Sie müssen das Skript auch nicht sehr oft aufrufen sondern nur, wenn sich an den Ordnern etwas ändert, die für dem Mailempfang aktiviert wurden. Da diese Funktion in der Regel auch kein Anwender sondern nur ein Exchange Admin machen kann, bleibt es am Exchange Admin hängen, dieses Skript nach einer Änderung aufzurufen.

Public Folder als Mitglied in einem Verteiler

Wenn Sie nun glauben, dass Sie damit alle Probleme gelöst haben, dann haben Sie einen Faktor vergessen. Exchange nutzt Windows Gruppen als Mailverteiler und auch ein öffentlicher Ordner kann "Mitglied" in einer Verteilergruppe sein. Eine Mail an so einen Verteiler muss natürlich auch in dem öffentlichen Ordner landen. Ich habe hier eine Testgruppe, die auch im Metaverse erscheint.

Wenn ich mir die Synchronisationsregeln der Gruppen anschaue, dann werden auch die "member" mitgenommen:

Das Problem liegt aber noch viel weiter vorne. Das Active Directory Objekt mit der Mailadresse hat eine besondere Objektklasse:

Die ObjectCategory ist "ms-Exch-Public-Folder" und die ObjectClass enthält nur "Top" und "publicFolder" aber z.B. nicht z.B. User oder Person. Es gibt eine eigene Regel für öffentliche Ordner, wenn Sie die Option im ADSync Setup aktivieren.

Durch diese Regel werden die AD-Objekte für Mailaktivierte öffentliche Ordner in das Metaverse übertragen und dann sogar raus in das AzureAD aber nicht weiter. Leider werden diese Objekte, die im Metaverse sind, eben nicht in die Verteilergruppen als "member" aufgenommen. Eine Lösung ist nicht über ADSync direkt möglich ohne umfangreich die Konfiguration zu ändern. Die dürfte aber das nächste Update vermutlich nicht überstehen

Es ist daher besser an ADSync nicht zu ändern. Wir könnten zwar die Kontakte direkt in Exchange Online anlegen aber da die Mailverteiler in der Cloud ebenfalls über ADSync verwaltet sind, können wir hier die Mitgliedschaften in den Verteilern natürlich nicht verwalten. Also bleibt nur der Umweg, dass man im lokalen Active Directory entsprechende "Kontakte" anlegt, die dann wieder Mitglied in den Verteilern sind.

Aber wir können die Mailverteiler, die ADSync in die Cloud überträgt, natürlich auch nicht in der Cloud verändern. Daher müssen wir die erforderlichen Änderungen im lokalen AD so durchführen, dass ADSync die Änderungen auch passend ins AzureAD und EXODS überträgt. Da wir keine "MailUser" oder "MailboxUser" anlegen wollen, bleiben ja nur MailContacts übrig.

Ich hätte mir also nun die AD-Objekte in "Microsoft Exchange System Objects" geschnappt aber mein Versuche hier die ObjectClass zu erweitern haben nicht zum ziel geführt.

Daher ist wohl der Ansatz des Microsoft Mitarbeiters Roman Zarka der einzige Weg, auch wenn er etwas ungewöhlich ist. Er hat seine Lösung hier gebloggt

Er sucht sich erst die MailPublicFolder um dann diese Objekte in den Verteilern zu finden. Nur für die Objekte, die Mitglied in einem Mailverteiler sind, legt er einen Mailcontact mit einer temporären Adresse an um diese Adresse dann direkt mit AD-Commandlets zu ändern. Das widerspricht natürlich jeder Vorgabe des Exchange Teams, die Änderungen an Exchange-relevanten Feldern an den Exchange Commandlets vorbei als "non Supported" ansehen.

Einschätzung

Die Koexistenz von öffentlichen Ordnern in einer lokalen Umgebung mit Exchange online ist möglich aber sobald die Ordner auch per Mail erreichbar sein sollen, reichen die Bordmitteln von Microsoft nicht mehr aus. Anscheinend ist der Anwendungsfall sehr selten oder die Einschränkungen führen dazu, dass Firmen noch schneller von mailaktivierten öffentlichen Ordnern abstand nehmen. Anders kann ich mir nicht erklären, dass selbst Ende 2019 und viele ADSync-Updates später diese Funktion noch immer nicht im Standard-Regelwerk enthalten ist.

Ich gehe aber nicht davon aus, dass dies kurzfristig sogar noch gelöst wird, genauso wenig wie ADSync Empfänger in der Cloud (Teams-Kanäle etc.) in absehbarer Zeit als Kontakte in eine lokale Umgebung replizieren wird. Auch wenn es hier seit einiger Zeit zumindest die Funktion "M365Groups Writeback" gibt.

Weitere Links