The DNS records for a Skype for Business (SfB) on-premises deployment can be somewhat complex, but are well documented (see Microsoft TechNet – DNS requirements for Skype for Business). While working on a recent hybrid Skype for Business (SfB) deployment, I realized there is a lot of confusion. This was a classic hybrid deployment – some SfB servers and users on-premises, and some in SfB Online sharing one DNS namespace. This article aims to clear up some of this confusion.
The unique question that comes up in hybrid is where should I point my DNS records for clients to logon? On-premises or online?
The general golden rule in a SfB hybrid environment is:
All Skype for Business external DNS records should point to the on-premises infrastructure.
This is a bit hidden but documented here in this TechNet article Plan hybrid connectivity between Skype for Business Server and Skype for Business Online.
A source of this confusion usually happens when client logins do not work for Skype for Business Online (SfBO) users in a hybrid deployment. Several Microsoft sources citing SfB Online client login issues and that DNS records should point to Office 365:
- Troubleshooting Skype for Business Online DNS configuration issues in Office 365
- Lync Connectivity Analyzer (and select Office 365 Custom/Vanity Domain Name Settings Test for Lync)
NOTE – both of these resources are meant for pure Skype for Business Online deployments in Office 365, NOT for hybrid.
For hybrid deployment the client autodiscover login DNS records should point to the on-premises deployment. The TechNet documentation is quite clear on this requirement “In a hybrid deployment that has an on-premises Lync Server deployment and Skype for Business Online, the DNS records for Lync Autodiscover must be pointed to the on-premises Lync server”.
When a Skype for Business Online user attempts to sign-in, the on-premises SfB server will go through a process of being redirected multiple times until they reach their final home server in the Skype for Business Online topology. This process is well documented in the bottom half of this Microsoft Support article: Users can’t sign in to Skype for Business Online in a hybrid deployment of Lync Server 2013.
For hybrid deployment, here is a convenient summary of the external DNS records and where they should point to on-premises:
(Note: this example uses the domain contoso.com)
| DNS RECORD | RECORD TYPE | WHERE IT SHOULD RESOLVE TO | PORT |
| sip.contoso.com | A | Public IP of Access Edge | n/a |
| _sip._tls.contoso.com | SRV | External on-premises Access Edge Interface (sip.contoso.com) | 443 |
| _sipfederationtls._tcp.contoso.com | SRV | External on-premises Access Edge Interface (sip.contoso.com) | 5061 |
| webcon.contoso.com | A | Public IP of Access Edge | n/a |
| av.contoso.com | A | Public IP of Access Edge | n/a |
But What about the CNAME records I read about Required for Office 365 Users?
Again, this is part of the confusion as this only applies to pure SfB online deployments. In this case, you will want the following two DNS records, but NOT FOR HYBRID:
> A DNS CNAME record for sip.contoso.com which points to sipdir.online.lync.com
> A DNS CNAME record for lyncdiscover.contoso.com which points to webdir.online.lync.com
If you add these external DNS records, external client login will break for the SfB on-premises users. They will receive this error:
For the internal DNS records, these are the same as the internal DNS records for a non-hybrid on-premises Skype for Business Deployment (which you can find here) so I won’t repeat them, but I will point out one exception:
> An DNS A record for sfedge.contoso.com which resolves to the IP address of the internal interface of Edge server
DNS and Using PowerShell with the Skype for Business Module in a Hybrid Environment
Now, to further confuse things, the Skype for Business Online PowerShell module relies on the DNS CNAME record for pure online deployments to connect with PowerShell. This record:
A DNS CNAME record for lyncdiscover.contoso.com which points to webdir.online.lync.com
Because this record is not used in a SfB / Lync hybrid deployment, the Remote PowerShell connection will fail.
This is well documented with the work around, here:
The work around is to use an OverrideDomain property on with the default domain for your Office 365 tenant (i.e. the *.onmicrosoft.com domain that was included with the tenant subscription).
This is also documented here: http://www.ucblog.co.uk/?p=25
LinkedIn
Twitter
So apart from the 5 external records in this article, no other external records are to be added ? ..what about the following records that i read somewhere that they must point to our reverse proxy server ?
lyncdiscover.domain.com
dialin.domain.com
meet.domain.com
webext.domain.com
officewebapps.domain.com
And as a follow up on the question posted by Khoj, if all records are pointed to the access edge interface and we use different IPs for the access, av, conf service; how does the client locate these services ?
Please clarity.
Thanks,
Benjamin
Why do we require webcon and AV external records to access edge. we have three interfaces on edge server
Those DNS records are used by the external clients to locate the appropriate edge interface for the associated edge service (e.g. web conferencing or audio/video).
Curtis