DirSync mit Exchange

Auf der Seite Exchange Online und DirSync habe ich beschrieben, wie man als kleine Firma in sehr kurzer Zeit einen Office 365 Vertrag abschließen und komplett autark nutzen kann. Wer hier aber dann den Verzeichnisabgleich addiert, wird erstaunt feststellen, dass er die Exchange Eigenschaften der Postfächer nicht mehr über die Office 365 Verwaltung bedienen 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.

Sonderfall: DirSync und Exchange - 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 OnPremise einen Exchange Server haben und ggfls. auch den Hybrid-Mode nutzen. Dann haben Sie OnPremise 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 OnPremises, most of the attributes cannot be managed from Exchange Online and must be managed from OnPremises. 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 OnPremises e-mail organization für mail delivery you can uninstall Exchange from servers in your OnPremises 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 OnPremises MEUs. für 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 OnPremise 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 OnPremise gar keinen Exchange Server habe, kann ich die entsprechenden Felder OnPremise 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 OnPremise 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 "OnPremise" 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 OnPremise (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 "OnPremise" 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, kommt um den lokalen Exchange Server aber nicht umhin. Es gibt sonst keinen offiziellen Weg um Benutzer in der Cloud bezüglich der Exchange Properties zu verwalten UND mit einem DirSync mit Office 365 abzugleichen.

Wenn Sie bislang noch nie einen Exchange Server "onPremise" 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
  • Exhange 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 "OnPremise" erfolgen. Auch dies ist nicht einfach möglich, wenn Sie gar kein Exchange lokal installiert haben.

DirSync 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 OnPremise 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 "OnPremise" zurück repliziert werden.
  3. Sie addieren eine ProxyAddresse "OnPremise" und ändern die primäre Mai-Adresse
    Der DirSync "addiert" diese Adresse im Ziel zu den bestehenden Adressen.
  4. Sie entfernen eine Adresse OnPremise
    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 !
  • 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"

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.

Linked Mailbox

Beachten sie, wenn ihre aktuelle Exchange OnPremise-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 OnPremise-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 OnPremise ein Postfach hat, dann ist dieses Feld OnPremise 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 "OnPremise" 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 OnPremise in die Cloud migriert

6

Postfach wurde von OnPremise in die Cloud migriert und das Archiv ist ein ExchangeOnline

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 (OnPremise) 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 OnPremise 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. (Danke an Martina Grom für die Diskussion). Fakt ist, dass aktuell (Stand Mai 2015) bei aktiviertem DirSync 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 DirSync 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
    Sicher kann man einen Exchange Server "OnPremise" 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.
  • Eigene GUI
    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 OnPremise 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