Exchange Extension Attribute

Diese Seite ist speziell den "Extension Attributes" gewidmet, die durch eine Exchange Installation im Schema angelegt aber oft fremd verwendet werden. In der PowerShell haben Sie den Namen "CustomAttributes".

exchange_extension_attribute.mp3

Geschichte

Seit Windows 2000 gibt es das Active Directory und das Active Directory Schema definiert die möglichen Objekte und deren Eigenschaften. Schema-Erweiterungen sind möglich aber nur sehr wenige Firmen haben jemals eine eigene Schema-Erweiterung durchgeführt. Genau genommen müssen Sie sich dazu eine weltweit eindeutige OID besorgen, damit Konflikte verhindert werden. Schließlich können auch andere Firmen mit ihren Produkten eine Schema-Erweiterung benötigen.

Microsoft Exchange war in dem Zuge vermutlich das erste Produkt, welches das AD-Schema umfangreich erweitert hat, um all die Einstellungen zu hinterlegen. Auch spätere Versionen und sogar Service Packs und Cumulative Updates haben manchmal das Schema um zusätzliche Felder erweitert. Allerdings hat Exchange viele der Felder kaum oder gar nicht genutzt oder schon in der AD-Basisinstallation vorhandene Felder (MailNickname, Mail, Proxyaddresses) genutzt.

ms-Exch-Extension*

Sehr früh haben Administratoren die "ExtensionAttribute1-15" für sich entdeckt, welche sowohl bei Benutzern, Kontakten, Gruppen und sogar Computern vorhanden ist. Die Felder sind zudem schon in der Standardeinstellung indexiert und im Globalen Katalog vorhanden.

Wenn Sie genau hinschauen, dann ist der Name der ersten 15 Attribute einfach nur "extensionAttribute1-15". Die anderen Attribute kamen erst mit Exchange 2010 SP2 und haben ein "msExch"-Prefix. Relativ neu sind dann die msExchExtensionCustomAttribute1-5, die sogar MultiValue sind. All diese Felder sind aber nicht Bestandteil des Windows AD Schema, sondern kommen erst mit der Exchange Schema Erweiterung mit.

Auch wenn Sie Exchange gar nicht nutzen, aber eigene Informationen im AD hinterlegen wollen, könnte die Erweiterung um das Exchange Schema eine Option sein, eine eigene private Schema-Erweiterung zu umgehen

 

LDAP-Name CN Exchange PowerShell Typ Indexiert ANR GC Copy
extensionAttribute1
...
extensionAttribute15		 ms-Exch-Extension-Attribute-1
...
ms-Exch-Extension-Attribute-15		 CustomAttribute1
...
CustomAttribute15

Unicode String (1024)

Ja

Nein

Ja

Ja
msExchExtensionAttribute16
...
msExchExtensionAttribute45		 ms-Exch-Extension-Attribute-16
...
ms-Exch-Extension-Attribute-45

nicht verfügbar

Unicode String (1024)

Ja

Nein

Ja

Ja
msExchExtensionCustomAttribute1
...
msExchExtensionCustomAttribute5		 ms-Exch-Extension-Custom-Attribute-1
...
ms-Exch-Extension-Custom-Attribute-5		 ExtensionCustomAttribute1
...
ExtensionCustomAttribute5		 Unicode String
MultiValue

Ja

Nein

Ja

Nein

Alle Felder sind im AD-Index und GC, d.h. auch in großen Umgebungen oder vielen Domains kann ihnen jeder GC eine Suche effektiv beantworten. Achten sie aber darauf, dass die ersten beiden Felder beim "Klonen" eines Benutzers mit der MMC für Benutzer und Computer auch mit kopiert werden.

Das kann durchaus unschöne Effekte haben, wenn sie die Werte der ExtensionAttribute z.B. im Provisioning zur Lizenzsteuerung oder Synchronisation (Siehe SyncM365 Filterung) nutzen.

ms-Exch-Extension-Attribute 1-15

Dieses Feld gibt es schon sehr lange und wurde vom Exchange Team für die Ablage verschiedener Informationen bereit gestellt. Allerdings haben auch viele Drittprodukte gerne dieses Feld genutzt, um eigene Konfigurationsinformationen zu hinterlegen. Das Feld ExtensionAttribute15 wurde z.B. bei Exchange 5.5 nach 2000/2003 Migrationen mit dem Inhalt "ADCNOMATCH" genutzt, um Objekte vom Active Directory Connector auszuschließen.

Da auch andere Produkte und Administratoren diese Felder gerne zweckentfremdet haben, will Microsoft diese nicht weiter verwenden. Diese Felder sind über Commandlets als "ExtensionAttribute1" bis "ExtensionAttribute15" erreichbar.

Exchange Server includes 15 extension attributes that you can use to add information about a recipient, such as an employee ID, organizational unit (OU), or some other custom value for which there isn't an existing attribute. ...
The custom attributes available to Exchange Server are labeled in Active Directory as ms-Exch-Extension-Attribute1 through ms-Exch-Extension-Attribute15. In the Exchange Management Shell, the corresponding parameters are CustomAttribute1 through CustomAttribute15. These attributes aren't used by any Exchange components. They can be used to store Active Directory data without having to extend the Active Directory schema.
Quelle: Custom Attributes http://technet.microsoft.com/en-us/library/ee423541.aspx

Microsoft bezieht sich sogar selbst auf diese Felder.

“Negative filtering: "do not sync these"
In the following example, you filter out (not synchronize) all users where extensionAttribute15 has the value NoSync”
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-configure-filtering#negative-filtering-do-not-sync-these

Achtung:
Microsoft schreibt zwar, dass Sie das Feld nicht mehr nutzen aber ein "Disable-Mailbox" oder "Disable-RemoteMailbox" leer diese Felder. Wer die Felder mit anderen Werten ohne Bezug zu Exchange füllt, verliert diese mit der Deaktivierung des Objekts in Exchange.

Umgekehrt können Sie das Feld über die Exchange Commandlets aber auch pflegen, wenn das AD-Object ein Exchange Objekt ist. "Set-User" kennt die Parameter zum Setzen nicht. Auch wenn Microsoft die Felder nicht mehr nutzt, kann es immer noch Konflikte mit anderen Anwendungen geben. Schreiben Sie ihren Code besser so, dass der Feldname nicht statisch ist, sondern konfiguriert werden kann.

Sogar die URL und Beschreibung im Microsoft "Developer"-Bereich verweist bei diesen Attributen auf "previous-versions" hin. Die Felder werden durch ADSync repliziert, wenn Sie lokal vorhanden sind.

ms-Exch-Extension-Attribute16-45

Microsoft hat mit Exchange 2010 SP2 die Felder 16-45 hinzugefügt, um damit zukünftig Einstellungen zu speichern.

Diese Felder sind über Commandlets als "ExtensionAttribute16" bis "ExtensionAttribute45" erreichbar.

Finally, we have also added ms-Exch-Extension-Attribute-16 to 45. Those are not exposed to various CMDlets and Exchange management UI, because they were added für future use. As such, we cannot recommend that you use non-Exchange tools to edit their values because we might use those attributes in the future für various Exchange features. If and when we add management tools access to them, we will definitely let you know!
Quelle: http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

ms-exch-extension-custom-attribute-1 bis 5

Mit Exchange 2010SP2 hat Microsoft aber nicht nur die ExtensionAttribute von 15 auf 45 erweitert, sondern zudem noch fünf MultiValue-Attribute ergänzt, die Microsoft selbst aber nicht verwenden will.

Diese Felder sind über Commandlets als "ExtensionCustomAttribute1" bis "ExtensionCustomAttribute5" erreichbar.

In Exchange 2010 SP2, we have added five new multi-value custom attributes that you can use to store information für mail recipient objects. They are the ExtensionCustomAttribute1 to 5 (also can be referred to as ms-exch-extension-custom-attribute-1 to 5).
http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

Weitere Limitierungen

Das Active Directory Schema schreibt vor, wie groß die Inhalte in den Feldern sein dürfen. Allerdings sind die Werte nicht zwingend mit dem EntraID übereinstimmend und im Sep 2024 hat Microsoft in de Meldung "MC884017 - Exchange Properties Limits addition" einige Felder noch einmal präsiziert:

Feldname Typ Min Max EntraID Length EntraID Count

ms-Exch-Extension-Attribute 1-15

Unicode String

1

1024

?

?

ms-exch-extension-custom-attribute-1

Unicode String[]

na

na

2048

750

ms-exch-extension-custom-attribute-2

Unicode String[]

na

na

2048

750

ms-exch-extension-custom-attribute-3

Unicode String[]

na

na

2048

400

ms-exch-extension-custom-attribute-4

Unicode String[]

na

na

2048

400

ms-exch-extension-custom-attribute-5

Unicode String[]

na

na

2048

250

Verwaltung per Exchange PowerShell

Denken Sie aber immer daran, dass diese Felder durch die Exchange Schema Erweiterung mitgekommen sind und daher nur über die Exchange PowerShell verwaltet werden sollten. Natürlich können Sie die Werte auch direkt über LDAP lesen und sogar setzen, aber dann können damit verbundene Exchange Aktionen nicht ausgeführt werden.

Es gibt Firmen, die z.B. über Empfängerrichtlinien die Mailadressen von Benutzern, Verteilern etc. zentral vorgeben und dazu ein ExtensionAttribute-Feld nutzen. Wenn nun das Feld mit "Set-Mailbox", "Set-MailUser", "Set-MailContact", "Set-DistributionGroup" geändert wird, dann passt Exchange auch davon abhängige Einstellungen direkt mit an.

Die passiert nicht, wenn Sie das Feld mittels "Set-ADUser", "Set-ADContact", "Set-ADGroup" oder direkt per LDAP modifizieren. Lesen ist kein Problem. Sollte so eine direkte Modifikation erfolgt sein, dann können Sie Exchange mit "Update-Recipient" aber anweisen, etwaige Unstimmigkeiten wieder gerade zu rücken.

Disable-Mailbox etc.

Diese Abhängigkeit von Exchange kann ihnen insbesondere bei der Nutzung von "Disable-*" Commandlets unerwartete Effekte bescheren. Ich habe dazu ein Postfach angelegt und alle ExtensionAttribute per Exchange PowerShell gefüllt.

Zudem habe ich die Felder 16-45 per ADSIEDIT beschrieben und danach mit "Disable-Mailbox" das Postfach entfernt aber das AD-Objekt belassen. Exchange räumt ziemlich radikal auf:

Wer also diese Exchange Felder für eigene Zwecke missbraucht, sollte seinen Provisioning-Prozess daraufhin überprüfen, wie er bestehende Exchange Empfänger unter Beibehaltung des AD-Objekts deaktiviert. Der korrekte und einzig supportete Weg ist die Nutzung der Exchange PowerShell, die ihnen aber dann diese Felder entfernt.

Bei verschiedenen Firmen habe ich gesehen, dass die Extension Attribute zur Ablage von Provisioning-Informationen (MDM, Lizenzen, VPN-Zugang, RSA-Token, Microsoft 365 DirSync-Steuerung, etc.), weitere Verwaltungsinformationen wie Kostenstelle, Personalnummer, Smartphone IMEI) oder andere Informationen benutzt wurden. War ihnen diese Verhalten der "Disable-*"-Commandlets bekannt?

Weitere Links