Duplicate Recipient Address
Empfängeradressen in Exchange müssen eindeutig sein. Es darf nie zwei Objekte mit der gleichen Mailadresse geben. Die Exchange Management Shell verhindert dies meistens aber hilft nicht, wenn AD-Replikation langsam ist oder andere Prozesse direkt die LDAP-Felder ohne vorherige Prüfung beschreiben. Daher ist eine direkte Änderung offiziell nicht unterstützt aber wird nicht verhindert.
Erkennen
Wenn eine Mailadresse doppelt vergeben wurde, dann stellen sie dies erst fest, wenn die erste Mail an das Postfach gesendet wurde. Interessanterweise erkennt z.B. Exchange 2016 diesen Fehler nicht schon beim SMTP-Empfang, denn da wird die Mail erst angenommen:
Message Tracking
Erst beim SMTP-Routing erkennt Exchange die doppelte Adresse und hinterlässt das im Messagetracking-Log:
Timestamp : 15.05.2023 10:16:41
ClientIp :
ClientHostname : EX16
ServerIp :
ServerHostname :
SourceContext : AmbiguousRecipient
ConnectorId :
Source : ROUTING
EventId : DEFER
MessageId : <73d89541-6b9b-968e-0991a49d938f@ex16.netatwork.de>
Recipients : {frank3@carius.de}
RecipientStatus : {[{LED=420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address};{MSG=};{FQDN=};{IP=};{LRT=}]}
TotalBytes : 1769
RecipientCount : 1
MessageSubject : DuplicateMailTest
Sender : frank@xxxxxx.de
ReturnPath : frank@xxxxxx.de
Directionality : Incoming
MessageInfo : 15.05.2023 10:46:41
TransportTrafficType : Email
Submission Queu
Die Mail wird aber nicht direkt mit einem NDR an den Absender gemeldet, sondern verbleibt noch einige Zeit in der "Submission"-Queue:
[PS] C:\>get-queue
Identity DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
-------- ------------ ------ ------------ -------- --------- -------------- -------------
EX16\3 SmtpDeliv... Ready 0 0 Normal 0 mailboxes
EX16\4 SmartHost... Ready 0 0 Normal 0 carius-de.mail.clou...
EX16\Submission Undefined Ready 1 0 Normal 0 Submission
[PS] C:\>Get-Queue | Get-Message
Identity FromAddress Status Queue Subject
-------- ----------- ------ ----- -------
EX16\Submission\6... frank@xxxxxx.de Retry EX16\Submission DuplicateMailTest
[PS] C:\>Get-Queue | Get-Message | fl
Subject : DuplicateMailTest
FromAddress : frank@xxxxx.de
Status : Retry
Size : 1.728 KB (1,769 bytes)
MessageSourceName : SMTP:Default ex16
SourceIP : ::1
SCL : 0
DateReceived : 15.05.2023 10:16:39
DeferUntil :
ExpirationTime : 17.05.2023 10:16:39
LastError : [{LED=420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address};{MSG=};{FQDN=};{IP=};{LRT=}]
RetryCount : 0
Recipients : {frank3@carius.de;3;0;[{LED=420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address};{MSG=};{FQDN=};{IP=};{LRT=}];0;;0}
ComponentLatency :
MessageLatency : 00:14:36.7814267
DeferReason : Ambiguous Recipient
Priority : Normal
Directionality : Incoming
OriginalFromAddress : frank@xxxxxx.de
AccountForest : carius.de
TrafficType : Email
TrafficSubType :
MessageIdentity : ex16\Submission\63819383225818
Queue : ex16\Submission
Identity : ex16\Submission\63819383225818
IsValid : True
ObjectState : New
Als Administrator können Sie nun die SubmissionQueue auf solche Mails überwachen. Ein Absender bekommt laut dieser Information erst nach 48 Stunden (ExpirationTime - DateReceived) einen NDR
Eventlog
Eine sofortige ein einfache Erkennung solcher Probleme ist über das Eventlog möglich:
Log Name: Application Source: MSExchangeTransport Date: 15.05.2023 10:16:41 Event ID: 9217 Task Category: Categorizer Level: Error Keywords: Classic User: N/A Computer: ex16.netatwork.de Description: More than one Active Directory object is configured with the recipient address frank3@carius.de. Messages to this recipient will be deferred until the configuration is corrected in Active Directory.
Sie können ihr System-Monitoring entsprechend erweitern, dass Sie solche Meldungen direkt zu einem Ticket eskalieren, damit eine Bereinigung möglichst noch vor dem Ablauf der zwei Tage erfolgt.
Exchange Online
Theoretisch kann auch in Exchange Online die Situation entstehen, dass doppelte SMTP-Adressen vorliegen. Interessant ist, dass ADSync selbst sich nicht an doppelten Inhalten stört.
Selbst beim Export in die Cloud gibt es keinen Fehler in der lokalen ADSync-Instanz. Der AzureAD Provisioing-Service lehnt dies erst einmal nicht ab, wenn zwei Objekte die gleiche ProxyAddress haben. Aber er kann die Informationen dann nicht in die nachgeschalteten Systeme übertragen. Das finden Sie als Administrator dann im Microsoft 365 Admin Portal (https://admin.microsoft.com)
Auch die Details sind durch einen Klick auf die Meldung sichtbar:
Analog können Sie die Daten auch in "https://portal.azure.com" eingesehen werden.
Das AzureAD Portal liefert aber neben den Details auch die Information, dass sich dieses Problem nicht von alleine löst.
Mir ist es nicht gelungen, an ADSync vorbei zwei Testuser mit der gleichen Adresse anzulegen. Das würde eh nur funktionieren, wenn ich das kleine Zeitfenster der AzureAD Replikation nutzen könnte.
Cloud-Gäste und Admins
Diese Konflikte passieren sehr oft in Verbindung mit Gastkonten. Wenn Sie einen Mitarbeiter eines anderen Tenant als Gast in ihrem Tenant angelegt haben, dann wird damit auch die Mailadresse belegt.
Es ist dann sehr wahrscheinlich, dass ein lokal als "MailUser" oder "MailContact" vorhandenes Exchange Objekt beim Export zu ExchangeOnline zu einer Dublette führt. Seltener ist der Fall, dass Sie ein "CloudOnly"-Konto z.B. als Administrator angelegt haben, welches die gleiche Mailadresse wie ein lokales AD-Konto hat und dies erst mit der Einrichtung von ADSync auffällt.
Beide Fälle können Sie alleine über eine lokale Analyse aber nicht ermittlen.
Such-Skript
Es ist natürlich mühselig darauf zu warten, dass eine Mail an solche eine Adresse eine Meldung im Eventlog triggert. Wir wissen ja, dass Exchange das Feld "ProxyAddresses" für das Routing nutzt und damit spricht nichts dagegen, einfach eine LDAP-Auflistung aller Objekte anzufertigen und die Feldinhalte z.B. über eine Hash-Tabelle zu prüfen. Das geht sogar ohne Exchange PowerShell direkt per LDAP und ist damit deutlich schneller. Ich konnte ca. 30.000 Objekte in weniger als 20 Minuten abprüfen.
Hier nur die Kurzform ohne Parameter, Diagnoseausgaben etc.
$root = [system.directoryservices.activedirectory.forest]::getcurrentforest().rootdomain.name
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher([ADSI]"GC://$root")
$objSearcher.PageSize = 1000
$objSearcher.Filter = "(&(ProxyAddresses=*))"
$objSearcher.PropertiesToLoad.Add("ProxyAddresses") | Out-Null
[hashtable]$mailaddresses=@{}
$colResults = $objSearcher.FindAll()
foreach ($objResult in $colResults) {
#write-host "Object $($objResult.path)"
foreach ($proxyaddress in $objResult.Properties.proxyaddresses) {
[string]$mail = $proxyaddress.tolower()
if ($mailaddresses.ContainsKey($mail)) {
Write-Warning "DuplicateProxy $($mail) `n Current: $($objResult.path) `n Other : $($mailaddresses[$mail])"
}
else {
$mailaddresses.Add($mail,$objResult.Path)
}
}
}
Sie können das Skript als PS1.Datei speichern und aufrufen oder direkt in einer PS1-Shell einfügen. Es gibt die betroffene Mailadresse und das aktuelle und vorherige Objekte mit Write-Warning aus.
Sie können das Skript natürlich erweitern, um dies z.B. regelmäßig automatisiert zu starten und die Ergebnisse in ihr reguläres Monitoring einzubinden.
Dies ist nur eine vereinfachte Version. Um die Last zu reduzieren können Sie sich z.B. die "HighestUSN" merken und beim nächsten Abruf nur die Mailadressen der geänderten Objekte überprüfen lassen.
