A good place to start understanding how the Mobility Service works is here: http://technet.microsoft.com/en-us/library/hh690030.aspx. Most of the steps are already provided in Technet but I find that many of the key essential must-do's are scattered in various pages rather than being consolidated in a single location. Hence, this article serves as a companion to the Technet documentation and is intended for anyone who is encountering difficulty in successfully getting the Mobility service to work. It will also be useful in case I ever need to deploy the Mobility Service again in a different environment and do not wish to spend time to troubleshoot the commonly encountered issues. The diagram below reproduced from Technet is very helpful to understand the how the mobility service works:
Tip#1: Lync Internal and External AutoDiscover DNS records
During Automatic Discovery, mobile devices will first use DNS lookup to the internal DNS record lyncdiscoverinternal.<internal domain>. If not found, it means that the client is on an external network and will then lookup the external DNS record lyncdiscover.<sipdomain>. A mobile device that is internal to the network connects to the internal Autodiscover Service URL, and a mobile device that is external to the network connects to the external Autodiscover Service URL. For split-brain DNS environment, the internal autodiscover DNS record should exist in the internal DNS and not in the external public DNS. Vice versa, the external autodiscover DNS record should exist in the external public DNS and not in the internal DNS.
Tip#2: Lync Web services FQDNs
The internal web services FQDN must be different from the external web services FQDN. This is a requirement as stated in Technet but not emphasized enough. This is particularly important when using a Standard Edition Front End, where the internal Web Services FQDN defaults to the Lync server FQDN and cannot be changed. If the same Lync server FQDN has also been used for the external web services FQDN for some reason, then it must be changed in order for the Mobility Service to work properly. Note that changing the external web services FQDN in Topology Builder requires a re-issuance of the default Lync server certificate.
Tip#3: Lync Web services DNS records
As mentioned in Technet: "The Lync Server 2013 Autodiscover Service returns all Web Services URLs for the user's home pool, including the Mobility Service (Mcx and UCWA) URLs. However, both the internal Mobility Service URL and the external Mobility Service URL are
associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Lync Server 2013 Mobility Service externally through the reverse proxy"
- The internal web FQDN must only resolve to and be accessible from inside the corporate network.
- The external web FQDN must only resolve to and be accessible from the Internet.
- For a user who is inside the corporate network, the Mobility Service URL must be addressed to the external web FQDN. This requirement is for the Mobility Service and applies only to this URL.
What is not obvious from the above statements are that for a DNS split-brain environment with mobile device clients connecting wirelessly, you need to configure the external web FQDN in the internal DNS with the public Reverse Proxy IP address. Otherwise, internal clients will not be able to reach the external web FQDN returned by the internal autodiscover service. Without this record, the mobile client will display an error "Can’t connect to the server. It may be busy or temporarily unavailable. Please try again" and you will likely encounter the error logs from the mobile client showing something like this:
"... The AppliesTo element of web ticket request points to a different web server or site... "
associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Lync Server 2013 Mobility Service externally through the reverse proxy"
- The internal web FQDN must only resolve to and be accessible from inside the corporate network.
- The external web FQDN must only resolve to and be accessible from the Internet.
- For a user who is inside the corporate network, the Mobility Service URL must be addressed to the external web FQDN. This requirement is for the Mobility Service and applies only to this URL.
What is not obvious from the above statements are that for a DNS split-brain environment with mobile device clients connecting wirelessly, you need to configure the external web FQDN in the internal DNS with the public Reverse Proxy IP address. Otherwise, internal clients will not be able to reach the external web FQDN returned by the internal autodiscover service. Without this record, the mobile client will display an error "Can’t connect to the server. It may be busy or temporarily unavailable. Please try again" and you will likely encounter the error logs from the mobile client showing something like this:
"... The AppliesTo element of web ticket request points to a different web server or site... "
Tip#4: Reverse Proxy Web Listener
Although Forefront TMG is no longer available for sale, many sites are still using an existing TMG as a Reverse Proxy for Lync. If so, the existing Web Access rule can be modified to cater for the Mobility Service. Obvously the web listener for this rule must have a certificate from a public CA (I'm using GoDaddy) and the external public AutoDiscover FQDN must be added to the certificates SAN if https is desired for service requests. As per the Technet documentation, the following settings are worthy of mention:
On the Web Publising rule, in the To tab, ensure the following:
◦ Select Forward the original host header instead of the actual one.
◦ Select Requests appear to come from the Forefront TMG computer.
◦ Select Forward the original host header instead of the actual one.
◦ Select Requests appear to come from the Forefront TMG computer.
On the Bridging tab, ensure the following:
◦ Select Web server.
◦ Select Redirect requests to HTTP port, and type 8080 for the port number.
◦ Select Redirect requests to SSL port, and type 4443 for the port number.
◦ Select Web server.
◦ Select Redirect requests to HTTP port, and type 8080 for the port number.
◦ Select Redirect requests to SSL port, and type 4443 for the port number.
Tip#5: Use the new Lync Connectivity Analyzer
The new Lync Connectivity Analyzer is a great tool for testing and verifying the Autodiscover and Mobility services. You can choose to test both internal and external Auto Discovery URLs. If your DNS records are not done properly, this tool will be a good place to start troubleshooting.
RSS Feed