The Microsoft Lync Connectivity Analyzer (MLCA) is a tool designed to help administrators of a Lync deployment (on-premises or in Office 365) verify whether their architecture is able to support Lync client apps that run on mobile devices. Lync apps require the following specific configurations:
- The DNS records (Lyncdiscover and Lyncdiscoverinternal) should be able to automatically locate Lync services
- A reverse proxy configuration is required to publish the previously mentioned resources
- Specific settings (hairpinning on the reverse proxy) for the clients on the internal network (for example, using a Wi-Fi system) that will connect to the Lync services like a client that comes from an external network
The MLCA is available in two different versions, 32-bit (http://www.microsoft.com/en-us/download/details.aspx?id=36536) and 64-bit (http://www.microsoft.com/en-us/download/details.aspx?id=36535) ones. The MLCA tool is available on Windows 7, Windows 2008 Service Pack 2, and all the previously mentioned operating systems. It requires the Microsoft .NET Framework 4.5 installed (on Windows Server 2012 R2 and Windows 8, it is a system feature activated by default).
- We have to download and install the MLCA. The setup process is a standard one, which just requires a confirmation about the installation path (it is advisable to run it with local administrative permissions).
- MLCA supports four different scenarios to test three different kinds of clients (the Lync Store app, the Lync 2010 app, and the Lync 2013 app). The scenario that we are going to use is defined by the network where the verification will occur (internal or on the Internet) and by the type of deployment we are going to verify (on-premises or in the cloud). All the configuration menus for the tool are shown in this screenshot:
- Similar to a real Lync app, it is required to insert a user's SIP URI, a password, and a domain account if it does not match with the SIP URI. Discovery can be automatic or manual.
- For our first test, we can try an Office 365 user that is connecting from the Internet. The results are available in three formats. We are able to see the summary and detailed information in the next screenshot:
- The previous test, when configured to simulate an external connection, tried to resolve the autodiscover service using the Lyncdiscover record. As we were analyzing connectivity for an Office 365 user, the Lyncdiscover server was contacted directly using HTTP.
- If we try to verify an on-premises user connected to the Internet, the test will perform a connection attempt via Lyncdiscover with the HTTPS protocol, and revert to HTTP if a failure occurs.