ADSync mit Exchange

Sobald Sie ihre Benutzer im Office 365/MIcrosoft 365 Tenant mittels ADSync verwalten, können Sie die Exchange-Einstellugen in der Cloud nicht mehr direkt verwalten. Diese Seite beschreibt die Rolle des ADSync in Verbindung mit Exchange.

Einleitung

Wenn ihr Tenant für den Verzeichnisabgleich mit einem lokalen Active Directory aktiviert wurden, blockiert Microsoft in der Cloud nicht nur die Stammdatenpflege der replizierten AD-Benutzer und AD-Gruppen sondern auch die Exchange Eigenschaften. Sie können in Exchange online weder per PowerShell, Graph noch die Admin Portale verändernd auf die Exchange Eigenschaften zugreifen, die es auch im lokalen AD gibt.

Das ist auch absolut relevant, wenn Sie noch lokale Exchange Server nutzen, denn eine synchrone GAL ist essentiell für ein korrektes Mailrouting und insbesondere den Hybrid-Betrieb. Wenn Sie dennoch eine "kleine Firma" habe und auf ADSync nicht verzichten wollen, dann können Sie seit April 2022 aber auch mit einer reduzierten Exchange Powershell im lokalen AD arbeiten. Aber eine Exchange Schemaerweiterung im AD und die Verwaltung im lokalen AD bleibt erhalten.

Auf der Seite Office 365 Small Business - Ganz schnell habe ich beschrieben, wie man als kleine Firma in sehr kurzer Zeit einen Office 365 Vertrag abschließen und komplett autark nutzen kann. Beim Einsatz von Exchange in der Cloud in Verbindung mit dem Verzeichnisabgleich sind also ein paar Besonderheiten zu beachten. Das gilt übrigens auch für den Office 365:UPN / Anmeldename in Verbindung mit dem DirSync. Das habe ich bei der Einrichtung meines eigenen Tenants (Siehe Office 365 Mittelstand) schmerzlich erfahren müssen.

Exchange LDAP-Felder

Welche LDAP-Felder von ADSync hinsichtlich Exchange abgeglichen werden, können Sie entweder im Rule Editor von ADSync sehen oder die lesen einfach die Microsoft Dokumentation:

Die meisten Felder werden "unidirektional" bearbeitet, d.h. ADSync liest die Felder aus dem lokalen AD aus und schreibt Sie in die Cloud. Das AzureAD-Backend sorgt dann dafür, dass die Felder in den entsprechenden Zielverzeichnissen in der Cloud landen. Es gibt nämlich nicht nur ein AzureAD

Exchange Extension Attibute

Auch wenn die Liste der Attribute explizit auch die ExtensionAttibute1-15 enthält, so sollten Sie nicht davon ausgehen, dass diese Felder immer synchronisiert werden. Das kann passieren, wenn ADSync vor der Exchange Schema Erweiterung installiert wurde. Zudem gibt es noch Felder wie ExtensionCustomAttibute1-5 und ExtensionAttibute16-35, die nicht repliziert werden. Ich selbst nutzt diese Felder auch gerne für das Provisioning oder die Anlage von eigenen Informationen. Auch "Multivalue"-Felder sind tückisch.

Daher sollten Sie immer prüfen, ob Felder wie erwartet gefüllt und repliziert werden.

Exchange "Name"

In der Exchange Online PowerShell finden sie bei einer Mailbox und Distributiongroup auch das Property "Name". Früher wurde hier einfach aus dem AD der CN übernommen und nicht wenige Skripte haben dieses Feld als "key" missbraucht, obwohl es nicht zwingend eindeutig in einem ADForest sein muss. Im AzureAD muss das Feld allerdings eindeutig sein und hat zu den ein oder anderen Problemen geführt. Daher hat Microsoft ein verändertes Verhalten für dieses Feld eingeführt.

Es wid nicht mehr von den durch ADSync gelieferten Daten provisioniert, sondern Microsoft nutzt den Wert der " ExternalDirectoryObjectId (EDOID)", um nicht nur dieses Feld zu füllen, sondern auch den CN des Objekts im Exchange Online Forest festzulegen. Diese neue Regel gilt aber nur für nach der Änderung neu angelegte Objekte. Bestehende Objekte werden nicht geändert, so dass ältere Tenants nun ein Mischmach von Objekten haben, bei denen der Name teils ein sprechender String und bei anderen Objekten eine GUID ist.

Prüfen Sie ihre Skripte, ob Sie das Feld "Name" bei der Exchange PowerShell für weitere Verwendungen einsetzen.

ADSync und ProxyAddresses

Für Exchange ist dieses Feld interessanter beim Management von Exchange Empfängern per DirSync/ADSync und Exchange Online. Dies gilt um so mehr, da es ein "Mehrwertiges Feld" ist, d.h. es ist ein Array und es kann so durchaus passieren, dass nur ein Eintrag geändert wird.

Der DirSync repliziert dieses Feld auf "Einzelelementen", d.h. es wird nicht das komplette Feld im Ziel durch die Daten aus der Quelle überschrieben, sondern die Daten werden differenziell übertragen. So kann es dazu kommen, dass in der Cloud Einträge in diesem Feld enthalten sind, die On-Prem nicht vorhanden sind. ein Beispiel:

  1. User wird in Office 365 manuell angelegt
    Das können Sie durchaus machen und auch komplett mit Exchange und Skype für Business verwalten
  2. Ein Benutzer im lokalen AD wird angelegt oder "passend" gemacht
    Beim nächsten DirSync-Lauf kann ein Matching erfolgen, wenn das Feld "mail" identisch ist. Aus dem "Cloud User" wird nun ein "DirSync User", der in der Cloud mit den Mitteln der Cloud nicht mehr frei verwaltet werden kann. Er hat aber weiter ein Postfach samt Proxyaddresse, welche ohne Hybrid-Mode auch nicht On-Premises zurück repliziert werden.
  3. Sie addieren eine ProxyAddresse On-Premises und ändern die primäre Mai-Adresse
    Der DirSync "addiert" diese Adresse im Ziel zu den bestehenden Adressen.
  4. Sie entfernen eine Adresse On-Prem
    Der DirSync entfernt auch wieder gezielt diese eine Adresse.

Wichtig: Beachten Sie die Seite Office 365:UPN / Anmeldename bezüglich der Übereinstimmung von UPN, Mailadresse und SIP-Adresse. Sie sollten diese auch bei manueller Verwaltung mit ADSIEDIT o.ä. beibehalten. Darauf achten müssen Sie aber selbst.

Es gibt noch ein paar Dinge, die sie beachten sollten.

  • Ungültige Adressen
    SMTP-Adressen mit Domänen, die sie in Office 365 nicht angelegt haben, werden nicht in die Cloud übertragen. Sie werden einfach ignoriert.
  • SIP-Adresse
    In den Proxy-Addresses in der Cloud ist auch die SIP-Adresse eines für Skype für Business aktivierten Benutzers enthalten. Diese kann nicht direkt per DirSync oder PowerShell geändert werden. Dieser Eintrag ist direkt mit der SIP-Adresse von Skype für Business verbunden und wird per Default an den Office 365:UPN / Anmeldename gebunden. Das muss aber nicht so sein!
  • X.500 Adressen
    Diese Adressen haben eine Besonderheit, dass Sie bei CrossForest-Migrationen den alten LegacyExchangeDN enthalten. So werden auch später noch Rückantworten zugestellt. Dieses Felder werden auch in die Cloud repliziert
  • SPO-Adresse
    Wundern sie sich nicht, wenn ihr Office 365 Konto noch eine SPO-Adresse zusätzlich für SharePoint online bekommt. Sie wieder aber nicht auf das On-Prem-Objekte repliziert.
  • X400-Adressen
    X400-Adressen werden die meisten On-Premises-Konten von früheren Exchange Versionen noch haben. Sie sind aber seit Exchange 2007 schon nicht mehr erforderlich. Der DirSync repliziert diese Felder nicht in die Cloud.
  • Ungültige Domäne als primäre Adresse
    Versuche ich eine Mailadresse aus einer Domäne, die mir nicht gehört, als primär zu setzen, dann wählt Office 365 nicht eine andere Adresse zufällig aus, sondern nutzt oder generiert eine Adresse aus der Tenant-Domäne, also *@tenantname.onmicrosoft.com"

Insofern sind die Objekte On-Premises und in Office 365 trotz DirSync nicht 100% identisch, da einige Felder bzw. Inhalte von Feldern gekürzt und erweitert werden. Wohl dem, der ein paar Lizenzen über hat und einen Office 365 Test-Tenant betreibt um solche Dinge nicht in Produktion testen zu müssen.

HCW und ADSync

Achtung: Der Exchange Hybrid Wizard kann beim "Minimum Mode" eine ADSync Installation mit ausführen.

Sie sollten genau entscheiden, ob sie Exchange auch als ADSync Server einsetzen wollen und beim HCW mit "Minimum Hybrid" die richtige Option in dem folgenden Fenster auswählen:

Ich installieren ADSync immer getrennt auf einem anderen System und wähle hier dann "on my own". Schade, dass HCW nicht eine bestehende Installation z.B. anhand des MSOL_Dirsync-Kontos erkennt.

Exchange Hybrid Checkbox in ADSync

Es ist mir mehrfach bei Kunden passiert, bei denen ich "Exchange Hybrid" einrichten sollte und ADSync nicht vorbereitet war. ADSync liest Identitäten aus dem dem lokalen AD und überträgt diese in das AzureAD, Office365 und auch Exchange Online lernt diese Objekte. ADSync repliziert neben dem UPN auch das Feld "Mail" in die Cloud und Exchange Online kann damit schon arbeiten, selbst wenn kein Hybrid-Mode eingerichtet ist.

Wenn Sie aber "richtig" mit Exchange Hybrid einrichten dürfen, dann müssen Sie zuerst im ADSync die entsprechende Checkbox setzten:

Es gibt den Sonderfall, dass diese Box nicht aktivierbar ist. Das passiert, wenn Sie ADSync vor der Exchange Schemaerweiterung installieren. Das ist durchaus realistisch, z.B. wenn Sie mit einem neuen Forest im Rahmen einer Migration oder Neugründung starten und ADSync zuerst installiert haben. Die Lösung ist einfach. Im bestehenden Azure AD Connect-Setup können Sie ein "Refresh Schema" auswählen.

ADSync lernt damit lokale Schema-Erweiterungen und bietet dann die zusätzlich passenden Funktionen an.

Sonderfall: ADSync und Exchange Online - ReadOnly

Sobald Sie ihren Office 365 Tenant für "DirSync" freischalten, werden Sie auch an anderer Stelle einige Veränderungen bemerken. Die umfangreichste Einschränkung ist bei der Verwaltung von Exchange Online zu bemerken. Der DirSync legt nicht nur den Benutzer an bzw. verwaltet den Benutzer und sie müssen auch weiterhin eine "Lizenz" zuweisen, damit der Benutzer ein Postfach bekommt. Aber durch den DirSync wird auch verhindert, dass Sie die Exchange-Eigenschaften des Benutzers über einen Webbrowser oder PowerShell in der Cloud verwalten können. Dies fällt den meisten Administratoren erst auf, wenn Sie das Feld "ProxyAddresses" ändern wollen. Sie können im Browser das Feld zwar noch editieren aber nicht zurück speicherm.

Die Fehlermeldung ist etwas irreführend:

"Fehler bei Vorgang für Postfach "User1", da es außerhalb des Schreibbereichs für den aktuellen Benutzer liegt. Die Aktion 'Set-Mailbox', 'EmailAddresses', kann nicht für das Objekt 'User1' durchgeführt werden, weil dieses Objekt von lokal synchronisiert wird. Diese Aktion sollte lokal für das Objekt durchgeführt werden."

Das bedeutet nichts anderes, als dass Sie keine Möglichkeit zur Pflege von Objekte haben, die per DirSync/ADSync in der Cloud verwaltet werden. Natürlich ist das kein Problem, wenn Sie On-Prem einen Exchange Server haben und ggfls. auch den Hybrid-Mode nutzen. Dann haben Sie On-Prem alle Werkzeuge, um die relevanten AD-Felder der Benutzer im lokalen Forest korrekt zu pflegen.

When directory synchronization is enabled for a tenant and a User is synchronized from On-Premises, most of the attributes cannot be managed from Exchange Online and must be managed from On-Premises. This is not due to the hybrid configuration, but it occurs because of directory synchronization. In addition, even if you have directory synchronization in place without running the Hybrid Configuration Wizard, you still cannot manage most of the recipient tasks from the cloud.
Quelle: https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx

Step5: After you’ve verified that all e-mail is being routed directly to the cloud-based mailboxes, completed the migration, and no longer need to maintain your On-Premises e-mail organization for mail delivery you can uninstall Exchange from servers in your On-Premises Exchange organization. However, it’s strongly recommended that you maintain at least one Exchange server so that you have access to Exchange System Manager (Exchange 2003) or Exchange Management Console/Exchange Management Shell (Exchange 2007 and Exchange 2010) to manage mail-related attributes on the On-Premises MEUs. For Exchange 2007 and Exchange 2010, the Exchange server that you maintain should have the Hub Transport, Client Access, and Mailbox server roles installed.
Quelle: https://community.office365.com/en-us/w/exchange/835

Der Einsatz von Office 365 ist aber gerade für kleine und mittlere Firmen interessant, die On-Prem keinen Exchange Server mehr haben. Solange ich keinen Verzeichnisabgleich eingerichtet habe, kann ich die Exchange-Eigenschaften noch über das Exchange Control Panel in der Cloud manuell verwalten. Interessant wird es, wenn die Benutzer mittels Verzeichnisabgleich in der Cloud verwaltet werden:

Microsoft hat natürlich schon seit Windows 2000 das Feld "ProxyAddresses" auch im Active Directory Schema hinterlegt: Technisch ist es also kein Problem die Felder auch ohne lokal installierten Exchange Server zu setzen und durch den DirSync in die Cloud übertragen zu lassen. Da ich allerding On-Prem gar keinen Exchange Server habe, kann ich die entsprechenden Felder On-Prem auch nicht einfach pflegen. Sicher kann ich das per ADSIEDIT oder DSA.MSC mit aktivierter erweiterter Ansicht machen. Aber muss ich das wirklich?

The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange Administration Center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects
https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx

Nach dem Zuweisen der Office 365 Lizenz erscheinen die per ADSync angelegten Benutzer nun auch in Exchange mit einen Postfach und der Standard Mailadresse Username@tenantname.onmicrosoft.com. Damit könnten diese Anwender sogar Mails senden und empfangen. Office 365 hat dies ja dankenswerterweise schon komplett eingerichtet. ich möchte aber meine eigene Domäne verwenden. Erst wollte ich es nicht glauben aber eine Recherche im Internet liefert dann schnell die Bestätigung, dass es aktuell (April 2015) anscheinend nicht anders möglich ist.

Die Verzeichnissynchronisierung steht für Kunden mit einer Hybridbereitstellung (lokale und cloudgehostete Postfächer) sowie für vollständig gehostete Exchange Online-Kunden zur Verfügung, die über ein lokales Active Directory verfügen.
Quelle: https://technet.microsoft.com/de-de/library/bb124381(v=exchg.150).aspx

Generally speaking, when DirSync is enabled, an On-Prem Exchange server is recommended für official supported uI management tools.
If you choose to disable DirSync, you can manage the Office 365 User’s Exchange-related attributes in Office 365 directly.
Quelle: How to Manager Exchange Attributes with DirSync Enabled (http://community.office365.com/en-us/f/148/t/227778.aspx)

Selbst wenn Sie lokal keine Exchange Services installieren, müssen Sie zumindest die Schema-Erweiterung anwenden, damit Sie mit anderen Werkzeugen On-Premises die LDAP-Felder entsprechend setzen können.

Aus meiner Sicht ist das natürlich ein sehr schlechtes Konzept, wenn man DirSync auf der einen Seite einsetzen will aber mangels Exchange On-Prem (und daher auch ohne Schemaerweiterung) auf dem lokalen Server nur ausgewählte Properties pflegen kann. Hinzu kommt, dass die ProxyAddresses in der Cloud zwar von Exchange generiert aber natürlich nicht On-Premises vorliegen.

Für die Verwaltung einer Exchange Online Umgebung mit aktiviertem DirSync ist ein lokaler Exchange Server zur Verwaltung der Benutzer sehr empfehlenswert. Er muss aber nicht per AutoDiscover erreichbar oder gar als Hybrid Server eingebunden sein.

Exchange Provisioning Server

Wer eine von Microsoft empfohlene Umgebung betreiben möchte, kam lange um den lokalen Exchange Server nicht herum. Mittlerweile gibt es aber auch einen Weg, ohne Exchange Server und nur mit der Exchange Adminrolle die Benutzer in der Cloud bezüglich der Exchange Properties zu verwalten UND mit einem ADSync mit Office 365 abzugleichen.

Wenn Sie bislang noch nie einen Exchange Server On-Premises installiert haben, dann starten Sie ganz einfach eine Exchange Installation. Sie können dazu einfach den Exchange Server von Microsoft als "Eval-Version" herunter laden. Den Lizenzcode bekommen Sie dann aus dem Office 365 Portal:

  • 2939261 So erhalten Sie einen Product Key Exchange Hybrid Edition für lokalen Exchange 2007 oder Exchange 2003-Organisation
  • Exchange Hybrid Verteilungsassistent
    http://aka.ms/hybridkey

Allerdings können Sie diesen Key wirklich nur für den Hybrid-Server verwenden. Es dürften auf diesem Server keine Postfächer angelegt werden und es darf auch keine anderen bereits installierten und lizenzierten Exchange Server existieren.

Die Installation entspricht der ganz normalen Installation eines Single Exchange Servers in ihrem Forest, der den Exchange Mindestvoraussetzungen entsprechen muss:

Vor der Installation sollten Sie noch kurz innehalten: Outlook Clients versuchen zuerst per LDAP einen CAs-Server zu finden. Ohne Exchange Server gibt es den Eintrag nicht und die Clients wechseln auf "autodiscover.<maildomain>". Mit dem Exchange Server hingegen ist nun ein Server vor Ort vorhanden, der von den Clients im LAN gefunden wird. Wenn der Server funktioniert und alle Cloud-User hier auch als "Remote Mailbox" mit passender TargetAddress konfiguriert sind, dann werden die Client direkt zur Cloud umgeleitet.

Sollte der Server aber einmal nicht erreichbar, das Zertifikat abgelaufen o.ä. Gründe die Funktion verhindern, dann bekommen die Anwender eventuell einen Fehler zu sehen. Um das zu vermeiden können Sie dem Server sagen, dass er keinen Service Connection Point im Active Directory veröffentlicht. Das geht mit:

# Exchange 2010/2013
Set-ClientAccessServer -AutoDiscoverServiceInternalURL:$Null

# Exchange 2016
Set-ClientAccessService -AutoDiscoverServiceInternalURL:$Null

Damit wird der Server nicht mehr veröffentlicht und die Clients gehen direkt nach "autodiscover.<maildomain>". Nach der Installation sollten Sie aber noch ein paar Dinge überlegen

  • Free/Busy Konfiguration
    Da es lokal keine Postfächer gibt, kann man sich die Einrichtung eines Microsoft Federation Trusts und die Veröffentlichung der Exchange WebServices sparen
  • Hybrid Konfiguration
    Genau genommen muss man nicht einmal eine Exchange Hybrid Konfiguration durchführen.
  • Mailrouting
    Sie können den lokalen Server aber durchaus als "Connector-Server" verwenden, z.B.: um Mails von lokalen Prozessen an diesen Server zuzustellen, der sich dann um die Weiterleitung kümmert und auch Mails von der Cloud z.B. an einen lokalen Faxserver oder Helpdesk-System per SMTP weiter leitet.
  • Datenbanken
    Auch wenn Sie keine Postfächer auf diesem Hybrid-Server betreiben dürfen, legt er per Default natürlich zumindest eine Postfachdatenbank an. Damit die Festplatten nicht durch Transaktionsfiles voll läuft, sollten Sie hier die Umlaufprotokollierung aktivieren.

Leider ist es auch ohne die Funktionen ein vollständiger Exchange Server. Windows Updates, und Patches sind nun kontinuierlich einzuspielen und auch über Backup und Virenschutz sollten Sie nachdenken.

Sonderfall: DirSync und Exchange - Andere Objekte

In Office 365 kann man natürlich auch noch andere Objekte verwalten. Auch diese können über den DirSync/ADSync angelegt werden. Interessant sind hier:

  • Verteiler
  • MailUser
  • MailContact

Sie können diese Objekte natürlich auch direkt in der Cloud anlegen und verwalten, aber genau dies ist mit dem DirSync ja nicht gewollt. Eine per DirSync angelegte Gruppe können Sie aber in der Cloud weder für Exchange aktivieren noch verwalten. Auch hier muss die Verwaltung On-Premises erfolgen. Auch dies ist nicht einfach möglich, wenn Sie gar kein Exchange lokal installiert haben.

Linked Mailbox

Beachten sie, wenn ihre aktuelle Exchange On-Prem-Umgebung noch Objekte vom Typ LinkedMailbox hat. Diese Objekte gibt es bei Umgebungen mit einem Ressourceforest und sind normalerweise Disabled Accounts. Es soll aber schon vorgekommen sein, dass diese Objekte auch bei Migrationen eingesetzt werden und nach Abschluss aller Umstellungen dennoch nicht zu "normalen Postfächern" konvertiert wurden. Das ist so kein Problem, da das Konto ja im AD durchaus aktiviert werden kann und Outlook und andere Clients sich problemlos an dieses Postfach auch anmelden.

Vom Konzept her sind aber solche Objekte eben keine aktiven Anmeldekonten. Der DirSync geht daher davon aus, dass "von woanders" noch das Anmeldekonto in die Cloud synchronisiert wird. Siehe dazu auch Multi-Forest Identity. Wenn der DirSync also aus einem anderen Forest das aktive Anmeldekonto in die Cloud repliziert hat, dann kann der DirSync dann auch die Exchange Properties dort anwenden.

Wenn Sie allerdings keinen weiteren Forest mehr haben, dann konvertieren Sie die Linked-Mailbox einfach in eine normale Mailbox.

# Linked mailbox in Usermailbox verwandeln
[PS] C:\>set-User User1 -LinkedMasterAccount $null

Siehe dazu auch

DirSync, Exchange Postfach, Lizenz msExchangeMailboxGUID und msExchRemoteRecipientType

Der Einsatz des DirSync ist natürlich für den Betrieb von Exchange Hybrid unersetzlich. Schließlich sorgt der DirSync dafür, dass es für alle Postfächer in der On-Prem-Welt auch einen passenden Mail Enabled User (MailUser, MEU) gibt. Diesen Benutzerobjekten in der Cloud muss keine "Office 365 Lizenz" zu gewiesen werden.

Sie können diesem Benutzer aber natürlich eine Lizenz zuweisen und wenn alles richtig konfiguriert ist, dann bekommt er damit das Recht, Exchange einzusetzen, Sharepoint zu nutzen mit Skype für Business zu arbeiten etc. Wer also Office 365 auch als "Lizenzspender" nutzt, muss dem Benutzer sogar eine Lizenz zuweisen. Allerdings müssen Sie sicher sein, dass der DirSync die entsprechenden Felder gesetzt hat, da ansonsten der Benutzer in der Cloud ein neues Postfach bekommt. Im schlimmsten Fall hat der Anwender dann zwei Postfächer, Autodiscover funktioniert nicht mehr und die Mailzustellung ist nicht mehr zuverlässig.

Der Schlüssel dabei ist das Feld "msExchangeMailboxGUID". Ein Benutzer On-Prem ein Postfach hat, dann ist dieses Feld On-Prem natürlich gefüllt. Der Verzeichnisabgleich muss dieses Feld natürlich in die Cloud übertragen. Nur dann ist sichergestellt, dass der Provisioning-Prozess in Office 365 erkennt, dass dieser Benutzer ein Postfach On-Premises hat und legt kein Postfach mehr in der Cloud an.

In allen anderen Fällen wird Office 365 mit der Zuweisung einer Lizenz automatisch ein Exchange Postfach erstellen. Das Feld "Mail" des Anwenders wird dabei dann als primäre Adresse übernommen, wenn die Domäne auch wirklich dem Tenant zugewiesen ist. Ansonsten wird eine Adresse aus der Domäne "*@<tenantname>.onmicrosoft.com" genommen.

Mit Office 365 bekommt ein weiteres AD-Feld eine besondere Bedeutung: "msexchremoterecipienttype".

Wert Bedeutung

1

Provision Mailbox

3

Postfach wurde direkt in der Cloud angelegt oder mit "New-. RemoteMailbox" direkt in der Cloud provisioniert

4

Postfach wurde von On-Prem in die Cloud migriert

6

Postfach wurde von On-Prem in die Cloud migriert und das Archiv ist ein Exchange Online

20

Migriertes Postfach bzw. Archiv wurde entfernt

100

"Shared Mailbox" in Exchange Online

102

"Shared Mailbox" in Exchange Online mit Online Archiv

Über dieses Feld im lokalen Active Directory (On-Prem) können Sie sehen, wie der Benutzer konfiguriert ist.

DirSync und Zertifikate

Seit einiger Zeit ist es möglich auch in Office 365 mit SMIME zu arbeiten. OWA unterstützte SMIME aber auch das Azure AD kann die PublicKeys der Mitarbeiter in Form von binär interlegten CER-Dateien vorhalten und in der GAL bereitstellen. Damit können Anwender direkt Mails aus Outlook und anderen Clients verschlüsseln, wenn der Client den passenden Publickey des Empfängers aus der GAL bezieht.

Das Beispiel Zertifikate ist für mich ein guter Aufhänger die Besonderheiten von ADSync mit Exchange zu erläutern. Normalerweise werden Sie die Zertifikate der Anwender durch eine interne PKI ausrollen und diese im lokalen Active Directory hinterlassen.

Wer nun DirSync einsetzt aber kein Exchange On-Prem hat, verwaltet lokal ja so gut wie keine Felder. Eigentlich wird nur das Feld "Mail" und "ProxyAddresses" gepflegt. Wer das macht, wird aber nicht mit SMIME arbeiten können. Hier beschreibe ich, warum das so ist.

Ändern Sie bitte nicht die Einstellungen in den ADSync Regeln ohne entsprechende Kenntnisse der Auswirkungen und Dokumentationen! Im Nachhinein ist es ehr schwer diese Änderungen nachzuvollziehen.

Starten Sie den ADSync Rule Editor und suchen Sie die auf Inbound die "In from AD - User Exchange" Regel. Diese Regel ist maßgeblich, dass viele Exchange Properties eine lokalen Exchange Installation auch in der Cloud landen.

Aber die Regel wird nicht pauschal immer angemeldet, sonder hat einen "Scoping Filter", den Sie durch Druck auf den EDIT-Button sehen. Erst hier sieht man im "Scoping Filter" die Beschränkung auf "mailNickname ISNOTNULL"

Für DirSync/ADSync ist die Existenz des Feldes "MailNickname" der Indikator, dass es sich um ein Exchange Objekt handelt. Das ist wichtig, da an diese Regel mit dem Filter bestimmt, welche Felder letztlich übertragen werden.

An dieser Regel hängt aber nicht nur das Zertifikat, sondern viele andere Exchange Felder, z.B.: die msExchMailboxGUID, die bei einer Cross Forest Migration viel zu sagen hat aber auch das Feld "TargetAddress", mit dem Kontakte aber auch Weiterleitungen ggfls. gesetzt werden.

Wenn Sie also Exchange Online ohne lokales Exchange nutzen, sollten Sie ihr Minimalprovisioning nicht nur auf das Feld "Mail" und eventuell auf "ProxyAddresses" beschränken, sondern zumindest auch das Feld "MailNickname" füllen.

Lösungsansätze

Eine "fertige" Lösung habe ich nicht aber ich möchte gerne ein paar Optionen bewerten. Fakt ist, dass aktuell (Stand Mai 2015) bei aktiviertem ADSync die Eigenschaften von Exchange in der Cloud nicht mehr über das webbasierte Exchange Control Panel geändert werden können.

  • Office 365 könnte das Management in der Cloud trotz ADSync erlauben
    Bei der Konfiguration von ADSync kann Exchange ja explizit ausgeschlossen werden. Das könnte die Clou ja "mitbekommen" und dann die Verwaltung per Webbrowser weiter zulassen. Man bräuchte keine weitere Software lokal, die installiert, gepflegt, aktualisiert oder bedient werden müsste. Damit könnten speziell kleine und mittlere Firmen den DirSync samt Kennwort-Sync auf einem DC aktiviert lassen und die Exchange Eigenschaften weiterhin per Browser in der Cloud verwalten. Es muss keine weitere lokale Software installiert und laufend aktualisiert werden. Das wäre mein primärer Lösungsansatz. Skype für Business, SharePoint und die komplette Lizenzverwaltung funktionieren ja auch bei aktiviertem DirSync weiterhin unabhängig.
  • Erweiterung eines lokalen Dashboards oder der MMC durch Microsoft
    Mein Windows 2012 Essentials Server hat z.B. ein Dashboard zur einfachen Verwaltung von Benutzern. Andere Administratoren nutzen die MMC für Benutzer und Computer. Wenn Office 365 auch für mittlere und kleinere Firmen mit DirSync nutzbar sein sollte, dann wäre es vielleicht eine gute Idee hier eine entsprechende "Office 365"-Funktion zu addieren. Diese könnte die Einträge dann lokal setzen, damit diese per DirSync in der Cloud landen.
  • Lokaler Exchange (Siehe LES - Last Exchange Server)
    Sicher kann man einen Exchange Server On-Premises allein zur Verwaltung hinstellen. Dazu muss wohl nicht mal der Hybrid-Mode konfiguriert sein. Denn für diesen bräuchte man ja wieder Zertifikate und eine Webveröffentlichung. Aber leider muss man dazu eben einen Server betreiben, auch wenn er keine Postfächer hat. Die Exchange PowerShell kann nun mal nicht ohne "CAS-Server" Gegenstelle arbeiten. Abgesehen von den Ressourcen für eine VM (oder Physik) ist der Betrieb, Patchen etc. nicht wirklich kosteneffektiv. Auf der anderen Seite kann der lokale Exchange Server natürlich als Hub-Server das Mailrouting von internen Systemen (Drucker, Scanner, BLAT etc.) deutlich vereinfachen.
  • Exchange Management Rolle
    Mal abgesehen davon, dass Microsoft natürlich jeglichen Support für so eine Lösung ablehnt, könne man schon eine kleine GUI bauen, die für den Kunden On-Prem die Werte "korrekt" setzt. Technisch ist das sicherlich eine pfiffige Idee die aber laufen aktualisiert werden müsste. Zudem muss dies erst mal "bekannt" werden und die Anwender müssen es installieren. Vielleicht baut jemand so etwas aber dann ist man nahe dran an einem eh schon vorhandenen Provisioning-Tool.

Vielleicht gibt es noch andere Optionen. Ich werde wachsam bleiben. Aber aktuell müssen Sie sich als Office 365-"Kunde" überlegen, welchen Mehrwert Sie durch den DirSync (z.B.: für KennwortSync, Gruppenmanagement etc.) haben und was Sie sich dafür bezüglich Management von Exchange an Nachteilen einkaufen. Die Rechnung müssen Sie aktuell aber selbst aufmachen.

Weitere Links