The Lync 2010 Phone Edition requires the usage of DHCP for a couple reasons. One of these being the ability to function on a network and the other being the ability to sign-in for newer phones that do not support NTLM but will rather utilize certificate based authentication as well as PIN Authentication. The ability to use DHCP options allowing the Lync 2010 Phone Edition to be able to contact the appropriate services in order to sign-in is new in Lync 2010 Phone Edition.
If you take your phone and plug it into your computer, you do not need to go through the DHCP Process to sign-in as it uses your Lync client. If you want to bring your phone home with you, you must go through the DHCP sign-in process at least once to get your phone fully provisioned for certificate based authentication and PIN authentication. Once you have an existing certificate on the phone, that certificate can be used to obtain a new certificate if needed. Just don’t go put your phone in the closet for months and expect it to still work. You may end up having to bring it into the enterprise to go through the DHCP Process to obtain a new certificate.
General DHCP Codes Used
General DHCP Options for Phones to Function on a Network
These DHCP Options in Lync Server 2010 also existed in Office Communications Server 2007 R2. These options include:
Option 15 is used when you want a connection-specific suffix. This is typical in a single domain environment.
Option 119 is used when you want to define a domain search list. This is typical when you have multiple DNS namespaces that you want a phone to be able to search through.
New DHCP Options in Lync 2010 allowing newer Lync 2010 Phone Edition devices to sign-in
These newly provided DHCP Options in Lync Server 2010 allow newer Lync 2010 Phone Edition devices that do not support NTLM Authentication to sign-in. These options include:
Option 43 is the Lync Server Pool Certificate Provisioning Service URL which utilizes the Web Components FQDN. A few things to note about this:
- If using a single server, this will be the typical internal web components FQDN
- If using a hardware load balanced pool, this will be the Pool FQDN
- If using DNS load balancing, there are some requirements to override the internal web components FQDN. This is because DNS Load Balancing works for SIP Traffic. A hardware load balancer is still required to load balance HTTP and DCOM Traffic. Because of this, your Web Components FQDN will be different and point to a VIP that uses the Hardware Load Balancer. Because of this, if using DNS Load Balancing, you will want to specify an FQDN that is different from your Pool FQDN. If using HLB across the board, Option 43 will be the Pool FQDN.
- Phones such as the new Polycom CX500 and CX600 that do not use NTLM to authenticate will require certificate and PIN authentication to be able to logon. This means that they will need to be able to contact the Web Components FQDN to request a certificate so they can utilize the certificate to do certificate based authentication. If they cannot contact the Web Components FQDN at time of sign-in, they will be unable to login. For example, at the time of sign-in, if you are in a branch office that does not have a pool but does have either an SBA or an SBS, you will obtain option 43 and make a connection attempt to Web Components. If your WAN link is down or your Central Site that contains your pool is offline, your phone will be unable to retrieve a certificate for certificate based authentication and the phone will not be able to sign-in
Option 120 according to the Technet DHCP documentation for Lync 2010, states Option 120 should point to the Pool FQDN or the Director FQDN. In a Branch Office scenario, the Technet Documentation states where you have a Survivable Branch Appliance (SBA) or a Survivable Branch Server (SBS), you would have DHCP in those Branch Office subnets provide users with the FQDN of the SBA or SBS so they register to a local server for Option 120.
Option 55 is used by the device to ask the server for the values of specific options (in our case 120 and 43).
DHCP Server – Regular DHCP Servers and/or Lync DHCP Servers
If you have a DHCP Server that can handle all the above DHCP Option Codes like Windows, then you’re all set. The problem is, not all DHCP Servers can handle all the above requirements. Lync DHCP is a new function in Lync Server 2010 that was not previously provided in previous versions. For the above codes, not all DHCP Servers will be able to handle these codes. Microsoft was smart about this and came up with their own Lync DHCP Server which is built into all Lync Registrars. A Lync Registrar lives on either a Front End Server, SBA, or SBS. Its job is to listen to DHCP Inform messages that come from a specific type of vendor class client known as MS-UC-Client. When the Lync DHCP Server sees this vendor class client broadcast DHCP Informs, the Lync DHCP Server will provide the necessary DHCP Option values back to a client allowing these devices to sign into the network.
One important thing to keep in mind, you can utilize Lync DHCP even when there is another DHCP Server servicing that same segment/subnet. The Lync DHCP Server does NOT participate in the IP acquisition process. It can live alongside another DHCP Server just fine. Again, the Lync DHCP Server only listens for DHCP Informs from the MS-UC Client vendor class only and only gives back the necessary Lync specific DHCP Option Values so Lync 2010 Phone Edition can sign into the network.
For the Windows DHCP Server or the Lync DHCP Server, Microsoft created a new tool called DHCPUtil which helps clean existing DHCP Options mentioned above and/or prepare your DHCP Server with these DHCP Option Values. You can then run a script called DHCPConfigScript.bat that takes the data provided by DHCPUtil and configures your Windows DHCP Server or your Lync DHCP Server. I will not go into detail about DHCPUtil or DHCPConfigScript.bat in this article. You can read more on that here.
Sign-in Process Examples
Let’s take a look at two examples:
- Sign-in Process using a Hardware Load Balanced Pool
- Sign-in Process using DNS Load Balancing
Sign-in Process using a Hardware Load Balanced Pool
In this example, our Pool is Load Balanced and therefore, just like in Office Communications Server 2007 R2, our Pool Name and our Internal Web Components FQDN can be the same. Because of this, our Option 43 will point to our Internal Web Components FQDN in our Central Site. Because we have an SBA in our Branch Site, we will specify Option 120 to include the local Registrar for that branch site. Our Polycom CX600 would do a DHCP Inform, find the Windows DHCP, find Option 43, contact the Web Components FQDN, get a certificate for mutual authentication, then use Option 120 to contact the local SBA. If the SBA has a certificate that contains a domain (whether it be in the CN or the SAN of the certificate) that matches the SIP URI of the user attempting to connect, the user will be allowed to connect and all is well.
Sign-in Process using a DNS Load Balanced Pool
In this example, our Pool is DNS Load Balanced which changes the process a little. As stated earlier, DNS Load Balancing is for SIP Only. We still need a Hardware Load Balancer for DCOM and HTTP. Therefore, we will have a special FQDN specifically for our Web Components. Everything in the following paragraph is 100% identical to the previous Hardware Load Balancing example.
Our Option 43 will point to our Internal Web Components FQDN in our Central Site. Because we have an SBA in our Branch Site, we will specify Option 120 to include the local Registrar for that branch site. Our Polycom CX600 would do a DHCP Inform, find the Windows DHCP, find Option 43, contact the Web Components FQDN, get a certificate for mutual authentication, then use Option 120 to contact the local SBA. If the SBA has a certificate that contains a domain (whether it be in the CN or the SAN of the certificate) that matches the SIP URI of the user attempting to connect, the user will be allowed to connect and all is well.