As Microsoft Lync Server 2010 was recently released to the general public many professionals will be starting to get their hands on the new UC endpoints designed specifically for use with Lync Server 2010.  My colleague Mike Stacy first talked about the new line of Polycom CX solutions back in May of this year during early beta cycles of the Lync product.

All previous endpoints are still supported in Lync Server with the identical functionality they contained when used in an Office Communications Server environment.  These device include the Polycom CX100, CX200 (LG-Nortel IP8501), CX300 (Plantronics Calisto P540), and CX700 (LG-Nortel IP8540) voice endpoints.  All of those except for the CX700 (the sole member of Tanjay family) are USB-only devices and simply just plug-and-play into a workstation running the Lync client.  They do not run any version of the Lync Phone Edition client.

Previously the CX700/IP8540 was the only device which ran the Phone Edition client, but now the new Aries family of devices (Polycom CX500, CX600, CX3000 and Aastra 6721ip, 6725ip) all run a new version the Lync Phone Edition client.

As there are many past articles covering the requirements for supporting both Ethernet and USB tethered login methods for the Tanjay phones this article will not cover those items individually.  Instead the configuration detailed here will support both device families for internal connections. No Edge Server configuration is included, that is reserved for a future article.



Basically the Tanjay series phones will function in the same way in Lync as in OCS, using the same interface and connection prerequisites.  For example contact photos are not implemented on the Tanjay as that features was not available in Office Communications Server. As there are many article already devoted to managing these devices there is no need to rehash it here.


The new PIN Authentication process greatly simplifies the user sign-in process on stand-alone device now.  As described in the Tanjay version keying a SIP URI, Domain Name, User Name, and Password on the touchscreen was not the most fun experience each time.  With the new version supported on the Aries devices user simply enter their phone extension and PIN to sign-in directly on the phone.  The Enterprise Voice normalization rules was leveraged (just as in Dial-In Conferencing) so that extensions can be supported.  This allows users to key in a short extension (e.g. 7501) versus their entire phone number (e.g. 13125557501).

The PIN used for authentication is the same PIN that is used for Dial-In Conferencing, so the user only needs to remember one unique PIN for logging in to either Aries phones or into audio conferences from PSTN analog phones.  An additional device-specific PIN will need to be set for Device Unlock, but this is asked for each time a new user signs into an Aries device.  This PIN is only used to unlock the device once the inactivity timeout value is reached and can be the same or different, provided that both authentication and unlock PIN policies are configured with the same length and complexity requirements.  Be default the PIN authentication requires 5 digits and the device unlock policy is set to 6; these can be easily modified to match if desired.

The DHCP option required to support the PIN Authentication method can either be added to an existing DHCP server or they can be handled directly by the Lync Server.  The first method is recommended and is the easiest to deploy when working with Windows DHCP services.  But if third-party or hardware-based DHCP solutions are deployed which may or may not supported the additional options required by the Aries devices then it may be beneficial to use the integrated Lync Server DHCP services.  Understand that this alternate approach does not replace the primary DHCP services as the Lync Server will not hand out DHCP leases, it only provides the additional DHCP options to clients which know to ask for them (the Aries phones).  Obviously where ever the device are located throughout the network these DHCP requests will need to be forwarded to the subnetwork where the DHCP server (and/or Lync Server) resides.


This in-depth article covers not only what each of the required components are, but what they do and why they are needed (or in some cases, not). These topics are:

  • Configuring legacy DHCP options and DNS records
  • Understanding the new DHCP options used to support PIN authentication on new Aries phones
  • Verifying the Lync Server configuration
  • Testing PIN Authentication
  • Connecting a Phone

Time Synchronization

Regardless of which family of devices (Tanjay or Aries) both require the ability to properly synchronize their clocks with an external time source.  Now this topic can go down the rabbit hole very quickly as between the different devices and versions of software I have witnessed slightly different behavior.  Yet most often devices are able to synchronize their time without issues as they will fallback to connecting to a hardcoded FQDN ( over the Internet.  So even if your environment is not correctly configured in this area as long as a default gateway is passed to the DHCP client and the phones can connect to the Internet then it’ will work regardless.

After some extensive testing I’ve come up with the basic recommendation to define time server settings in both DHCP and DNS regardless of what device you plan to use and on what levels of code. There really can be no valid argument for omitting time server settings in either system so in an attempt to save yourself some possible heartache take my advice and just configure all of these settings.

Verify NTP Servers

The TechNet instructions for utilizing NTP indicates that the Enable Windows NTP Server group policy setting should be enabled without any mention of what this setting does or why it might be needed.  But most often this step can be omitted as Windows Domain Controllers are already enabled for handling NTP client requests.  Thus the DHCP and DNS time server settings should all be pointed to a domain controller.

  • To validate that the NTP server functionality is enabled, simply run this command from the Windows Command Prompt on the domain controller of choice.

w32tm /query /configuration

In the results look under the [Time Providers] section for the following NtpServer settings.

NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)

The setting Enabled:1 means the server is enabled and actively listening on port 123 for UDP requests for time synchronization data from client.

Additionally run the same command on a standard Windows Member Server (the Lync server, for example) and most likely the NtpServer section will not be listed at all, indicating that the server is acting as an NTP client only.

Configure DHCP Options

Add both the 004 Time Server and 042 NTP Servers options to the Windows DHCP server configuration.

  • Using the DHCP Manager configure the IPv4 Server Options, add the 004 Time Server option, and enter the IP address of the desired domain controller.


  • Highlight the 042 NTP Servers option and enter the same IP address as used above.



Configure DNS Records

The importance of the DNS records really comes into play with externally connected devices, but they are equally important for internal connections.  Once the devices are aware of their SIP domain then they perform Service Locator record lookups in the same domain for a time server (e.g.

It important that each SIP domain in the environment contains an NTP record as the lookup will be based on the suffix of the authenticating user’s SIP URI.  And following the same best practices used in the past of pointing SRV records only to other records in the same domain a new Host (A) record will be required for each domain as well (e.g.

  • Create a new DNS Host (A) record in the SIP domain’s forward lookup zone which resolves to the desired domain controller (e.g.


  • Create a new DNS Service Location (SRV) record in the same forward lookup zone and then define the Host offering this service as the new host record which was just created.  The Service should be _ntp with the Protocol set to _udp and the Port Number at 123.


Also make sure to verify that the Lync Server environment is correctly configured for Automatic Configuration of Lync clients.  At minimum this includes creating a _sipinternaltls SRV record as discussed in this previous article.

DNS Search Lists

DHCP Option 119

When it is appropriate to use option 119 was covered by Jens Trier Rasmussen a few years ago and his article breaks down the process and requirements clearly.  In short if the Phone Edition devices are located in the same subnet as the Windows servers or broadcast packets are fully routed between the clients and server, then setting this option is not necessary.  If the devices are separated from the server via VLANs or physical routing devices which do not allow for NETBIOS broadcast traffic to traverse them, the either (a) configure WINS Servers and add them to the DHCP Options list or (b) use User Principal Name (UPN) format when signing into the CX700.

This same requirement applies to the Aries devices when attempting to authenticate to Lync Server after tethering to the phone via USB to a workstation.  If PIN authentication is utilized directly from the device’s Ethernet connection then option 119 is not necessary (given the previously stated environmental conditions are true).  But considering you cannot prevent users from tethering in most cases it would be foolish to not support NETBIOS based (DOMAINusername) username formats in the deployment.

So, although this is not needed for my lab environment I’ve included instructions on how to add option 119 to the existing DHCP scope; defining a few domains will not hurt anything as long as they are valid.

Configure DHCP Option

  • Using DHCP Manager highlight IPv4 and select Set Predefined Options then click Add.  Enter a  Name of DNS Search List, select a Data Type of String, and enter a Code of 119.  The Description field is optional


  • Under IPv4 highlight Server Options select Configure Options.  Locate 119 DNS Search List and enter the desired domain names in the String field, using a semi-colon to separate additional names (e.g. schertz.local;


At this point the Scope Options (which display both inherited Server Options and Scope-level options) should display at least the following items: 003 Router, 004 Time Server, 006 DNS Servers, 015 DNS Domain Name, 119 DNS Search List.  Additional items may be included which are specific to your existing deployment and are not utilized by Lync.


Aries PIN Authentication

Here is where things start to get interesting as the new Aries devices now leverage a host of new DHCP options.  A number of sub-options are categorized under option 43 and are used for provisioning new devices over Ethernet.  The second option is used to allow the Aries phone to locate a Lync SIP registrar to sign-in to.

What is important to understand is that these options are solely for supporting the PIN authentication process of the phones without first utilizing USB tethering and are not mandatory.  It is possible to tether an Aries phone to a workstation with a Lync client signed-in and the phone will download the root/issuing certificate from the Lync server as well as cache the Lync user’s SIP URI and domain credentials.  Once the phone has successfully connected it can be untethered (and even restarted) and will sign-in to the Lync server over the Ethernet connection automatically.  The cached SIP URI will be used to preform a standard SRV/A client lookup to locate the correct Lync registrar, and the cached credentials will be used to authenticate against the Lync Server.

Just to reiterate this point, as it is commonly misunderstood in the field, there is no requirement that an Aries device (which contains a USB port) must be provisioned first on an internal network in order to download a certificate.  This is incorrect as a brand new device can function in either ‘Better Together’ mode (USB) or in Ethernet stand-alone mode (via PIN auth) once it is first successfully tethered to a workstation with the Lync client. 

That said, the Polycom CX500 and Aastra 6721ip endpoints do not include USB ports for tethering so if either of those devices are to be used then the new DHCP options must be deployed on the internal DHCP server.  And as a general best practice these options should really be deployed as it’s not a great user-experience to always require USB tethering each time a new user needs to sign-in to a device.

DHCP Option 43

As previously mentioned Option 43 is not really a single option but a number of sub-options which tell the phone where to locate the Certificate Provisioning service on the Lync server.

Option Number
Option Name
ASCII Value (example)

When reassembled into a single value these sub-components build a complete URL as Option 43 to the DHCP client.


DHCP Option 120

Once the certificate is downloaded to the phone then a valid Lync registrar server needs to be located.  The value of Option 120 will be the FQDN of the Lync server which will handle authentication requests from the phones.  This must be a Lync server as the Aries devices cannot sign into a down-level OCS 2007 or 2007 R2 server.

Option Number
Option Name
ASCII Value (example)
120 UCSipServer lync.schertz.local


The TechNet documentation on this option currently states that “the pool FQDN suffix must match the user’s SIP address”.  This statement is under review and should be updated to more correctly explain that it is not a requirement that the suffixes match.  In the example here I have used the local AD namespace of schertz.local to reference the Lync server’s actual hostname.  This value is in the Lync server’s certificate and thus any users in the SIP domain of will still connect successfully.

Configure Windows DHCP Server

Luckily setting up these options is much simpler than actually understanding what they do.  Microsoft has included a utility and script with Lync Server which will automatically add the appropriate values to a Windows DHCP server.  Currently this utility is only supported on 64-bit operating systems so if your Windows DHCP server is running on an older 32-bit server then you will have to run the commands separately.  A completely manual process will be required if any non-Windows DHCP servers are used in your environment.

  • If using 64-bit Windows DHCP servers copy the DHCPUtil.exe and DHCPConfigScript.bat files from the following default location on the Lync Server to the Windows Server(s) running DHCP services for subnets where any phones will be connected.

%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPUtil.exe

%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPConfigScript.bat

  • If using 32-bit Windows DHCP servers then only copy the DHCPConfigScript.bat file from the Lync server to the DHCP server.  The DHCPUtil.exe tool will be run on the Lync server locally and the output will be used to call the batch file manually on the DHCP server.

Executing DHCPutil.exe /? will return most of the available switches and a quick read-through appears to indicate a number of switch will be necessary.  The keys to using this commands are that (1) if a single Lync Server is deployed in the environment then only the -SipServer is required as the same FQDN will be used for the other settings and (2) the –RunConfigScript option needs to be included otherwise the command will only printout what changes it ‘would’ make but will not actually do anything.

  • So this next step is optional (and purely for education) when dealing with a 64-bit DHCP server configuration, but must be run on the Lync Server for 32-bit DHCP server configuration.

DHCPUtil.exe -SipServer lync.schertz.local

(If the error “application has failed to start because its side-by-side configuration is incorrect” then take a look at Mike Stacy’s blog article for the resolution.)

The following output explains that you must either (1) re-run the command with the aforementioned –RunConfigScript or (2) manually execute the example command which contains the hexadecimal strings.

SIP Server FQDN : lync.schertz.local
Certificate Provisioning Service URL : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc

Option 120: 00046C796E63077363686572747A056C6F63616C00

Vendor Class Identifier: MS-UC-Client
Option 43 (for vendor=MS-UC-Client):
        sub-option 1 <UC Identifier>: 4D532D55432D436C69656E74
        sub-option 2 <URL Scheme>: 6874747073
        sub-option 3 <Web Server FQDN>: 6C796E632E7363686572747A2E6C6F63616C
        sub-option 4 <Port>: 343433
        sub-option 5 <Relative Path for Cert Prov>: 2F4365727450726F762F43657274

To configure DHCP Server with appropriate values, you can do one of the following things:
        1. Run DHCPUtil on the DHCP Server: use ‘-RunConfigScript’ switch
        2. Run the following command on the DHCP Server (modify the path of DHCP
ConfigScript.bat appropriately):
“C:\DHCPConfigScript.bat” Configure MS-UC-Client 00046C796E6307736368657274
7A056C6F63616C00 4D532D55432D436C69656E74 6874747073 6C796E632E7363686572747A2E6
C6F63616C 343433 2F4365727450726F762F4365727450726F766973696F6E696E6753657276696

  • For 32-bit DHCP server configuration capture the command line string listed under item #2 at the end of the output and then execute it locally on the DHCP server

C:>DHCPConfigScript.bat Configure MS-UC-Client 00046C796E6307736368657274
7A056C6F63616C00 4D532D55432D436C69656E74 6874747073 6C796E632E7363686572747A2E6
C6F63616C 343433 2F4365727450726F762F4365727450726F766973696F6E696E6753657276696

  • For 64-bit DHCP server configuration re-run the DHCPUtil command locally on the DHCP server with the RunConfigScript switch to apply the changes to the DHCP server options.

C:>DHCPUtil.exe -SipServer lync.schertz.local –RunConfigScript

The script will open in a new window and the various netsh commands will be executed with the secondary closing upon completion.

  • To validate the new changes highlight the server name in DHCP Manager and refresh the console.  Expand IPv4 and then highlight Server Options to the new options should be listed.


  • To view the details of these new options simply view the properties of any one entry in this list and the Advanced option list should appear, showing the MSUCClient Vendor Class options.



Configure Lync Integrated DHCP (Alternative Configuration)

This step is optional and will not actually be used in this article, but it is important to understand there are two choices here.  As previously explained the DHCP options 43 and 120 can be offered by either the same DHCP server scope which provides IP addresses to requesting clients, or they can be provided directly by the Lync Server, after clients have received an IP address fro the primary DHCP server.

So basically the scenarios are either:

  1. All DHCP options on configured on a standard DHCP server
  2. Most DHCP options are configured on a standard DHCP server and options 43 & 120 are configured on a DHCP ‘lite’ service which runs on the Lync Server.

Again, only configure this next setting if the devices will be installed in the same subnetwork that the Lync Server is installed in or if the current DHCP server does not support the ability to add the 43 sub-options.  Only enable this option if the previous configuration steps were not performed and the primary DHCP server does not or cannot handle the 43 and 120 options.

  • From the Lync Server Management Shell enter the following cmdlet.

set-CsRegistrarConfiguration –EnableDHCPServer $true

Validate Options 43 & 120

The DHCPUtil tool can also be used with the –EmulateClient switch to test that the new options are correctly installed and will be presented to the DHCP client as expected.

Select a workstation or server other than the DHCP server itself to run the client emulation test.  The client emulate test does not function from the DHCP server locally .  Also select a test host with a single active network adapter as there is a bug which makes the test fail with multiple adapters enabled.  This test should also work from the Lync server but make sure to also test from a client on the same subnet where the phones will be deployed.

  • Copy the DHCPUtil.exe program to a test computer and execute the following command.

DHCPUtil.exe -EmulateClient

If a Windows Security Alert appears for the DHCP Configuration Utility click Allow Access.  The results will list the contents of both the DHCP client’s INFORM packet and the DHCP server’s ACK response packet.

Firstly the Option Field portion of the INFORM packet shows how the client uses Option 55 to ask for specific options 120 and 43 from the server, as well as offers the known Vendor ID of MS-UC-Client.

DHCP: Option Field
    DHCP: Server Identifier(  54) = (Length: 0)
    DHCP: Client Identifier(  61) = (Length: 7) ☺ (0100155D670224)
    DHCP: SIP Server( 120)        = (Length: 0) enc:0  ()
    DHCP: Host Name(  12)         = (Length: 4) LYNC
    DHCP: Vendor Identifier(  60) = (Length: 12) MS-UC-Client
    DHCP: Param Req List(  55)    = (Length: 2) 120 43
    DHCP: Vendor Info(  43)       = (Length: 0)  ()
    DHCP: End of this option field

In the returned ACK packet the same Option Field section now lists the options 120 and 43 in the DHCP server which have been supplied to the DHCP client.

DHCP: Option Field
    DHCP: DHCP MESSAGE TYPE(  53) = (Length: 1) DHCP ACK
    DHCP: Server Identifier(  54) = (Length: 4)
    DHCP: Client Identifier(  61) = (Length: 0)  ()
    DHCP: SIP Server( 120)        = (Length: 21) enc:0 lync.schertz.local (00046
    DHCP: Host Name(  12)         = (Length: 0)
    DHCP: Vendor Identifier(  60) = (Length: 0)
    DHCP: Param Req List(  55)    = (Length: 0) 0 0
   DHCP: Vendor Info(  43)       = (Length: 90) ☺♀MS-UC-Client☻♣https♥↕lync.sch
♥NAP (010C4D532D55432D436
    DHCP: End of this option field

The final portion should display these option values (SIP Server and Certificate Provisioning URL) in a more readable format along with a Success status.

Result: Success
DHCP Server :
SIP Server FQDN : lync.schertz.local
Certificate Provisioning Service URL : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc


Lync Server Configuration

At this point the environment is ready to connect both Tanjay and Aries devices.  But before a user can sign-in directly from a phone the Lync user account must first be enabled for Enterprise Voice (for both device types) and a PIN defined (Aries only).

Enable Enterprise Voice

  • To enable a Lync user account for Enterprise Voice create new account, or edit an existing account , and select Enterprise Voice from the Telephony drop-down and then define a unique Line URI in the proper format (e.g. tel:+<number>).  This process is discussed in more detail in this previous blog article.



  • Using the Lync Server Management Console locate and highlight the user account and then select Set PIN… from the Action menu.  Enter the desired PIN, adhering to any policy requirements.  The default policy will only accepts PINs of 5 digits and series or repeating numbers (e.g. 12345 or 44444) cannot be used.


  • Alternatively the Lync Server Management Shell can be used to set the authentication PIN on Lync user accounts by using the following Set-CsClientPin cmdlet.

Set-CsClientPin -Identity Laura -Pin 14753


Enable PIN Authentication

The PIN Authentication method is already enabled by default on the Lync Server, but it is a good idea to first validate that is enabled.  If for some reason it is not, or a different policy (other than the Global) is in use which it is disabled on, then PIN authentication using the following commands.

  • Enter the cmdlet Get-CsWebServiceConfiguration in the Lync Server Management Shell and verify the value of the UsePinAuth setting is ‘True’.



  • If the value is False (it should be enabled by default) then use the following cmdlet to enable it on the global policy.
    Set-CsWebServiceConfiguration -Identity Global -UsePinAuth $true

Alternatively the Lync Server Control Panel (LSCP) can be used to check the current

  • In the LSCP go to Security > Web Service and look at the Global object’s properties for verify the Enable PIN authentication setting is checked. (The PIN check in the previous window also shows the same setting.)



Bootstrap Emulator

The easiest way to test that the configuration is correct an working is to use the Lync Phone Edition emulator which is spawned by using the Test-CsPhoneBootstrap cmdlet.  This process can be run from the Lync Server itself, assuming that DHCP server responses can reach the subnet where the Lync Server is installed.  In a flat network this is no problem, but in a larger, segmented network it may not work locally.  In that case the Lync Server Management Console can be installed on a workstation in the correct subnet and the test run from there.  (Or if you are feeling adventurous just fire up that shiny new CX600 and see if everything works.)

  • Run the following cmdlet from the Lync Server Management Console and supply the extension number and PIN for an Enterprise Voice enabled Lync user account.  (Note that in this example only four digits are supplied as the PhoneOrExt value as the Lync Server contains Normalization Rules which will translate that 7501 string out into a full RFC3966 format of +13125557501.  For more details see Part 3 of the Lync deployment articles.)

Test-CsPhoneBootstrap -PhoneOrExt 7501 -PIN 14789

As this process dumps a ton of output I will just highlight the important items.

  • The client constructs a DHCP request packet, specifically asking for the required options that Lync Phone Edition needs. 

Constructing a dhcp packet
Successfully added dhcp option
Successfully added dhcp option
Successfully constructed dhcp packet

  • The response from the DHCP server is deconstructed with the various DHCP options. (Some of the text will be goofy ASCII characters when read in plain text.)

Constructing a dhcp packet from received raw data
Extracting DHCP Options
DHCP Packet successfully constructed

Message Type : DHCPACK
Option43 : ☺♀MS-UC-Client☻♣https♥↕lync.schertz.local♦♥443♣%/CertProv/CertProvisioningService.svc?♥NAP
Option55 :
Option60 :
Option120 :  ♦lyncschertz♣local
Other options : 6♦??g¶☺♦???

  • A standard HTTP connection is attempted to the Certificate Provisioning service on the Lync Server.  If the connection is successful then the client will request to download the root certificate for the Lync Server’s configured certificate.

Connecting to web service : http://lync.schertz.local/CertProv/CertProvisioningService.svc 
Using anonymous authentication 
Successfully created connection proxy and website bindings 
Attempting to download certificate root chain 
request created 
GetRootCertChain() webservice call successful

  • With the root certificate downloaded the client then connects to the Lync server over SSL (443) and requests a Web Ticket.

Connecting to web service : https://lync.schertz.local:443/WebTicket/WebTicketService.svc
Using PIN authentication
Successfully created connection proxy and website bindings
Requesting new web ticket
Sending Web-Ticket Request:

  • The  20 or so lines of XML after the text below is comprised of the request data.


  • A Web-Ticket response is then received from the server, followed by a hundred or so lines of the XML data.  Don’t read this if you value your free time.


    • Another new connection is made from the client to server via SSL.

Connecting to web service : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
Using Webticket Proof authentication
Trying to download MEX data from
Searching for end point with name CertProvisioningServiceWebTicketProof
Searching for end point with name CertProvisioningServiceWebTicketProof
Found endpoint with name CertProvisioningServiceWebTicketProof
Using CertProvisioningServiceWebTicketProof endpoint
Successfully created connection proxy and website bindings
Attempting ResolveUser()Creating WebTicket security token request
ResolveUser() webservice call successful
Connecting to web service :
Using PIN authentication
Successfully created connection proxy and website bindings
Requesting new web ticket
Sending Web-Ticket Request:

  • A second Web-Ticket response is received. More excitement. I’ll spare you the screenshot.


  • The response is handled by the client and should complete with a successful GetAndPublishCert webservice call.

Connecting to web service : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
Using Webticket Proof authentication
Trying to download MEX data from
Searching for end point with name CertProvisioningServiceWebTicketProof
Searching for end point with name CertProvisioningServiceWebTicketProof
Found endpoint with name CertProvisioningServiceWebTicketProof
Using CertProvisioningServiceWebTicketProof endpoint
Successfully created connection proxy and website bindings
Requesting certificate for
EndpoinID:4815e36e-4028-5c2f-99c6-7e95082e4fc8Creating WebTicket security token request
GetAndPublishCert() webservice call successful

  • The bootstrap test should then finish with a brief summary report.

TargetUri  : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
TargetFqdn : lync.schertz.local
Result     : Success
Latency    : 00:00:02.3250824
Error      :
Diagnosis  :

Polycom CX500

The final test is to connect an Aries device without a USB interface (no cheating!) to validate that everything is setup correctly.

  • Power-on the phone and wait for the animated logon-screen to appear.  Press the select button as demonstrated.


  • Enter the same Phone Extension and PIN of the user account previously used with the test bootstrap method.

image     image

  • The Signing In process while briefly display “Contacting Time Server” followed by “Connecting to Lync Server” for a few seconds.
  • Indicating a successful connection, the next prompt will ask to define the temporary phone-unlock PIN which will be used for the duration of the time this account is signed into this phone.  This PIN is retained between phone reboots and it only lost when either the user is signed-out or a factory-reset is performed.

image     image

By Jeff Schertz

Site Administrator

111 thoughts on “Configuring Lync Server for Phone Edition Devices”
  1. Great article!

    I feel its a shame however, that the more expensive Tanjay phones lack some of the features like the display photo functionality. Tanjays have these huge touchscreen LCDs, I dont understand why this feature is not utilized on those. Prodivind the same feature set as in OCS R1/R2 is not an excuse. If I make a greenfield deployment with Lync only, and CEOs want the bigger phones, it turns out those have limitattions, I cannot tell them "thats because OCS didnt have photo functionality".

    1. Richard, Although I agree that it would be nice to see a newer client on the Tanjay devices I'll have to assume that Microsoft did not have the resources available during development to write an entirely new client for these previous generation phones in order to add a few minor features (like photos). I'd guess that those development resources are reserved for a brand new client for future devices.

      1. Hi jeff,

        recently i found my contacts in snom phone not showing. earlier it was coming same like lync client.
        recently we did exchange 2016 and AD

        1. I don’t believe the SNOM phones have kept up with the latest Microsoft server versions so there may be an issue now that you’ve moved to Exchange Server 2016.

  2. Hi Jeff,
    great Article thanks!
    I have a quastion, did you install an Archiving/Monotoring Server?
    Maybe you can post any pictures i have one bad problem.

    1. I have not yet deployed that role in my lab for the purposes of documenting it but it's on my (ever-increasing) to-do list.

  3. So if you have had your certificates issued from a public CA and not used self signed ones, is it still necessary to include the "Certificate Provisioning Service URL"?

    1. Dave, yes. The certificate provisioning service is not related to the X.509 certificate that is issued to the Lync server for TLS communication but is instead what the Lync client contacts to be issued 'web tickets' in order to authenticate and communicate.

  4. Jeff, can you clairify what the procedure is for externally publishing these DHCP scope options for when handsets are not going to be located on the same site/subnet as the Lync server but will connect in over the Lync Edge server?

    Should it be just a case of issuing "DHCPUtil.exe -SipServer <fqdn of edge server> –RunConfigScript" ?
    Can the record exist in public DNS?

    Also, are you aware of any restrictions on using Server 2003 x64 DHCP? (i seem unable to set option 119 DNS Search List anywhere)



    1. Dave, PIN Authentication will not operate through and Edge Server to configuring the DHCP options alone would not be enough to allow the Common Area Phones to operate off-network. If you have a location with a full site-to-site VPN connection where the internal Lync server is directly reachable, then you could leverage PIN Authentication. The configuration is the same, you'll just either need to forward DHCP replies in that network to the desired DHCP server (typically not desirable) or configure the local DHCP server with the options. so in short, these phones do not work on the Internet without first tethering them to a workstation.

      I can confirm that DHCP service in Windows Server 2003 functions the same as I have devices running in environments with both 2008 and 2003 DHCP servers. For 32-bit 2003 servers the configuration is roughly the same except that you have to run the DHCPutil command on the Lync server (or any 64-bit server) without the -RunConfigScript option. Then take the command output and copy the DHCPConfigScript to the 32-bit DHCP server.

      1. Jeff,

        As a follow up to Dave's question, do you think the following scenario can be made to work:

        -Location 1 (data center)
        …Front End Server (GoDaddy cert on external webservices / internal cert on default and internal webservices)
        ……Ran the GoDaddy cert tester to make sure intermediate was configured properly
        …Access Edge Server
        …Reverse proxy for Front End Server that maps an external IP (80/443) to an internal IP (8080/4443)
        ….. . works but asks for domain credentials
        ….. . returns 403 forbidden

        -Location 2 (remote office without a VPN in to data center, without Lync, not connected to the data center domain, has Windows 2008 R2 server, and has DHCP)
        …dhcputil -webserver -sipserver -runconfigscript

        I gave it a whirl today. The command "dhcputil -emulateclient" returns success. I setup DHCP 42 to

        When I run test-csphonebootstrap -phoneorext *** -pin ******, I get "Attempting to download certificate root chain request created" followed by "Http request was forbidden with client authentication scheme 'anonymous' "

  5. Is there a way to use the Lync registrar to provide option 120 to phones located in a different subnet where broadcast packets and DHCP requests are blocked? This is specifically for pin auth to work outside of the Lync servers's subnet

    1. I suppose you could forward DHCP requests on the router to that network, but then you'd have to have the standard DHCP server placed in the same destination network. I have not tested using the Lync-integrated mini-DHCP server if routed networks, it is really designed for use in test environments or small businesses with a single network.

    1. I'd guess either you had the incorrect WebServer FQDN defined during DHCPutil execution or there is a port connectivity issue between the phone and Lync Server. The best troubleshooting tool is to use a network packet capture program (NetMon or Wireshark), but to isolate and capture traffic to/from the phone you'll need to connect the phone and a computer it to an unmanaged, unswitched basic Ethernet hub. Up-link the hub to the rest of the network and then run the network capture tool on the laptop in promiscuous mode.

  6. Excellent post.

    I was searching for the role of DNS for LPEs and landed here. From what I can see, if the DHCP server is providing options 42 (NTP), 43 (Vendor), 44 (Netbios) and 120, there is no need for special SRV/A records. Is that an accurate observation?

    Does the LPE even need a DNS server for resolver function if WebServerFQDN and UCSipServer values are IP addresses?

    1. I have not validated this yet but those records are still needed by the standard client and for device tethering. In every environment these records are typically created during the initial server deployment anyways. Also I wouldn't think that an IP address could be used in place of FQDNs for those settings as just will standard TLS and MTLS communications the name has to match a value in the server certificate.

  7. Is there a way to turn off the unlock pin? for example, while logged in, that extension will always be the same. If the user is looged out, then another can login using a different extension.

    1. Yes, you can disable this behavior either by unchecking "Enforce Device Locking" from the Clients > Device Configuration section of the Lync Control Panel, or by using the "Set-CsUCPhoneConfiguration -EnforcePhoneLock $FALSE". Also you can either disable this on the default global policy, or create a new Site-level Device Configuration policy and remove the phone lock option there instead. This depends on your environment and desired results.

  8. On W2K3 "w32tm /query /configuration" exit with error "The command /query is unknown". I don't see /query and /configuration as valid parameters? Please clarify. Thanks

  9. Ahsan, the /query switch was added in Windows Server 2008 and is not available on the Server 2003 version of the w32tm command.

  10. Hello Jeff I have some problems with Microsoft Lync phones (CX600, aastra 6725ip):

    I can use phone normaly with my lync client. All functions works good

    When I shutdown my pc, and then restart cx600 or 6725ip, phone will automaticaly log on server., but ….

    when I try open calendar on phone I take message: microsoft exchange is unavailable. Please contact you support team.

    On phones I have firmware 7577.250

    I have exchange 2010 sp1

    On my phones I can search tel. numbers from AD.

    On my lync client I dont have messages about problems with connecting to exchange – but still I have that problem on lync phones. I check that on 2-3 users.

    Thanks a lot for help.

    1. Are you tethering the phones first via USB and entering the Windows credentials prior to shutting them down? If so then the device should still connect to Exchange using cached credentials for some time after, but if you are not tethering them first but only using PIN Authentication then they will never have the ability to authenticate directly to Exchange.

  11. Hello Jeff,
    I have some concerns about the Lync Phone (ex: CX500, CX600, 6721i, 6725i), could those phones work together with Lync client.
    That means when i can simultenous log in Lync Phone and Lync Client at the same time???

    Thanks a lot for help.

    1. Yes, the Lync Phone Edition devices support MPOP (Multiple Points of Presence) so you can be signed into multiple clients at the same time and they all work together to correctly update and broadcast your presence and status correctly.

      1. Many thanks Jeff, I'm a Lync Technical Specialist in Viet Nam, hope we could get in touch for further cooperation.
        Currently, I'm dealing with PBX Interoperability, could you recommend some typical scenarios?

        Thanks a lot for help.

  12. Hi Jeff, we are using lync here and now we will use polycom phones. CX600 needs option 43 from DHCP configured but we use SonicWall as DHCP Server.

    You have some knowledge about this? How I should configure sonicwall option 43?

    Thanks for helping us.

    1. I have not attempted to configure a SonicWall device for the DHCP settings yet so I don't know if they will support this or not.

  13. estimated
    I have an X64 with Windows 2003 Enterprise DHCP but the command did not work in 2003, I get an Error

    The system cannot execute the specified program.

    This procedure is supported for Windows 2003 or is it just for 2008

    1. The procedure works on Server 2003 as I've succesfully configured a few 32-bit Server 2003 systems for PIN auth.

      1. If DHCP is on server 2003, you can't execute the DHCPUtil.exe utility on the DHCP server, but rather you execute it on the Lync server and then cut and paste the results and execute on DHCP server.

  14. Thanks Jeff – really, really helpful – especially the bit about the time server scope options – it made the difference: I just got a "an account could not be found" error on this until I scoped option 43.

    1. I have the same problem. After test-csphonebootstrap I got the error: A certificate chain could not be built to a trusted root authority.
      You wrote that update fixed the problem. Could You write me what exactly was fixed?
      Did You update only lync server or other servers were also to be updated?

  15. Anyone have the LG-Nortel 8540's and after sign-in get the "Acquiring IP Address…." message? We have 600 of these phones and about 10% have this problem. I assume it's the NIC because the PoE switch never sees the phone MAC. Have tried the reset button and the #, * reboot. Just wondered if is's common and if anyone's ever made it work?

  16. Hello,
    when I run the Command:
    Test-CsPhoneBootstrap -PhoneOrExt 7501 -PIN 963852
    I get this error back:
    TargetUri :
    TargetFqdn :
    Result : Failure
    Latency : 00:00:00
    Error : Could not extract the option value for option codeVENDOR_SPECIFIC_

    Diagnosis :
    Has anybody an Idea what is wrong??

    Thanks for your help

    1. It appears that your DHCP configuration is invalid. Take a look at my more recent article "Understanding DHCP Option 43" for more details on reading and validating your current configuration.

  17. I don't understand… Lync is setup to support two domains: and domain.local (our AD domain). My Lync PC Client can login without a problem with either or peter@domain.local (obviously after changing the login domain in the Lync administration webpage), however my desk phone (6725ip) only works with peter@domain.local. When trying it fails.

    Looking at the Wireshark logs I can see it finds the right server (lync.domain.local), sends a Client Hello and receives a Server Hello, Certificate, Certificate Request and Hello Done, however straight after the phone closes the connection. It seems to not trust my certificate. It's strange, as it does trust my certificate when logging in with the domain.local-accountname.

    The certificate does contain all 'default' domainnames as SAN's and lync.domain.local as commonname.

    Anyone any ideas why my phone doesn't accept the certificate?

    1. Hi Peter, you have to publish DNS-Records for your Domain and assign certificates to your frontendpool or directorpool wich include the fqdn in the san-certificate, then it will work, I had same problem with phones on LYNC 2013..


        1. This depends on what FQDN you’ve selected for automatic configuration and if you have SRV records deployed or not. A ‘’ entry is not applicable for LPE.

  18. How long are certificates cached?
    Is the amount of time different for remote devices that connect by USB tethering?
    Will a remote device with a cached cert maintain the cert through a reboot if the USB tether is removed?

    1. They are cached permanently, until you either sign-out or perform a manual reset of the phone. It doesn't matter which process is used to sign in.

  19. Jeff,__Does this work over the edge as well too? I have a couple of VVX500's that we cant get to log on _and its becoming a real bugger

    1. Yes, external SIP registration via Edge and all ICE/STUN/TURN media scenarios are fully supported. Make sure that the certificate assigned to your Edge server is one that the UCS software trusts by default (check the UCS Administrator Guide online) and if it's not then you'll need to manually import that CA's Root cert(s).

  20. Hello, Jeff! Thanx for all the info you always bring to us!! I have a question regarding CX600 phones and later… When connecting them to the intranet, as there are a few firewalls keeping ports closed, etc, and although the typical ports where open (443, 80, and I do not remember all the others, I am talking on behalf of a client), the phone will not authenticate. BUT, when he opens all ports (it is a Fortinet, and sets it up as "ANY" ports available), the phone authenticates smoothly. Which ports are requested, then, by the phone to be open? Thank you again!!

    1. Lync Phone Edition uses all the same ports that the Lync clients use for communications so you need to make sure you've addressed all ports and protocols listed in the TechNet documentation Also make sure that HTTP (TCP80) is addressed as the phones will need to use that first to download the root CA certificate before switching to HTTPS (TCP443) as discussed in this article.

  21. I keep getting an installer error as I try to run DHCPUtil.exe. First, it seemed I needed to install C++ Runtime 2012. Did that and now I have another error: The procedure entry point __crtCreateSymbolicLinkW could not be located in the dynamic link library MSVCR110.dll.

    At this point, it might just be easier to manually setup the DHCP Options, since that's all the script does, correct?


    1. I would just try running the utility on a different server and than copy over the output to run the actual batch file as all that does is execute 'netsh' commands which any modern Windows Server OS supports

  22. Hi Jeff,

    We are setting CX600 in our environment and I configured the DHCP option 42, 43 and 120. The way that the CX600 will be used is by PIN logging. Do we need to configure the DNS record to setup the NTP server for these devices?

    Please, let me know about it.

    1. The NTP record is not a requirement as if the phones have Internet access then they will be able to sync the time using the hard-coded Microsoft time servers. But is is highly recommended to add that configuration so that you are using local servers for time sources and not relying on public Internet servers to do so.

  23. Thanks Jeff for all your help in this area. We have both 4 and 5 digit extensions at our location. Pin Auth works for numbers with a 4 digit extension but not a 5 digit one. Even if I enter the full phone number for the 5 digit extension user, auth still fails with a message that says that cannot sign in. Please check your sign-in address, domainuser name and password.
    When I try the same number and pin from the server with the Test-CsPhoneBootstrap i get success. do you have any suggestion as to where to look next?

    1. I might guess that your Dial Plan rules are not correctly written to handle both 4 and 5 digit phone number extensions. The phones will use the dial plans to identify extensions and normalize it into a full phone number for the purposes of PIN Authentication.

  24. Hi Jeff,

    I got the provisioning with USB working. However, autoprovisioning with PIN is still a problem. In the end of the 'test-csphonebootstrap' commandlet I get the following error:

    Web Service Url :
    Using PIN authentication with PhoneExt : 0125 Pin : 5883
    GetWebTicketActivity completed.
    'GetWebTicket' activity completed in '0.0586075' seconds.
    'GetCSCertificate' activity started.
    Trying to download a CS certificate for User : endpoint :
    Web Service Url :
    Could not download CS certificate from web service.
    – Web service Url is valid and the web services are functional
    – If using Phone NumberPIN to authenticate, make sure they match the user uri

    – If using NTLM\Kerberos authentication, make sure you provided valid

    Apperantly the URI and PIN are correct, because the server acknowledges the SIP-address. Also I tested the URL for the CertProv-service, also in working order (with internal root CA)

    get-cscertificate shows me the correct root CA is being used on the particular Web Service. Any idea what I'm missing here?


    Martijn den Ouden
    The Netherlands

    1. It sounds like you have everything configured correctly so I can't really say what the issue may be. Make sure that you have HTTP (TCP 80) traffic allowed internally from the phones to the Lync Front End pools, that is the most common issues. the test cmdlets will work fine on the server but the phones would be unable to download the certificate if they only have access to the Lync Server over 443 and not 80 as well. With HLB scenarios I've seen HTTP traffic omitted from the configuration all too often. See this article for more details:

      1. Earlier today I finally managed to get over this (small but irritating) hurdle :). Windows Server 2012 R2 apparently handles TLS caching a little different than before. gives us a workaround for that. Bit weird that, although this article is from October 2013, the Lync-team didn't include the fix in the January update of Lync Server 2013….

        Anyway, that fixed above error. Now still troubleshooting the fact that some accounts do and other accounts don't want to use PIN authentication and the FE just loses contact with the OWA from time to time…. :S

  25. Thanks Jeff for all your help in this area. We have both 4 and 5 digit extensions at our location. Pin Auth works for numbers with a 4 digit extension but not a 5 digit one. Even if I enter the full phone number for the 5 digit extension user, auth still fails with a message that says that cannot sign in. Please check your sign-in address, domainuser name and password.

    1. I would guess that something is not correct with the Dial Plan normalization rules as there is no limitation on the digit length used.

  26. Great stuff Jeff. Question…when trying to configure SBA and resiliency…
    – The SRV record points to a pool at the central site.
    – Option 120 at each branch points to the pool at the central site.
    – SBA is branch users primary registrar.
    – AD integrated DNS servers available at each branch.
    In the event of a WAN outage, SBA users would not be able to get to the central site and be directed to their primary registrar at the SBA correct? I assume they would be cut off from getting that information while the WAN is down unless they have previously logged in and the info is cached. So my questions are as follows:
    1) Do the full Lync clients cache their primary registrars and backup registrars so if they can't reach SRV target they can proceed with cached info?
    2) Do Lync Phone Edition phones cache their primary and backup registrars so if they can't reach the Option 120 SIP server, then can still proceed?
    3) Should Option 120 at each branch point to the SBA instead? And if so, what happens in the event of an SBA failure? Will the Phone Edition phones attempt their backup registrar?
    4) Lastly (sorry for so many), is it a good strategy to create multiple SRV records with central site as first priority and SBA's with lower priorities? That way during a WAN outage, Lync clients can try the other SRV records at login…

    A lot of questions, I know! Any insight would be greatly appreciated.

    1. It's hard to address all of those as it depends on the topology, but just keep this in mind when planning: DHCP Option 43 points to a web service while 120 points to a registrar. So in SBA scenarios 43 must still point back to a real Lync Pool, but 120 can point to the SBA. In WAN outage scenarios any Lync clients which have already successfully signed in at least once prior to the outage will still work as they will already have been given a valid TLS-DSK client certificate; they have no need to contact the webticket service so they can still register directly to the local SBA. But because the SBA does not have any web service like a real pool then new clients and devices cannot sign-in during this outage, they must wait until the WAN connection is restored to connect to the Lync Front End pool. Also, Primary/Backup registrar failover works on the phones the same way it does on desktop clients.

      1. Jeff, thanks so much for your reply! So helpful as always. A question that I have with SRV records is that we have AD integrated DNS so every DNS server points to the same target pool at central site (even branch DNS servers). Is it an acceptable plan to have multiple SRV records with lower priority that point to the SBA's at each branch so that during a WAN outage, the SBA full clients can still get connected?

  27. Hi Jeff,

    We are running a number of the Polycom CX range Lync Phone Edition devices as well as some Aastra 6725ip Lync Phone Edition devices and I have a query about the DHCP option 006 DNS configuration.

    If we set two DNS servers in the scope options, when we check the Lync phone System information, it only shows the first DNS server address (second address is nowhere to be seen). I have used the send logs function and checked over them on the front-end, but no DNS addresses are mentioned at all (I was hoping it might show both, even though the sysinfo doesn't).

    I would like to know whether in the event of the first DNS server being unavailable, would the second server specified in DHCP option 006 be used by the Lync phone ? or is the phone not even aware of it ?


    1. Sam, while the System Information menu only displays the first entry the device is aware of of the other for example I exported this from the registry of my phone which shows that both my primary and secondary DNS servers are stored in the device configuration: "DhcpDNS,REG_MULTI_SZ,".

  28. Trying to get Polycom and Snom phones to connect to Lync. They were not connecting and I did some research and came across several of your articles. Environment is Lync 2013 and Windows Server 2012 running in VMWare. Ran a Test-CsPhoneBootstrap – verbose and it passes all the parameters except download CS Certificate from Web Service. the endpoint showing during the test is STEpid, and I’m not sure that is what should be showing. I’m currently at a loss as to why this is failing. I have verified the pool name and FQDN are correct and I’ve reloaded Certificates from the Root CA server. I’m thinking this test is an internal test and until it runs successfully no phone will register with the FE server, am I correct?

    1. If that configuration does not yet function than no Lync phone will be able to register using PIN Authentication. Any phone that supports NTLM authentication will still work fine regardless of the DHCP 43/120 configuration.

  29. Hello Jeff,

    I have found your directions to be a great help with our first MS Lync 2013 deployment! I was able to get the various functions of Lync up and running in our environment and now are looking at testing VoIP phones in the environment. Before I try to register the IP phones I decided to test the function of the server internally using the Test-CsPhoneboostrap -verbose. Everything passes to the point of downloading a CS certificate from the Web Service and fails. My team has verified the DNS and DHCP settings are in place on our Enterprise server. The unique thing about our environment is we are currently changing from a 5 domain network structure to a single domain and we have two forests active to facilitate the switch. Do I need to have the DHCPutil.exe and the DHCPConfigScript (options 43 and 120) operating on both DNS/DHCP forests to let the Test-CsPhonebootstrap -verbose run through it’s process completely?

    1. This depends on if DHCP requests are forwarded from all network segments on to the Lync Server or configured DHCP server. If you have separate scopes for different network segments than you’ll need to configure the 43/120 Options on all DHCP servers.

  30. Is it possible to configure the Certifcate Provisioning service as Scope Options as opposed to server options? I ask because these obviously show in all my DHCP scopes.

    Great article BTW

  31. Very nice article. However, it seems to apply to the Lync Server solution. I am trying to use a CX600 with Lync online, and have trouble configuring that phone. Will you be writing a special topic on how to configure Lync phones to use Lync online? My company is too small to afford a solution hosted on a local server..

  32. Hi Jeff

    Polycom Exchange integration doesn’t work fine. Error: Microsoft Exchange is unavailable’. We have Exchange Hybrid with Office365 & use Ping SSO (ADFS). When user’s mailbox is in On-premise then the EWS works fine in the phone. However if it’s moved to Office365, then it stops working.

    The Ping SSO uses a Wild card certificate: * & the root CA is Commodo RSA Certification Authority which is not listed in the supported list of certs for phone edition.

    Taking Wireshark, there are no TLS failures but from phone logs we get the below error:

    Ignoring E_INVALIDARG error when resetting INTERNET_OPTION_CLIENT_CERT_CONTEXT – InternetSetOption failed (0x80070057)

  33. Hi Jeff,

    Is there a way to upgrade firmware on Polycom cx3000 without Skype on premise?

    Thanks in advance,

    1. Not currently. I do not believe that LPE updates are being pushed from Office 365 yet. You’l need credentials in someone’s environment to upgrade the device today.

  34. Hi Jeff,

    Our PIN-authentication isn’t working until we use the FQDN of the Lync Web Services Internal (poolweb..local) as Common Name in our Server default certificate. When we use the FQDN of the pool (in our environment: pool..local) it won’t work.
    According to this Technet site:, we need to use the pool FQDN as Common Name of Server default certificate.

    We are using Polycom IP-phones, VVX310 and VVX410. We’ve configured the DHCP-settings, the phones downloads our root-certificate.

  35. Hi Jeff,

    Beautiful articles. Thanks a lot for sparing time and sharing.

    One question: How does Phone edition clients learn QoS DSCP settings? Through DHCP or DNS?


    1. Thanks. The DSCP value is actually passed directly from the Lync/SfB Server via in-band provisioning during registration. It does not come from the network (e.g. DHCP or DNS).

  36. Hi,

    I’ve been back and forth with Microsoft support about this issue and O365 and they say there are unable to help update CX3000 devices, to later firmware version to support office 365

    is there any chance as you have a lync environment you could make a account available so those of us unable to self host Lync so that we could sign in temporarily and update our devices.

    We would have to use usb to sign in but this would be greatly appreciated.



    1. At this point this is a moot issue as Microsoft plans to enforce TLS 1.2 in Office 365 in a few weeks (Oct 31). This will prevent any Lync Phone Edition device from connecting to SfB Online or Exchange Online regardless of firmware.

  37. For option 43-sub option 003 – can the value be more than 1 single FE pool.
    In our environment we have 2 FE pools for resiliency – can both FE pools be configured in sub-opion 3 of option 43?

    If yes, how will be the syntaxt like for separating the 2 pools i.e. using comma or slash?


Leave a Reply

Your email address will not be published. Required fields are marked *