Konfiguration des Exchange Servers ab 2010

Für Exchange Server 2010 muss Exchange WebService (EWS) aktiviert sein. Dies ist bei einer Standardin­stallation automatisch der Fall, jedoch in Exchange Online nicht immer. Siehe die Hin­weise zu Exchange Impersonation weiter unten.

Es wurde festgestellt, dass es Probleme mit der Exchange-Kopplung bei der Authentifizierung geben kann, nachdem neue (aktuellere) Exchange Server aufgesetzt wurden (Server 2016). Die Digest-Authen­tifizierung scheitert aus noch nicht geklärten Gründen.

Erste Maßnahme: Digest abschalten (wichtig, damit das nicht mehr ausgehandelt wird), dafür die Standard-Authentifizierung (Basic Authentication) einschalten.

Best practice: Der EWS-Benutzer sollte als voller UPN (Benutzerprinzipalname) eingetragen werden (user@domain.xyz), wenn damit zu rechnen ist, dass die Postfächer über eine andere Domäne erreicht werden. Letztere wird dann in der Groupware-Konfiguration hinterlegt. Beispiel von "Musterfirma" in Frankreich: EWS-Benutzer "dcomaccess@icfr.firma.fr", Domäne: "firma.fr", Groupware-Nutzer: "Mar­tina.Muster", Principal: Martina.Muster@firma.fr.

Insbesondere beim zweiten Punkt kommt es zu Problemen, weil sich mit der Umstellung auf die neuen Exchange-Server auch die Login-Namen (und damit die Postfachnamen) geändert haben. Das lässt sich jedoch relativ leicht klären, nachdem die Authentifizierung wieder funktioniert.

Es muss sichergestellt werden, dass für den Internet Information Server (IIS) auf dem Exchange-Host die erforderlichen Rollendienste verfügbar sind. Im Server-Manager muss unter "Rollen / Webserver (IIS) / Rollendienste" bei "Sicherheit" die "Digestauthentifizierung" als installiert gekennzeichnet sein. Fehlt sie, so muss sie installiert werden.

Nachdem die Digest-Authentifizierung im Server-Manager installiert wurde, muss sie nun für den Exchange WebService aktiviert werden:

Ist die Windows-Authentifizierung wider Erwarten hier nicht verfügbar, dann muss sie analog zur Digest­-Authentifizierung vorher installiert werden.

Nach einer Standard-Installation hat der Exchange-Server ein selbstzertifiziertes SSL-Zertifikat, das z.B. von allen gängigen Web-Browsern zurückgewiesen wird, wenn man beispielsweise die WSDL-Dateien mit herunterladen möchte:

"https://Name_Of_EWS_Host/ews/Services.wsdl"

Dabei erhält man die Möglichkeit,

a) das Zertifikat nach genauer Überprüfung als vertrauenswürdig im Browser zu hinterlegen und

b) und es als Datei zu speichern.

Letzteres ist erforderlich, um das Zertifikat der Java-Umgebung bekanntzumachen. Fügen Sie das Zertifikat zur Java-Umgebung ("JRE") hinzu, die für den CRM-Server verwendet wird.

Beispiel für Java 6 unter Unix/Linux (für Windows wird $JAVA_HOME durch %JAVA_HOME% ersetzt und "/" durch "\" ersetzt):

Anmerkungen

• Die Aufruf-Syntax kann von JRE zu JRE unterschiedlich sein. Näheres dazu finden Sie in der Dokumen­tation des JREs.
• Als ALIAS bietet sich der Hostname des Exchange-Servers an.
• Der Parameter Path_to_Cert_File ist der Pfad zum gespeicherten Zertifikat.
• Das Password ist tatsächlich changeit, sofern man es noch nicht geändert hat!
• Die Meldungen von keytool sind lokalisiert. Auf einem deutschen System muss man also die Frage mit "ja" beantworten.

Besitzen Sie für den Exchange-Server ein durch eine anerkannte CA bestätigtes SSL-Zertifikat, dann ist dieser Schritt in der Regel nicht notwendig, wenn die CA auch vom JRE akzeptiert wird. Dies können Sie mit keytool überprüfen. Siehe dazu die Dokumentation von keytool (Bestandteil der JRE-Dokumenta­tion).

Als Anhaltspunkt kann gelten: Akzeptiert der Web-Browser das Zertifikat ohne Warnung, dann sollte auch das JRE das Zertifikat ohne weitere Schritte akzeptieren.

Bei Exchange Online oder einer alternativ extern gehosteten Exchange-Umgebung sollte der Dienstan­bieter immer ein öffentlich signiertes SSL-Zertifikat vorweisen. Somit sollte dieser Schritt (Import des Zertifi­kats) bei Exchange Online eher vermieden werden. Bei Problemen mit dem Zertifikat schließen Sie sich bitte mit dem Dienstanbieter kurz.

Für den Zugriff auf lokal gehostete Exchange-Server-Umgebungen oder MS Exchange Online (MS 365) wurde EWS-Impersonation zusätzlich in die CRM-Groupware-Konfiguration integriert. EWS-Imper­sonation ermöglicht den Zugriff auf mehrere Exchange-Konten mithilfe eines einzigen Benutzers (Identi­tätswechsel).

Auf Exchange-Server-Seite muss EWS-Impersonation eingerichtet sein. Bei lokalen Exchange-Installatio­nen und "Office 365 Enterprise Plan E3" kann der Impersonations-Account frei definiert werden, bei Office 365 Small Business ist es automatisch der Administrator-User.

Im Groupware-Konfigurationsdialog müssen ein EWS-Benutzer, das dazu gehörende Passwort und die EWS-Version eingetragen sein. Siehe auch Konfiguration des Groupware Connectors.

Siehe hierzu den Artikel aus der Microsoft Library.