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.

This article will explain and demonstrate how both Lync 2010 and 2013 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.  But what is important to understand is that this is achieved by completely different methods between 2010 and 2013 mobility clients.

Background

Back in Cumulative Update 4 of Lync Server 2010 Microsoft introduced an entirely new web service to the Front End server role.  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.  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.

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.

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.  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.  No longer was the Autodiscover service only handling connections from mobile device clients, but now also Windows clients.  This forced a change in the previous best practices as not all client could be treated the same.

Lync 2010 Behavior

As 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.  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.  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.   These clients were completely serviced by a new web service called Mcx.  This approach provided for a lighter client which was not heavy on SIP chatter and battery usage.  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 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.

After 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.  Most important of these was related to how internally connected mobile clients would be directed to the Mcx service to sign-in to Lync.  The following statements outline the key behaviors and practices used in Lync 2010 Mobility.

• Mobile clients can be directed to either the internal or the external Autodiscover service.  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.  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.  In the event that Lync Server 2010 only needs to support internal mobility clients and there is no external connectivity then the Set-CsMcxConfiguration cmdlet should be issued on the Lync servers with the ExposedWebUrl parameter set to Internal.  This would result in both the internal and external URLs using the internal web services FQDN.

• Either the Internal Mcx service and External Mcx service can support 2010 mobility client connections, but not at the same time.  As will be shown towards the end of this article the internal and external Mcx FQDNs will always be set to the same value, either the internal or external FQDN depending on the state of the ExposedWebUrl parameter.  Mobile clients cannot be allowed to use either service as the Mcx services on Front End servers do not talk to each other and cannot coordinate connection state for a device which might move between an external network (e.g. 4G cellular data) and an internal network (e.g. corporate Wi-Fi).  Thus all mobile clients in an environment must be directed to either the internal web service or the external web service.  In any typical deployment with external Lync connectivity the external Mcx web service will handle all connections and the internal Mcx web service would never be used.

The fact that internally-connected mobile clients would by default be passed the external web services URL then this would create the ‘hair-pinning’ traffic scenario which was the topic of so much discussion when introduced.  Deployments needed to be configured to allow and support this type of traffic from internal clients to reach the external interface of a reverse proxy server and travel back into the Front End servers.

But before the registration process could occur the mobile client would need to be redirected to the Mcx URL by first connecting to the Autodiscover service.  But due to the complexities of dealing with HTTPS connections and the potential headaches of managing private internal root certificates on a multitude of mobile devices in the organization, most of which are personal devices, a general best practice arose to simply point any internal mobile clients directly to the reverse proxy for even the initial autodiscover attempt.  This was typically done by configuring one or both of the lyncdiscover or lyncdiscoverinternal DNS host records located on internal DNS zones to point directly to the external IP address of the reverse proxy.  This approach simplified the configuration by treating all mobility clients as external clients regardless of their location. This also insured that all of these clients would able to connect via HTTPS across the board as a trusted third party certificate would be in place on the reverse proxy.  In a Lync 2010-only world this workaround was fine as only the mobility clients leveraged the autodiscover service, so nothing else was impacted.

Unfortunately for any environments configured with this work-around then the introduction of the Windows Lync 2013 client would result in an undesirable communication path.

Lync 2013 Behavior

In Lync 2013 both the standard Windows and Windows Store applications begin to leverage the Autodiscover service and will perform the same autodiscover steps as the mobility clients first, even before the now ‘legacy’ SRV/Host record lookup process.  What this means in the scenario where all autodiscover requests are pointed externally is that all internal Lync 2013 Windows clients (which is typically the critical mass of deployed users) could also be forced outside and be registering to an Edge server and hair-pinning all traffic.  This is certainly a less than ideal configuration.

As this behavior became known in Lync 2013 then it was evident that the autodiscover service first provided in Lync 2010 was not meant solely for mobility clients, but eventually for all Lync clients.  This means that the proper configuration of autodiscover DNS records was now imperative for a healthy Lync environment.

• In the internal DNS zones for the SIP domain namespace a single lyncdiscoverinternal.<sipdomain> host record should be created which points to either a Lync Front End or Director server or pool.

• In the external DNS zones for the same SIP domain namespaces a single lyncdiscover.<sipdomain> host record should be created which points to a reverse proxy server which has published the external web service ports from the internal server(s).

This simple approach will insure that internally connected clients are treated as ‘inside’ and externally connected clients are categorized as ‘outside’.  What is important to understand here is that not all Lync clients will behave the same way given this configuration, which introduces the primary topic of this article: the behavior of the Lync 2013 mobility client.

In Lync Server 2013 a new web service was introduced which plays a major part in this story: the UCWA web service.  The Lync Unified Communications Web API (UCWA) service was created to aid third-party developers with an API platform for using with customized application.  Microsoft also optimized this service for mobility applications and thus the Lync 2013 Mobility clients are programmed to use this new web service, and no do not utilize the previous Mcx web service.  Note that the Mcx web service is still included and operational on Lync 2013 servers for backward compatibility with Lync 2010 mobile clients (with the same behavior as described in this article for 2010 servers), but the 2013 mobility clients will only leverage the UCWA web service.

The following example screenshots show the list of internal and external web services provided on a Standard Edition Lync 2013 Front End server.

The functionality of this new UCWA web service differs from the Mcx service as that was solely designed for the 2010 mobility clients while the UCWA service can be used by more than just the 2013 mobility clients; third party applications can be written to leverage this service.  Additionally the new UCWA service improves over limitations in the Mcx service by removing the requirement for cookie-based affinity on a load balancer

Client Behavior Comparison

Most importantly the programmed client behavior differs between 2010 and 2013 mobility clients in one key area.  Although they both will receive the same list of service URLs from the Lync Server the 2010 client has the ability to choose from either Mcx URL while the 2013 client is in essence dumb and only leverages a single URL.

In order to illustrate this behavior the response from the Lync autodiscover service can be viewed in any Lync Server environment by downloading and running the Microsoft Lync Connectivity Analyzer tool.

• Launch the Microsoft Lync Connectivity Analyzer tool and then enter the SIP URI and password of a Lync-enabled user in the desired environment.  Select the appropriate Network access location and select Lync mobile apps to test those specific requirement.

• Allow the tool to complete all tests and then select All Results from the Show menu.

The results pane should display at least one occurrence of results from a mixture of unencrypted and encrypted connections to both internal and external servers.  The provided parameters are used by different Lync clients to locate various services for SIP registrations, mobility access, Web Scheduler information, client certificate provisioning, etc.

In these results three unique FQDNs are provided which are resolve to three different systems.

• Internal Lync 2013 Front End Server FQDN: lync.schertz.name

• External Lync 2013 Access Edge Server: sip.mslync.net

• External TMG Reverse Proxy Server: lyncwebext.mslync.net

Lync 2010 Mobile Client

The Lync 2010 clients will look at both the Internal MCX service and External MCX service parameters and the client will select the URL that matches the associated location.  So if the mobile client is identified as connecting to Lync either from an internal or external network it will use the appropriate URL to contact the server and sign-in.

The key here is that the Lync 2010 (or Lync 2013) server has defined both of those parameters as the same exact value, so in the end the client really has no choice.

Internal MCX service : https://lyncwebext.mslync.net/Mcx/McxService.svc
External MCX service : https://lyncwebext.mslync.net/Mcx/McxService.svc

Note that because both of these URLs are identical then 2010 mobile clients are forced to use (in this example) the external web service regardless if their network location.

Lync 2013 Mobile Client

On the surface it would be logical to assume that the Lync 2013 clients, which leverage UCWA, will instead utilize the following parameters.

Internal UCWA service : https://lync.schertz.name/ucwa/v1/applications
External UCWA service : https://lyncwebext.mslync.net/ucwa/v1/applications

Unfortunately that would be an incorrect assumption. These parameters are not currently used by the 2013 mobility clients and are reserved for future use, or for third-party applications to leverage.  Notice that the internal URL is using the internal web services FQDN while the external URL is pointing to the external web service FQDN.  This configuration allows for an application to select the appropriate URL for its location, if desired.

What the Lync 2013 mobility clients actually use to connect to the server and sign-in is a third UCWA parameter simply entitled ‘Ucwa’ which was included specifically for these 2013 clients.  This parameter is set to always use the external web services FQDN.

• In order to see this additional parameter in the analyzer tool change the results view to Detailed Information and look then for the Autodiscover response which includes all of the service URLs.  The Ucwa URL should be located adjacent to the two other internal and external Ucwa parameters.

<Link token=”Ucwa” href=”https://lyncwebext.mslync.net/ucwa/v1/applications“ />

<Link token=”Internal/Ucwa” href=https://lync.schertz.name/ucwa/v1/applications />

<Link token=”External/Ucwa” href=”https://lyncwebext.mslync.net/ucwa/v1/applications“ />

Although the 2013 mobility clients are using a separate dedicated Ucwa parameter the URL is the same web services location as provided by the External/Ucwa parameter.

In summary the Lync 2010 mobile clients are basically ‘tricked’ by the server into all registering to the external services regardless of their network location.  But by comparison all Lync 2013 mobile clients are hardcoded to look for a unique parameter which always pushes them to the external services.