Kategorie-Archiv: Exchange

Problem

Nach dem Update auf Exchange 2013 CU6 (oder neuer) gibt es plötzlich einen neuen Ordner in

%ProgramFiles%\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces

der riesig wird. Dort sammeln sich DocumentProcessingTrace*.etl Dateien, die auf gut 50Mbyte pro Stück anwachsen können. In einem Fall hatten sich dort etwas mehr als sieben Gbyte an Daten angesammelt, die nicht so wirklich jemandem helfen.

Das sind die Diagnose-Dateien der Exchange Volltextsuche. Man kann diese auch mit Eventviewertools öffnen und Exchange entfernt diese auch irgendwann, aber ob diese in der Zwischenzeit so viel Platz belegen müssen bleibt dem Admin überlassen.

Lösung

Glücklicherweise lässt sich das Diagnostische Tracking der Suche Konfigurieren. Sowohl der Pfad zu den Dateien, die Größe als auch die Anzahl sind in der Registry einstellbar:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\16.0\Search\Diagnostics\Tracing]
"TracingPath"="C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Bin\\Search\\Ceres\\Diagnostics\\ETLTraces"
"MaxTraceFileSize"=dword:00000028
"MaxTraceFileCount"=dword:0000000a

Die Werte für „MaxTraceFileSize“ und „MaxTraceFileCount“ sind hier hexadezimal anzugeben.

Nach einer Änderung müssen die Dienste „Microsoft Exchange-Diagnose“ und „Microsoft Exchange-Suche“ einmal neu gestartet werden und schon ist man die Plage los.

Problem

Ein Ressourcenpostfach ist via „AutoAccept“ auf die automatisch Annahme einer Buchung konfiguriert Wenn man diese Ressource (Eine Raum oder ähnliches) nun bucht, bekommt man die Besprechung im eigenen Kalender auch korrekt angezeigt, im Kalender der Ressource allerdings nicht. Dort sieht man nur den Namen des Organisators im Betreff (anstelle des Betreffs).

Lösung

Dieses Verhalten ist das Standardverhalten für neue Ressourcenobjekte. Aber die Einstellung lässt sich jederzeit ändern:

Set-MailboxCalendarSettings -Identity <NAME> -AutomateProcessing AutoAccept -AddOrganizerToSubject $False -DeleteSubject $False

Problem

Auf einem Exchange 2013/2016 funktioniert IMAP „auf einmal“ nicht mehr. Alle IMAP-Verbindungen brechen sofort ab. Eine TCP-Verbindung wird zwar hergestellt, jedoch kommt es zu keinem Nachrichtenaustausch und die Verbindung wird sehr schnell wieder beendet. IMAP-Tools an der Kommandozeile geben den „Error: ReadLine“ zurück, also „keine Daten erhalten“.

Zudem wird (oder wurde …) im Ereignisprotokoll das MSExchangeIMAP4 Ereignis 1011 protkolliert.

Lösung

In diesem Fall war der interne IMAP-Proxy für den Frontendserver ausgeschaltet. Die Ursache dafür haben wir noch nicht gefunden, aber es kommen Updates (CU) und gehäufte Verschlüsselungsfehler bei IMAP-Verbindungen in Frage.

Status prüfen:

[PS] C:\>Get-ServerComponentState -Identity <SERVERNAME>

Im Fehlerfall ist der Proxy hier als „inactive“ zu sehen. Dann werden keine Mails ausgetauscht.

Status ändern:

[PS] C:\>Set-ServerComponentState -Identity <SERVERNAME> -State Active -Requester HealthAPI -Component ImapProxy

Danach klappt’s sofort wieder.

Problem:

Bei einer On-Premise Exchange Umgebung funktionieren „plötzlich“ Outlook und OWA nicht mehr. OWA und auch die ECP-Site zeigen noch den Login, danach bleibt die Seite allerdings leer.

Im System-Eventlog gibt es massenweise folgendes Event: (Source: HttpEvent; Event-ID: 15021)

Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:444 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten.

Lösung:

Ursache ist eine fehlende Zuordnung des SSL-Zertifikats für die Backend-Site im IIS.

Dort das SSL-Zertifikat wieder bei der korrekten Bindung auswählen, ggfs. den IIS neustarten und schon sollte der Zugriff wieder klappen:

1. IIS Manager öffnen
2. Sites -> Exchange Back End
3. Im Aktionsbereich auf Bindungen
4. Die https Bindung *:444 Bearbeiten
5. das SSL-Zertifikat auswählen
6. ggfs. iisreset