Seit gestern erreichen mich Fehlermeldungen auf Exchange-Servern, die über einen Smarthost von 1&1 (jetzt IONOS) versenden.

Das SMTP-Logfile des Sendeconnectors sieht wie folgt aus:

2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,17,192.168.0.20:8319,212.227.15.167:25,,,Remote certificate 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,18,192.168.0.20:8319,212.227.15.167:25,,"CN=smtp.1und1.de, L=Montabaur, S=Rheinland-Pfalz, O=1&1 Telecommunication SE, C=DE",Certificate subject
 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,19,192.168.0.20:8319,212.227.15.167:25,,"CN=TeleSec ServerPass Class 2 CA, STREET=Untere Industriestr. 20, L=Netphen, PostalCode=57250, S=Nordrhein Westfalen, OU=T-Systems Trust Center, O=T-Systems International GmbH, C=DE",Certificate issuer name 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,20,192.168.0.20:8319,212.227.15.167:25,,289B2D8A7DE5FEEEB5E117131748CC27,Certificate serial number
 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,21,192.168.0.20:8319,212.227.15.167:25,,ECAE7BFD0F1CF5F33853D6D81E9A37A90B6D9674,Certificate thumbprint 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,22,192.168.0.20:8319,212.227.15.167:25,,smtp.1und1.de,Certificate alternate names
 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,23,192.168.0.20:8319,212.227.15.167:25,,,"TLS protocol SP_PROT_TLS1_0_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA1 with strength 160 bits and key exchange algorithm CALG_ECDHE with strength 256 bits" 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,24,192.168.0.20:8319,212.227.15.167:25,,,Received certificate
 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,25,192.168.0.20:8319,212.227.15.167:25,,ECAE7BFD0F1CF5F33853D6D81E9A37A90B6D9674,Certificate thumbprint 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,26,192.168.0.20:8319,212.227.15.167:25,,UntrustedRoot,Chain validation status
 2019-01-18T09:37:11.558Z,1und1,08D67C27692E0958,27,192.168.0.20:8319,212.227.15.167:25,>,QUIT,
 2019-01-18T09:37:11.573Z,1und1,08D67C27692E0958,28,192.168.0.20:8319,212.227.15.167:25,<,221 kundenserver.de Service closing transmission channel,
 2019-01-18T09:37:11.573Z,1und1,08D67C27692E0958,29,192.168.0.20:8319,212.227.15.167:25,-,,Local

Was ist passiert?

Mit einem der letzten Updates von Microsoft ist das Stammzertifikat der TeleSec-Zertifizierungsstelle aus dem Pool der vertrauenswürdigen Stammzertifizierungsstellen entfernt worden.
Unter dem nachfolgenden Link kann das Stammzertifikat heruntergeladen werden, damit es danach erneut manuell importiert werden kann:

https://www.telesec.de/de/public-key-infrastruktur/support/root-zertifikate/category/59-t-telesec-globalroot-class-2

Auf dem Exchange-Server muss das MMC-Snapin für das lokale Computerkonto geöffnet werden. Unter dem Punkt „Vertrauenswürdige Stammzertifizierungsstellen“ kann das Zertifikat importiert werden (siehe Screenshot).

Anschließend muss der „MSExchangeTransport“-Dienst neu gestartet werden, damit das neue Zertifikat geladen wird.

Wird ein Exchange-Postfach angelegt durch einen Admin, ist noch nicht festgelegt, in welcher Sprache die Standardordner wie Posteingang etc. dargestellt werden. Diese Entscheidung wird beim ersten Anmelden des Benutzers getroffen. Hierbei spielt die Spracheinstellung des verwendeten Clients die entscheidende Rolle.

Wird ein englisches Outlook verwendet, dann heißt der Posteingang plötzlich „Inbox“. Im OWA wird bei erster Anmeldung sofort nach den Regions- und Spracheinstellungen gefragt. Diese werden dann auf die Ordner angewendetet.

Um dies wieder rückgängig zu machen, kann folgender Parameter an die Outlook.exe übergeben werden, der die Standardordner auf die Spracheinstellung des übergebenden Outlooks zurücksetzt:

outlook.exe /resetfoldernames

Leider ist es bei Exchange 2013 nicht mehr über die GUI möglich, einen angelegten Kotakt aus dem Adressbuch auszublenden. Um dies zu erreichen muss folgender Powershell-Befehl angewendet werden:

C:\> Set-MailContact <contact alias> -HiddenFromAddressListsEnabled $true

Um zu überprüfen, ob der Befehl erfolgreich angewendet worden ist, kann mittels dieses Kommandos eine Kontrolle erfolgen:

C:\> Get-MailContact <contact alias> | fl *hidden*

Seit Exchange 2013 ist das Logging wirklich mehr als ausführlich geworden. Da kommt es häufiger vor,  dass die Festplatte, auf der die Logs abgelegt werden, quasi überquellt. Im Standardfall ist dies Laufwerk C: und hat den Systemstillstand zu Folge.

Folgendes Powershell-Skript sucht alle Logs zusammen uns wirft sie weg, wenn sie älter als X Tage sind. In diesem Beispiel wird alles älter 30 Tage gelöscht:

Get-ChildItem 'C:\Program Files\Microsoft\Exchange Server\V15\Logging','C:\Inetpub\Logs' -Directory | Get-ChildItem -Include '*.log','*.blg' -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-30) | Remove-Item

Heute musste ich feststellen, dass die Exchange-Management-Tools nicht auf dem herkömmlichen weg über Systemsteuerung – Software deinstalliert werden können. Man kann das Exchange-Setup auf diesem Wege aufrufen, aber die Deinstallationsroutine besteht darauf, dass Serverrollen zur Entfernung markiert werden.

Nimmt man den Weg über die CMD glückt die Deinstallation allerdings:

C:\Program Files\Microsoft\Exchange Server\Bin>Setup.com /m:uninstall /roles:MT

Willkommen bei der unbeaufsichtigten Installation von Microsoft Exchange Server
2007

Das Exchange-Setup wird vorbereitet.

Die folgenden Serverfunktionen werden entfernt
    ManagementTools

Die Voraussetzungen für Microsoft Exchange Server werden überprüft


Konfigurieren von Microsoft Exchange Server

    Exchange ManagementTools         ......................... ABGESCHLOSSEN
    Die Exchange-Dateien werden entfernt.
    Status                           ......................... ABGESCHLOSSEN

Der Installationsvorgang von Microsoft Exchange Server wurde erfolgreich abgesch
lossen.

C:\Program Files\Microsoft\Exchange Server\Bin>

Generell kann über die Exchange-Management-Shell angepasst werden, wie viel, wie lange und was die Nachrichtenverfolgung nachhält. Zumindest gilt das für Exchange 2010 und 2013 – 2007 habe ich nicht getestet.

Dieser eine Befehl steuert dies:

Set-TransportService <ServerIdentity> -MessageTrackingLogEnabled <$true | $false> -MessageTrackingLogMaxAge <dd.hh:mm:ss> -MessageTrackingLogMaxDirectorySize <Size> -MessageTrackingLogMaxFileSize <Size> -MessageTrackingLogPath <LocalFilePath> -MessageTrackingLogSubjectLoggingEnabled <$true|$false>

Interessant zu wissen ist, dass mit -MessageTrackingLogMaxAge 00:00:00 die Vorhaltezeit auf unendlich gesetzt wird. Trotzdem greifen aber die Maxima der Logfile-Größen. Diese sollten ebenfalls angepasst werden, wenn eine unendliche Speicherung dieser Daten angestrebt wird.

Mit folgendem Befehl kann überprüft werden, welche Werte gesetzt worden sind:

Get-TransportService <ServerIdentity> | Format-List MessageTrackingLog*

In der Regel möchte man die Exchange-Datenbanken auf einer eigenen Partition oder LUN auf dem Exchange-Server laufen lassen oder einfach auf andere Festplatten verschieben.

So wird es gemacht…

Über die Powershell

Mittels des folgenden Befehls wird die angegebene Datenbank sowie deren Logfiles verschoben:

[PS] Move-DatabasePath -Identity "Mailbox Database 0695288994" -EdbFilePath "D:\ExchangeDB\Mailbox\Mailbox Database 0695288994\Mailbox Database 0695288994.edb" –LogFolderpath "D:\ExchangeDB\Mailbox"

Bestätigung
Möchten Sie diese Aktion wirklich ausführen?
Der Datenbankpfad 'Mailbox Database 0695288994' wird verschoben.
[J] Ja  [A] Ja, alle  [N] Nein  [K] Nein, keine  [?] Hilfe (Standard ist "J"): J

Bestätigt man nun mit J wird die Bereitstellung der Datenbank sofort aufgehoben!

Mit folgendem Befehl kann abgefragt werden, on die Datenbank nach Verschiebnung wieder erfolgreich gemountet worden ist:

[PS] Get-MailboxDatabase "DatabaseName" | FL Name,*Path*

Heute bin ich bei einem Kunden auf ein Phänomen gestoßen, das mir ein paar graue Haare mehr beschert hat.
Nach Installation eines Exchange 2013 – CAS innerhalb einer bestehenden Exchange 2007 – Organisation zeigte sich den bereits auf 2013 migrierten Benutzern folgendes Fehlerbild:

• Passwortabfrage erschien beim Starten von Outlook
• Zugriff auf öffentliche Ordner nicht möglich (Fehlermeldung: Ein Clientvorgang ist fehlgeschlagen)
• Kalenderfreigaben auf alten Exchange-Server konnten nicht geöffnet werden.

Um die Situation nachvollziehen zu können, muss man wissen, dass die öffentlichen Ordner  noch auf dem Exchange 2007 lagen und auf dem Exchange 2013 noch nicht eingerichtet worden sind.

Was ist passiert?

Seit Exchange 2013 gibt es keine Kommunikation via MAPI-Protokoll nativ mehr. Stattdessen kommt der gleiche Mechanismus zum Tragen, der bei Outlook Anywhere eingesetzt wird. Es werden MAPI-Pakete in HTTPS-Paketen gekapselt. Somit kommuniziert ein Exchange 2013 mit einem Exchange 2007 via „Outlook Anywhere“, sofern dies auf dem Exchange 2007 aktiviert worden ist.

Die Kommunikation kommt aber in diesem Fall nicht zustande, da die von den Servern unterstützen Authentifizierungsmethoden nicht übereinstimmen.

Abhilfe

Die Outlook Anywhere Authentifizierungsmethoden müssen auf Exchange 2013 und Exchange 2007 übereinstimmen.

Die Servereigenschaften unter Exchange 2013:

Die Servereigenschaften unter Exchange 2007:

Autodiscover ist ein Mechanismus, der Clients ein XML-File auf einem Webserver zum Download hinterlegt, in welchem die Konfigurationsparameter für den Client aufgeführt sind. So ist eine manuelle Einrichtung von beispielsweise Outlook nicht mehr nötig.

Damit dies tadellos funktioniert, muss dieser Webservice innerhalb und außerhalb der Exchange-Organisation verfügbar gemacht werden. Erschwerend kommt dabei hinzu, dass Exchange dieses Service von Hause aus über eine gesicherte Verbindung zu Verfügung stellt. Vor der Installation sollte daher konzeptioniert werden, wie der Zugriff auf den Dienst realisiert werden soll.

Client-Seite

Um zu verstehen, wie das Autodiscover an die eigenen Bedürfnisse anzupassen ist, ist es meiner Meinung nach wichtig zu verstehen, was der Client (Outlook/Smartphone/etc.) abfragt, um an die Informationen zu gelangen.

Outlook fragt folgende Stellen in der nachfolgenden Reihenfolge ab. Das Verhalten ist hardkodiert und kann somit nicht geändert werden. Werden die gewünschten Informationen über eine der Quellen bezogen, werden die restlichen Quellen nicht mehr abgefragt.

• SCP-Suche
• HTTPS-Stammdomänenabfrage
• HTTPS-AutoErmittlung-Domänenabfrage
• Lokale XML-Datei
• HTTP-Umleitungsmethode
• SRV-Datensatzabfrage
• Zwischengespeicherte URL im Outlook-Profil (neu für Outlook 2010 Version 14.0.7140.5001 und neuere Versionen)
• Direkte Verbindung mit Office 365 (neu für Outlook 2016 Version 16.0.6741.2017 und neuere Versionen)

An dieser Stelle ist wichtig zu wissen, was sich hinter dem Begriff Domäne verbirgt:
Hier handelt es sich um die primäre Maildomäne, nicht etwa die AD-Domäne. Lauten die Mailadressen beispielsweise auf adresse@mail.de, dann ist mail.de die Domäne.

Verfügbarkeit anpassen

In der Regel ist hier kein Handlungsbedarf. Bei der Installation von Exchange werden innerhalb der AD zum einen der SRV-Record im DNS, zum anderen der SCP ins AD geschrieben.
Interessant wird es, wenn die Autodiscover-URL wegen Zertifkatsnamen etc. geändert werden soll. Sprich es soll nicht mehr der interne Servername abgefragt werden. Für diesen Fall kann über die Powershell die URL manipuliert werden.

Zur Abfrage der aktuellen Autodiscover-URL ist folgender Befehl vorgesehen:

Get-AutodiscoverVirtualDirectory | fl internalurl,externalurl

sowie

Get-ClientAccessServer | fl *InternalUri*

Um die URL’s zu setzen werden entsprechend folgende Befehle verwendet:

Set-ClientAccessServer -Identity "EX-CAS-01" -AutodiscoverServiceInternalURI "https://mail.mydomain.com/autodiscover/autodiscover.xml"

sowie

Set-AutodiscoverVirtualDirectory -ExternalUrl 'https://mail.mydomain.com/Autodiscover/Autodiscover.xml' -InternalUrl 'https://mail.mydomain.com/Autodiscover/Autodiscover.xml'

Letztens bin ich bei einem Kunden auf folgende Fehlermeldung gestoßen. Scheinbar prüft das Setup des Exchange 2013 nicht mehr zwingend, ob das Schema für den Exchange aktualisiert werden muss, wenn bereits eine Exchange-Organisation besteht.

Abhilfe

Die Lösung des Problems ist relativ simpel. Auf einem Domänencontroller kann das Setup mit folgenden Parametern gestartet werden, um das Schema zu erweitern:

setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Damit das Setup erfolgreich auf einem DC ausgeführt werden kann, muss zuvor das Windows Management Framework 3.0 installiert werden:

• http://www.microsoft.com/en-us/download/details.aspx?id=34595