Monday, 11 March 2013

Lyncdiscover redirection using CNAME records

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

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: 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, if they have a SIP address of, 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 domain, pointing it to

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


No comments: