Lync Control Panel

Auf der Seite Lync Deployment können Sie lesen, dass Lync "anders" installiert wird, als z.B. Exchange, Windows, Office, SQL etc. Lync wird aber auch anders verwaltet, auch wenn es Parallelen zu Exchange gibt. Die normale Administration erfolgt nämlich über eine Silverlight-gestützte GUI oder eben per PowerShell. Dabei kommen die gleichen Verfahren wie bei Exchange zum Tragen, um die Berechtigungen zu steuern.

Die Verwaltung von Lync per GUI ist möglich aber nicht gerade für "MassenÄnderungen " gedacht. Sie können damit problemlos einzelne Benutzer oder Einstellungen anlegen und verwalten aber nicht bei mehreren Benutzern umfangreiche Änderungen vornehmen

Frontend

Für den Zugriff auf das Control Panel benötigen Sie einen Browser mit Silverlight. Auf dem Lync Server ist durch das Betriebssystem  Windows 2008 natürlich schon der Internet Explorer installiert worden und Silverlight können Sie relativ einfach nachinstallieren. Das Controlpanel wird klassisch über einen Link im Startmenü gestartet

Wer sich aber die Eigenschaften der Verknüpfung anschaut, sieht keine URL sondern einen Start eines LyncAppHost.exe, der dann die richtige URL erst ermittelt und die Verbindung herstellt. Bei einer Farm wird übrigens der Poolname verwendet, d.h. auch wenn Sie lokal auf einem Server sind, kann es durchaus passieren, dass sie der DNS-Eintrag auf den Loadbalancer verweist und sie dann auf dem anderen Server landen.

Wer dies vermeiden will, kann natürlich auch den Servernamen bzw. die URL direkt im Browser eingeben.

https://<lyncservername>/cscp

Von der Bedienung gibt es keinen unterschied, ob da nun ein Browserfenster drum herum ist oder nicht.

Der Pfad "CSCP" steht für Communication Server Control Panel. Die Änderung des Produktnamens hat es also nicht mehr überall hingeschafft.

Backend

Wenn ein Browser zur Konfiguration per HTTPS auf den Lync-Server zugreift, dann lohnt sich der Blick in den IIS-Manager, der die Daten liefern und die Befehle annehmen muss.

Das virtuelle Verzeichnis CSCP ist nur auf der "Lync Server Internal Website" integriert. Ein Zugriff von außen ist daher bei korrekter Konfiguration des Reverse Proxy für die LyncWebservice nicht möglich

WWer einen Zugriff auf dieses virtuelle Verzeichnis versucht, wird im IISLog protokolliert. Hier sehen Sie zuerst die anonymen Anfragen, die abgewiesen werden und nach der erfolgreichen Anmeldung als "DOMAIN\AdminUser" kommen dann die POST-Befehle auf den BigFinWebService.asmx.

Welche Aktivitäten jemand aber über den Webservice ausgelöst hat, ist im ISLog nicht weiter zu sehen

CSCP geht nicht und dann ?

Mit dem Wissen um die Funktionsweise ist die Fehlersuche relativ einfach. Hier ein paar einfache Checks und Prüfungen.

Frage/Fehler/Topic Ja Nein

Ist der Webserver erreichbar ?. Dies können Sie ganz einfach aus einer CMD-Box mit einem "TELNET Servername 80" oder "TELNET Servername 443" prüfen. Das Fenster muss "schwarz" werden und nicht mit eine Fehlermeldung zeigen ,dass das System nicht erreichbar ist.

Telnet ignoriert die Proxy-Einstellungen, so dass dieser Test meist zuverlässig die Erreichbarkeit des IIS anzeigt.

Prüfen Sie, ob der IIS auf dem Lync Server läuft, ob ein Virenscanner oder eine Firewall den Traffic verhindert (notfalls mit NetMon).

Namensauflösung
Prüfen Sie lieber doppelt, ob der Name korrekt aufgelöst werden kann und auf den richtigen Host verweist

Weiter zum nächsten Punkt

Korrigieren Sie die Namensauflösung.

Loopback / Loadbalancer
Windows 2008 schützt sich gegen "Loopback-Attacken", d.h. wen ein Browser den Webserver mit einem anderen Namen anspricht aber der Zugriff von "localhost" kommt, dann erlaubt der IIS keine Anmeldung. Das ist bei Lync der Fall, wenn Sie ohne Loadbalancer arbeiten und den Poolnamen per "Hosts" oder "DNS" auf einen der Frontendserver verbunden haben.
Können Sie /CSCP von einem anderen Client starten ?

Nutzen Sie den anderen Client oder warten Sie bis ein Loadbalancer die Webservices korrekt bereit stellt

Weiter zum nächsten Check

IPV6
Auch wenn Lync selbst mit IPV6 offiziell nicht nutzt, so nutzt der IIS und die Webservices das Protokoll, wenn es verfügbar ist. Das sehen sie ja oben schon im IISLog. Der IIS sollte also auch in diesem Umfeld arbeiten.

Prüfen Sie, ob der IIS ihre Anfragen auch annimmt.

Dann wird es mal Zeit für einen Netzwerkmitschnitt mit NetMon auf dem Client oder dem Server um zu sehen, wohin die Pakete tatsächlich gehen.

HTTP Anfragen
Der IIS kann auch ganz einfach mit einem Browser angesprochen werden, z.B. auf https://servername/dialin und andere Lync-URLs

Ist der Test erfolgreich, dann sollte der Webserver und Proxyeinstellungen kein Problem darstellen

Prüfen Sie das IISLog, ob ihre Zugriffe wirklich dort ankommen.

Automatische Anmeldung
per Default versucht das Control Panel eine Anmeldung mit dem aktuellen Benutzer. können Sie sich mit einem anderen Benutzer anmelden

Wenn ein anderer Benutzer arbeiten kann, könnte es an Berechtigungen oder RBAC-Rollen liegen.

Prüfen Sie das Security Eventlog des Servers auf fehlerhafte Anmeldungen

PProxy und Zonen
Zugriffe auf CSCP sind HTTPS Zugriffe. Stellen Sie sicher, dass die Lync Server als "intern" angesehen werden und daher den Proxy umgehen und auch in der Internetzone "Intranet" auftauchen. Nutzen Sie dazu den Browser und gehen Sie auf https://LyncserverFQDN/CSCP

Anderes Thema versuchen

Korrigieren Sie die Einstellungen im Internet Explorer bezüglich Zonen und Proxy

Silverlight ist nicht installiert

Installieren Sie Silverlight, was manchmal nicht ganz einfach ist (User Account Control, Server kommt nicht ins Internet

Andere Fragestellungen prüfen.

Dies ist nur eine kurze Checkliste. Sie müssen sich immer daran orientieren, dass die grafisches Frontend auf dem PC bzw. in dem Browser läuft und eine Kommunikation per HTTPS mit dem Backend erfolgt.

Weitere Links