During the Lync Phone Edition roll out phase of a recent Lync Server 2010 deployment, we came across some problems configuring the organisation’s Infoblox DHCP appliances to work with the DHCP options required for Lync Phone Edition (LPE).

Doug Deitterick’s sensational blog post on this was a great starting point and enabled us to get most of the configuration sorted, but we still found that LPE wasn’t picking up the DHCP Options required.

The Problem

After we found that the phone wasn’t signing in, it was time to setup a mirrored switch port and Wireshark to find out what was happening with the DHCP traffic. With the phone booted up, when you input an extension and PIN and hit Sign In, LPE sends a DHCP INFORM packet to the DHCP server that gave it its IP address and also broadcasts it across the subnet. Within this packet is the critical vendor-class-identifier (Option 60) string of MS-UC-Client, asking for Option 120 and 43 that give LPE its SIP server and Cert Provisioning URL it needs to connect to the Lync Front End Pool.

This is where the problem was. Infoblox wasn’t responding to these INFORM packets with the right DHCP ACK packets that contain Options 120 and 43.

The Solution

After a lot of rummaging around and checking that the hex values were correct for each sub-option of Option 43 based on what we’d generated using DHCPUtil on the Lync Front End server, we found a checkbox in the Advanced configuration of the DHCP scope of interest:

The DHCP scope we’d setup to test LPE was inheriting some settings from a parent scope. After we clicked Override to stop inheritance on this setting and checked the box DHCP server is authoritative for the domain, we found that Infoblox now responded to the DHCP INFORM packets LPE was sending with DHCP ACK packets with the right options for LPE.

After I tried signing in again on the phone, I saw all the right SIP/TLS traffic in our Wireshark capture and the Polycom CX600 in question signed in fine.