Szenario:

Über ein beliebiges Tool wird versucht, per SMTP eine Mail unter Verwendung des Exchange-Servers als Relay zu versenden. Die Authentifizierung klappte tadellos und als Absenderadresse wird die Antwortadresse des Accounts verwendet, mit dem man sich zuvor angemeldet hat. Und doch sagt der Exchange-Server:

5.7.1 Client does not have permissions to send as this sender

Grund / Lösung:

Man muss obige Fehlermeldung nur in Google eingeben, um herauszufinden, dass es so einige Ansätze zur Problemlösung gibt. Bei uns war es jedoch ein sehr unüblicher Grund: Vor zwei Tagen hatte ich die Domain, die die Mailadresse des Benutzers hinter dem @ stehen hat, als „External Relay“ definiert. Damals wollte ich sicherstellen, dass der Exchange immer versucht, die Mail über das Internet zu versenden, auch wenn das Empfängerpostfach lokal vorliegt. Das oben beschriebene Szenario ist hier jedoch ein unangenehmer Nebeneffekt. Verwendet man also den Exchange-Server als Relay für andere Programme, so sollte die sendende Domain immer als „Authorative“ oder „Internal Relay“ eingerichtet sein.

Wird ein öffentlicher Ordner bzw. ein darin untergeordneter Ordner für das Empfangen von Mails aktiviert, kann es sein, dass er auf Grund von vorher gesetzten Berechtigungen dennoch keine Mails empfängt. Sollte dies externe Mails betreffen, können Sie die Lösung hier nachlesen. Geht es jedoch um interne Mails, sind Sie hier richtig.

Führt man eine Sendungsverfolgung auf dem Exchange aus, wird uns folgender Fehler angezeigt:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.NotAuthorized; not authorized [Stage: CreateMessage]};{FQDN=};{IP=}]}

Hier wird also ein Benutzer erkannt, von dem die Mail ausgeht. Dieser hat keine Berechtigung, Mails im Zielordner zu „erstellen“. Nichts anderes passiert im Prinzip, wenn man eine Mail an einen Public Folder schickt. Beheben kann man das folgendermaßen:

Add-PublicFolderClientPermission -identity "\Ordner\Unterordner” –User Default -AccessRights CreateItems

Man kann es natürlich an dieser Stelle auch auf einzelne Benutzer runterbrechen. „Default“ beschreibt alle nicht extra genannten Benutzer.

Bei uns gab es die Anforderung, die Größe eines Öffentlichen Ordners zu bestimmen. Kein Problem eigentlich, gibt es doch folgenden Befehl:

[PS] C:\Windows\system32>Get-PublicFolder "\[Ordnername]" | Get-PublicFolderStatistics | Select TotalItemSize

Doch weit gefehlt, dieser Befehl gibt nur die Größe der direkt darin befindlichen Dateien zurück. Größen von Unterordner bzw. der darin befindlichen Dateien werden nicht berücksichtigt. Abhilfe schafft hier folgender Befehl:

[PS] C:\Windows\system32>Get-PublicFolder "\[Ordnername]" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum

Oder etwas freundlicher fürs Auge:

[PS] C:\Windows\system32>Get-PublicFolder "\[Ordnername]" -Recurse | Get-PublicFolderStatistics | Measure TotalItemSize -sum | Select @{N='Anzahl der Items'; E={$_.Count}}, @{N='Speicher in Byte'; E={$_.Sum}} | fl

Bitte beachten Sie, dass es eine Weile dauern kann, bis der Befehl durchgeführt wurde.

Anders als es der Begriff ‚Cluster‘ vielleicht vermuten lässt, müssen einige Vorbereitungen getroffen werden, um einen Exchange-Server in einer „Database Availability Group“ – kurz DAG – sauber neuzustarten. Macht man das nicht, so kann es gut gehen, im schlimmsten Falle fliegt einem allerdings der Datenbank-Index um die Ohren und die Suche funktioniert nicht mehr. Das wäre der schlimmste mir bekannte Fehler.

Um das zu vermeiden, machen wir folgendes:

Mittels dieses PowerShell-Befehls:

Get-MailboxDatabaseCopyStatus *

lassen wir uns alle Postfach-Datenbanken auf jedem eingehängten Server in der DAG ausgeben. Nun schauen wir nach Datenbanken, welche auf dem neuzustartenden Server den Status „Mounted“ beziehungsweise „Eingehängt“ haben. Sind solche Datenbanken vorhanden, muss folgender Befehl ausgeführt werden:

Move-ActiveMailboxDatabase -Server [Neuzustartender Server]

Hiermit erreichen wir, das die Datenbanken nicht mehr auf diesem Server eingehängt sind, sondern ein beliebiger anderer Server in der DAG diesen Job übernimmt.

Nun kann der Neustart durchgeführt werden. Sobald dieser durch ist, kann man mit dem ersten Befehl prüfen, ob alle Datenbanken den „Healthy“-Status haben bzw. nach kurzer Zeit wieder annehmen. Wichtig ist, dass alle Datenbanken einen solchen Status haben, bevor eine Verschiebung stattfindet. Ist dies der Fall, könnte auch mit dem nächsten Neustart fortgefahren werden.

Es wird davon abgeraten, innerhalb eines Clusters mehr als einen Server gleichzeitig neuzustarten.

 

Da wir diese Anforderung erst auf dem Tisch liegen hatten, bastelten wir uns folgende „OneLiner“, die wir gerne mit euch teilen.

Liste aller Mailbox-Aliase:

Get-Mailbox -OrganizationalUnit "[DN der OU]" | Select -Expand EmailAddresses Alias | Select SmtpAddress, Alias

Liste aller Gruppen-Aliase:

get-distributiongroup -OrganizationalUnit "[DN der OU]" | Select -Expand EmailAddresses Alias | Select SmtpAddress, Alias

Oftmals müssen noch nachträglich Rechte auf öffentliche Ordner vergeben werden. Ist dieser jedoch zu dem Zeitpunkt schon gut gefüllt, so kommt es vor, dass die Rechtevergabe über das Exchange Control Panel (ECP) mit einer OutOfMemory-Exception fehlschlägt. Umgehen können wir dieses Problem durch die Nutzung der Exchange-eigenen PowerShell-Scripts:

  1. Als erstes öffnen wir eine neue Instanz der Exchange Management Shell (EMS). Alternativ können wir auch eine PowerShell-Konsole verwenden, müssen hier aber erst über den Befehl „Add-PSSnapin Microsoft.Exchange.Management.Powershell.Snapin“ den Exchange-Befehlssatz laden, da dieser in den offiziellen Scripts nicht nochmal extra importiert wird.
  2. In der Shell wechseln wir nun die Working-Directory über cd und begeben uns somit in den Script-Ordner:
    cd „C:\Program Files\Microsoft\Exchange Server\V15\Scripts“
    Der Ordner „V15“ muss durch die entsprechend verwendete Exchange Version ersetzt werden.
  3. Nun führen wir folgenden Befehl aus:
    .\AddUsersToPFRecursive.ps1 -TopPublicFolder „\[Ordner-Pfad]“ -User „[UPN des Users]“ -Permission „[Rechtebezeichnung]“
    Bsp.: .\AddUsersToPFRecursive.ps1 -TopPublicFolder „\technet“ -User „mmustermann@c4y.biz“ -Permission „Owner“
  4. Nach einer kurzen Wartezeit werden nacheinander sämtliche Ordner aufgelistet und die Rechtevergabe auf selbige bestätigt.

Das war’s schon!

Wird ein öffentlicher Ordner bzw. ein darin untergeordneter Ordner für das Empfangen von Mails aktiviert, kann es seit dem SP1 für Exchange 2013 sein, dass dies nicht mehr für den Empfang externer Mails genügt. Schuld daran ist die fehlende Berechtigung für Anonymous (das sind externe Sender in diesem Fall), in dem Ordner Elemente zu erstellen.

Führt man eine Sendungsverfolgung auf dem Exchange aus, wird uns folgender Fehler angezeigt:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]};{FQDN=};{IP=}]}

Aus diesem Grund muss für jeden für den Mailempfang aktivierten Ordner folgender Befehl noch über die Exchange-Shell ausgeführt werden:

Add-PublicFolderClientPermission –identity “\Ordner\Unterordner” –User Anonymous –AccessRights CreateItems

Damit ist das Problem schon behoben.

Oft bietet es sich an, mit der Adresse einer Verteilergruppe eine Mail zu versenden. Beispielsweise um sicherzugehen, dass die Antwort des Empfängers auch wieder an den Verteiler geht. Nun pflegt man dies entweder von Anfang an mit ein, oder es fällt einem erst nach einer gewissen Zeit ein, so dass man nun gefühlte hundert Verteiler vor sich hat und das nachtragen darf. So geschehen bei mir.

Klarer Fall, es musste ein Script her:

Grant-SendAs-To-Group

Dieses Script durchläuft alle Verteiler und fügt jeweils den Verteiler gleich als SendAs-Berechtigten hinzu.

Um den vollen Funktionsumfang aller Exchange-Dienste ausnutzen zu können, müssen alle Namen, sowohl intern als auch extern, mit einem oder mehreren Zertifikaten abgedeckt werden. Nun hat man zwei Möglichkeiten, das ganze zu bewerkstelligen:

  1. Verwendung von zwei unterschiedlichen Zertifikaten: Eins ausgestellt von der internen CA zur Abdeckung aller internen URLs und eins ausgestellt von einem Zertifikatsanbieter Ihrer Wahl zur Abdeckung der externen URLs.
  2. Umstellung der internen URLs auf die externen, um anschließend im internen DNS die öffentlichen URLs zusätzlich zu pflegen, allerdings unter Verwendung von internen IPs. Hier wird dann nur ein Zertifikat benötigt.

Die bisherige dritte Möglichkeit, nämlich sowohl lokale als auch öffentliche URLs in ein Zertifikat zu packen, wird ab dem 1. November 2015 nicht mehr unterstützt. Für mehr Informationen hierzu klicken Sie bitte auf folgenden Link: https://www.icann.org/en/system/files/files/sac-057-en.pdf

Die zweite Möglichkeit werden wir nun durchführen. Hierfür müssen wir allerdings einige Befehle in der Exchange Management Shell absetzen. Diese lauten wie folgt:

Set-ClientAccessServer -Identity <HostName> -AutodiscoverServiceInternalUri https://mail.example.de/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity "<HostName>\EWS (Default Web Site)" -InternalUrl https://mail.example.de/ews/exchange.asmx

Set-OABVirtualDirectory -Identity "<HostName>\oab (Default Web Site)" -InternalUrl https://mail.example.de/oab

Set-ActiveSyncVirtualDirectory -Identity "<HostName>\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.example.de/Microsoft-Server-ActiveSync

Set-OWAVirtualDirectory -Identity "<HostName>\owa (Default Web Site)" -InternalUrl https://mail.example.de/owa

Set-ECPVirtualDirectory -Identity "<HostName>\ecp (Default Web Site)" -InternalUrl https://mail.example.de/ecp

Optional (kann zuvor über Get-OutlookAnywhere getestet werden):

Set-OutlookAnywhere -Identity "<HostName>\Rpc (Default Web Site)" -InternalHostname  -InternalClientsRequireSsl $true

Im Anschluss daran muss man den IIS Application Pool recyclen, damit die Änderungen wirksam werden. Hierfür muss der IIS Manager geöffnet werden. Darin angekommen, klicken wir unter Application Pools auf den MSExchangeAutodiscoverAppPool und anschließend auf Recycle. Sobald dies erledigt ist, sind die Einstellungen übernommen und die Clients ziehen sich bei der nächsten Autodiscover-Abfrage die neuen URLs.

Was ist das?

SMTP Tarpitting ist ein pro Empfangskonnektor setzbarer Parameter. Dieser sorgt dafür, dass beim Versand über den jeweiligen Konnektor an eine dem Exchange nicht unmittelbar bekannte Adresse (sprich extern oder nicht vergebene Aliase) eine definierte Verzögerung eintritt.

Macht das Sinn?

Ja und nein. Es macht Sinn für meistens genau einen Konnektor, nämlich den, der Mails von extern empfängt. Wenn man nun versucht, den Exchange-Server mit Spam zu überschütten, wird die ein oder andere falsche Adresse dabei sein, was immer zu einer Verzögerung führt. Vielen Spammern wird das dann letztendlich zu blöd, da sie diese Zeit sinnvoller nützen können.
Keinen Sinn macht es jedoch für interne Relays, die meist zügig die Mails nach außen schieben sollen. Hier wird so manche externe Adresse dabei sein, die diese Verzögerung bewirkt. Viele einfach programmierte SMTP-Konnektoren werden bis die Response kommt sogar komplett freezen. Daher macht dies intern wirklich keinerlei Sinn.

Konfigurieren der Konnektoren

Standardmäßig sind 5sek. pro Konnektor gesetzt. Um beim erstgenannten Empfangskonnektor für Mails aus dem www die Zeit sogar noch zu erhöhen, kann folgender Befehl ausgeführt werden: 

Set-ReceiveConnector “FromInternet” -tarpitinterval 00:00:10

Um z.B. für interne Relays die Tarpitting komlett abzuschalten, ist stattdessen dieser Befehl hier nötig: 
Set-ReceiveConnector “Internal” -tarpitinterval 00:00:00