For many folks that have deployed Skype for Business (or one of its predecessors) this post might seem a bit dated. Still, I can’t help that lately, I’ve seen quite a number of issues arise while deploying handsets with Skype for Business.

When deploying handsets for Skype for Business, there are certain requirements that need to be met from a network and systems perspective to ensure that they can function properly. This post is mainly to provide my readers a checklist of sorts to ensure that phones can log in, function, as well as be managed.

First, some global basics.

NTP (DHCP Option 42): We should always ensure that all the devices on our network are getting the correct time, and handsets are no exception. When the handsets are not set to the right time it can cause issues with sign-in. Bonus level: ensure that the local time zone is being set by the management tool or offered via DHCP so that the phone automatically shows the right time for the location. DHCP Option 002 can be used to set the Time Offset: https://phyler.wordpress.com/2013/11/01/dhcp-option-002-time-offset-for-lync-and-polycom-phones/

Network Access: Verify that the handsets have access to critical services if they are located on a separate voice VLAN. Too often I see these dedicated VLAN’s not have access to things like Active Directory, Skype for Business, or in the case of Skype for Business Online, the Internet. Ensure that appropriate ports such as HTTPs (TCP/443) and the media ports are allowed.

SIP URI and the UPN: This one seems to rear its head more commonly. If your user’s Skype for Business sign-in address is user@domain.com, then their AD account’s UPN Suffix should be domain.com also. When the UPN Suffix is not the same as the SIP URI, then you get issues such as being prompted for the username at sign-in as well as calendar integration breaking. It is also important to note that ideally, the UPN Suffix and the primary SMTP domain are the same as well.

Phone Management: Are you using Skype for Business (on-premises or Online) to manage the firmware? Or are you using a third-party such as AudioCodes, EventZero, or Polycom? If the latter is true, then there are a few things you need to do to ensure that you will be able to successfully manage the devices.

The first thing when dealing with a 3rd party device manager is to ensure that DHCP Option 160 is set up. For some devices, they will search other options such as 66 or 161 but all of the 3rd party phones will look for Option 160.

We also need to make sure that the phones have access to the device manager. This ties back to the Network Access comment that I made above. If the handset is on a dedicated VLAN, you need to ensure that it has access to the device manager that will most likely be on a data network.

If you are using Office 365/Skype for Business Online, there is one more step you need to take. Within the O365 tenant, you need to set the EnableDeviceUpdate to False. If you don’t, every time the device signs in, it will get updated by Microsoft back to whatever their current released software is which many times is older than what is currently published by the manufacturers. The screen shot below shows that this tenant will provide updates to devices registered to it.

You will also want to make sure that Better Together over Ethernet (BToE) is set to True (see the EnableBetterTogetherOverEthernet setting in the screenshot above). The default is $True but I have seen a few cases where it was set to $False and causing issues.

Now that we have covered the basics that apply to both Online and On-premises, let’s focus in on a few things that only apply to On-premises:

DHCP Option 43: this option allows for Lync/Skype for Business clients to find the Lync/Skype for Business certificate provisioning server on the network. To get more details on this, we can go waaaay back to an old Lync 2010 Technet article: https://technet.microsoft.com/en-us/library/gg398088. When DHCP Option 43 is not working correctly, phones cannot find the certificate provisioning server, which then means that the phones cannot sign-in due to not having the proper certificate.

DHCP Option 120: This option allows the phone to actually find the Front-end server. Most phones now will also look for Lyncdiscover records so this one is a bit more legacy. It’s always nice to have this published when dealing with on-prem as it can help if for some reason, you Lyncdiscover record is not working.

Verify Media Ports: This one is missed in many deployments. When using Skype for Business, our clients are set to use specific media ports (at least they should be per best practice). We look for these media ports for things like QoS. If these media ports are being blocked (see the Network Access point above) or being routed through a proxy, VPN, or a WAN Accelerator, we can see voice quality or dropped call issues arise. To find out more about planning out your Media Port range, check out Technet: https://technet.microsoft.com/en-us/library/gg405412(v=ocs.14).aspx

Now, one last comment, all of these things are for handsets to connect to Skype for Business (On-premises or Online) or Lync. With the recent announcements at Microsoft Ignite 2017, all of the phone vendors have announced that they will support Microsoft Teams with their devices. While none of the major vendor devices will register with Teams today, that will come and we will see what is needed for that in the (hopefully) near future. For more information about what might be coming for handsets with Microsoft Teams, check out this post: https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Certified-Skype-for-Business-Online-Phones-and-what-this-means/ba-p/120035.