Outlook ist primär der Client zum Exchange Server, ein Einsatz ohne Exchange ist aber auch möglich. Erstmals erschien es 1997 im Zusammenhang mit dem Microsoft Server.
Exchange Posteingang bleibt nach Konto hinzufügen bei Mobile leer
Symptom
Exchange Administratoren erleben das der Posteingang auf dem Smartphone leer bleibt, die Ordner werden nicht Synchronisiert. Das Exchange Konto wurde erfolgreich hinzugefügt, der Posteingang jedoch bleibt leer, auch neue Mails erscheinen nicht.
Ursache
Ab Exchange 2003 SP1 wurden Vererbbare Berechtigungen des übergeordneten Objekts standardmässig für Mitglieder von geschützten Gruppen, beispielsweise Domänen-Admins deaktiviert. In der Tat wird jede Stunde der DACL für Mitglieder geschützter Gruppen zurückgesetzt und vererbbare Berechtigungen werden entfernt. Dieser Vorgang wird als AdminSDHolder bezeichnet, um unsachgemässe Änderungen an geschützten Gruppen zu vermeiden.
Ereignisanzeige
Lösung
Active Directory-Benutzer und -Computer aufrufen und zum betreffenden Benutzer gehen, auf Eigenschaften und Sicherheit gehen, den Button Erweitert wählen und den Hacken setzen bei Vererbbare Berechtigungen des übergeordneten Objektes einschließen, übernehmen klicken und mit OK schließen. Nun ist für eine Stunde die Berechtigung erteilt, das Objekt MsExchActiveSync für das Mobile Gerät zu erstellen.
Vererbbare Berechtigung
Für Windows Server 2012 R2 und 2016 muss bei Active Directory-Benutzer und -Computer in der Menuleiste unter Ansicht, die Option Erweiterte Features aktiviert sein.
Unter Eingenschaften des Benutzers geht man zum Tab Sicherheit und Erweitert.
Den Button Vererbung aktivieren klicken, nun wird für eine Stunde AdminSDHolder aktive sein, in diesem Zeitfenster hat der Admin die Möglichkeit das Smartphone beim Exchange als Device zu registrieren. Danach werden die Postfach Elemente synchronisiert.
Möchte man Outlook 2010/2013 mit der AutoErmittlung (Outlook Anywhere) automatisch konfigurieren, und das Postfach auf einem Exchange 2010/2013 liegt, wird man nach der Installation folgenden Sicherheitshinweis erhalten.
Dies liegt oft daran das kein Zertifikat vorliegt, welches von Microsoft Active Directory Certificate Services (AD CS) ausgestellt wurde.
Problembeschreibung
Nachdem ein neues Zertifikat von einer root CA Zertifizierungsstelle beim Exchange-Server importiert wurde, kann es zu Fehlermeldungen beim Start bei den Outlook Clients kommen.
Im Sicherheitshinweis Fenster sehen wir in der ersten Zeile, dass sich unser Exchange-Server mit seinem internen FQDN “exchsrv.domain.local” meldet. Ebenfalls gibt uns die Meldung die Information, dass das Zertifikat ungültig ist oder die Namen nicht übereinstimmen.
Symptome
Outlook oder das Mobiltelefon können nicht konfiguriert werden.
Outlook hat die Suche nach den URLs für die Autodiscover-Informationen Hardcodet und wird in folgender abfolge durchlaufen:
Autodiscover Lookup Reihenfolge
Wenn nun die nötigen DNS-Records fehlen oder keine der definierten URLs aus dem Internet erreichbar sind, kann Autodiscover nicht abgefragt werden.
Der Name „autodiscover.domain.com“ ist auch im Zertifikat vorhanden, aber die Warnung tritt stattdessen für den Namen „exchsrv.domain.local“ auf.
Zertifikat Details
Ursache
Nicht wie die Vorgänger, verwendet Outlook 2013 intern nicht nur den SCP (Service Connection Point) zur Suche nach Autodiscover, sondern macht gleichzeitig eine DNS-Auflösung gemäss oben dargestellten Reihenfolge. Wenn jetzt die DNS-Auflösung von exchsrv.domain.com auf einen Webserver mit HTTPS Binding zeigt, erscheint der oben gezeigte Sicherheitshinweis.
Lösung
Neues Exchange-Zertifikat erstellen
Neues Zertifikat erstellen
Der EMC-2010 Assistent erstellt abschliessend die Anforderung welche in einer Datei(.req) gespeichert wird, dieser private Schlüssel wird benötigt um bei der CA Zertifizierung (z.B. CAcert.org) mittels Copy & Paste dann über das Formular den Public Key zu erzeugen. Anschliessend wird der ausgestellte Schlüssel mit „Anstehende Anforderung abschliessen“ der wiederum mit Copy & Paste von der Zertifizierungsstelle eingefügte Schlüssel erzeugt. Zuletzt noch dem Zertifikat die Dienste zuordnen.
Die von CA Cert Signing Authority ausgestellten X.509-Zertifikate enthalten nur im Internet auflösbare FQDN, daher müssen die Internen URLs per Exchange Management Shell angepasst werden.
Mit folgendem cmdlet wird die aktuelle URI abgefragt.
Exchange Management Shell
Die AutoDiscoverServiceInternalUri wird nun auf den Externen FQDN geändert, damit es dem ausgestellten Zertifikat entspricht.
Set-AutoDiscoverVirtualDirectory -Identity "exchsrv.domain.local\Autodiscover (Default Web Site)" -InternalUrl "https://exchsrv.domain.com/Autodiscover/Autodiscover.xml" -ExternalUrl "https://exchsrv.domain.com/Autodiscover/Autodiscover.xml"
Set-WebServicesVirtualDirectory -Identity "exchsrv.domain.local\EWS (Default Web Site)" -InternalUrl "https://exchsrv.domain.com/EWS/Exchange.asmx" -ExternalUrl "https://exchsrv.domain.com/EWS/Exchange.asmx"
noch kontrollieren ob alles stimmt..
Get-AutoDiscoverVirtualDirectory | ft InternalUrl, ExternalUrl
Get-WebServicesVirtualDirectory | ft InternalUrl, ExternalUrl
Get-ClientAccessServer -Identity exchsrv.domain.local | ft AutoDiscoverServiceInternalUri
Ohne DNS geht nichts, deshalb erstellen wir eine neue Forward-Lookupzone, wir öffnen dnsmgmt und erstellen eine neue Zone für unser exchsrv.domain.com
dnsmgmt Neue Forward-Lookupzone
Rechts im Fenster wieder mit Rechtsklick ein neuen Host als Type A erstellen, das Name Feld leer lassen und die IP Adresse von exchsrv.domain.com eintragen.
Neuer Host A
Nun sollten die Exchange-Dienste neu gestartet werden, den IIS mit iisreset /noforce aktualisieren. Ist der Nameserver als BIND auf einem Linux/Unix Host, steht folgende Zone für unsere Mail Domain für Autodiscovery.
DNS Zone
Für Windows wird im DNS-Manger im Kontextmenu unter weitere Einträge der Eintrag „Dienstidentifizierung SRV“ erstellt.
Windows DNS Manager
Zu guter letzt soll unser Zertifikat auf die Clients ausgerollt werden, hierzu bieten sich die Gruppenrichtlinien an.
Mit Rechtsklick auf Importieren gehen, mittels des Assistenten die zuvor exportierte Zertifikatsdatei (.cer) importieren.
Beim Client wird mit gpupdate /force die Policy aktualisiert.
Alternativ kann das Zertifikat auf den Clients auch mittels des cmd-Tool certutil importiert werden, beispielsweise aus einer Batch Datei.
Troubleshooting
Am einfachsten geht’s mit dem Browser um herauszufinden wohin die URL https://exchsrv.domain.com zeigt. Alternativ kann auch nslookup oder host aufgerufen werden.
Browser SSL Zertifikat
Ebenso bietet sich hier das cmd-Tool certutil zur Überprüfung an.
certutil -f –urlfetch -verify exchsrv.crt
Ob das Zertifikat an der richtigen stelle im Zertifikatsspeicher ist, lässt sich anhand der mmc-Konsole überprüfen.
Hinweis!
Das hier verwendete Zertifikat wird mit dem öffentlichen Schlüssel der kostenfreien Zertifizierungsstelle CAcert (cacert.org) ausgestellt, dies erfordert dass das Stammzertifikat von CAcert als Klasse 1 PKI Schlüssel im PEM oder DER Format zum Zertifikatsspeicher „Vertrauenswürdige Stammzertifizierungsstellen“ importiert werden muss.
Das Zertifikat ist für die dauer von einem Jahr gültig, danach muss es erneuert werden, wer dies mit „Exchange Zertifikat erneuern“ versucht, wird feststellen das dies nicht geht, Exchange 2010 möchte nur neue Zertifikate erstellen, deshalb die Methode mittels certutil.
Certutil -repairstore my Seriennummer
Die Seriennummer findet man in den Zertifikat Details, danach das Exchange-Zertifikat importieren.
