If like me, your email domain (SMTP domain) is different to your internal AD domain, and you have externally hosted services on the same email domain and you’re Lync deployment does not interact with the World Wide Web, you’re in for some fun. Microsoft clearly never thought this would be a scenario their customers would use. In other words:
- www.walker.uk.com is externally hosted.
- firstname.lastname@example.org is internally hosted (Exchange).
- email@example.com is your internal UPN.
Lync / Microsoft makes the horrible assumption that your internal domain is the same as your external domain and therefore will try to look for the autodiscover record at autodiscover.walker.uk.com. It is unlikley that this will exist for internal only deployments and there is no way you’re about to create it (is there!).
Some have AD DNS configured with a zone for the external domain as the authoritative server and you look after that zone already. This is fine and you only need to create a C-Name record of autodiscover, pointing to your CAS load balanced address in the external zone.
- C-Name: autodiscover.walker.uk.com > excas.addomain.net
However, if you don’t already have this zone, you probably don’t want to create it and then have to maintain it. So here is the trick:
- Create a primary DNS zone of autodiscover.walker.uk.com
- In the new zone, create an A-record for each CAS server. Note, the Name is intentionally left blank. You cannot create a C-Name in this manor.
If you set up a Wireshark session on the Lync Client machine, you should see it trying to resolve autodiscover.walker.uk.com. That it now can.
Clearly, Exchange’s autodiscover, via DNS (not AD) must be working as Lync uses this to work out where Exchange Web Services (EWS) are.