Änderungen an den Plänen Exchange Online, um die Identifizierung von Postfächern effizienter zu gestalten

Eindeutige Namen und Austauschverlauf

Microsoft hat in MC365786 (30. April) angekündigt, dass es Ende Mai damit beginnen wird, diese Änderung auf die Tenants auszurollen.

Am 13. Aprilkündigte die Entwicklungsgruppe Exchange eine Änderung an, die einen kleinen Teil der Produktgeschichte in Anspruch nahm. Microsoft möchte das Format der Attribute Name und DistinguishedName für Postfächer ändern, um sie eindeutiger zu machen, und plant, stattdessen die Kennung des externen Verzeichnisobjekts zu verwenden.

Als Microsoft 1996 Exchange 4.0 einführte, übten die Standards X.400 und X.500 noch einen enormen Einfluss auf die Welt der E-Mails aus. Aus diesem Grund verwendeten die Entwickler X.500-ähnliche Namenskonventionen in Exchange Directory Store (DS), dem Vorläufer dessen, was zu Active Directory wurde, als Windows 2000 1999 auf den Markt kam und Azure Active Directory später eingeführt wurde. X.500-Objekte verwenden eindeutige Namen als eindeutige Identifikatoren. Um einen eindeutigen X.500-Namen zu erstellen, verknüpfen Sie Attribute, um einen Pfad zu dem benannten Eintrag zu bilden. Objekte mit der E-Mail-Erweiterung Exchange Online haben diese Werte immer in der Eigenschaft LegacyDn, wo Sie so etwas wie das hier finden:

Exchange Online hat seine eigene Form von eindeutigen Namen, die immer als eindeutige Identifikatoren für Objekte dienen. Hier ein Beispiel:

Der CN-Teil (Common Name) stammt aus dem Namen der Mailbox. Die Organisationseinheitsentitäten identifizieren den Kunden. Microsoft 365 und Exchange Online, während die Domänencontroller-Entitäten den Pfad zum Outlook.com-Domänencontroller zuweisen, mit dem sich Exchange Online bei der Erstellung des Postfachs verbunden hat.

Die Synchronisation freundlicher gestalten

Was Microsoft jetzt sagt, ist, dass sich das Format, das für eindeutige Namen Exchange Online verwendet wird, ändern muss. Sie sind auf Situationen gestoßen, in denen es zu Konflikten kam, wenn Objekte vonAzure Active Directory zu Exchange Online synchronisiert wurden. Als sie darüber nachdachten, wie es zu den Konflikten kam, entschieden sie, dass eine bessere Quelle für die Eindeutigkeit benötigt wird.

Microsoft schlägt vor, die Generierung der Eigenschaft Name für Objekte mit E-Mail-Erweiterung aus seiner aktuellen Datenbank(MailNickName oder Alias) so zu ändern, dass die Kennung eines externen Verzeichnisobjekts, die auf das Konto verweist, verwendet wird. Azure AD Eigentümer des Objekts verweist. Lassen Sie uns erkunden, was das bedeutet.

Verwendung eindeutiger Identifikatoren

Alle Azure AD Objekte haben eindeutige Identifikatoren (GUIDs). Wenn Sie ein Konto Microsoft 365 mit einer Exchange Online-Lizenz erstellen, übernimmt Exchange Online die Eigenschaft MailNickName des Kontos und verwendet sie für den Postfachnamen und die Alias-Eigenschaften. Wenn Sie beispielsweise ein neues Konto mit einem Benutzernamen von Sue.P.Pickett@office365itpros.com erstellen, gehören zu den Eigenschaften des Kontos Azure AD :

• GivenName: Sue
• Nachname: Pickett
• MailNickName: Sue.P.Pickett
• Post: Sue.P.Pickett@office365itpros.com
• UserPrincipalName: Sue.P.Pickett@office365itpros.com
• ObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3

WennExchange Online ein Postfach erstellt, nimmt es den Wert MailNickName und verwendet ihn, um den Alias, den Namen und den eindeutigen Namen des Postfachs zu erstellen. Die ersten beiden Eigenschaften haben denselben Wert wie MailNickName, während der eindeutige Name zu :

Außerdem schreibt Exchange Online den ObjectId des Kontos Azure AD in die Eigenschaft ExternalDirectoryObjectId des Postfachs. Sie können diesen Wert verwenden, um nach einem Postfach zu suchen, wie in :\

Die von Microsoft vorgeschlagene Änderung bedeutet, dassExchange Online die Kontokennung Azure AD für den Mailboxnamen und als CN-Teil des eindeutigen Namens verwenden wird. Folglich finden wir uns mit:

Da eine Kontokennung Azure AD in Microsoft 365 einzigartig ist, sind die Eigenschaften des Postfachs Exchange ebenfalls einzigartig und lösen die Synchronisationsprobleme. Tatsächlich können Sie die Kontokennung in die Eigenschaft Name eines Postfachs heute schreiben, wenn Sie möchten :

Wenn Sie die Eigenschaft Name aktualisieren, aktualisiert Exchange den eindeutigen Namen des Postfachs, so dass der CN-Teil des Namens mit dem Wert übereinstimmt, der der Eigenschaft Name zugewiesen wurde.

Eindeutige Namen und Exchange Online

Die eindeutigen Namen existieren nur in Exchange Online. Es gibt keine Spur von ihnen in den Objekteigenschaften von Azure AD , da die Verbindung zwischen Azure AD und Exchange Online über die externe Verzeichnisobjektkennung hergestellt wird. Diese Eigenschaft existiert für alle Exchange Online-Objekte, die ein entsprechendes Objekt in Azure AD haben:

• Postfächer (alle Typen - Benutzer, freigegeben, Raum, Gruppe).
• Verteilerlisten (aber keine dynamischen Verteilerlisten oder Platzhalterlisten).
• E-Mail-Kontakte.
• E-Mail-Benutzer.

Microsoft gibt an, dass die Änderung nur für neue Objekte mit E-Mail-Erweiterung gelten wird. Sie planen nicht, alte Objekte rückwirkend mit dem neuen Benennungsschema zu aktualisieren. Wenn das neue Namensschema ausgerollt wird, gibt Microsoft an, dass es die Fähigkeit von Administratoren, die Eigenschaft Postfachname mithilfe von Cmdlets wie Set-Mailbox und Set-User zu aktualisieren, beenden wird, was logisch erscheint.

Eine Pause zum Nachdenken

Kurz nachdem Microsoft seinen Blog veröffentlicht hatte, fügten sie eine Aktualisierung hinzu, in der sie sagten, dass sie aufgrund des Feedbacks die Änderung verzögern und Ende April einen neuen Zeitplan bekannt geben würden. Ich denke, das ist vernünftig. Obwohl ich mir keine Sorgen über die Verwendung von Objektbezeichnern in eindeutigen Namen mache, ist die Eigenschaft Name etwas anders, da Exchange Online sie häufiger ausstellt. Wenn Sie z. B. schauen, wer eine Verteilergruppe verwaltet, scheint diese Ausgabe nicht korrekt zu sein :

Und die Liste der Benutzerpostfächer mit Get-Recipient sieht seltsam aus :

Während die Überprüfung, wer über die Berechtigung Senden als für ein freigegebenes Postfach verfügt, eher zu einer lästigen Pflicht wird :

Die Benutzerschnittstellen Exchange und Microsoft 365 verschleiern das Failover, da sie die GUIDs übernehmen und in "hübsche" Werte wie Anzeigenamen auflösen können (Abbildung 1).

Jedes potenzielle Problem wird in Verwaltungsskripten auftreten, die die Eigenschaften Name oder DistinguishedName verwenden und erwarten, dass die von Exchange Online zurückgegebenen Werte einem bestimmten Format folgen. Skripte (wie dieses zur Meldung von Verteilerlisten und deren Verwaltern), die Werte auflösen, um vollständige Namen abzurufen, sind von der Änderung nicht betroffen.

Wie bei jeder vorgeschlagenen Änderung für etwas, das schon sehr lange verwendet wird, gibt es zwangsläufig Extremfälle, die auftreten und gelöst werden müssen. Ich denke, dass die Entwickler Exchange auf dem richtigen Weg sind, um nach eindeutigen Ankern für die Synchronisierung zu suchen. Ich hoffe nur, dass sie es schaffen können, ohne allzu große Umwälzungen für die Kunden zu verursachen.