Microsoft Lync 2010 Lync Mobility (MCX) Installation Guide

So the waiting (as of writing) is almost over and the server-side bits for shiny new Lync Mobility Service (MCX) have been released!

All clients have been released and can be downloaded via your Smartphone’s respective AppStore/Marketplace etc…

For those that are keen to get this up and running quickly, I have put together a short step-by-step guide, for official Microsoft documentation head here. With all clients RTW’d this guide is officially v.1.0

Configuration of Lync Mobility Autodiscover Records

First up you’ll need to create the internal (lyncdiscoverinternal.<SIPFQDN>) and external (lyncdiscover.<SIPFQDN>) MCX discovery records, mine can be seen below:

As this is being configured within a test lab environment my internal discovery DNS is pointed at my Lync Standard Edition Server, for a larger deployment this is likely to be your Front End Pool or Director.

I have also configured the external discovery record, which can be verified using NSLOOKUP (see below). This is pointed toward the external listener address of my TMG reverse proxy.

Next we need to ensure that the November Lync Cumulative Update (CU4) is installed – see more on this here, once this is complete we need to open up some internal MCX ports via the Lync management shell.

First the internal listening port: (my Lync Front End is lyncserver.jacobs.local, you will need to substitute this for your own front end/pool/director name)

Or the following within the Windows command line, ensure command is run as admin if UAC is enabled(for Windows Server 2008):

ServerManagerCMD.exe –Install Web-Dyn-Compression

One complete you will be presented with the following

If you are running Window Server 2008 (IIS7.0) then you need to make a minor ASP.Net change (follow Microsoft procedure included below) – I’m running Windows Server 2008 R2 (IIS7.5) so I skipped this.

To change ASP.NET settings in IIS 7.0

1. Log on to the server as a local administrator.2. Use a text editor such as Notepad to open the applicationHost.config file, located at C:\Windows\System32\inetsrv\config\applicationHost.config.3. Search for the following:<Add name=”CSExtMcxAppPool”4. At the end of the line, before the ending angle bracket (>), type the following:CLRConfigFile=”C:\Program Files\Microsoft Lync Server 2010\Web Components\Mcx\Ext\Aspnet_mcx.config”5. Search for the following:<Add name=”CSIntMcxAppPool”6. At the end of the line, before the ending angle bracket (>), type the following:CLRConfigFile=”C:\Program Files\Microsoft Lync Server 2010\Web Components\Mcx\Int\Aspnet_mcx.config”

During the installation you will be presented with “Installing MCXStandalone…” (see below)

Certificate Update

Now we need to update our internal SAN certificate, this needs to include the newly createdlyncdiscoverinternal
record our internal certificates and first up we have to find the correct certificate identifier or thumbprint for this to be completed successfully. To display all certificates type the following within the Lync Management Shell:

Get-CsCertificate

This will return all certificates and their corresponding thumbprints, in my case all certificates are the same, so I can run the following command to update the cert for all uses.

During this process I was presented with a warning, upon further investigation neither Lync Discovery addresses were within my internal or external SAN certificates. To re-generate, I ran the following command within the Lync Management Shell

The easiest method for re-generating certificates is by re-running the Lync Deployment Wizard, going toInstall or Update Lync Server System and executing Step 3 Request, Install or Assign Certificates

For more information on this the Microsoft MCX deployment guide details alternate certificate scenarios i.e. where you have a unique cert per usage type, refer to the section – Modifying Certificates for Mobility

Forefront TMG Configuration for Lync Mobility

There are two approaches here, one uses SSL for setup the other does not. The main reason for allowing a re-direction from port 80 (http) to 443 (https) is to avoid the need of replacing your existing SAN.

The recommended approach is to only permit the Lync mobility client to communicate on port 443, so I replaced the certificate within my existing Lync web listener within Forefront TMG – so we’re going to run you through this setup below (you could also add the additional public name “lyncdiscover.SIPFQDN” to an existing Lync website rule, but I’m going to run through this as an independent rule).

First we need to create the new web publishing rule (see below)

Give it a name (see below)

Select Allow (see below)

Select Publish to a single Web site or load balancer (see below)

Select Use SSL to connect to the published web server or server farm (see below)

Specify your internal site name, this will be the name of your Front End Pool (see below)

Path should be “/*” and select the check box for Forwarding the original host header (see below)

Add the public lyncdiscover address (see below)

Select your existing Lync web listener, with the new SAN certificate that now includes the lyncdiscover address. Select No delegation, but client may authenticate directly (see below)

Finally allow requests from All Users and Finish

You will now need to go into your newly created web publishing rule and go to the to tab, in the sectionProxy requests to published site, ensure that Requests appear to come from Forefront is checked for a single Front End server or Standard Edition server. Alternatively select Requests come from the original client if you have a Front End Pool (see below) This statement is incorrect, and unlike the single Front End server scenario was not tested directly and was taken directly from the official documentation – in both scenarios requests should appear to come from TMG.

Finally go to the Bridging tab and change the default ports from 80 -> 8080 and 443 -> 4443 (this is the external web site on your Lync Front End). Once complete ensure you apply the new rules.

Your TMG rule is complete!

Push Notifications Configuration

Push notifications are handled by Microsoft Office 365 or Lync Online, so you need to have federation deployed and run the Set-CsPushNotificationConfiguration cmd-let

First let’s enable push notifications within the Lync Management Shell by running:

Set-CsPushNotificationConfiguration

Next we should enable federation with Office 365 (if not completed already), within the Lync Management Shell type: (this will add a new Hosted Provider)

The latest batch of Lync cumulative updates are detailed below, server-side updates can be deployed via the Cumulative Update installer (recommended) or manually (download links below). Updates will as always make their way to Microsoft Update ETA late August.

Early indications from CU PowerShell help files (credit to Tom Arbuthnot and Ari Protheroe) suggest that CU4 paves the way for Lync mobility, with the addition of six shiny new cmd-lets:

CsAutodiscoverConfiguration – Modifies an existing collection of Autodiscover configuration settings. The Autodiscover service provides a way for client applications such as Lync Web Access or Microsoft Lync Mobile to locate key resources such as a user’s home pool or the URL for joining a dial-in conference.

New-CsWebLink – Creates a new web link that points to the Autodiscover service. The Autodiscover service provides a way for client applications such as Lync Web Access or Microsoft Lync Mobile to locate key resources such as a user’s home pool or the URL for joining a dial-in conference.

Test-CsMcxPushNotification – Verifies that the push notification service is working. The push notification service (Apple Push Notification Service and Microsoft Lync Server 2010 Push Notification Service) provides a way to send notifications about event s such as new instant messages or new voice mail to mobile devices like iPhones and Windows Phones, even if the Microsoft Lync 2010 application on those devices is currently suspended or running in the background.

CsMobilityPolicy – Modifies an existing mobility policy. Mobility policies determine whether o r not a user can use Microsoft Lync 2010 Mobile. These policies also manage a user’s ability to employ Call via Work, a feature that enables users to make and receive phone calls on their mobile phone by using their work phone number instead of their mobile phone number.

CsMcxConfiguration – Modifies an existing collection of Microsoft Lync Server 2010 Mobility Service configuration settings. The Mobility Service enables users of mobile phones such as iPhones and Windows Phones to do such things as exchange instant messages and presence information; store and retrieve voice mail internally instead of with their wireless provider; and take advantage of Microsoft Lync Server 2010 capabilities such as Call via Work and dial-out conferencing.

CsPushNotificationConfiguration – Modifies an existing collection of push notification configuration settings . The push notification service (Apple Push Notification Service and Micros oft Lync Server 2010 Push Notification Service) provides a way to send notifications about events such as new instant messages or new voice mail to mobile devices such as iPhones and Windows Phones, even if the Microsoft Lync 2010 application on those devices is currently suspended or running in the background.

Uncovering a last minute inability to join a Lync online meeting (or Live Meeting) can be incredibly frustrating, fumbling around for PSTN dial-in details and then switching from the “richer client” or Lync Attendee to the audio/video challenged Lync Web App a disappointment.

That is why I have spent that last couple of months (on and off) looking into an issue with both the Lync Attendee and Live Meeting Clients when joining via an authenticated web proxy – in my case a Cisco IronPort, but the proxy vendor is immaterial – if it isn’t anonymous then you’ll hit a similar stumbling block.

The first thing you’ll notice when you try to join is a failure (see below) and the inability to make it into the meeting lobby.

If we examine a network capture we’ll see why, pay particular reference to the “Using NTLM Authorization” (see below)

Whilst both clients support web proxies and obtain server settings via the Internet Explorer settings, they do not support any form of proxy authentication. Fear not there is a way around this, my workplace defined a group on our proxy for specific domains that we want to permit without content filtering or the need to enforce A/D authentication (IronPort examples below).

AccessNoAuth group definition:

The only drawback with this method, is that it requires you maintain a list of “white-listed” domains, for Microsoft we added livemeeting.com (Live Meeting) and sip.microsoft.com (Lync), the domains can easily be determined within a network trace.