LyncWeb Services
Für Exchange Administratoren ist es nicht wirklich neu, wenn Server verschiedene Funktionen per HTTP bzw. HTTPS bereit stellen. Autodiscover ist sicher der erste solche Service, mit denen Exchange 2007/2010 Einsteiger konfrontiert werden. Und Outlok2007/2010 nutzen mit Exchange 2007/2010 auch noch Exchange Web Services, OAB-Downloads etc., die alle per HTTPS veröffentlicht werden wollen.
Auch Lync nutzt dieses Verfahren, um verschiedene Dienste für interne und externe Clients bereit zu stellen. Anders als Outlook, welches über "autodiscover.maildomain.de" den ersten Zugang findet, um dann per XML-Antwort die weiteren URLs zu erhalten, nutzt der Lync Communicator hierzu natürlich SIP. Über eine bestehende SIP-Verbindung bekommt der Client die URL für die Lync Webservices.
Topology Builder
Den Namen der einen Lync-Webservice-URL müssen Sie im Topologie Builder konfigurieren. Es gibt je StandardServer bzw. je Pool eine eigene URL, die hinter "External Web Services" konfiguriert werden kann. In dem Beispiel hier ist "lyncweb.domain.de" als Adresse gewählt.
Sie sehen hier auch, dass Lync zwischen den internen und externen Webservices unterscheidet und da diese auf dem gleichen Server laufen, unterschiedliche Ports dafür verwendet. kommt ein Client von Intern, dann nimmt er sich den Poolnamen oder Namen des Standard Servers um auf die Dienste zuzugreifen.
Kommt der Client aus dem Internet, dann nimmt er den konfigurierten externen Namen. Hier spricht der Client aber auch Port 443 an, d.h. wer einen externen Zugriff benötigt, sollte eine passende Firewall haben, die Zugriff von extern auf den Port 443 nach intern auf 4443 (oder einen anderen konfigurierten Port) umleitet. Idealerweise ist dies ein HTTP-Reverse Proxy, wie er schon für die Veröffentlichung von OWA oft zum Einsatz kommt. Der Server, auf dem der Client "auftrifft", muss natürlich ein gültiges Zertifikat für diesen Namen vorweisen können.
Wer einen Enterprise Pool betreibt, muss sich auch über die Lastverteilung der Zugriffe auf die Frontendserver des Pools Gedanken machen. Hier ist ein Loadbalancer erforderlich.
IIS Konfiguration
Ausgehend von den Einstellungen in der Topologie richtet das Lync Setup auf dem jeweiligen Server die virtuellen Verzeichnisse im IIS ein. Die Standardwebseite wird dabei nicht entfernt aber einfach gestoppt. Zusätzlich gibt es die beiden Webseiten
- Lync Server Internal Web
Site
Diese nimmt Verbindungen auf Port 80/443 von internen Clients an und sollte so nicht aus dem Internet erreichbar sein. - Lync Server External Web
Site
Diese eigene IIS-Webseite ist für die Veröffentlichung in das Internet vorgesehen. Allerdings lauscht diese erst mal nur auf Port 8080 und 4443. Sie müssen also bei der Veröffentlichung von Extern die Ports über einen ReverseProxy oder NAT umdrehen. Auch wenn die Separierung in eine Webseite einen besseren Schutz bietet, so sollten Sie dennoch besser einen ReverseProxy zur Publizierung einsetzen. Wenn sie sogar einen Lync-Pool betreiben, dann müssen Sie sowieso eine Verteilung der Zugriffe vornehmen.
Genau genommen hätte Microsoft die Funktion der beiden Webseiten auch einfach in einer Webseite verschmelzen können und dem Administrator einfach ins Pflichtenheft schreiben, dass er die Dienste "sicher" veröffentlichen muss. Nun kenne wir alle die Begeisterung, Dokumentationen zu lesen. So zwingt Microsoft sicher den ein oder anderen Admin zum Nachdenken, wie er die Dienste veröffentlichen kann.
Es ist übrigens durchaus möglich, die Ports im Topology Builder zu ändern. genau könnten Sie den Server mit zwei Netzwerkkarten versehen und die Webseite auf die IP-Adresse binden, von denen eine Karte "nach außen" verweist. Trotzdem sollten Sie sich natürlich über die Absicherung ihres Servers Gedanken machen und die Sparsamkeit nicht übertreiben.
Schauen wir uns die virtuellen Verzeichnisse mal genauer an, dann sehen Sie im linken baumdiagramm aufgeklappt die Struktur der "External Website und rechts die Details der "Internal Website".
Durch diese Gegenüberstellung können Sie auch schnell erkennen, welche virtuellen Verzeichnisse nur intern vorhanden sind. So fehlt extern natürlich das "CSCP-Verzeichnis" und "Location Information". Auch die "OCSPowerShell" ist nur von intern zu erreichen.
Die Web Dienste im Einzelnen
Auch wenn in den hier mit aufgezeigten TMG-Traces als User "anonymous" steht, so bedeutet dies nicht, dass die URLs auch für jeden erreichbar sind. Lync nutzt intern die Authentifizierung mit Zertifikaten, die aber vom TMG nicht gesehen wird.
Virtuelles Verzeichnis |
seit Lync Version |
Web | Funktion |
---|---|---|---|
ABS |
2010RTM |
extern |
Über diese URL wird das Adressbuch bereit gestellt, welches sich dann die Clients herunterladen. Auch Photos werden so bereit gestellt.
|
CertProv |
2010RTM |
extern |
Dieser Webservice stellt nach einer Anmeldung die Zertifikate für den Client bereit. In der Folge kann sich der Client dann direkt mit dem "Zertifikat" anmelden. |
CollabContent |
2010RTM |
extern |
|
cscp |
2010RTM |
intern |
Das Communication Server Control Panel stellt die bekannte Administrationsoberfläche basierend auf Silverlight bereit und sollte nicht ohne Not von "extern" erreichbar sein. |
DataColabWeb |
2010RTM |
Extern |
WebService für Data Collaboration, z.B. Um Powerpoint bei Lync 2013 hoch zu laden.
|
Dialin |
2010RTM |
extern |
Für den
Betrieb der
SimpleURL ist "dialin"
erforderlich.
Sie sehen, dass
dies keine
eigene Webseite
ist. Bei der
Veröffentlichung
sollten Sie also
darauf achten,
dass der gleiche
Listener im
Zertifikatnamen
auch die
Hostnamen der
SimpleURLs
enthält. |
Fonts |
2010RTM |
extern |
|
GroupExpansion |
2010RTM |
extern |
Dieser Webservice löst die Gruppenmitgliedschaften auf. Immer wenn Sie also eine Gruppe addresieren oder in der Karteikarte sich die Mitglieder einer Gruppe oder Mitgliedschaften eines Benutzers anzeigen lassen, greift der Lync Communicator hierauf zu.
|
HybridConfig |
2013 |
extern |
|
LMStaticData |
2010RTM |
extern |
LiveMeeting Static Data ? |
LocationInformation |
2010RTM |
intern |
Über diesen Webservice kann ein Client, sofern er intern ist, seinen Standort ermitteln und dann im SIP-Paket auch weiter melden. Diese Funktion ist in den USA für die E-911 Nutzung erforderlich. Aber auch sonst kann diese Information z.B.: den "Ort" im Communicator automatisch aktualisieren. |
lwa |
2013RTM |
|
|
mcx |
2010 CU4 |
Extern |
Das Verzeichnis MCX wird von den mobilen Clients genutzt, die per HTTPS so ihre Daten abrufen.
|
meet |
2010RTM |
extern |
Für den Betrieb der SimpleURL ist "meet" erforderlich. Sie sehen, dass dies keine eigene Webseite ist. Bei der Veröffentlichung sollten Sie also darauf achten, dass der gleiche Listener im Zertifikatnamen auch die Hostnamen der SimpleURLs enthält. |
MeetingContent |
2010RTM |
extern |
|
MeetingFiles |
2010RTM |
extern |
|
PassiveAuth |
2013RTM |
|
|
PersistentChat |
2013RTM |
|
|
OCSPowerShell |
2010RTM |
intern |
Hier zeigt sich noch der Name "OCS", der Vorgänge von Lync. Über den Weg können Sie Lync "remote" verwalten. Dieses Verzeichnis sollte normal nicht extern erreichbar sein. |
Reach |
2010RTM |
extern |
|
RequesthanderExt |
2010RTM |
extern |
|
RgsClients |
2010RTM |
extern |
Webservice um den Status der Responsegroup zu erkennen.
|
RgsConfig |
2010RTM |
intern |
Hier hinter verbirgt sich die Webseite, mit der Sie die Response Groups verwalten können. Zwar hat Lync einige Einstellungen in die GUI gebracht, aber die Workflows sind weiterhin eine Webseite |
Scheduler |
2013RTM |
Extern |
Web Scheduler |
UCWA |
2013RTM |
Extern |
Unified Communication Web API |
Webtickets |
2010RTM |
extern |
Auch die Webdienste nutzen nur kurzfristig eine Anmeldung mit Benutzername und Kennwort bzw. Zertifikat. Dieser Webservice stellt für die Anwender kurzfristige "Tickets" aus, die in nachfolgenden Anfragen im HTTP-Header mit übertragen werden und damit eine weitere immer wiederholte Anmeldung vermeiden. Quasi "Sessionkeys".
|
EWS |
Exchange |
Extern |
Die Bereitstellung von Exchange Webservices ist keine originäre Lync Aufgabe sondern Exchange. Aber der Lync Client nutzt natürlich EWS und wenn Sie einen Trace auf den Client machen, dann sehen Sie auch solche Anfragen
|
Hier nicht
Port 80 ?
Nun könnten Sie ja sagen, dass alles per SSL abgesichert wird und damit der Port 80 oder 8080 gar nicht erforderlich wäre. Dem ist aber nicht so, wie ein schneller Blick in die IISLogs einer aktiven Lync-Installation zeigt:
POST /CertProv/CertProvisioningService.svc/anon - 80 - 10.1.1.3 OCPhone/4.0.7576.0+(Microsoft+Lync+2010+Phone+Edition) GET /RequestHandler/Files/UCPhone/AASTRA/6725ip/A/ENU/4.0.7577.250/CPE/CPE.cat - 80 - 10.1.1.3 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457) GET /lyncweb - 80 - 10.1.1.2 Mozilla/4.0+(compatible;+MSIE+7.0) OPTIONS /Ansagen/03_Warteschleife_mono.wma - 80 - 10.1.1.2 Microsoft-WebDAV-MiniRedir/6.1.7601 200 0 0 5 GET /cscp - 80 - 10.1.1.2 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) 403 4 5 215
Mal abgesehen von der Anfrage nach "Ansagen", was ein Zugriff eines Clients auf eine in den Gruppenrichtlinien hinterlegten WMA-Datei sind sind die beiden ersten Request ein wichtiger Aspekt. Die Lync Phones laden über HTTP bei der ersten Verbindung die Liste der Stammzertifikate herunter. Das ist insbesondere dann wichtig, wenn Sie eine interne Zertifizierungsstelle betreiben und die internen Zertifikate entsprechend "privat" sind.
Und dann sieht man hier auch noch, dass ein Aastra-Telefon auch ohne HTTPS eine Anfrage nach der Firmware-Version stellt.
Eine Änderung dieser Konfiguration ist immer nur temporär, da ein "Publish Topology" mit einem "Enable-CSComputer" die aus Sicht von Lync richtigen Einstellungen wieder einträgt. Vergessen Sie es also, diesen IIS zu "verbessern" oder andere Aufgaben bereit stellen zu lassen.
Es ist schon komisch. Früher
gab es auch schon PCs im Umfeld von
Telefonanlagen, primär für Call Control,
Adressbücher etc. Und ich habe viele Umgebungen
gesehen, wo diese "TK-Systeme" nicht gesichert
waren, d.h. kein Virenscanner, keine Updates und
nicht mal die Standardkennworte wurden geändert. Und diese Systeme standen natürlich im LAN.
Nun kommt Lync und es gibt nicht wenige
Administratoren, die nun auch die Server
"härten" wollen und sich daran stören, dass da
ein IIS auf den Standardport hört.
Ein IIS ist ein Webserver und Webdienste werden
von Clients genutzt. Sicherheit erreicht man
nicht durch die Verwendung von "nicht Standard
Ports" sondern durch sichere Kennworte, passende
Firewalls und Intrusion Detection Systemen.
Windows 2008 ist von Hause aus deutlich besser
abgesichert als alte Windows Server und schon
der Ansatz zwei eigene virtuelle Webseiten
aufzubauen um allen Diensten den Wind aus den
Segeln zu nehmen, die sich ungefragt in die
"Default Web Site" installieren, sollte ihnen
schon zeigen, dass Lync einen hohen Anspruch an
die Lösung hat.
SSL und Offloading
Da der Einsatz von NLB auf Lync Frontend Servern nicht sinnvoll möglich ist und Microsoft für die Veröffentlichung der Webdienste eines Enterprise Pools sowieso LoadBalancer vorschreibt, müssen Sie diese Dienste über gesonderte Hardware "veröffentlichen".
Die Webdienste nutzen aber SSL und einige Loadbalancer bieten eine SSL-Acceleration oder SSL-Offloading an. Dies kann genutzt werden. Allerdings ist auf dem Lync Webdiensten eine Umleitung von Zugriffen auf Port 80 nach 443 eingerichtet. Das bedeutet aber auch, dass ein Loadbalancer nicht wirklich mit SSL-Offloading arbeiten kann. Er kann natürlich die SSL-Verbindung aufbrechen, um z.B. Anhand von Cookies die Sessions zu erkennen aber er muss auch zum Backend (also Lync Server) wieder mit SSL weiter arbeiten, da ein umsetzen der Zugriffe von Extern Port 443 auf intern 80 einen "Redirect" auslösen würde.
Versuchen Sie nicht diese SSL-Umleitung im IIS außer Kraft zu setzen. Zum einen würde der LyncPBA dies anmeckern. Spätestens bei der nächten Änderung der Topologie würden diese Einstellungen aber wieder zurück gestellt.
- Microsoft Unified Communications Load Balancer
Deployment
http://technet.microsoft.com/en-us/office/ocs/cc843611.aspx - Lync 2010 Planning Ports and Protocols für Internal
Servers
http://technet.microsoft.com/en-us/library/gg398833.aspx - Load Balancing Requirements
http://technet.microsoft.com/en-us/library/gg615011.aspx - Introducing DNS Load Balancing in Lync Server 2010
http://technet.microsoft.com/en-us/library/ff755052.aspx - Issue when Moving Legacy Users to a Lync Server 2010 Pool using HLB
http://blogs.technet.com/b/dodeitte/archive/2010/12/19/issue-when-moving-legacy-Users-to-a-lync-server-2010-pool-using-hlb.aspx
Kerberos
Wer nur einen einzelnen Standard Server mit einer überschaubaren Anzahl an Anwendern betreibt, muss sich um die Anmeldung per Kerberos keine größeren Gedanken machen. Der Zugriff auf die Webseite erfolgt intern normalerweise über den Poolnamen, der zum Servernamen identisch ist und so können die Clients auch den SPN finden.
Wer aber einen Frontendpool mit einem Poolnamen betreibt, muss wissen dass sich hier die Clients erst mal nur mit NTLM anmelden können, was auf anderer Seite wieder Probleme mit sich bringt (Ressourcenbedarf auf DCs zur Überprüfung der Anmeldedaten). Daher kann es für größere Installationen durchaus relevant sein, die Anmeldung per Kerberos auf den Webservices zu aktivieren. Dies gilt um so mehr, wenn eine Firewall eine Preauthentication macht und sie mit Constraint Delegation arbeiten können.
Die Konfiguration ist wie bei Exchange und anderen Webdiensten vergleichbar. Die Anwendungen auf den verschiedenen Servern müssen mit einem Dienstkonto laufen, zu welchem der passende SPN im Active Directory hinterlegt wird
- Setting up Kerberos
Authentication
http://technet.microsoft.com/en-us/library/gg398976.aspx - Kerberos
- Constraint Delegation
- SPN
Internet und Reverse Proxy
Die externen Lync Webdienste sind auf dem Lync Server über 8080/4443 erreichbar. Das ist natürlich nicht der Port, unter dem externe Clients den Dienst erwarten. Daher ist eine Umsetzung von 80/443 auf 8080/4443 erforderlich. In sehr kleinen Umgebungen wird das vielleicht ein NAT-Router machen. Die meisten Firmen veröffentlichen aber ihre Webservices und Webseiten in so einem Fall über einen Reverse Proxy.
Die Lync Web Dienste müssen immer dann aus dem Internet erreichbar sein, wenn Clients oder Meeting-Teilnehmer aus dem Internet ohne VPN mit ihrer Umgebung kommunizieren müssen. Das ist fast immer der Fall, da Meetings mit Browsern oder mobile Clients heute zum Standard gehören. Da jeder Anwender aber immer mit "seinem HomeServer" kommuniziert, muss natürlich auch jeder Lync Pool, Standard-Server und Director-Server mit einem eigenen externen DNS-Namen versehen und im Internet veröffentlicht werden.
We recommend that you
configure your HTTP reverse proxy to publish all
Web Services in all pools. Publishing https://
ExternalFQDN/* publishes all IIS virtual
directories für a pool. You need one publishing
rule für each Standard Edition server, Front End
pool, or Director or Director pool in your
organization. In addition, you need to publish
the simple URLs. If the organization has a
Director or Director pool, the HTTP reverse
proxy listens für HTTP/HTTPS requests to the
simple URLs and proxies them to the external Web
Services virtual directory on the Director or
Director pool. If you have not deployed a
Director, you need to designate one pool to
handle requests to the simple URLs. (If this is
not the User’s home pool, it will redirect them
onward to the Web Services on the User’s home
pool). The simple URLs can be handled by a
dedicated web publishing rule, or you can add it
to the public names of the web publishing rule für the Director. You also need to publish the
external Autodiscover Service URL.
Quelle: Setting up reverse proxy servers für Lync Server 2013
https://technet.microsoft.com/en-us/library/gg398069.aspx
Leider hat Microsoft sich dagegen entschieden, den TMG2010 weiter zu betreiben, so dass andere ReverseProxy-Systeme hier zum Einsatz kommen. Hierbei sind einige Dinge zu beachten, von denen es eigentlich keine Abstufung nach Wichtigkeit gibt
- Timeout
Der Einsatz von mobilen Clients macht es erforderlich, dass TCP-Sessions nicht nach vielleicht 120 Sekunden schon abgebrochen werden, sondern deutlich länger bestehen bleiben. Wenn ein Proxy oder eine Firewall die Verbindung vorschnell kappt, können Clients mit Fehlern reagieren, z.B. dass der mobile Lync Client neu gestartet werden muss - Authentifizierung
der Zugang zu Lync Web erfolgt entweder anonym (z.B. DialIn/Meet) oder durch eine Software. Damit fallen formularbasierte Anmeldungen oder Multi-Faktor Anmeldungen mit Einmaltokens raus. Der Zugang darf keine "Preauthentication" erwarten sondern muss die Authentication Header durchreichen - Offloading und Verteilung
Wenn als Backend mehrere Lync Server die Dienste bereitstellen, dann wird oft der Reverse Proxy auch zum Verteilen der Anfragen genutzt. In dem Falle muss der Reverse Proxy die SSL-Verbindung aufbrechen um anhand der Anmeldedaten , Cookies o.ä. den Client eindeutig zu identifizieren und das Paket zum gleichen Backend weiterleiten zu können
Die entsprechende Konfiguration ist je nach Reverse Proxy individuell. Viele Firmen nutzen interessanterweise Apache als Reverse Proxy. Hier ein Ausschnitt einer Konfiguration:
ProxyRequests Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyReceiveBufferSize 4096 ProxyPass / https://lync.domain.com:4443/ retry=1 acquire=3000 timeout=600 keepalive=On ProxyPassReverse / https://lync.domain.com:4443/ ProxyPreserveHost On
Hier ist zu sehen, dass die Anfragen auf den Port 4443 intern weiter gegeben werden und der Timeout 600 Sekunden beträgt.
- Using IIS ARR as a Reverse
Proxy für Lync Server 2013
http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx - Lync 2013 Mobile Clients and
Apache Reverse Proxy
http://www.confusedamused.com/notebook/lync-2013-mobile-clients-and-apache-reverse-proxy/ - Lync 2013 Mobility published
on IIS ARR - Your server
configuration has changed.
Please restart Lync
http://www.lynced.com.au/2013/08/lync-2013-mobility-published-on-iis-arr.html - Configuring PfSense as a
Reverse Proxy für Lync Web
Services
http://blogs.technet.com/b/nexthop/archive/2014/04/07/configuring-pfsense-as-a-reverse-proxy-for-lync-web-services.aspx
Reverse Proxy und Deep Inspection (Sophos)
Gerade die "Intelligenz" von solchen Reverse Proxy Systemen kann auch zu sehr schwer zu findenden Effekten kommen. Bei Net at Work hatten wir den Fall, dass genau eine Person von einem Windows 8 Phone nicht den Lync Mobile Client nutzen konnte. Interessanterweise konnten anderen Personen problemlos arbeiten. Selbst auf einem anderen Telefon konnte der Anwender wieder arbeiten, so dass wir zuerst das Telefon im Verdacht hatten. Der Fehler äußerte sich wie folgt.
Mit dem CLSLogging erscheint ein
UCWA,Helper.ValidateEtagPrecondition:helper.cs(1386))Failing operation because precondition was not met. currentEtag: 1123784134, expectedEtag: 1123784134-gzip
Auf dem Smartphone kam folgender Fehler
Als wir dann aber auf der Firewall etwas ausführlicher die Logs inspiziert haben, konnten wie sehen, dass die Firewall die Requests als SQL-Injection-Angriff gewertet hat
Allerdings wurden ganz verschiedene Muster getriggert. Erst also wir dann auf diesem Service die SQL-Prüfungen entfernt haben, war auch die Problem bei dem Client gelöst.
Fehlersuche
Es handelt sich ganz einfach um einen IIS. Insofern ist die erste Anlaufstelle natürlich das IISLog, welches jeden Request beinhaltet. Hier sehen Sie meist die Clients, ihre Anfragen und auch den Benutzer, zumindest sofern er sich erfolgreich anmelden konnte.
Sie können aber auch mit einem Browser den ein oder anderen Test einfach durchführen. Dabei gibt es drei Stellen zum Testen
- Intern gegen die interne
Webseite
Das muss problemlos funktionieren, damit interne Clients arbeiten - Intern gegen die Externe
Webseite
Diese Anfragen werden so normal nicht benötigt. Sie sind aber ein test um die Erreichbarkeit der "external Websites" zu überprüfen und hier Probleme zu erkennen.
Hinweis: Einige URLs machen einen Redirekt auf den Hostnamen der ExternalURL. Der Trace zeigt aber schon, dass eine Verbindung möglich war - Extern gegen die Externe
Webseite
Dies ist dann von extern auf jede Lync Installation, zu der man die ExternalURLs kennt, möglich. Sie hilft bei der Fehlersuche beim ReverseProxy und Firewall
Folgende URLs nutze ich gerne, wobei diese natürlich abhängig von ihrem Namenskonzept für die SimpleURL zu sehen sind.
Host | URL | Ergebnis | Status |
---|---|---|---|
https://<lyncweb> |
/dialin |
Hier sollte der Lync Server ohne Anmeldung die Konferenznummern anzeigen. Beim Zugriff |
|
https://<lyncweb> |
/Dialin/Conference.aspx |
Beim Zugriff
von extern
leitet Lync auf
eine andere
Seite um |
|
https://<lyncweb> |
webticket/webticketservice.svc/mex |
Liefert die Webservice-Definition für den WebTicketTest |
|
Bei Lync 2013 sind auch die Office Web Components für Zugriffe relevant
Weitere Links
- Lync Share
- SimpleURL
- LyncZertifikate
- LoadBalancer
- How Lync Clients Connect to
Lync Server 2010
http://www.infotechguyz.com/lync2010/HowLyncclientsconnecttoLyncserver2010.html - Publishing Lync Director Web
Services
http://blog.schertz.name/2011/03/publishing-lync-director-web-services/ - Lync External Web Services
without Reverse Proxy
http://ucken.blogspot.com/2011/01/lync-external-web-services-without.html - Kerberos and Microsoft Lync
Server 2010 Web Services
http://blogs.technet.com/b/jenstr/archive/2010/09/23/kerberos-and-microsoft-lync-server-2010-web-services.aspx - Enabling Kerberos
Authentication für Lync Server
2010 Web Services
http://www.technotesblog.com/2011/05/20/enabling-kerberos-authentication-for-lync-server-2010-web-services/ - Publish Microsoft Lync
Server 2010 Web Services and
Simple URLS through ISA Server
2006
http://cmcgreanor.wordpress.com/2010/10/06/publish-microsoft-lync-server-2010-web-services-and-simple-URLs-through-isa-server-2006/ - Publishing Lync web services
http://technet.microsoft.com/en-us/library/hh490317.aspx - Publishing Lync with Forefront TMG
Part 1 - Covers the initial configuration of Forefront TMG
Part 2 - Publishing Lync Web Services with Forefront TMG
Part 3 - Creating the protocols needed für publishing Lync Edge server
Part 4 - Publishing Lync Edge server with Forefront TMG
Part 5 - Installing Lync Front End and Lync Edge - Using IIS ARR as a Reverse
Proxy für Lync Server 2013
http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx - IIS ARR as Reverse Proxy für Lync 2013
http://trogjels.wordpress.com/2013/08/09/iis-arr-as-reverse-proxy-for-lync-2013/ - Lync 2013 Mobile Clients and
Apache Reverse Proxy
http://www.confusedamused.com/notebook/lync-2013-mobile-clients-and-apache-reverse-proxy/