Exchange 2013/2016 IMAP funktioniert nicht mehr (MSExchangeIMAP4 Event 1011)

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.

Outlook E-Mail Standardschriftart mit GPO festlegen

Praktisch seit dem Erscheinen des ersten Outlook-Clients in „Office 2000“ wünschen sich Unternehmen die Möglichkeit, eine Standartschriftart in E-Mail für Benutzer in der Domöne vorzugeben. Natürlich ist es generell nicht möglich Fonts zu verwenden die der Empfänger nicht besitzt – und man hat ja keine Ahnung welche der Empfänger hat. Aber nunja „bei uns wird das dann ja richtig angezeigt“ scheint das faktenignorierende Killerargument zu sein. Und der Kunde ist ja schliesslich König.

Unter OWA gibt es sowiso bisher keine Möglichkeit, die Standartschriftart vorzugeben. Jeder Postfachnutzer muss das selber machen.

Aufgrund der technischen Unlösbarkeit dieser Herausforderung, gibt es keine Standart-Gruppenrichtlinie (GPO) dafür; jedenfalls nicht bis Windows Server 2016 und Office 2016 (Office365).

Outlook Standartschriftart mit GPO vorgebenSo legt man die Standart-Schriftart für Outlook (Office 365) mittels GPO fest

  1. Einen Outlook-Client wunschgemäß mit der Standartschriftart konfigurieren.
    Je nach Outlook-Version findet sich die Einstellung etwas versteckt. In Outlook 2013/2016 liegt das beispielsweise unter Datei > Optionen > E-Mail > Briefpapier und Schriftarten.
  2. Einstellungen aus der Registry in eine GPO (idealerweise GPO-Preferences) übernehmen
    HKEY_CURRENT_USER\Software\Microsoft\Office\<Version>\Common\Mailsettings

    Die Einstellung ist ein Wert von Typ „REG_BINARY“ und sieht etwas seltsam aus, das ist aber korrekt so. Es reicht auch eine „Benutzer-Richtlinie“ um den Wert zu vergeben,

Am einfachsten geht das, wenn auf dem client mit Outlook auch die Remoteserver-Verwaltungstools für Windows 10 (RSAT) installiert sind. Dann öffnet man die Gruppenrichtlinienverwaltung einfach auf dem Client, erstellt/bearbeitet das passende Richtlinienobjekt (GPO), fügt unter Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung ein neues Element hinzu und wählt die passenden Schlüssel aus.

Zum Beispiel für Outlook 2016 lautet der Registry-Pfad:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\MailSettings

Die relevanten Schlüssel für die Auswahl der Outlook-Schriftart sind:

  • ComposeFontComplex – Neue E-Mail
  • ComposeFontSimple – Neue E-Mail
  • CReplyFontComplex – Antworten und Weiterleiten
  • CReplyFontSimple – Antworten und Weiterleiten
  • TextFontComplexLokale Anzeige bei Plain-Text E-Mails
  • TextFontSimpleLokale Anzeige bei Plain-Text E-Mails

Exchange 2016 OWA/ECP leere Seite nach Login

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

Ressourcenpostfach Kalenderbuchungen automatisch akzeptieren um Konflikte zu vermeiden

Problem:

Ein Ressourcenpostfach (Gerätepostfach) soll Kalenderbuchungen automatisch akzeptieren. In der Standardeinstellung sind Konflikte bei der Buchung möglich.

Lösung:

Standardmäßig werden bei Gerätepostfächern Kalenderbuchungen zwar als „Mit Vorbehalt“ im Kalender eingetragen, allerdings nicht automatisch bestätigt. Somit sind auch doppelte Buchungen möglich.

Diese Einstellung lässt sich relativ schnell via Exchange-Management-Shell ändern:

Set-CalendarProcessing -Identity "POSTFACH" -AutomateProcessing AutoAccept

Kalenderdetails eines Ressourcenpostfaches anzeigen (Exchange 2016/Online)

Problem:

Benutzer sehen im Kalender eines Ressourcenpostfaches standardmäßig lediglich den Frei-/Gebucht-Status und können Termine auch nicht zum anzeigen von Details öffnen.

Lösung:

Es gibt mehrere Möglichkeiten dies zu ändern:

  1. Einem Benutzer Vollzugriff auf das Ressourcenpostfach geben (via EMC). Mit diesem Benutzer können dann die Berechtigungen des Kalenders vom betroffenen Postfach angepasst werden. Oder:
  2. Die Kalenderberechtigungen für den „Default“-Benutzer via Exchange-Management-Shell anpassen:
Set-MailboxFolderPermission "POSTFACH-ID:\Kalender" -AccessRights Reviewer -User Default

Die Rolle „Reviewer“ behinhaltet die Berechtigungen „FolderVisible, ReadItems“, somit also auch das Anzeigen der Termindetails.
Die anderen möglichen Berechtigungen bzw. Rollen finden sich unter https://technet.microsoft.com/de-de/library/dd298062(v=exchg.160).aspx

Mapi session /o=Erste Organisation/ou=Erste administrative Gruppe/cn=Recipients/cn=benutzername with client type MoMT exceeded the maximum of 500 objects of type FolderView

Problem

Bei einem (oder mehreren) Benutzer reagiert Outlook nicht mehr. Outlook sagt „Die Anwendung reagiert nicht“ und wird blass. Außerdem möchte sich das Outlook selbst nach einem Neustart nicht so richtig am Server anmelden und fragt ständig nach Benutzername und Kennwort. Nach einer Stunde geht wieder alles.

Zudem wird auf dem Exchange-Server diese Fehlermeldung im Anwendungsprotokoll protokolliert:

Mapi session /o=Erste Organisation/ou=Erste administrative Gruppe/cn=Recipients/cn=benutzername
with client type MoMT exceeded the maximum of 500 objects of type FolderView

Quelle: MSExchangeIS   Ereignis: 9646 (Event 9646)

Lösung

Das Exchange-Throtteling hat mal wieder zugeschlagen. Das passiert gerne mal, wenn ein Benutzer mehrere Mailboxen hgeöffnet hat.

Das FolderView-Objekt kann man in der Registry konfigurieren, unter HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession. Wenn der Schlüssel „MaxObjsPerMapiSession“ noch nicht existiert, einfach anlegen.

In diesem Fall wird der FolderVie-Wert von 500 auf 2000 erhöht:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession]
"objtFolder"=dword:000007d0
"objtFolderView"=dword:000007d0

E-Mails die in Outlook von einem gemeinsamen Postfach aus versendet werden, landen nicht im gemeinsamen „Gesendete Objekte“ Ordner

Seit Office 2010 ist die Standardeinstellung von Outlook-Ablageobjekten nicht immer optimal. Neue Nachrichten, die von einem gemeinsamen (ob fremdgeöffnet oder als shared Mailbox angelegt ist egal) Postfach gesendet werden, werden nicht im Ordner „Gesendete Objekte“ des freigegebenen Postfachs abgelegt, sondern im Postfach des absendenden Benutzers. Das sorgt oft für Verwirrung.

Das liegt daran, das in Exchange 2010+ und Office 365 freigegebene Postfächer keine Lizenz mehr benötigen und man Outlook nicht mehr als „unabhängiges“ Postfach verbinden kann. In so einem Fall meldet man sich konsequenterweise aber beim eigenen Postfach an und öffnen das freigegebene Postfach zusätzlich. Beim Senden nimmt Outlook dann standartmäßig das Konto des Absenders. Daher werden Nachrichten – im Prinzip folgerichtig – auch immer im Ordner „Gesendete Objekte“ das Postfach des Absenders (also angemeldeten Nutzers) gespeichert.

Dieses Verhalten ist reine Outlook-Sache (nicht Exchange) und lässt sich schnell in der Registry anpassen:

HKCU\Software\Microsoft\Office\<VERSION>\Outlook\Preferences
DWORD: DelegateSentItemsStyle
Wert: 1 (für Ablage in geöffnetem Postfach)
Wert: 0 (für Ablage in eigenem Postfach, Standard)

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Wenn man unter Windows mit dem MMC Zertifikats-SnapIn einen frischen CSR erstellt („REQ“ im Windows-Jargon), wird standartmäßig der aktuelle „Microsoft Strong Crytographic Provider“ als Kryptoanbieter ausgewählt. Das ist im Prinzip auch gut so, denn das ist der aktuellste und vom Umfang her größte CSP (Certificate Storage Provider) den Windows mitbringt. Die meisten Windows-Features können damit auch problemlos umgehen – der IIS, der SMTP, RDS und so weiter.

Nicht jedoch Exchange (bis einschliesslich 2016 CU3). Exchange FBA unterstütz keine CNG Zertifikate. Nutzt man diese doch, kommt es zu dem berüchtigten Exchange OWA und Exchange EAC Anmeldeloop.

Folgt man dem im Blog angegebenen Anweisungen zum austausch der Zertifikates und erstellt ein neues passendes Zertifikat, kommt es beim Import der neuen Zertifikate (ob CER oder PFX spielt keine Rolle) oftmal zu dem Fehler

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Ursache hierfür ist, das der im CSR angegebene CSP nicht korrekt ist. Wenn man den CSR unter Windows erstellt, versteckt sich das zugehörige Häkchen unter Neue Anforderung erstellen > Eigenschaften > Privater Schlüssel > Kryptografiedienstanbieter. Der für den CSR ausgewählte CSP lässt sich mit certutil an der Kommandozeile selbstverständlich nicht nachschauen …