-> external IP address fo the external web services published by a reverse proxy. Note: Will not work for Lync mobile one WP8, you need to publish -> external IP address fo the external web services published by a reverse proxy. -> STD edition server IP or HLB HTTPS IP if it is Enterprise Edition. Internallyncdiscover record forautodiscover of Lync services. -> STD edition server IP or HLB HTTPS IP if it is Enterprise Edition. Consolidated simpleurlfor meet,dialin, scheduling and admin. -> Internal Front End server IP address or servers if it is a DNS LB Enterprise Pool. However, the mobile clients does not need to trust your internal CA, they will get their external sign in location without certificate issues. 
local type domain, then you must use internal PKI to issue the certificates Recommendation is to use public certificates on internal servers, unless you have a.Like sipdomain.local internally and externally.This applies to disparate scenarios where youhave a different domain internally than externally.It is more expensive because you need more SAN names in the certificate, but unmanaged clients with the Lync desktop client, Windows Store App and the Windows Phone Lync mobile clients will just work.Recommendation is to use public sertificates on internal servers.
This applies to split-brain DNS scenarios where you have the same domain internally and externally. This article does not talk much about external DNS records since they are the same as for Lync 2010, mostly. I will start with the conclusion, and then continue with some background information and finish with some test results. I have spent a couple of days trying to figure out the most restrictive way to DNS records where all clients work and here is my recommendation regarding internal DNS records and where the clients should sign in from. The Lync 2013 clients uses lyncdiscover to find the pools and url’s they need to sign in to.
0 kommentar(er)
