Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03646.jsonl.gz/1360

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 später zu Active Directory wurde, als 1999 Windows 2000 und später Azure Active Directory auf den Markt kamen. 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 des Postfachs. Die Organisationseinheit-Entitäten identifizieren den Client 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 die eindeutigen Namen Exchange Online verwendet wird, ändern muss. Sie sind auf Situationen gestoßen, in denen es zu Konflikten kam, wenn Objekte von Azure Active Directory zu Exchange Online synchronisiert wurden. Als sie darüber nachdachten, wie es zu den Konflikten kam, kamen sie zu dem Schluss, 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) zu ändern, um die Kennung des externen Verzeichnisobjekts zu verwenden, die auf das Azure-Konto AD zeigt, das Eigentümer des Objekts ist. Lassen Sie uns erkunden, was das bedeutet.
Verwendung eindeutiger Identifikatoren
Alle Azure-Objekte AD 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 <email-pii> erstellen, gehören zu den Eigenschaften des Azure-Kontos AD :
- GivenName: Sue
- Nachname: Pickett
- MailNickName: Sue.P.Pickett
- Post: <email-pii>
- UserPrincipalName: <email-pii>
- 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 Azure-Kontos 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 Azure-Kontokennung AD für den Postfachnamen und als CN-Teil des eindeutigen Namens verwenden wird. Folglich finden wir uns mit:
Da eine Azure-Kontokennung 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
Eindeutige Namen existieren nur in Exchange Online. Es gibt keine Spur von ihnen in den Azure-Objekteigenschaften AD, da die Verbindung zwischen Azure AD und Exchange Online über die externe Verzeichnisobjekt-ID hergestellt wird. Diese Eigenschaft existiert für alle Exchange Online-Objekte, die ein entsprechendes Objekt in Azure haben AD :
- 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.