This happens because by default both the Internal Mcx service and External Mcx service URLs are set to the same value: the external web services FQDN. Regardless of which DNS records are populated (lyncdiscover, lyncdiscoverinternal) or where they point to (Front End server, Reverse Proxy) all mobile clients would still be redirected toward the external web services to sign-in. Mobile clients can be directed to either the internal or the external Autodiscover service.The following statements outline the key behaviors and practices used in Lync 2010 Mobility. Most important of these was related to how internally connected mobile clients would be directed to the Mcx service to sign-in to Lync.
This approach further cemented the importance of a reverse proxy solution in the Lync deployment as publishing the external web services was now a requirement if external mobility client connectivity was desired.Īfter a fair amount of deployments were leveraging this new functionality and the behavior was generally understood a number of new practices were sifted out from the results. Sure the Edge server still played a role in the overall mobility story in terms of handling features like Push Notifications, but for the basic client-to-server communications the web services were handling the entire workload. This approach provided for a lighter client which was not heavy on SIP chatter and battery usage. These clients were completely serviced by a new web service called Mcx. What was most unique about these new clients was that they were not SIP clients like the others, thus were the first Lync client to not utilize the SIP registrar services located on either Front End, Director, or Edge servers. The Autodiscover service was created to allow these clients to easily locate a Lync server using only a SIP URI and connecting from any network. Lync 2010 BehaviorĪs mentioned Lync Server 2010 received two new web services to handle the new mobile clients provided across Apple, Android, Windows, and other mobile device platforms. This forced a change in the previous best practices as not all client could be treated the same.
No longer was the Autodiscover service only handling connections from mobile device clients, but now also Windows clients. This brought some important changes to the mobility story which also blurred the lines a bit between these clients and the standard desktop clients as mentioned above. With the later release of Lync Server 2013 the new Windows clients would also leverage this service, which was explored in the previous article Lync 2013 Client Autodiscover. Initially there was much confusion in the field regarding both the behavior and intended design of these new services, but eventually a few important items came to be understood and some best practices arose to assist in designs and deployment. This included a new Autodiscover service which paved the way for an entirely new approach that future Lync clients would leverage to automatically locate servers, starting with the mobility clients in Lync 2010. In fact a pair of services were added to both of the separate internal and external web sites in IIS which were covered in detail in the previous article Deploying the Lync 2010 Mobility Service.
Backgroundīack in Cumulative Update 4 of Lync Server 2010 Microsoft introduced an entirely new web service to the Front End server role. But what is important to understand is that this is achieved by completely different methods between 20 mobility clients.
This article will explain and demonstrate how both Lync 20 mobility clients are designed to be redirected out to a reverse proxy in most deployments by forcing the use of the External Web Services FQDN. The Microsoft TechNet documentation covering Technical Requirement for Mobility includes a statement explaining that “all mobility service traffic goes through the reverse proxy, regardless of where the origination point is” but does not explain exactly how this is achieved.