Lyncdiscover redirection using CNAME records

There is a great article and download on Lync Mobility from Microsoft here.

http://www.microsoft.com/en-us/download/details.aspx?id=28355


One thing that it doesn't specifically cover _exactly_ is the Lync App from the Windows Store for Windows 8.

When using iOS, Android or Windows Phone devices we can specifically set an https url location for the lyncdiscover service, for example: https://lyncdiscover.contoso.com. However this is not possible to set using the Windows 8 app.

So Lync deployments that have multiple SIP domains in use but only one lyncdiscover record on these devices manually enter https://lyncdiscover.contoso.com, if they have a SIP address of user@tailspintoys.com, but are ultimately part of the same Lync infrastructure.

In the above guide it mentions using CNAME records to create for example, a lyncdiscover CNAME record for the tailspintoys.com domain, pointing it to lyncdiscover.contoso.com.

Now if your reverse proxy solution only has port 443 open this redirect will fail on Windows Phone and iOS devices. Newer Android devices appear to be able to cope with the redirection and bind to SSL ok, hence many organizations simply entering the lyncdiscover record manually in the setup information.

But as I said this work-around doesn't exist for the Windows 8 app. So here's what you do.

1. On your reverse proxy solution as well as having the 443-4443 redirection to the Lync Director or Front End pool that owns the this lyncdiscover endpoint, also add an 80-8080 rule. This will then allow a CNAME in DNS to work on iOS and Windows Phones, and also the Windows 8 app.

2. Once this is configured simply open the Windows 8 Lync app and when logging in you will receive a redirection notice (which just like autodiscover redirects for Exchange you can set to only prompt the first time)

 

 

 



  

The Windows 8 app will then allow your users to login. Additionally this will also allow your iOS and Windows Phone devices to use discovery also and login without additional manual input.

 

 

 

So is this really needed? Well if you only have a select few SIP domains you can simply add these additional lyncdiscover records to your public SSL certificate and just pay any additional fees that come from your SSL provider for adding extra SAN names. But in a multi-tenant environment where you may have many hundreds of domains the only real solution at this time is the above.

 

Looking at my recent blogs it has all been about Lync so I have a few Exchange 2013 blogs I will get out of the door in the next two weeks.

 

Take care!

 

Oliver Moazzezi - MVP Exchange Server

 

 

Lync 2010 Mobilty service MCX Director install issue

I recently had an issue on Lync 2010 Directors where the entire Lync Mobility install would occur, not just the autodiscover service like you would expect.

Information on the internet for this appears to be vague at best so I thought a clear post about the issue should help others clear this up and fix it without some serious head scratching.

 

When deploying the Lync Mobility service you can easily see what parts are installed from the command line process.

 

 

Lync Front End:

 

Lync Director:

 

 

However I was repeatedly getting both the autodiscover and mcx component installed on a Director server.

 

So how was that possible? Surely the process realises it is a Director server right?

 

Well it turns out the above isn’t entirely true. It checks to see on the server it is being installed on whether the McxPrimaryListeningPort and MxcSIPExternalListningPort are set.

If these are anything other than zero it will install both packages and the Lync Mobility service will not work if you are directing users to your Directors!

 

So how did this happen and how do we fix this?

 

Well the issue was caused because I ran the following on both the Director and Lync Front End FQDNs:

 

Set-CSWebServer LyncDirector_FQDN –McxSIPPrimaryListeningPort “value” –McxSIPExternalListeningPort “value”

 

And specified a value other than zero, 0.

 

When configuring this service this should only be run against your Front End FQDNs.

 

So to fix this I ran:

 

1. Set-CSWebServer LyncDirector_FQDN –McxSIPPrimaryListeningPort 0 –McxSIPExternalListeningPort 0

2. Remove the Lync Mobility Service via the uninstall feature from Programs and Features

3. Re-deploy the Lync Mobility Service via the bootstrapper process (and as a side note only ever do it via .\bootstrapper.exe, running it via the UI appears to unlock a number of bugs)

 

You should now find you get the following on your Director:

 

 

All fixed!

 

Take care,

Oliver Moazzezi - MVP Exchange Server