Kategorien
Exchange Office Tipps & Tricks

Outlook-Suche im Exchange-Postfach für ältere Elemente schlägt fehl

Hat man den Cache-Modus in Outlook für ein Exchange-Postfach auf einen bestimmten Zeitraum begrenzt, muss die Suche für frühere Ergebnisse auf dem Server fortgesetzt werden. Dazu wird man meist in der untersten Zeile der Suchergebnisse dann aufgefordert. Fälschlicherweise kann es dann hier zu der Meldung kommen, dass der Server offline oder nicht erreichbar ist.

Server unavailable. 12 months of results shown.

Fehlermeldung auf Englisch

Ob der Server tatsächlich ein Problem hat, können Sie bei Exchange-Postfächern sehr einfach über die „Outlook Web App“ prüfen. Wenn hier die Suche erfolgt, hat der Server normalerweise keine Probleme. Kommt es auch hier zu Fehlern, genügt es in den meisten Fällen, den Datenbank-Index neu aufzubauen. Das wollen wir aber in dem Fall nicht behandeln, wir gehen also davon aus, dass die Suche in OWA funktioniert.

Die Lösung, um die augenscheinliche Falschmeldung in Outlook zu beheben, ist mehr als seltsam. Bitte befolgen Sie folgende Schritte:

  • Klicken Sie per Rechtsklick links in der Ordnerübersicht auf Ihre Email-Adresse (also in der obersten Ebene)
  • Klicken Sie auf „Datendateieigenschaften….“
  • Klicken Sie auf „Ordnergröße…“
  • Wechseln Sie auf den Reiter „Serverdaten“. Hier müsste der Aufbau ein paar Sekunden benötigen.
  • Das war’s, sie können die Fenster wieder in umgekehrter Reihenfolge schließen.

Versuchen Sie im Anschluss die Suche erneut. Nun sollte die Schaltfläche wieder verfügbar sein, die es Ihnen ermöglicht, ältere Ergebnisse auf dem Server zu suchen.

Hat es Ihnen geholfen? Wir freuen uns auf Ihr Feedback!

Exchange-Postfächer in jeder Edition und Größe können Sie übrigens bei uns ganz unkompliziert buchen, schauen Sie mal vorbei unter: https://cloud4you.biz/cloud/kommunikation/hosted-exchange

Kategorien
Exchange

Migration der X500- / Legacy-Adressen

Viele Personen kennen diese Adressen gar nicht mehr, dabei basieren Termine und auch die gute alte Autovervollständigen-Funktion bei Eingabe einer Adresse in An:/Cc:/Bcc: noch immer auf diesen Adressen. In Folge dessen kommt es nach einer Migration oft zu Problemen bspw. beim reorganisieren von Terminen, so dass Teilnehmer nicht mehr benachrichtigt werden. Um dem entgegenzuwirken, kann man diese Adressen migrieren. Wie das geht, zeigen wir hier.

Export vom alten Domain Controller

Zunächst erstellen wir in der alten Umgebung mit Hilfe von PowerShell einen CSV-Export, der die Legacy-Adressen enthält.

Get-ADUser -SearchBase "OU=MyOffice,DC=domain,DC=int" -Filter * -Properties legacyExchangeDN  | Export-CSV C:\x500adresses.csv -NoTypeInformation

Import auf dem Ziel-Exchangeserver

Die CSV-Datei muss nun möglicherweise zu einem Server/PC kopiert werden, der auf die Exchange-Shell Zugriff hat. Dort angekommen importieren wir die Datei wieder und führen dann folgendes aus:

$Asdf = Import-CSV "C:\x500adresses.csv"
foreach ($User in $Asdf){ if ($User.legacyExchangeDN){ Get-Mailbox -Identity $User.UserPrincipalName | Set-Mailbox -EmailAddresses @{add="X500:$($User.legacyExchangeDN)"} } }

Ob die Migration erfolgreich war, kann über folgenden Befehl geprüft werden:

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,ServerName,PrimarySmtpAddress, @{Name="EmailAddresses";Expression={$_.EmailAddresses | ForEach-Object {$_}}}
Kategorien
Exchange Server Windows

Terminüberschneidungen in Ressourcen-Postfächern

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.

Kategorien
Exchange Server Windows

Exchange-Server schließt IMAP- oder POP3-Verbindungen sofort wieder (Aktualisiert)

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.

Kategorien
Exchange Server Windows

Exchange antwortet mit „SMTP 5.7.1 Client does not have permissions to send as this sender“ für eigene Adresse

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.

Kategorien
Exchange Server Windows

Mail-aktivierter öffentlicher Ordner empfängt keine Mails von intern

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.

Kategorien
Exchange Scripts

OneLiner: Größe eines öffentlichen Ordners und dessen Unterordner bestimmen

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.

Kategorien
Exchange Server Windows

Wie starte ich einen Exchange-Server in einem DAG-Cluster neu?

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.

 

Kategorien
Exchange Server Windows

OneLiner: Alle Mail-Aliase von Benutzern / Gruppen aus einer OU anzeigen

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
Kategorien
Exchange Server Windows

Exchange Public Folder – Nachträgliche rekursive Rechtevergabe

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!