Remove-ProxyAddresses

Das Skript entfernt natürlich nicht stumpf alle ProxyAddresses aber es bereinigt MailUser und MailContacts, die z.B.: durch eine unpassende Empfängerrichtlinie oder "historische Altlasten" auch Mailadressen ihrer produktiven Domäne haben und es Konflikte gibt.

Startumgebung

Exchange OnPremises nutzt das lokale Active Directory zur Verwaltung von Postfächern, Verteilern aber auch externen Empfängern. Externe Empfänger haben kein Postfach auf ihren Exchange Servern sondern irgendwo außerhalb. Damit diese Empfänger auch im Adressbuch erscheinen und Mitglieder in Verteilerlisten sein können, werden Sie ebenfalls als AD-Objekte gepflegt. Hat die Person, z.B. ein externer Dienstleister, auch ein Anmeldekonto, dann kann dieses als "MailUser" konfiguriert werden. Externe Empfänger ohne ein AD-Konto sind dann MailContacts, so dass Exchange ein AD-Kontakt anlegt.

Beiden Objekten ist gemeinsam, dass Sie für Exchange dann relevante Felder haben. Das ist nicht nur der "Displayname" und das Feld "Mail", mit denen der Empfänger im Adressbuch erscheint. Exchange pflegt im Hintergrund natürlich auch noch die Zieladresse im Feld "TargetAddress" (ExternalEmailAddress), die ProxyAddresses (Emailaddresses), den Mailnickname (Alias) und weitere Felder.

Im Idealfall haben diese Empfänger im Feld "ProxyAddresses" nur die externe Mailadresse. Die Realität sieht aber anders aus und daran ist oft auch Exchange mit Schuld, denn über die "Default Empfängerrichtlinie" kommen eventuell weitere Adressen hinzu. Das kann zu folgenden Problemen führen.

  • Konflikt mit Bestandsuser
    Stellen Sie sich vor, sie haben in ihrem Exchange Verbund einen MailContact "John.doe@msxfaq.de" angelegt und durch der hat als ProxyAdresse John.doe@<ihrefirma>. Da Kombinationen aus Vorname+Nachname nicht eindeutig sind, soll ein neuer Mitarbeiter gleichen Namens in ihrem Unternehmen die Adresse bekommen. Das geht erst, wenn Sie den Kontakt anpassen.
  • Unerwünschte Weiterleitung
    Das größere Problem ist aber, dass so ein externe Kontakt auch unter ihrer Domain erreichbar ist. Es ist tatsächlich eine legitime Umleitung, wenn eine externe Person etwas an john.doe@<ihrefirma> sendet und sich dahinter ein MailUser oder MailContact mit einer externen Adresse verbirgt. Das kann gewollt sein, z.B. wenn Drucker eine Statusmail nicht anonym zum "Printer as a Service"-Dienstleister ins Internet senden dürfen und sie daher einen Kontakt als Zwischenstation eingerichtet haben. Aber sonst ist es nicht gewollt
  • Exchange Online und Gäste
    Da alle ProxyAddresses auch in die Cloud repliziert werden, könne es auch hier einen Konflikt mit bestehenden Gastbenutzern o.ä. geben. Denn in ihrem Tenant kann es eine Mailadresse auch nur genau einmal geben.

Vielleicht haben Sie noch andere Sonderfälle, in denen eine Mailadresse aus ihrer Domain an einem MailUser/MailContact stören könnte. Wenn Sie dies erkennen und vielleicht auch lösen sollten, dann lesen Sie weiter.

Achtung:
Achten Sie darauf, dass Sie nicht Objekt erwischen, die für eine Migration oder Koexistenz mit eine anderen Mailsystem benötigt werden. Dies ist bei SMTP-Sharing z.B. der Fall. Dann müssen Sie genauer hinschauen

Exchange Online und Hybrid ist kein Problem, denn Cloud-Postfächer sind lokal eine "RemoteMailbox", und werden zumindest bei der aktuellen Exchange PowerShell mit einem "Get-MailUser/Get-MailContact" nicht geliefert. Sie unterscheiden sich im msExchRecipientTypeDetails, auch wenn Sie im RecipientType selbst wie ein "MailUser" aussehen.

Wenn Sie Fehler gefunden haben, dann versuchen Sie herauszubekommen, wie diese erfolgt sind. Vielleicht sollten Sie eine Empfängerrichtlinie derart anpassen, dass die "DefaultPolicy" nur eine interne Domain vergibt, z.B. "intern.<ihrefirma>". Wer dann nicht unter eine andere Richtlinie mit der passenden Domain fällt, ist falsch konfiguriert und kann keine Mails empfangen. Auch ihre Provisioning-Prozess muss ggfls. verbessert werden.

Lösungsansatz

Zuerst habe ich an einen klassischen Einzeiler gedacht, der in Umgebungen mit genau einer relevanten Domäne auch funktioniert. Mit folgenden Befehlen bekommen Sie alle MailUser/Mailkontakte heraus, die eine ProxyAddresses aus ihrer Domain verwenden. Sie müssen natürlich "msxfaq.de" durch ihre Domain oder sogar Domains ersetzen.

# Zur Sicherheit, wenn grosse Umgebungen mehrere Domains haben
Set-ADServerSettings -ViewEntireForest $true

# Liste aller MailUser ermitteln die eine externe Mailadresse als Ziel aber dennoch eine eigene Domain als ProxyAdresse haben
Get-Mailuser `
   -Filter "(ExternalEmailAddress -notlike '*@msxfaq.de') -and (emailaddresses -like '*@msxfaq.de')" `
   -Resultsize unlimited `
| fl externalemailaddress

# Fast der gleiche Befehl für Kontakte
Get-Mailcontact `
   -Filter "(ExternalEmailAddress -notlike '*@msxfaq.de') -and (emailaddresses -like '*@msxfaq.de')" `
   -Resultsize unlimited `
| fl externalemailaddress

Wenn die Abfrage keine Ergebnisse liefert, dann sind sie hier fertig. Wenn Sie aber Objekte finden, dann sollten Sie überlegen, ob die aktuelle Konfiguration so korrekt ist.

Auswertung per Skript

Da eine Firma aber problemlos mehrere Domains haben kann und eine Bildschirmausgabe nicht immer einfach zu sortieren und filtern ist, habe ich ein PowerShell-Skript entwickelt, welches entweder alle MailUser und MailContacts abfrage oder eine Liste der Objekte über die Pipeline erwartet. Die Funktionsweise pro Objekt ist dann schnell erklärt.

  • AcceptedDomains
    Zuerst holt sich das Skript einmalig alle Domänen ihrer Exchange Umgebung. Die nutzt das Skript dann für den Vergleich
  • Vergleich 1: Primaryaddress
    Wenn Sie kein SMTP-Sharing mit einem anderen Mailsystem betreiben, dann sollten alle MailUser/MailContacts eine primäre Mailadresse außerhalb ihrer SMTP-Domains haben. Alle Objekte mit einer Adresse in ihrer Domain werden als Information auf dem Bildschirm ausgegeben aber nicht weiter behandelt
  • Vergleich 2: ExternalEmailAddress
    Diese Feld, auch als TargetAddress bekannt, enthält die Zieladresse, an die Exchange die Mail zustellt. Auch diese Adresse sollte nie aus ihrer interne Domain sein.
  • ProxyAddresse aufschlüsseln
    Für alle dann noch übrig gebliebenen Objekte werden die ProxyAddresses einzeln abgearbeitet. Relevant sind nur die SMTP-Adressen, FAX, X400, MSMAIL etc. sind uninteressant. Wenn sich hier dann Adressen finden, die aus ihren AcceptedDomains stammen, dann werden diese gemeldet.

Die Ausgabe erfolgt "farbig" auf dem Bildschirm aber das Skript schreibt auch strukturierte Daten in eine CSV-Datei, die sie dann einfach per Excel auswerten können.

Diese Auswertung sollten Sie gewissenhaft machen, ehe Sie die geplanten Änderungen umsetzen wollen.

Korrekturen

Wenn das Skript schon so viel weiß und richtig von falsch unterscheiden kann, dann kann es die Fehler auch gleich korrigieren. Dazu müssen Sie nur den Schalter "-delete" setzen, damit das Skript alle überzähligen SMTP-Adressen aus den ProxyAddresses entfernt, die erkannt wurden. Wenn sie sich nicht ganz sicher sind, dann nutzen Sie den zweiten Parameter "-confirmdelete", damit sie bei jeder Löschung erst "gefragt" werden. Natürlich können Sie auch mit "-WhatIf" die Löschung nur anzeigen lassen. Ein "Undo" habe ich in das Script aber nicht eingebaut.

Protokollierung

Über den Parameter "-csvfilename" können Sie eine eigene Datei angeben, in die das Skript die Ergebnisse aber auch Änderungen protokolliert. Die Datei wird immer weiter angehängt und jede Zeile enthält neben einem Zeitstempel auch die PrimaryAddress, ExternalAddress und die ProxyAddresse mitsamt der geplanten oder ausgeführten Korrektur.

Download

Das Skript ist in der Standardkonfiguration auf "ReadOnly" gestellt und wertet nur aus.

remove-proxyaddresses.ps1
Nach dem Download die Extension .TXT entfernen und im Explorer "unblocken"

Kontrollieren Sie anhand der angelegten CSV-Datei für jede ProxyAdresse, die mit "REMOVEPENDINGx" gekennzeichnet ist, ehe sie das Skript mit "-delete" und optional "-confirmdelete" aufrufen.

Einsatz auf eigene Gefahr. Das Skript liegt im Sourcecode vor. Kontrollieren Sie bei Skripten immer, was sie diese mit ihren privilegierten Berechtigungen sonst noch tun

Exchange Online?

Wer im Hybrid-Mode mit ADSync unterwegs ist, muss das Skript auf dem lokalen Exchange Server ausführen. In der Cloud können Sie zumindest keine MailUser/MailContacts verwalten, die von ADSync abgeglichen werden. Aber sowohl im Hybrid-Mode als auch ExchangeOnlineOnly können sie natürlich auch direkt in der Cloud einen MailUser/MailContact anlegen und auch falsch provisionieren. Allerdings ist das schon Vorsatz, denn Exchange Online macht dies in der Regel richtig. Aber Sie können die Einzeiler von oben ja in einer Exchange Online PowerShell starten. Meine Tenant haben bislang keine Objekte geliefert.

Weitere Links