ProxyAddresses

Das Feld "ProxyAddresses" ist einem Exchange Administrator wohl bekannt, enthält es doch alle Mailadressen, für die ein Postfach zuständig ist. Diese Seite beschreibt ein paar Details um dieses Feld und den Einsatz.

Siehe dazu auch Cloud ProxyAddresses.

ProxyAddresses im Schema

Wenn Sie das AD Schema Snap-In mit ("regsvr32.exe schmmgmt.dll" registriert haben, können Sie in einer normalen MMC das Snap-In Active Directory Schema" addieren und damit per Maus und GUI die Eigenschaften des Felds "ProxyAddresses" im Schema nachschauen.

ProxyAddresses ist laut Schema hier ein "Multi-Value" Feld, welches jeweils Unicode-Strings bis zu 1123 Zeichen enthalten kann. Es ist im globalen Katalog, indexiert und unterstützt eine Ähnlichkeitssuche. Im Schema ist aber z.B. nicht hinterlegt, welches Formt der Inhalte haben muss. Unicode ist ja ein sehr umfangreicher Zeichensatz, die so als Mailadresse gar nicht gültig sind.

ProxyAddresses und Mail

Das Feld "ProxyAddresses" ist seit Exchange 2007 nicht mehr über "Active Directory Users und Computers" zu verwalten. Dort können Sie aber weiterhin den Inhalt von "Mail" pflegen.

An das Feld "ProxyAddresses" kommen Sie in der erweiterten Ansicht über die grün markierte Karteikarte "Attribute Editor". Sie sollten solche Änderungen aber unbedingt unterlassen, wenn in ihrer Umgebung z.B. Exchange installiert ist. Die entsprechenden Commandlets von Exchange aber auch Skype for Business sorgen z.B. dafür, dass...

  • ... Mailadressen eindeutig und sind
    Das Active Directory selbst prüft nicht, ob die Adresse schon einmal an einem anderen Objekt vergeben wurde
  • ... Mailadresse "gültig" ist
    In Mailadressen dürfen nur bestimmte Zeichen enthalten sein. Jeder wird verstehen, dass z.B. zwei "@" nicht erlaubt sind. Aber auch ein Punkt am Anfang oder Ende des User-Parts sind nicht erlaubt.
  • ... Mail und die primäre ProxyAdresse übereinstimmen
    Die beiden Felder sind seitens des Domain Controllers nicht verknüpft. Exchange sorgt dafür, dass die primäre SMTP-Adresse aus den ProxyAddresses auch im Feld "Mail" ohne führendes "SMTP:" gepflegt wird.
  • ... nur "Accepted Domains" verwendet werden
    Exchange ist für bestimmte SMTP-Domänen verantwortlich und nur für diese Domänen macht es Sinn, auch Mailadressen anzulegen
  • SIP-Adressen für Voicemail gepflegt werden
    Skype for Business addiert die SIP-Adresse mit dem Prefix "SIP:", damit die Voicemail funktioniert.

All diese und andere Checks müssten Sie in ihrem eigenen Code einbauen, wenn Sie wirklich die Commandlets von Skype for Business und Exchange nicht nutzen wollten. Unabhängig davon ist die direkte Änderung von Exchange Properties von Microsoft nicht unterstützt.

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

SIP, SMTP, FAX, X400, X500

Wenn Sie sich einen gültigen Anwender mit Postfach anschauen, dann werden Sie in der Regel gleich mehrere Einträge im Feld ProxyAddresses finden, die alle ein Präfix haben.

  • SMTP:Userpart@domainpart
    Dies sind die wohlbekannten SMTP-Adresse, die es schon weit Exchange 5-Zeiten gibt und sich seitdem nicht verändert haben. Gerade bei SMTP ist es wichtig, dass genau ein Eintrag ein groß geschriebenes "SMTP:" hat während alle anderen Einträge kleingeschrieben also nur mit "smtp:" versehen sind. Das Feld mit dem groß geschriebenen SMTP ist die primäre Adresse, die von Exchange als Absenderadresse genutzt wird. Es darf immer nur genau eine solche Adresse geben und diese sollte auch ohne das Präfix "SMTP:" im Feld "mail" stehen.
  • X400
    Als Microsoft MS-Mail durch Exchange abgelöst hat, war tatsächlich "X.400" ein wichtiges Übertragungsprotokoll. bie Firmen und Behörden. SMTP war zwar schon da, aber das Internet war bei weitem noch nicht so verbreitet.
  • X500
    X.500 steht eigentlich für einen Adressbuch-Standard, so wie "User@domain.tld" zwar eine SMTP-Adresse ist aber SMTP das Übertragungsprotokoll beschreibt. X.500-Adressen wurden genutzt, um Nachrichtenempfänger und Sender zu definieren, die dann über X.400 übertragen werden.
    Heute nutzt Exchange die X.500 Adresse in den ProxyAddresses als Ablageort des "LegacyExcangeDN bei Migrationen. Der LegacyExchangeDN ist eigentlich pro Exchange Installation "Einmalig" und wenn ein Postfach in eine andere Organisation übertragen wird, dann würden Antworten etc. nicht mehr ankommen, wenn der alte LegacyExchangeDN nicht als X.500 an das neue Postfach angehängt würde.
  • MS
    Wer ganz für schon MS-Mail eingesetzt und nach Exchange migriert hat, hatte damals MS-Mail Adresse in der Form "Netzwerk/Postoffice/Postfach". E Heute sind die Adressen obsolet und zeigen nur noch an, dass die Exchange Organisation schon sehr alt ist.
  • CCMAIL
    Auch cc:Mail war früher ein Wettbewerber zu MS-Mail und es gab Konnektoren und Migrationswerkzeuge.
  • GWISE
    Gleiches galt für GroupWise. Es gibt auch 2016 wohl immer noch ein paar GroupWise-Installationen aber Seitens Microsoft keinen Support für eine native Kopplung mit Verzeichnisabgleich und Migration. Mailrouting ist per SMTP möglich. Die Adressen sind daher meist obsolet und als Altlast zu bezeichnen.
  • FAX, MRS, FACSYS
    Einige Fax-Server haben sich in den ProxyAddresses ebenfalls hinterlassen, um z.B.: die Faxnummer oder Einstellungen wie Deckblattinformationen etc. zu hinterlegen. Solche Einträge sind auch in 2016 durchaus noch vorhanden und wichtig.
  • Sonstige
    Bis Exchange 2003 war die Bildung der Adressen in ProxyAddresses durch DLLs und den RUS vorgegeben. Seit Exchange 2007 "versteht" Exchange eigentlich nur noch SMTP und X500-Einträge aber stört sich auch nicht an anderen Adressen. Eigentlich können Sie hier alles andere ebenfalls speichern.

Ändern und AD-Obergrenze

Obwohl es im Schema nicht hinterlegt ist und viele Firmen es gar nicht bemerken werden, gibt es durchaus Limits für das Feld ProxyAddresses. Für meine Tests habe ich mich bewusst darüber hinweg gesetzt, dass man die ProxyAddresses nicht direkt ändern sollte. Ich wollte ja gerate sehen, welche Grenzen und Probleme es gibt.

Import-Module ActiveDirectory
1..2000 | Foreach {
   Write-host "." -nonewline
   Set-ADUser -Identity testUser -Add @{Proxyaddresses="SMTP:testUser@"+$_+".test.de"}
}

Dieses immer wiederholende addieren ist natürlich keine effektive und schnelle Methode. Je nach Performance des DCs dauert es einige Sekunden bis die folgende Fehlermeldung erscheint:

Set-ADUser : The administrative limit for this request was exceeded
At line:2 char:5
+     Set-ADUser -Identity testUser -Add
@{Proxyaddresses="SMTP:testUser"+$_+".tes ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (testUser:ADUser) [Set-ADUser], AD
   Exception
    + FullyQualifiedErrorId : ActiveDirectoryServer:8228,Microsoft.ActiveDirectory.Management.Commands.SetADUser

Eine Kontrolle der Anzahl liefert dann:

(Get-ADUser testUser -Properties proxyaddresses).proxyaddresses.count
1245

Mein Domain Controller erlaubt es nicht, mehr als 1245 Elemente dort zu speichern.

In a forest at Windows 2000 functional level, non-linked multi-valued attributes are limited to about 800 to 850 entries. If the forest functional level is at least Windows Server 2003, the limit is about 1200 to 1300 entries. Further, once this limit is reached, you cannot add entries to any other non-linked multi-valued attributes of the same object
Quelle: http://social.technet.microsoft.com/wiki/contents/articles/31919.active-directory-non-linked-multi-valued-attribute-size-limits.aspx

Durch einen Fehler einer Exchange CrossOrg Migration oder den Exchange 2003 RUS hatte ich schon Fälle, bei denen wirklich 1250 Einträge im Feld ProxyAddresses enthalten waren. Fast alle waren "X.500-Adressen".

Ich hatte auch schon mal ein DC-Replikationsproblem zu lösen, bei dem alle DCs innerhalb der gleichen Site noch die Informationen hatten aber die Replikation über AD-Standorte hinweg unterbrochen war. Auch hier war es ein Benutzer mit sehr viele ProxyAddressen. Eine Liste der Benutzer und deren Anzahl an ProxyAddresses kann per Powershell schnell generiert werden.

get-adUser `
   -Filter * `
   -Properties proxyaddresses `
| where{ $_.proxyaddresses.count -ge 10} `
| select distinguishedname,name,@{name="count";expression={$_.proxyaddresses.count}} `
| ft -autosize

Sie können die Ausgabe natürlich auch in einer CSV-Datei umleiten o.ä.

Office 365

Auch wenn On-Premises in dem Feld ProxyAddresses bis zu 1250 Einträge möglich sind, So gibt es andere Dienste, die schon sehr viel früher die Regel streichen. Dazu gehört z.B. Office 365. Je nach Quelle wird hier von einer Obergrenze von 400 Adressen gesprochen.

Recipient proxy address limit = 400
Quelle: Exchange Online Limits - Recipient and sender limits https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx?f=255&MSPPError=-2147217396#RecipientLimits

You can create up to 400 aliases for a User. No additional fees or licenses are required
https://support.office.com/en-us/article/Add-additional-email-aliases-to-a-User-in-Office-365-0b0bd900-68b1-4bf5-808b-5d240a7739f4

Die Grenze wurde immer mal wieder angepasst. Anfangs waren es 100 und später 200. Insofern können Fehlermeldungen und Informationen in Bildern abweichend sein.

Wer seine Anwender manuell in Office 365 mit den Exchange Commandlets verwaltet, bekam im September 2016 bei 200 Adressen eine Fehlermeldung beim Set-Mailbox:

There are too many proxy addresses: 502, and maximum supported number of recipient proxy 
addresses is 200.
     + CategoryInfo          : NotSpecified: (retail:ADObjectId) [Set-Mailbox], DataValidationException 
" The administrative limit for this request was exceeded "

Alle Firmen mit einem größere Active Directory verwalten die Benutzer natürlich nicht mehr direkt in der Cloud, sondern lassen dies durch den Verzeichnisabgleich erledigen. Auch hier ist an mehreren Stellen gut sichtbar, wenn das lokale Objekt nicht repliziert werden kann. Wenn Sie in ihrem Tenant eine gültige Mailadresse angegeben haben, dann bekommen Sie bei jedem Verzeichnisabgleich eine Warn-Email:

Die Meldung kommt nicht nur einmal, sondern bei mir all 30 Minuten.

Aber auch wenn Sie diese Meldung nicht bekommen, weil jemand anderes das Postfach liest, dann können Sie im Eventlog des AADConnect-Servers die gleichen Meldungen sehen:

Log Name:      Application
Source:        ADSync
Date:          24.09.2016 11:39:23
Event ID:      6100
Task Category: Management Agent Run Profile
Level:         Warning
Keywords:      Classic User:          N/A
Computer:      DCUser.accountdom.local
Description:
The management agent "carius.onmicrosoft.com - AAD" step execution 
completed on run profile "Export" with errors.
 
 Additional Information
 Discovery Errors       : "0"
 Synchronization Errors : "0"
 Metaverse Retry Errors : "0"
 Export Errors          : "1"
 Warnings               : "0" User Action
 View the management agent run history for details.
Log Name:      Application
Source:        ADSync
Date:          24.09.2016 11:39:22
Event ID:      6941
Task Category: MA Extension
Level:         Error
Keywords:      Classic User:          N/A
Computer:      DCUser.accountdom.local
Description:
ECMA2 MA export run caused an error. 
 
Error Name: LargeObject 
Error Detail: Das bereitgestellte Objekt ist zu groß. Verringern Sie die Anzahl der 
Attributwerte für dieses Objekt. Der Vorgang wird bei der nächsten Synchronisierung 
wiederholt.

Tracking Id: 4514ac03-972e-4256-965c-2ada0c0412cf

Mit der passenden Monitoring-Software erhalten Sie so auch die Information. Spätestens dann ist es an der Zeit den Verzeichnisdienst zu kontrollieren, wenn Sie das problematische Objekte noch nicht aus der Statusmail ermittelt haben:

Hinweis:
Wer sein lokales Active Directory mit IDFix (Siehe Dirsync Check) vorab geprüft hat, kann diese Fehler nicht finden. IDFix überprüft nicht die Anzahl der ProxyAddresses.

Weitere Links