Lync Client und EWS/Autodiscover

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/

Das primäre Protokoll bei Lync ist SIP aber für einige Funktionen greifen die verschiedenen Lync-Clients z.B. auf Exchange zurück. für viele überraschend wird dabei sein, dass die Exchange WebServices eine wichtige Rolle spielen und nicht das MAPI-Profil. Outlook ist nur auf "Windows Clients" vorhanden aber eben nicht auf Tablet, Mobiltelefonen, Lync Telefonen, WebClients o.ä. Und da immer mehr Clients gar nicht "in der Domäne" sind, kommt der Funktion Autodiscover eine große Bedeutung zu. Aber sogar der Windows Client verzichtet bei der Auflösung auf die bekannten Pfade eines Exchange Clients.

Wozu braucht Lync den EWS-Zugriff?

Das stellt sich die Frage, was der Lync Client denn damit macht. Die Quellen hierzu waren nicht ganz einfach zu finden

  • Lesen und Löschen von Elementen im Ordner "Unterhaltungsverlauf"
  • Lesen oder Löschen von Voicemail-Elementen
  • Teilweise: Anzeigen der "Voicemail"-Buttons zur Verbindung mit der Voicemail
  • Anzeigen erweiterter Frei-/Gebucht-Informationen sowie von Besprechungsbetreff und Standort

Da kann man sich natürlich fragen, ob ein "Problem" bei EWS wirklich ein Problem darstellt. Aber da niemand weiß, welche anderen Probleme damit zukünftig entstehen können, sollten Sie auch für Lync die Autodiscover-Funktion bereitstellen

Kontrolle: Funktioniert EWS mit Lync?

Der erste, schnellste Weg die Funktion von EWS zu testen ist die Kontrolle in der Lync Konfigurationsübersicht, die Sie "CTRL - Rechte Maustaste" auf das Lync Icon in der Statusleiste erhalten:

In den Konfigurationsinformationen sehen Sie dann auch den aktuellen Status für MAPI und EWS.

MAPI ist die lokale Verbindung des Lync Communicators mit einem lokal installierten Outlook. Lync prüft z.B. ob das "Postfach" zur "SIP-Adresse" passt und nur wenn dies vorhanden ist, dann nutzt Lync auch den MAPI-Client. Bei EWS ist es etwas anders, dass Lync hier direkt mit dem Exchange Server spricht. Sie sehen dass sogar bei mir hier mal ein "EWS nicht bereitgestellt" erscheint. mögliche Statusmeldungen sind:

Eintrag Meldung Bedeutung
MAPI

MAPI nicht verfügbar; es wird versucht eine Verbindung aufzubauen

Lync versucht Outlook und Exchange per MAPI zu erreichen. Da kann noch etwas dauern.

MAPI

MAPI nicht Verfügbar

UCMAPI ist mit Outlook verbunden aber ein oder mehrere Ordner werden nicht aktualisiert. Das ist ein sehr sicheres Zeichen, dass das Lync-Konto und das MAPI-Konto nicht die gleiche SMTP-Adresse/SIP-Adresse haben. Dann weitert sich Lync die Verbindung zu nutzen. Es könnte ja sonst sein, dass "Verpasste Unterhaltungen" in einem falschen Postfach landen

MAPI

MAPI-Status OK

Alles in Ordnung und der Communicator konnte eine Verbindung zum lokalen Outlook per MAPI einrichten

EWS

EWS wurde nicht vollständig initialisiert

Haben Sie noch etwas Geduld. Vermutlich wurde ihr Client gerade gestartet und der Startvorgang ist noch nicht abgeschlossen.

EWS

EWS nicht bereitgestellt

Die Auflösung per "Autodiscover" war nicht erfolgreich.

Wenn Autodiscover gar nicht funktioniert, dann ist die auch daran zu erkennen, dass die EWS-URLs nicht gefüllt sind.

Sollten hier aber gültige URLs stehen, dann ist Autodiscover zumindest gelaufen und Sie müssen "nur" noch nach EWS-Fehlern suchen.

Leider ist es nicht möglich, diese Werte statisch z.B.: per Gruppenrichtlinie zu setzen, da die je nach SIP-Adresse ja unterschiedlich sein können.

Exchange Autodiscover mit Lync Clients

Für Outlook und Exchange ist Autodiscover umfangreich beschrieben. Ein Outlook Client nutzt LDAP-Abfragen, DNS-SRV-Records. DNS-A-Records und ein Administrator kann sogar per lokaler XML-Dateien Outlook entsprechend impfen. Dazu sind folgende Aussagen wichtig:

  • Lync nutzt den Inhalt des Felds "Mail" bzw. "WindowsEmailAddress" des Lync Kontos, um den passenden Eintrag in Exchange zu finden.
  • Kein Lync Client nutzt den Autodiscover Service Connection Point im Active Directory
  • Der Lync Client kann nicht per Gruppenrichtlinien die EWS-Einstellungen erhalten

Damit Lync mit Exchange kommunizieren kann, müssen Sie als eine funktionierende Autodiscover-Auflösung per DNS bereitstelle, Die Clients nutzten dazu folgende Reihenfolge:

Abfrage Beschreibung

https://<smtpdomain>/Autodiscover/Autodiscover.xml

Die meisten Administratoren wissen gar nicht, dass Outlook aber auch Lync Clients zuerst die einfache SMTP-Domain "versuchen". Bemerkt wird dies meist erst, wenn diese Adresse ohne das bekannte "www"-Prefix auf die Firmenhomepage führt und diese ein SSL-Zertifikat hat. Dann wird der Client ggfls. eine Warnung liefern, wenn das Zertifikat nur den Namen  www.<smtpdomain> enthält.

https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

Aber dann kommt schon der direkte Versuch den Zugriff per HTTPS auf den Host autodiscover.<smtpdomain> zu fahren. Wenn das Ziel per HTTPS erreichbar ist, muss der Name im Zertifikat enthalten sein, sonst sehen die Clients einen Zertifikatfehler.

http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

Schlagen beide ersten Optionen fehl, dann wird ein Zugriff ohne SSL versucht. Dann erwartet der Client aber einen "Redirect" auf den richtigen Host. Der Anwender sieht eine entsprechende Warnung.

DNS: _autodiscover._tcp.<smtpdomain> SRV  0 0 443 hostname

Als letzte Option kann der Client auch noch eine DNS-Abfrage nach einem SRV-Record stellen. In den Logs ist gut zu sehen, dass neben dem Communicator auf Windows auch der Lync Client auf IOS diese Auflösung versucht.

Für viele Firmen ist dieses eingeschränkte Verhalten der Lync Client aber oft ein Problem. Gerade kleinere Firmen, die bislang auf Autodiscover per DNS und HTTP verzichtet haben, steht nun die Einführung an. Dies kann Auswirkungen auf Exchange (z.B. Zertifikate), DNS (z.B. Einführung Split-DNS) und offizielle Zertifikate haben.

All diese nette Funktionen hat der Lync Client bislang (Sep 2013) noch nicht sondern nutzt nur DNS-Anfragen nach den Werten:

Und darauf muss ein Exchange Server mit einem Zertifikat reagieren, die Anmeldedaten des Anwenders entgegen nehmen und dann als Antwort die URL für Exchange liefern. Also ist NSLookup und PING der erste Schritt. Es kann aber dann auch so aussehen wie hier:

Im ersten Moment ist man versucht an Hexerei zu glauben. Da kann ich per NSLookup meine Fritz!Box zuhause fragen und bekommt Antwort aber bei einem PING meint das gleiche Windows, es kann den Namen nicht auflösen? NSLookup fragt immer direkt die per IP-Konfiguration zugewiesenen DNS-Server. Ein Ping oder andere Dienste fragen aber den "lokalen Resolver" und da kann es schon mal gerade mit Direct Access oder anderen VPN-Lösungen dazu kommen, dass die Anfragen umgebogen werden. Kontrollieren Sie dies daher.

Manuelle Konfiguration

Eine funktionierende "Autodiscover"-Auflösung ist immer wünschenswert und hat nichts damit zu tun, ob die Clients dann letztendlich per OWA, RPC/HTTP oder ActiveSync zugreifen können. Das wird immer noch z.B. mit Set-CASMailbox gesteuert. Sollten Sie aber Autodiscover.<maildomain> nicht bereit stellen können, dann können Sie immer noch statisch die EWSURLs hinterlegen. Allerdings ist das nicht einfach per Gruppenrichtlinie möglich, da die SIP-Adresse teil des Pfades ist. Hier die Einstellungen für den Lync Communicator 2013:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Office\15.0\Lync\Username@domain.com\Autodiscovery]
"InternalAvailabilityServerURL"="https://server.domain.com/EWS/Exchange.asmx"
"InternalOofServerURL"="https://server.domain.com/EWS/Exchange.asmx"
"InternalEwsURL"="https://server.domain.com/EWS/Exchange.asmx"

Sie können natürlich per Script zuerst die SIP-Adresse des Anwenders ermitteln und dann die Werte setzen.

  • 2787614 Conversation history, contact cards, Free/Busy, and Out of Office information are unavailable when Lync fails to connect to Exchange

DisableEmailComparisonCheck

Ein Sonderfall besteht, wenn die SIP-Domäne von der SMTP-Domäne des Anwenders abweicht. zuerst geht es um die MAPI-Verbindung des Communicators mit Outlook:

Der Skype for Business Client prüft, ob zur SIP-Adresse eine passende Outlook-Mailbox vorhanden ist. Wenn dies nicht der Fall ist, z.B. weil die SIP-Adresse nicht mit in den ProxyAddresses gepflegt wird, dann wird Skype for Business sich weigern, diese MAPI-Verbindung nutzen. Sie sehen in Skype for Business dann keine Integration von Kontakten etc. Diese strenge Prüfung können Sie über die ClientPolicy und dern Parameter "DisableEmailComparisonCheck " abschalten.

Get-CSClientPolicy | Set-CSClientPolicy -DisableEmailComparisonCheck $True

Alternativ können Sie dies auch per Richtlinien oder Regedit verteilen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator]
"DisableEmailComparisonCheck"=DWORD:00000001

TrustModelData

Beim EWS-Zugriff prüft der Client, ob der FQDN des Exchange Servers in der gleichen DNS-Domäne liegt, wie die SIP-Domäne. Wenn ihre SIP-Domäne aber z.B. "uclabor.de" lautet und der Exchange Server und Skype Server aber auf uclabor.intern reagieren, dann stört sich der Communicator daran. Der Trick hierbei ist dann die Pflege der Domains in "TrustedModeData"

HKEY_CURRENT_User\Policies\Microsoft\Communicator
HKEY_LOCAL_MACHINE\Policies\Microsoft\Communicator
HKEY_CURRENT_User\Software\Policies\Microsoft\Office\15.0\Lync\

Hier ist gut zu sehen, dann auch Office 365 über diesen Weg die Exchange Service Domains als "Trusted" addiert, damit Lync diesen vertraut. Der Name muss dem Zertifikatnamen entsprechen.

Sie sehen, dass auch Microsoft mit diesem "Trick" arbeitet, um für die vielen neuen Kunden nicht jedes mal eine neue Domäne als Zertifikat addieren zu müssen. Dieser Weg kann aber auch steinig sein, da Sie diese Einstellungen auf Domänenmitgliedern einfach per Policy setzen können aber PCs, die sie nicht verwalten, manuell vom Anwender angepasst werden müssen. Bei Office 365 macht das z.B.: der "Anmeldeassistent" mit, den Sie als Nutzer von Office 365 installieren.

Intranet-Zone

Denken Sie in dem Zuge auch auf die Zoneneinstellungen im Internetnet Explorer. Wenn Sie immer noch Probleme haben, dann könnte es daran liegen, dass die Exchange URLs vom Client nicht als "Local Intranet" angesehen werden und er sich daher weigert, eine Authentifizierung automatisch durchzuführen.

Authentifizierung

Ein Client kann sich über verschiedene Verfahren an einem Webserver authentifizieren. Innerhalb eines privaten Netzwerks ist natürlich Kerberos das Mittel der Wahl, aber dies ist von extern nicht möglich. Unter dem Sammelbegriff "Negotiate" ist auch NTLM möglich. Der kleinste Gemeinsame Nenner ist "Basic Auth" bei der die Anmeldedaten eigentlich nur Base64-Codiert werden. Das ist aber keine Verschlüsselung. Um so eine Übertragung zu schützenm müssen Sie also zwingend mit SSL verschlüsseln.

Hinweis:
Anscheinend meldet der Lync 2013 Communicator sich nicht an, wenn der Autodiscover-Webserver nur "BasicAuth" anbietet.

Cached Data in der Registrierung

Der Lync Communicator nutzt selbst auch wieder die lokale Registrierung, in der die ermittelten Ergebnisse zwischengespeichert werden. Hier ein Auszug meiner Firmenumgebung mit Lync 2010.

Bei der Schreibweise von "Autodiscovery" mit dem "y" am Ende handelt es sich nicht um einen Tippfehler. Da hat wohl ein Entwickler geschlafen.

Wenn Sie diese Felder hier finden, dann hat Autodiscover zumindest einmal von innen geklappt. Mit Skype for Business finden Sie die vergleichbaren Einstellungen auf

Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync\user@uclabor.de\Autodiscovery

Fehlersuche

Die Suche nach Fehlern des Lync Clients ist bezüglich EWS nicht gerade einfach, denn ich durfte selbst schon mal "suchen" aber leider protokolliert der Lync Client nicht alles

  • Lync Trace
    Wer im lokalen UCCAPI-Trace nach Spuren von EWS und Autodiscover sucht, wird nichts finden. Zumindest konnte ich in keinem dieser Logs einen Hinweis auf Fehler finden
  • Eventlog
    Der Lync Client protokolliert manchmal auch etwas im Eventlog.
  • Outlook
    Ein immer wieder gerne genommener Helfer ist Outlook und dessen Funktion "E-Mail Autokonfiguration testen", die über "CTRL-RechteMaus" auf das Outlook Icon erreichbar ist. Hier ist gut zu sehen, ob Autodiscover prinzipiell funktioniert.
  • IPCONFIG
    Autodiscover macht DNS-Anfragen, die im lokalen DNS-Cache landen. Ein "ipconfig /Displaydns" sollte zumindest die erfolgreiche Auflösung der Autodiscover-Einträge aufzeigen. Viel mehr sagt das aber erst mal nicht aus. Es hilft aber auch bei DNS-Problemen und VPN-Lösungen wie Direct Access
  • NetMon 3.4 / Wireshark (vormals Ethereal)
    Natürlich können Sie mit NETMON auch den Paketen nachforschen aber mehr als ein paar HTTPS-Connects auf 443/TCP sehen Sie nicht. Vielleicht erkennen Sie indirekt einen Zertifikatfehler, weil der TLS-Handshake gar nicht zustande kommt oder die übertragenen Daten zu wenig sind.
  • Fiddler
    Da Autodiscover und EWS reine Protokolle über HTTPS sind, kann ein lokaler Proxy wie Fiddler wertvolle Dienste leisten. Allerdings kann er auch Messergebnisse verfälschen. Dessen sollten Sie sich bewusst sein.
  • FREB
    Wer nicht auf dem Client mitschneiden kann, kann natürlich auch dem Exchange Server mit FREB (Siehe IISDebugging) die Zugriffe des Clients unverschlüsselt ausgeben lassen.

Mein Favorit ist für einen "normalen Client" natürlich erst mal der Outlook-Test, sofern Outlook installiert ist. Dann sollten Sie prüfen, ob das Problem "alle" Clients oder nur einer hat und entsprechend weiter gehen. Am Ende landen Sie aber oft bei Fiddler oder FREB um genau zu sehen, was der Client tatsächlich anstellt.

Weitere Links

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/