Today I really got a nice opportunity to configure and install the Microsoft Lync Phone Edition 2010 (Polycom CX3000) in a customer network. Since I didn’t touched the “spider phone” much I was really surprised to have one in my hands. More information about the Polycom CX3000 (here).
As many of probably know it is pretty easy to plug in the device but you need to make a step further to make it actually visible in your Microsoft Lync Server environment. Visible as that you can use the device as common are (conferencing) phone and also that the device is updated automatically without any human interference. More information about that part read the documentation how the Device Update Web service is working etc.
I can really encourage you the read the specific (Admin Guides) documentation on how you can configure this. In the basic you need to have the following components in place to make sure this work and provide a solution which is secure.
- Network Infrasturcture (IP / VLAN)
- Microsoft Lync Server - deployed (Standard or Enterprise)
- Microsoft Lync Phone Edition (device like I used: CX3000)
- (Windows) Server CA (advice: Enterprise CA)
- DC / DNS / DHCP (with a specific scope configuration)
- NTP Server
As the IT pro (MSFT) documentation is a very good guidance I would like to share my thoughts on extra material you really should read to make it more clear. First read is absolutely all the good stuff Jeff Schertz created on this blog about updating and configuring the devices (here) more stuff (here). Check also his artcile on Common Area Phones (here). After the read of all these good stuff I would like to point out some things you really need to configure and test to make sure everything is working. As all these items are crucial to make this work.
Good to know is that a device like the CX3000 is going through a bootstrapping process to get connected and fully operational:
- Finding the VLAN ID
- Obtain an IP Address
- Find the Device Update Service
- Check for Updates
- Obtain Registrar FQDN and Web Service URL
- Connect to the Web Service and Download the Root CA Certificate Chain
- Authentication Process
- Receive and Publish Certificate.
- Log on to the Lync Server
Useful tools and (PowerShell)commands:
(No device is actually needed in order to run the test.) In order to connect to Lync Server 2010, Lync 2010 Phone Edition-compatible devices need to use Dynamic Host Configuration Protocol (DHCP) to retrieve the address of a Lync Server Registrar; these devices must also provide a valid phone number and associated personal identification number (PIN) in order to be authenticated by the system. (This process is known as "bootstrapping".)
Background: the Test-CsPhoneBootstrap cmdlet enables administrators to verify that a given user -- using the phone number and PIN assigned to him or her -- is able to log on to the system from a Lync 2010 Phone Edition-compatible device. (Source: MSFT)
Example: test-CsPhoneBootstrap –TargetFQDN server01.contoso.local -PhoneOrExt tel:+31123456789 -PIN 12345 -verbose
TIP: Another tip here (as Jeff Schertz already said) while testing do only use one network interface card (active for the bootstrap) as I expect also issues when having multiple network card who are active.
TIP: As a double check I really suggest to trace your switch(es) while testing and setup (and run) a local instance of for example Wireshark during the actual test (on that only activated networkcard). This give you a better understanding about the setup and the stack itself.
TIP: As I discovered it myself make sure for Windows Firewall is allowing the traffic to the specific endpoint ((DHCP server) on the network.
(No device is actually needed in order to run the test.)
DHCPUtil does not configure the DHCP servers by itself. It delegates that responsibility to a script which can be changed to suit the organization’s need. After it calculates the values for various options, DHCPUtil passes these values to a script, which can then take appropriate action. (Source: IT documentation MSFT)
TIP: As I really suggest to run this test from a different machine in the same segment and VLAN as your (conference) phones.
The most interesting part here is while testing it on a machine in the same VLAN / segment and gives you the feedback that you correctly configured the DHCP options. Beneath a result you need to have to make sure your configuration is working (this script was run in my own environment but it should be overall the same).
Example: C:\stufftoinstall\Lync>DHCPUtil.exe –EmulateClient
After connecting to the Registrar, the first thing the device does is to download the server’s certificate issuer’s chain of trust. This is stored on the device and is used to verify that the certificate the server uses to authenticate itself with. Upon receiving the address of the Registrar and Web Services, the device connects to the web server and downloads the root certificate chain. This is a certificate chain of trust linking the web server to the certificate authority. This assists the device in requesting a certificate for authentication, as well as improving efficiency in subsequent secured communication.
For sure my answer is that NTP is crucial to make this work because during the actual login process the certificate chain of your rootCA is downloaded and needs to be validated on its timestamp.To validate the certificate chain is actually download review your outcome of the bootstraplogging and search for:
VERBOSE: Target server fqdn or web service url not provided. Will have to do
DHCP Registrar Discovery. 'DHCPDiscovery' activity started.
Starting DHCP registrar discovery... DHCP discovery message send. Waiting for dhcp servers to respond. Response received for the DHCP Discovery message. Found registrar fqdn : frontendpool.contoso.local.
Found web service url :
DHCP registrar discovery activity completed successfully.
'DHCPDiscovery' activity completed in '1.4601416' secs.
'STActivity' activity started.
Trying to download a certificate chain from web service.
Web Service url : http://cswebfe.contoso.local/CertProv/CertProvisioningService.svc
Certificate chain downloaded successfully.
'STActivity' activity completed in '3.7707621' secs.
'STActivity' activity started.
Trying to get web ticket.
Background: Network Time Protocol (NTP) is the default time synchronization protocol used by the Windows Time Service in Windows Server operating systems. NTP is a fault-tolerant, highly scalable time protocol and is the protocol used most often for synchronizing computer clocks by using a designated time reference.
Microsoft Lync 2010 Phone Edition communications software requires NTP to set the correct time and date for phones running Lync 2010 Phone Edition.Network Time Protocol (NTP) must be configured correctly for the device. See also the good post on the BCUC blog about NTP (here) Thanks Brian!
Microsoft Lync Phone Edition searches for an NTP server in Domain Name System (DNS) by searching for the following:
- NTP SRV record (User Datagram Protocol, or UDP, port 123)
- _ntp._udp.<SIP domain> pointing to NTP Server (on your network).
If Microsoft Lync Phone Edition cannot find the NTP SRV record, it will attempt to use http://time.windows.com as an NTP server by searching for the following:
- NTP A record
- time.windows.com (as this is not always allowed by firewall restrictions I really suggest my option first is to correctly configure NTP in your own network infrastructure.
The best of it is that you have a up and running device at the end and better you got a infrastructure prepared to rollout all kind of devices to rip and replace your legacy and out of support PBX (conference) devices.
Since lots of stuff (and new stuff) is coming up I really recommend downloading Microsoft Lync Server 2010 (Trail) and test if out yourself. Cheers!