Secrets of configuring DHCP policies for Lync handsets alongside other vendors

After battling with a non-Microsoft DHCP server to get it to configure multiple vendors of handset I figured out some very useful undocumented ‘habits’ of Lync handsets which might help someone else…

1. Lync handsets (e.g. the Polycom CX600) use TWO vendor IDs during their DHCP requests

The first vendor ID that is used during negotiation of an IP address is “CPE-OCPHONE”. This is the legacy ID that was used during the OCS 2007 days. Despite being legacy it is actually the first one that appears on the wire. Knowing this if you are struggling with getting Lync handsets to do vlan tagging you’ll hopefully realise that CPE-OCPHONE is the vendor ID you need to be using in option 60 for the vlan tagging configuration policy in DHCP.

The second vendor ID used is the modern Lync handset ID, namely “MS-UC-Client”. This is the one you use in option 60 when you provide the configuration to the phones.

2. If you have to use a non-Microsoft DHCP server (e.g. QIP) and you are in the middle of migrating from an IP-PBX (e.g. Alcatel) over to Lync but need to use the same voice vlans for both handset vendors, make life easy and use Vendor Class policies.

Using Vendor Class policies assigned to your voice networks means you can have multiple DHCP policies available on a single subnet! This way you can have non-voice clients that get a standard policy, and multiple vendor handsets that can get their own configuration sets. You could configure each individual IP address to have a single DHCP policy and statically assign phones to pre-configured IPs, but that doesn’t scale and it’s horrible to deal with.

Microsoft use vendor classes, and for good reason, so make sure you do your best to configure your non-Microsoft DHCP to use them too. Having to use multiple vendors’ phones is a pretty rare thing so you may not be able to get much support from anywhere.

3. Get hold of a simple network hub and use this with wireshark on a laptop to monitor DHCP traffic. It’s much easier than guessing what settings are (or are not) working.

4. If your network switches support LLDP-MED for goodness sake use it!

LLDP-MED is so much easier to handle and can be assigned to all ports on a switch instead of having to assign a specific voice vlan for a specific port. That and if you can use LLDP-MED you will not need to configure the phone to know what vlan to use for tagging because the LLDP protocol will do that for you.

5. When you’re stuck with a non-Microsoft DHCP server, read this article and this one from TechNet. The info you’ll need is there, they just haven’t really explained it too well.

I plan to do a deep dive into the stages a Lync handset goes through at boot-up and initial configuration in a later article, so if you find any of this of use you may wish to watch out for it.

  • verheek

    Great article.

    I’m using DHCP on Server 2008 R2. What I’m trying to do is have each vendor’s phone,
    go to the correct subdirectory on a tftp server to get its own files.
    I don’t want them all in root because of organization.

    I have defined my vendor class for a Polycom, SNOM and Grandstream phone and then
    use the standard class set for the PCs.

    I’m setting Option 66 to point to a TFTP server. I have DHCP reservations for
    the phones. Option 66 is predefined to the url of the corresponding files
    on the tftp server.

    If I put the Option 66 from the standard or polycom vendor
    class into the reservation for the phone it works fine and the phone finds the
    tftp server on bootup.

    If I put option 66 in from standard into the scope it also works.
    But if I put the polycom vendor option 66 into the scope, the phone gets
    everything but this vendor class option 66. It makes me think the vendor
    ID I’m using is incorrect but it works in the reservation.

    I’ve googled and read polycom’s articles but can’t get it to work. I haven’t posted this online yet.

    I’d rather not have to add the specific option 66 boot server location to every reservation as it defeats the purpose.

    Watching tcpdump, it seems the process gets stuck on DHCP INFORM.

    Any ideas? Or maybe an alternate way to accomplish the same goal?


  • Hi verheek. Thanks for all the detail in your question which is very helpful. What strikes me as interesting in your text is that you haven’t mentioned “policies” anywhere. When you’re dealing with vendor classes you’re meant to use dhcp policies filtered by the vendor class to assign special values to specific devices.

    So I think your use of scopes is where you’re going wrong. Make sure you’ve got no specific settings for your phones in any scopes you’ve created, check the vendor classes are all ok (right-click on the IPv4 node of your dhcp server, and click “define vendor classes”) then go straight to the policies section and create one policy for each vendor. Use each vendor-specific policy for only the relevant options for each vendor’s phone, and then the scope will provide the rest (e.g. time server and ip ranges).

    I found these’s articles which might help you if you want a bit more depth…
    1 –
    2 –