Updating Lync Phone Edition Devices for Lync 2013

This article is a brief update to the process previously documented for Lync Server 2010.  In Lync Server 2013 the Device Update service is unchanged and the steps shown in that article are still applicable, so why the need for a new post on this subject?


It is important to understand that although Lync Server 2013 brings a host of new 2013-branded clients (e.g. Windows, Mobility), the Lync Phone Edition (LPE) client was not updated in the same manner.  Microsoft continues to release semi-quarterly Cumulative Updates of firmware for the various LPE models.  In the round of releases in December 2012 and January 2013 (aka CU7) official support for Lync Server 2013 was added, as well dropping the ‘2010’ from the previous name of Lync 2010 Phone Edition.  This signals the intent to provide a single LPE client for both Lync platforms and not have separate 2010 or 2013 clients with different interfaces.

What this all means is that to utilize any Lync Phone Edition devices with Lync Server 2013 the phone firmware may need updated to at least the CU7 release, which is version 4.0.7577.4363 / .4366 / .4372 for different device families.  As of the writing of this article the most recent firmware release is from April 2013 (CU8 or 4.0.7577.4387).

Understand that although Microsoft officially supports Lync Phone Edition with Lync Server 2013 starting with this CU7 release it is often still possible to register directly to Lync Server 2013 environments with many older firmware versions.  In these cases it will still be required to update Tanjay device in a two-step process to get to a supported version.

The oldest tested version which could successfully register to a Lync 2013 server is 3.5.6907.187.  Attempts to use 1.0.522.x versions would always fail with SIP 401 Unauthorized errors regardless of the client version policy configuration.

As older versions of firmware may still be in use or come pre-installed on new devices then there may exist a scenario where the devices are unable to successfully sign-in to a Lync Server 2013 environment (specifically OCS 2007 RTM versions).  And because the only way to update the Lync Phone Edition firmware is by the device requesting and downloading the package from the Lync Server then this appears to be a cyclic problem.  How can a device which cannot register to the server download an update from the server when it needs to first register to be provided the device update server information?  This might mean that the device would instead need to be connected to and registered to Lync 2010 server first, then updated to CU7 or higher, no?

Actually, no.  There is one alternative which would allow any previous version of Lync Phone Edition to download an update package directly from a Lync 2013 server without even the ability to first successfully register to it.

This little-known behavior is hardcoded into all firmware releases.  The phones are programmed to look for a specific hostname which is not typically included in the Lync topology, but if it is added manually to the environment then phones will be able to update without signing in.  Normally device updates are triggered after signing in to the Lync Server as described in detail in the previous article.

But by adding the suggested configuration to a Lync 2013 server as outlined in this article then the issue can be avoided and devices can be updated as needed.


When a Lync Phone Edition device is powered up and receives a successful DHCP lease it will look for the commonly used DHCP Option 15 parameter which provides a single DNS Domain Name.  It will also query for the optional DHCP Option 119 which provides a DNS Search List.  In an environment that contains multiple domain names then Option 119 can be leveraged to provide more than one domain name to the client.

The device will then automatically perform a DNS query for the hostname ucupdates-r2.<domainname> for each domain name which may have been passed via those DHCP options.


The Device Out of Box section shown at the bottom of this page in TechNet lists the requirements to support this registration-less device process.

  • The phone must be on the corporate network.  This statement defines that the process will only work on devices connected internally which have direct access to the Lync Front End server.  This process is not supported for devices connecting outside of the Edge Server and Reverse Proxy server.

  • UCUpdates-R2 must be configured in DNS.  Clearly the phone will need to correctly resolve the hardcoded DNS entry so a Host record needs to be defined in DNS.  Only the FQDN needs to be defined, there is no need to deploy a WINS server solely for shortname resolution as the device only needs to resolve the FQDN.


  • Device Update certificate must have SAN entries containing the hostname and FQDN.  This means that the certificate installed on the Lync Front End server which the device will connect to for the device updates must have both a Fully Qualified Domain Name entry (e.g. ucupdates-r2.schertz.name) as well as a short hostname (ucupdates-r2) defined in the Subject Alternative Name field.  By default the Lync Certificate Wizard does not include either of these as options so typically they are not already defined.  But a new certificate request can be generated with these entries added to the request manually in the wizard.  The short hostname must be included in the certificate even though the device does not need to actually resolve this shortname (WINS is not a requirement for this solution).  During the update process the phone will actually use the hardcoded shortname to connect to the Lync server even though the FQDN is used to resolve the server’s address.  If the shortname is missing from the certificate then a TLS connection will fail to be established, preventing the device from accessing the update web service.


  • The server running the Device Update Web service must have a certificate trusted by Lync 2010 Phone Edition.  This is the most important requirement.  Basically this means that if the Lync Server’s certificate was issued by a third party Certificate Authority which is the same as one of the pre-installed and trusted Root CAs stored in the Trusted Authorities Cache in the Lync Phone Edition firmware then the phone should be able to successfully establish a TLS connection to the Lync Server.  But typically the certificate issued to the Lync Front End server is from an internal, private Certificate Authority, which means the device cannot automatically download the updates.  In this case user-intervention is required by first attempting to sign-in to the Lync Server.  Even though this registration may fail due to unsupported firmware attempting to connect to Lync Server 2013, the act of attempting to register will kick-off the client bootstrap process which will download the private Root CA certificate from the Lync Server by leveraging DHCP Option 43 to locate the Lync Server Certificate Provisioning web service.  After the Root CA certificate is imported the pending authentication attempt can still fail, returning the phone to the sign-in menu.
  • Network Time Protocol (NTP) must be configured correctly for the device.  Without an available time source the device will not be able to connect to and communicate with the Lync Server.  If neither a Network Time Service Locator Record (SRV) nor DHCP Option 42 is available on the network then LPE will fall back to connecting to the hard-coded time.windows.com host to locate a time source.
  • Additionally the DHCP Option 43 and 120 utilized by PIN Authentication need to be present, if not already configured, as described in this previous article.


Update Process

  • Connect a phone to the network which is currently installed with a firmware version older than what is approved on the Lync Server.

  • Perform a soft-reset on the phone to wipe any cached client credentials or certificates.

The following text is from a network capture run on the DNS server which shows the device asking for the IP address of the ucupdates-r2<domainname> query for the only domain name provided by the DHCP Option 15 value.

DNS:QueryId = 0×3, QUERY (Standard query), Query  for ucupdates-r2.schertz.name of type Host Addr on class Internet    {DNS:517, UDP:516, IPv4:513}

  • Attempt to sign-in on the device using PIN Authentication.  If the sign-in process should fail, an error message similar to the following should be displayed..


  • It is important to not leave the phone at this menu by selecting Backspace numerous times to the main sign-in screen.

  • Once at the main screen leave the device alone and the automatic device update process should kick-off shortly, but there will be no indication on the device that this is happening.
  • To confirm that the device has queried the server for any approved updates check the latest RequestHandlerAuditLog file located by default in the DeviceUpdateLogs folder.


  • Open the file and look for the most recent log entry and verify that the IP address matches the test device and that path to the image file (CPE.nbt) is passed to the device.

05/31/2013 17:08:10,,,UCPhone,5/31/2013 3:08:07 PM,"0004F29531A2","0004f29531a2","POLYCOM","CX600","Rev-4","ENU",cpe.nbt;
4.0.7577.4366;12/18/2012 5:56:16 PM, http://lync.schertz.name/RequestHandler/Files/UCPhone/POLYCOM/CX600/
; https://lync.schertz.name/RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/
Rev4/ENU/4.0.7577.4387/CPE/CPE.nbt;4.0.7577.4387;4/10/2013 6:55:12 AM

After a few additional minutes of idle time on the phone it will automatically reboot, activating the newly downloaded firmware version.  At this point the device should be able to successfully register to a Lync 2013 server.

About Jeff Schertz
Site Administrator


36 Responses to “Updating Lync Phone Edition Devices for Lync 2013”
  1. Thanks for yet another excellent and informative article! Just to note that it seems that your 2010 version of the article from Jan 11 has gone missing.

  2. Yoelski says:

    After moving myself to a 2013 pilot pool, I'm unable to search by name without having to dig down in the contacts list on the CX600 phones. This is both on firmware 4372 and 4387. Thoughts?

  3. Kaeon says:

    Hi Jeff, great article again! Only it's a bit unclear to me which domain to use. My Lync server is in an internal AD domain, which isn't the SIP domain the phones use. Do I have to add DNS & DHCP records for my AD domain where the Lync server is or do I need these records for the SIP domain (our public domain)?

    • jeffschertz says:

      The domain name you provide via DHCP is what needs to be used on the 'ucupdates-r2' FQDN as that is what the phone will append to the hardcoded hostname.

  4. Anne says:

    Thanks for all of this great info. What do I do if the path to the image file is not getting passed? In the log I see the phone's IP, MAC addr, etc, but no mention of a path.

    • jeffschertz says:

      This typically indicates that there is no newer applicable update for the phone, so no URL is passed to the phone.

  5. Chubacca says:

    Hi Jeff–Thank you for the breakdown of the sign in process!

    We have our phones VLANed off on a separate network that prevents internet connectivity and for whatever reason, the phones are failing to sign-in (once internet connectivity is allowed, the phones sign in just fine). Upon further investigation, it turns out the phones are trying to contact something on our webserver via https (which is hosted outside of our network by a 3rd party/uses a public IP). Since we have a masked domain name (UPN) for mydomain.com instead of mydomain.local assigned to our users, when the phones somehow pulls the mydomain.com address (not sure how it gets this), it goes out and tries to talk to that server (which turns out to be our web server, using the public IP, which is blocked by the firewall on the phone VLAN). Do you know why the phones would be trying to contact mydomain.com over HTTPS and not talk directly to the Lync server the entire time? I am seeing this traffic occur after I type in the user's phone number and then pin. Once the sign-in process has been completed, I never see this traffic again either.

    Have any ideas on why the phones would be trying to poll mydomain.com via HTTPS during the sign-in process?


    • jeffschertz says:

      This sounds like the phone's attempt to reach the Certificate Provisioning service via the web services FQDN. It appears you have your network configured in an unsupported method.

  6. Michael M says:

    Nice post. One thing I have noticed in my environment is we were still able to sign in to our Lync 2013 environment using a Polycom CX600 with software version 4.0.7577.4100.

    • jeffschertz says:

      Yes, older versions can often still register but the scenario is not supported by Microsoft. The officially supported versions include numerous fixes specific to Lync 2013.

  7. Ulrik NN says:

    Hi Jeff – thanks for plenty of great stuff about Lync :)

    We are migrating on to Lync 2013 and have gotten as far as getting phones to upgrade from 4100 to 4397 (Polycom CX600)

    Hoewever after the Upgrade Exchange integration has stopped working. Now getting error message "Microsoft Exchange is unavailable" for Calendar and no Outlook contact lookup.

    Phones are outside the Edge. Tried all usual stuff including soft resets. Are there changes to infrastructure requirements for LPE in this release?

    • jeffschertz says:

      The newer releases have been enforcing strict domain naming policies differently than past versions, so it's possible that our configuration is using different domain names between the autodiscover SRV and A records in Exchange. Otherwise I suggest opening a support ticket to identify why the Exchange integration is not working as there are a couple different issues with Exchange integration across nearly every different firmware release which can pop up in different environments.

  8. Richard says:

    Hi Jeff,

    yet another great article regarding the Phone edition. I wonder though, that it needed 7 years to be documented by an external resource, as MS was unable to achieve this task. Nevermind, I would like to ask something related:

    I noticed in the recent Lync 2013 firmwares, there is an option "Remote Log Access". I tried it on an ancient Tanjay phone (have no Aries currently), but it does not seem to do anything, after enabling it and clicking OK, I go back to the menu selector, and checking Remote Log Access again, its again disabled, no matter how many times I Enable it.

  9. Sujoy Mukherjee says:

    Dear Jeff
    I have a Polycom CX 3000 desk conferencing phone version is upgraded to ver 4.0.7577.4397.
    We are trying to integrate with Office 365 Lync online.
    When we did for the first time it did get integrated and we could make and receive calls from the CX 3000 to any online contacts after a few configuration steps.Subsequently we removed the POE connection and rebooted the unit and henceforth it comes to the point where it says "Authentication complete"Retrieving user information.After that it prompts us to put the six digit PIN but before we are able to thru with it; it says "Signing off"and in the computer which is connected with the USB cable with the CX 3000 unit gives the message "Lync cannot connect to your deskphone because you are not signed in.Make sure the phone is connected to the network and enter your sign in info on the desk phone if necessary"
    For info we are signed in with the account credentials in the laptop having office 365 client.And onne we are connected to the CX 3000 with the USB cable a pop up comes which prompts to put the credentials for the CX 3000 to login.
    Kindly can you suggest what may be the issue.The setup only worked once as mentioned above.

    • jeffschertz says:

      To use CX devices with Office 365 users you must have the proper licensing package (O365 Plan e4 or Lync Online Plan E3). these profiles will enable Enterprise Voice for the user account which is a requirement to use Lync Phone Edition devices. The immediate sign-out is typically an indication that the Lync user is still configured for Peer-to-Peer calling only.

  10. Mike ETC says:

    Hi Jeff,

    Thank you for your post.

    We are having an issue with our external Lync devices getting any device update. The last device update status is listed as (0x2ee2/0) which is converted to code 12002 The request has timed out. In your post Troubleshooting Lync devices you mention in the IIS logs after the device has been given the path to download the update you should see shortly after the original POST message there should be a GET message showing the actual device requesting the file from the web server. I never see the GET message in the IIS logs. This device is a CX600_Rev-4 running ver. 4.0.7577.4387 with ver. 4.0.7577.4397 approved and 4.0.7577.4414 pending with my device as a test device. I do see in the request handler audit log my request for the .4397 file. However, I do not see the request for the pending file even though the test device is setup correctly with the correct MAC address of the device. Either way the device is not getting either file. Our devices are all external going through TMG for Web services. Any idea why we are not able to update or why we are not receiving the GET message after the post?

    • jeffschertz says:

      My only guess is that the device is not attempting to download the package. I've seen this before when the same version is already loaded into the inactive partition and in other erroneous cases. I would test resetting that device to the previous firmware version and testing again. If no devices are uable to update externally but work internally then it could be related to the reverse proxy rule.

  11. lorezyra says:


    Should the ucupdates-r2.schertz.name be configured on the internal or external DNS? Or, both?

    • jeffschertz says:

      This approach is only supported for internal use. Typically a public certificate is used on the Access Edge service and public CAs will not issue certificates with requests for simple hostnames; they must be verifiable FQDNs.

  12. Brian Davidson says:

    On a related topic from a Lync novice in advance of an upcoming OCS/Lync migration. Can Lync 2013 be configured to use an alternative to DHCP option 43? E.g. if option 43 is already being used by a previously installed and separate live running ICT solution. Any advice and guidance would be much appreciated.

    • jeffschertz says:

      Option 43 is not actually DHCP option 43 but is a string of sub values which together created that vendor class ID. The exact configuration is used only for these Microsoft phone clients and when configured properly should not conflict with any other DHCP configuration you may have for other solutions.

  13. Dave P says:

    We use a public CA for all of our Lync certs. Regarding the requirement for the short hostname ucupdates-r2, after November 1, 2015, internal names will no longer be supported in public certs. Is that definitely a requirement? Is there a workaround?

    • jeffschertz says:

      Yes, it is a requirement so if the entry is missing then I assume the updates will not function correctly. I have not tested with an incorrect certificate configuration in a very long time so I don't know what the exact behavior would be.

  14. Jason B says:

    We've run into a similar issue here. We were finally able to get our CX600 devices connected, but our IP5000/7000 devices are still not working.

    The new limitation of no short names on public certs seems to be a growing problem. I'm not exactly sure how short names play into Lync and if these names are 100% required for things to function. Perhaps MSFT needs to provide a working update to not include these SAN entries and support FQDNs.

    I'm not sure what else we can do here. Perhaps you or Dave P can shed some light if he figures it out.

    • jeffschertz says:

      The only short hostname requirement in Lync is for unregistered Lync Phone Edition devices to automatically download firmware updates. Once an LPE device signs-in to Lync then the ucupdates-r2 names are not applicable. This has nothing to do with the IP 5000 or any other third party phone not running LPE. Also the IP 7000 is not supported for Lync, only the 5000 and Duo so you can give up on trying to get the 7000 to work with Lync. The 5000 is fully supported and should be working when using the Lync Base Profile.

      • Jason B says:

        You're right Jeff. We were finally able to get the devices to connect locally, but there seems to be some bugs with the Polycom software and how it selects which certificate to use. When there is one that is explicitly added to the phone, you must also explicitly select it as the only CA to use.

        However, now our issue is that the same devices in our regional offices do not connect back across the WAN. Not sure if it is just timing out during the cert process or what. Will need to try to set up a packet trace to determine the issue.

  15. ryan says:

    Jeff, sorry for double posting. I posted a question today but ended up figuring it out.

    Here's our environment. Two resilient lync pool in. We are using 95% vvx phones with the other 5% CX series (for common area location….cx3000 in conference rooms as we want the hotdesking features in these location….VVX does not support this at this time). The problem with VVX series phones is at this time they do not support pool fail-over and thus, in a pool failover situation, would require us to log into each DHCP scope, change the url to the lync environment (to now point to the backup pool FQDN) and then have the users reboot their phones to reconnect to the backup pool. As you can bet, this would be problematic. To get around this, instead of using the poolFQDN in our DHCP configs, we chose to use our Meeting URL (in a fail-over situation, we would adjust the internal DNS record for our meeting url to point to our backup pool). Here's what we found. If the CX3000 series phone is running .4372 version (this is what ours came shipped with), you could NOT login to the CX3000s when the URL dhcp is giving to the phones pointed to our meeting url (note the meeting url and the Pool FQDN point to the same IP). Firmware version .4372 requires the PoolFQDN. Simply changing it to the poolfqdn, reboot the CX series phone, and everything worked as expected. As I stated before, now VVX phones are up a creek when we have a pool failure. What we found is once you update the phones to .4420 the CX phones will use any FQDN on the Front End cert SAN entry to pull down the lync cert.

    So what we're going to do is stand up a CX series provision VLAN. On this VLAN, we will use the PoolFQDN in our DHCP configs. 10 min after the CX series are online and not used, they will get updated to .4420 via lync device update. After the update, the CX3000's now running .4420 can then be deployed to their locations (and thus onto a different VLAN using our meeting URL in the DHCP configs).

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!