So the waiting (as of writing) is almost over and the server-side bits for shiny new Lync Mobility Service (MCX) have been released!
The client-side bits are likely to be released next week and in the meantime there is nothing stopping you from prepping your Lync Servers. 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. I will however caveat one minor thing at this early stage, with the clients still unreleased this guide is still very much in beta! 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)
Set-CsWebServer –Identity lyncserver.jacobs.local -McxSipPrimaryListeningPort 5086
Second the external listening port: (as stated in the prior step, my Lync Front End is lyncserver.jacobs.local, you will need to substitute this for your own front end/pool/director name)
Set-CsWebServer –Identity lyncserver.jacobs.local -McxSipExternalListeningPort 5087
Finally you will need to enable the topology, within the same shell type:
Enable-CsTopology –verbose
MCX Service Installation
Now we’re ready to install the MCX server components, this can be downloaded here. Before you can run the installation a few changes need to be made to IIS.
Within the Lync management shell run, ensure shell is run as admin if UAC is enabled (Windows Server 2008 R2):
Import-Module ServerManager
Add-WindowsFeature Web-Server, Web-Dyn-Compression
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” |
Now we’re ready to run the MCXStandalone.msi
First you’ll need to copy the McxStandalone.msi to C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup, then execute C:\Program Files\Microsoft Lync Server
2010\Deployment\Bootstrapper.exe
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 created lyncdiscoverinternal
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.
Set-CsCertificate –Type Default,WebServicesInternal,WebServicesExternal –Thumbprint <Certificate Thumbprint>
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 to Install 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 section Proxy 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)
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)
New-CsHostingProvider –Identity "LyncOnline" –Enabled $True –ProxyFqdn "sipfed.online.lync.com" –VerificationLevel UseSourceVerification
Then add the Lync Push federated domain type:
New-CsAllowedDomain –Identity "push.lync.com"
That’s it!
