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.
0 kommentar(er)
