Ressourcen-Postfächer kann man so konfigurieren, dass Sie Termine automatisch annehmen. Geschieht die Konfiguration über das ECP oder über den simplen

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept

-Befehl, so klappt die automatische Annahme solange, bis ein Terminkonflikt entsteht. In einer Terminserie ist das dann besonders ärgerlich, da alle Serienelemente abgelehnt werden, sobald sich ein Element mit einem vorhanden Termin überschneidet. Dies kann man umgehen, in dem man weitere Parameter anpasst. Grundsätzlich zu klären wäre dabei folgende Frage: Sind Überschneidungen erlaubt?

Wenn Überschneidungen erlaubt sind, kann man die Einstellungen wie folgt überschreiben:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $true

Damit werden die Termine einfach parallel zu eventuell bereits bestehenden Terminen eingetragen. Das macht dann Sinn, wenn ein Raum beispielsweise doppelt belegbar ist.

Wenn man Überschneidungen vermeiden will und stattdessen wünscht, dass sich überschneidende Termine einfach abgelehnt werden ohne die ganze Serie abzulehnen, so ist folgender Befehl zu verwenden:

Get-CalendarProcessing [Identity] | Set-CalendarProcessing -AutomateProcessing AutoAccept -AllowConflicts $false -ConflictPercentageAllowed 50 -MaximumConflictInstances 15

Der Parameter –ConflictPercentageAllowed gibt hierbei an, welcher Anteil an Serienelementen auf Grund von Überschneidungen abgelehnt werden darf (in Prozent, aber anzugeben ohne ‚%‘-Zeichen), während -MaximumConflictInstances angibt, wie viele Serienelemente wegen Überschneidungen abgelehnt werden dürfen. Beide Werte kann man dabei natürlich utopisch hochsetzen um zu garantieren, dass jede Serie angenommen wird. Dennoch sind sicher an der ein oder anderen Stelle sinnvoll gewählte Grenzwerte nützlich.

Achtung: Solange -AllowConflicts auf $true steht, haben die für –ConflictPercentageAllowed und -MaximumConflictInstances gesetzten Werte keinen Einfluss, sie werden ignoriert.

Szenario:
IMAP- oder POP3-Verbindungen mittels Email-Clients funktionieren einfach nicht mehr, die Verbindungen werden vom Server sofort wieder geschlossen. Bei der weiteren Recherche stellt sich raus, das man mittels Telnet auf dem Exchange-Server selbst unter Verwendung von 127.0.0.1 die Dienste noch abfragen kann. Führt man jedoch Telnet von einer anderen Maschine remote aus, so wird die Verbindung sofort wieder getrennt. Die jeweiligen Dienste sind jedoch auf dem Server aktiv.

Problem:
Wenn oben beschriebenes teilweise oder gar komplett auf Sie zutrifft, liegt es vermutlich daran, dass die Proxy-Komponente des jeweiligen Dienstes inaktiv ist. Prüfen können Sie das, indem Sie eine PowerShell-Eingabeaufforderung starten, und folgende Zeile eingeben:

Get-ServerComponentState -Identity [Servername]

Folgendes könnten Sie als Ausgabe zurückbekommen:

Server Component State
-------
[...]
[Servername] ImapProxy Inactive
[...]
[Servername] PopProxy Active
[...]

Die Ausgabe ist selbstverständlich nicht eingefärbt, dies dient nur der Veranschaulichung.

Behebung:
Sollte nun eine oder gar mehrere Komponenten als Inactive angezeigt werden, müssen wir selbige wieder aktivieren. Dies erfolgt durch folgenden PowerShell-Befehl:

Set-ServerComponentState -Identity [Servername] -Component [Komponente] -Requester HealthAPI -State Active

In unserem Beispiel würde der Befehl wie folgt aussehen:

Set-ServerComponentState -Identity SRV-EXCHANGE -Component ImapProxy -Requester HealthAPI -State Active

Damit sollten die Verbindungen wieder möglich sein. Eventuell müssen die jeweiligen Dienste noch neugestartet werden.

Ursache:
Auch nach weiterer Recherche konnte nicht herausgefunden werden, was den Server dazu trieb, die Komponente auf inaktiv zu setzen. Zwar sieht man im Eventlog, dass er es tat, aber keinen tieferen Grund. Sollte sich hier noch etwas ergeben, werde ich den Blogeintrag entsprechend erweitern.

Nachtrag:
Scheinbar führt irgendein Softwarefehler beim Exchange Server 2013 regelmäßig zum Absturz solcher Komponenten. Aus diesem Grund wurde ein Script angefertigt, das dieses Problem automatisiert behebt, falls es existent sein sollte. Dieses ist auch TaskScheduler-kompatibel, kann hier also ganz einfach eingesetzt und alle 5 Minuten gestartet werden:

#Ausführung des Remoting-Scripts, der Pfad muss bei anderen Server-Versionen abgeändert werden
. "C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1" | Out-NULL
Connect-ExchangeServer -auto | Out-NULL

$LocalHost = $env:computername

Write-Host "Checking IMAP4: " -NoNewline
$ImapState = (Get-ServerComponentState -Identity $LocalHost -Component ImapProxy).State
if($ImapState -eq "Active")
{
   Write-Host "$ImapState" -ForegroundColor Green
}
else
{
   Write-Host "$ImapState" -ForegroundColor Red
   Write-Host "Enabling Component ImapProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component ImapProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Backend Service: " -NoNewline
   Restart-Service "MSExchangeIMAP4BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting IMAP4 Service: " -NoNewline
   Restart-Service "MSExchangeImap4"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Write-Host "Checking POP3: " -NoNewline
$PopState = (Get-ServerComponentState -Identity $LocalHost -Component PopProxy).State
if($PopState -eq "Active")
{
   Write-Host "$PopState" -ForegroundColor Green
}
else
{
   Write-Host "$PopState" -ForegroundColor Red
   Write-Host "Enabling Component PopProxy: " -NoNewline
   Set-ServerComponentState -Identity $LocalHost -Component PopProxy -Requester HealthAPI -State Active
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Backend Service: " -NoNewline
   Restart-Service "MSExchangePOP3BE"
   Write-Host "done." -ForegroundColor Green
   Write-Host "Restarting POP3 Service: " -NoNewline
   Restart-Service "MSExchangePop3"
   Write-Host "done." -ForegroundColor Green
}
Write-Host ""

Zur besseren Veranschaulichung der Ausgabe besitzt dieses Script einige Zeilen, die im Taskscheduler natürlich unnötig sind. Diese habe ich violett markiert.

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.