Wer Lync 2013 auf DirectAccess Clients über den/die “normalen” Internet-facing Lync Edge Server fahren will (was bei Audio/Video/Sprache angesagt ist weil sonst alles doppelt verschlüsselt wird und Jitter, Lags & Co. ausufern) muss die ganzen URLs (sip, dialin, meet, webcon, av, discover, _sip._tls, _sip._internaltls) in der DirectAccess Konfiguration aus dem Tunnel ausschließen – das ist bekannt und wohl dokumentiert (auch wenn die Fülle an Namen schon Potential für spaßige Effekte hat).

Eher unbekannt sind aber 2 zusätzliche Tatsachen:

1) Lync-Discovery fährt über HTTPS auf lyncdiscover.mydomain.com und je nach Proxyconfig geht das im DA-Umfeld über den Proxy. Ich habe auch gesehen dass Lync Client irgendwo ins Internet hin will (irgend eine 23er Adresse) und da natürlich über Proxy gehen will/muss.

2) TMG liefert per default (in einer single Node Config) bei http://myproxy.mydomain.com/array.dll?Get.Routing.Script) in der MakeProxies() Funktion die IPv4 Adresse des TMG Hosts aus.

Diese zwei Umstände führen dazu dass der Lync-Client über die IPv4 Adresse des Proxies auf Lync-Discovery machen will und daran scheitert – die Effekte sind je nach weiterer Lync- und DA-Konfiguration ebenso manigfaltig wie spannend (und unter Garantie zeigt keiner davon in die richtige Richtung).

Also: Script aus TMG holen, ändern, wo anders speichern (Webserver) und Browser manuell oder via Policy dorthin schielen lassen und schon macht der Lync Client auch das was er soll.