This brief article walks through some common steps which can be used to locate the Fully Qualified Domain Name (FQDN) of a Lync or Skype for Business registrar from either on-premises or online environments.  (This content was originally to be part of another article but was split into a separate post for easier reference.)

This can be used as a reference for other articles on this site as a common step performed when troubleshooting device registrations to Skype for Business is to manually configure the endpoint.  To do this one must know the proper FQDN of the desired Microsoft SIP registrar.  Not all of the natively interoperable voice and video solutions supported with Lync and Skype for Business today leverage the newer Lyncdiscover web service model and may still need to automatically discover the SIP registrar directly.  The configuration that supports these is still used by most clients but was the only available method supported in legacy clients like Lync 2010 and devices like Lync Phone Edition.

On-Premises and Hybrid Deployments

This section focuses on Lync Server and Skype for Business Server deployments where on-premises Front End pools and Edge Server pools are deployed.  Some of these environments may also be configured in the Hybrid model with a split-domain configuration connected to an Office 365 tenant.  Either way there are multiple potential registrars that client would be directed to connect to depending on the client’s network location at the time, as well as VPN connectivity is applicable.

DNS Resolution

The Lync/SfB registrar pool FQDN will be needed for the desired user account .  The following steps can be used to validate if the appropriate DNS records exists for the SIP domain to support legacy discovery processes.

• From a internal workstation located inside the corporate network use the Command Prompt or PowerShell to enter the following nslookup commands to search for any Service, Host, or Alias records specifically pointing to an internal registrar (e.g. Front End Pool).

PS C:\> nslookup -q=srv _sipinternaltls._tcp.jdskype.net
Server:  dc.jdskype.net
Address:  192.168.1.100

Non-authoritative answer:
_sipinternaltls._tcp.jdskype.net      SRV service location:
priority       = 0
weight         = 0
port           = 5061
svr hostname   = fepool.jdskype.com

fepool.jdskype.com   internet address = 192.168.1.102
fepool.jdskype.com   internet address = 192.168.1.103
fepool.jdskype.com   internet address = 192.168.1.104

PS C:\> nslookup sipinternal.jdskype.net
Server:  dc.jdskype.net
Address:  192.168.1.100

Non-authoritative answer:
Name:       fepool.jdskype.com
Addresses:  192.168.1.102
192.168.1.103
192.168.1.104
Aliases:    sipinternal.jdskype.com

PS C:\> nslookup sip.jdskype.net
Server:  dc.jdskype.net
Address:  192.168.1.100

Non-authoritative answer:
Name:       fepool.jdskype.com
Addresses:  192.168.1.102
192.168.1.103
192.168.1.104
Aliases:    sip.jdskype.com

• From an external workstation located outside the internal network use these nslookup commands to search for any Service, Host, or Alias records specifically pointing to an external registrar (e.g. Edge Pool).

PS C:\> nslookup -q=srv _sip._tls.jdskype.net
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
_sip._tls.jdskype.net SRV service location:
priority       = 10
weight         = 100
port           = 443
svr hostname   = sip.jdskype.com

PS C:\> nslookup sipexternal.jdskype.net
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:       sip.jdskype.net
Addresses:  140.242.5.104
140.242.5.107

PS C:\> nslookup sip.jdskype.net
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:       sip.jdskype.net
Addresses:  140.242.5.104
140.242.5.107

Note that not all of these records will typically return results.  The sipinternal and sipexternal records are rarely used, but the basic sip record is commonly configured internally for legacy devices as is often added during the server certificate creation.  It is also very commonly used as the external Edge FQDN for external clients and federation.

If none of the lookups performed above are successful then the environment being used has not been configured to support any of the legacy autodiscovery lookup records, which is not entirely uncommon these days.  At this point a specific registrar name can be found using the desktop client instead.

Client Information

• Sign in to a Windows Lync or Skype for Business client.  After the client has completed the sign in process hold down the the CTRL key and right-click the client icon in the System Tray.

• Select the now-visible Configuration Information menu item.

• Look for the Skype for Business Server entry and take note of the FQDN displayed.

The following example shows an internally connected client as denoted by an Inside User Status value of TRUE.  The connected Skype for Business Server is displayed as the internal Front End pool FQDN (e.g. fepool.jdskype.net).

Be aware that in some instances this may instead display the user’s specific home server FQDN instead of the entire pool FQDN (which is shown in the example above) when registered to an internal Front End pool.  In multiple server pools the use of an individual server FQDN to manually register a device or client would not allow for any High Availability redundancy, so make sure to keep in mind that while this approach is fine for testing it is best to retrieve the pool FQDN from the IT administrator if it cannot easily be located programmatically.  (In deployments leveraging Standard Edition Front End Servers then this is moot.)

This second example is from an externally connected client as denoted by an Inside User Status value of FALSE.  The connected Skype for Business Server is displayed as the external Edge pool FQDN (e.g. sip.jdskype.net).

When registered to an Edge pool the actual home Front End server FQDN is not shown and only the external Edge FQDN is displayed.  Thus for external registration this value is perfectly fine for production use as it does not circumvent any High Availability capabilities which may be provided by the external pool.

Skype for Business Online

This section applies only to pure Skype for Business Online tenants where there are no on-premises Skype for Business servers deployed.

For all users hosted on Skype for Business Online there is a single defined FQDN

• From any workstation use these nslookup commands to search for the Service and Host/Alias records which point directly to the Skype for Business Online pools in Office 365.

PS C:\> nslookup -q=srv _sip._tls.jdskype.net
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
_sip._tls.jdskype.net SRV service location:
priority       = 100
weight         = 1
port           = 443
svr hostname   = sipdir.online.lync.com

PS C:\> nslookup sipexternal.jdskype.net
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:     sipdir.online.lync.com
Address:  52.112.66.148
Aliases:  sip.jdskype.net

This process shows the common sipdir.online.lync.com FQDN used for all registration attempts to Skype for Business Online.  This single FQDN should be used be all devices or client connecting to a Skype for Business Online account from any location.  Leveraging this FQDN insures the best connectivity.

Alternatively the Skype for Business Configuration Information can be reviewed using the process shown in the previous section. Because the sipdir.online.lync.com FQDN is simply a geographically balanced DNS record the actual server name shown will be that of whichever registrar pool the user’s account is homed on.