January 2015 Lync Users Group

January 16, 2015 by · Leave a Comment 

The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.


Event Details

This meeting will be conducted in our familiar two-session format:

The first session presented by Enghouse Interactive will cover Contact Center solutions for Lync.

The second session presented by a local subject matter expert will discuss the announcement of, as well as provide an update on Skype for Business Server.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync.  Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group and its official sponsors.

Our ever-growing LUG family has adopted two new regions this quarter in Baltimore and Kansas City.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.


For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group.  For current members if your region’s event is not yet scheduled just make sure that your notification options are configured so that you’ll get an alert when the new event is posted.  For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.

Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Tuesday, January 20th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago UC Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

Announcing Skype for Business

November 11, 2014 by · 17 Comments 


Just this morning Microsoft has announced, by way of Twitter and new posts on the Office and Skype blogs that the Lync Server product will be rebranded as Skype for Business.

Microsoft’s Corporate Vice President for Skype, Gurdeep Singh Pall, released the following message to Twitter coinciding with the official blog articles confirming the hunches of many in the industry on how Microsoft would ultimately tie the Lync and Skype products even more closely together.


The articles do not go into much detail at all about exactly what is happening, outside of some semblance of a rebranding but a closer look at some of the statements do point to a few important items.

In the first half of 2015, the next version of Lync will become Skype for Business with a new client experience, new server release and updates to the service in Office 365.

This basically means that the next on-premises server, clients, and Office 365 releases of what would be Lync will now simply be renamed, and the Lync name will be apparently be deemphasized.  Surely this does not mean that the existing consumer Skype platform would be positioned to businesses, or mean the death of Lync as a platform.  For all intents and purposes the two separate products must still exist : the consumer ad-driven solution known as Skype, and the enterprise-grade solution known to all as Lync which will simply be rebranded as Skype for Business.

Many enterprises will continue to run on Lync 2010 and 2013 platforms if they have just upgraded and moving to the next platform may be far off for them, while others will be excited to start evaluating the next release to see if it is a candidate for them to warrant upgrading to.

And speaking of upgrades the following statement seems to validate the rumors that in-place upgrades will be supported in the next server release cycle.

Current Lync Server customers will be able to take advantage of these capabilities simply by updating from Lync Server 2013 to the new Skype for Business Server in their datacenters. No new hardware is required.

Ultimately this rebranding fits a pattern that the product has had since it was first rolled out as Live Communications Server  (LCS) 2003 and then 2005.  It was brought into the Office collective by name as Office Communications Server for the next two releases (2007 and 2007 R2), followed by two more release cycles rebranded as Lync 2010 and 2013.   So this is not a surprise at all given the history of the product.

Furthermore a redesign of the Windows client has also occurred in the past three release cycles (Office Communicator 2007, Lync 2010, and Lync 2013) so this change also comes as no surprise.  A closer look at the Windows client shows that while the design borrows the color scheme and icons from Skype, the layout and function is still most definitely Lync at its core.


On a personal note I have known about this rebranding for quite some time and have already gone through the five stages of loss and grief that the rest of the technical community will undoubtedly be experiencing starting today.

  1. Denial – “Well that’s a silly idea, so clearly they will come to their senses.”
  2. Anger – “Stop changing the name already! People just became comfortable with Lync.”
  3. Bargaining – “ Look, how about using the Skype client with the Lync server, akin to Exchange and Outlook”"?”
  4. Depression – “Well, forget this. I’m going to stop blogging about the product and join a monastery.”
  5. Acceptance – “OK, I suppose it’s not the end of the world.  There might be some upside here.”

It will be confusing for a bit as the lines are blurred between the consumer and enterprise products, but in the end the user community (and not necessarily IT administrative staff) should benefit the most.  Imagine an employee, already comfortable with operating the Skype client on their personal computer and devices, seeing this familiar interface on their corporate workstation and devices, both handheld and in conference rooms?  Nearly 5 years ago there was roughly the same initial reaction to the new Lync rebranding of OCS and the product itself clearly won over many fans in the years to come.  On the upside at least I won’t have to hear anyone calling it ‘Lynx’ anymore. :)

SILK Audio in Lync Mobile Clients

November 7, 2014 by · 2 Comments 

A previous article entitled Media Codes in Lync 2013 covered the introduction of the SILK narrowband and wideband audio codecs from Skype into the Lync 2013 desktop client.  Since posting that article Microsoft has also added SILK support into the various Lync 2013 mobile clients, which means that some call scenarios like mobile-to-mobile Lync calls are already using SILK Wideband as the primary audio codec for those calls.

While this new behavior for Lync audio calls is not made evident directly to the user by the client it can be validated by reviewing the Peer-to-Peer Session detail reports from the Lync Monitoring Server.

The following image shows only the relevant data clipped from the Media Quality Report of a test audio call between an iPhone and an Android phone both running the latest Lync 2013 mobile clients.


Both audio streams are reported as using SILKWide which is the wideband SILK audio codec.  A Sample Rate of 16000 denotes wideband codecs while a value of 8000 means it is a narrowband codec. (There is one exception to this rule which is called out later in this article).

To understand how SILK was used for this peer-to-peer Lync audio call a capture of the SIP messages generated during the call setup will show which audio codecs the clients advertise to each other.

The Session Description Protocol (SDP) data in a SIP INVITE message sent by a 2013 mobile client currently advertises the following codec capabilities for receiving audio streams:

m=audio 37124 RTP/AVP 104 9 111 0 8 103 97 13 118 101
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtpmap:104 SILK/16000
a=fmtp:104 useinbandfec=1; usedtx=0
a=rtpmap:9 G722/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 SILK/8000
a=fmtp:103 useinbandfec=1; usedtx=0
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

As explained in the previous article the m=audio line declares all of the client’s supported audio codecs and lists them each by their payload type in order of preference.  The other client in the conversation also sends its own list in return.

The first payload listed is 104 which is SILK wideband, as denoted by the 16000 clock rate.  When negotiating an audio call with another Lync endpoint which supports this same codec it will be used by default.  A mobile to mobile or a mobile to desktop client call would utilize SILK wideband unless some other event (like constrained bandwidth) triggers the selection of a more appropriate (and less-preferred) codec.  Additionally the use of in-band Forward Error Correction (FEC) is defined (useinbandfec=1) after the initial declaration of the SILK codecs.

Yet a mobile client joining a conference call, thus negotiating media directly with the Lync AVMCU, will not use SILK as it is not currently supported by the Lync AVMCU.  That call would instead leverage the first compatible codec which happens to be the next in the list: G.722 (9).

Looking closely at the list above shows that these mobile clients do not include Real-Time Audio (RTA) which could be construed as an indication of a move away from RTA as the primary audio codec for Lync peer calls.  In head-to-head tests SILK has consistently outperformed the other Lync wideband audio codecs.  Although the wideband version of SILK requires slightly more bandwidth than the wideband version of RTAudio it is much less than G.722 and also can perform better is less than ideal network conditions. That makes it a great option for the mobile clients which are at best on a Wi-Fi network and at worst using a cellular data network; both of which are lossy networks.

Also note that (as explained in this article) G.722 is incorrectly declared in SDP as a narrowband codec with a clock rate of 8000Hz even though it is truly a wideband audio codec.

The following table compares the quoted bitrates for the different wideband audio codecs in peer-to-peer sessions only. 

Audio Codec Payload
Scenario Audio
G.722 9 Peer-to-Peer 64 Kbps 80 Kbps 96 Kbps 160 Kbps
SILK Wideband 104 Peer-to-Peer 36 Kbps 52 Kbps 64 Kbps 100 Kbps
RTAudio Wideband 114 Peer-to-Peer 29 Kbps 45 Kbps 57 Kbps 86 Kbps


Each value in the table includes the column before it as additional overhead, like when Real-Time Protocol (RTP) control messages and Forward Error Correction (FEC) data are stacked on.  When planning for media bandwidth on the network it is best to use the FEC value for any calculations as there is also some level of packet loss or delay in wireless networks to contend with.  Using only the payload value is not indicative of the actual bandwidth which could potentially be consumed by a single stream.

Be aware that to-date Lync to Skype audio calling is still using the v1 gateway model explained in the previous article so audio sessions between the Lync mobile clients and Skype clients are not yet utilizing SILK in a direct peer-to-peer model in the way that Lync peer calls function.  The v2 model for Skype interoperability with Lync 2013 is still pending a release form Microsoft.

Lync Phone Edition and Public Certificates

October 28, 2014 by · 7 Comments 

This article aims to serve two purposes.  Firstly, as a reminder to always keep Lync Phone Edition (LPE) devices updated and not to grow lackadaisical regarding the routine administrative tasks of frequently downloading these periodic cumulative updates and applying them to the Lync servers.

Secondly, if the previous advice was not taken to heart then some Lync administrators may already be experiencing a specific problem directly related to running older device firmware versions in a current Lync environment.  There is also the potential for newly purchased devices coming from existing stockpiles to have older firmware preinstalled from the factory which can exhibit this same issue, by no fault of the Lync administrator.

The problem referred to is that Lync Phone Edition devices may fail to successfully sign-in to a Lync Server due to an untrusted certificate being presented by the server itself during the initial secure TLS network connection setup.  This scenario can occur when an LPE device is running on an older version of firmware which still contains an outdated public Certificate Authority (CA) store.  In the event that the Lync Server is using a server certificate from a public CA which was signed and issued by a newer CA than the phone is aware of it will fail to connect because it will treat the certificate presented by the Lync server as untrusted.

Be aware that this issue should be limited to the USB-tethered provisioning approach which uses a different method  to download root CA certificates then when using the PIN Authentication method.  Depending on the exact issue it can be possible to leverage the DHCP Option 43 configuration to allow a PIN Authentication attempt to download the proper public CA certificate directly from the Lync Server Certificate Provisioning Web Service.

But to support USB-tethered provisioning a workaround may be required to get the updated public CA certificate installed into an internally connected phone using an LDAP connection to Active Directory so it can then trust the certificate passed by the Lync server to establish a successful TLS connection.  There are two ways to accomplish this, the easy way and the hard way.

  • The preferred method is simply the guidance stated in the opening paragraph and is a preventative step.  If the issue in this article is not a current problem in an environment but the ingredients sound familiar (public certificates on internal servers and LPE not running recent firmware versions) then heed this warning and go download and update those devices today before it is too late.  As usual test the newer version out on a few test phone to validate that no unrelated problems appear before rolling it out to all phones in the environment.

  • On the other hand if this article came up as a result of an administrator frantically searching for a resolution to this problem then unfortunately the preventative route cannot be taken at this point as that ship has sailed.  Luckily there are a few options available to get past this ‘catch-22’ scenario of needing to update the firmware to get TLS working again but requiring TLS in order to facilitate an update.


Because Lync utilizes TLS for all signaling traffic this secure connection must be established before any additional steps like the actual user registration or a device update can take place.

A typical Lync environment will most often utilize an internal Windows Enterprise CA for the Lync server certificates, while a public certificate from a well-known third party certificate authority would be used for only the external side of any Edge Servers.  While this still is the most popular topology in use today it is slowly becoming common to see public certificates used on the internal Lync server roles instead of private certificates for a myriad of reasons.

Environments using public certificates on the internal Lync server roles present a unique problem to LPE devices that many other clients are not subject to.  There is no mechanism in the Windows CE-based LPE firmware to automatically refresh any preinstalled public root and intermediate CA certificates like other Windows-based operation systems.  In the event that a specific public CA makes a change to one of their root or issuing CAs then the new certificate for that CA would need to be propagated down to any clients or servers which currently trust the previous certificate.  Standard Windows operating systems utilize Windows Updates to refresh these types of changes, but LPE does not.  The only way these phones can be made aware of these external changes is by being upgraded to a newer firmware release in which Microsoft has specifically updated the certificate store.  Note that many other 3PIP Qualified phones for Lync can have the same manufacturer-updated behavior so make sure to keep those current as well for the same reasons.

Trusted Certificate Authorities

For optimized Lync Phone Edition devices from all manufacturers Microsoft manages the firmware and updates the root CA store periodically as public CA server certificates expire, are revoked, or are simply replaced.  The TechNet article Certificates for Lync Phone Edition contains a list of the various CA certificates stored in the firmware’s Trusted Authorities Cache but this table is not kept up-to-date.  As of the posting of this article that page still reflects the October 2013 Cumulative Release 10 (4.0.7577.4414) which is over a year old.

The following table lists all of the trusted root CA certificates utilized by LPE, both old and new:

Vendor Friendly Name Expiration Thumbprint Algorithm Key Added
CyberTrust GlobalSign Root CA 1/28/2014 2F173F7DE99667AFA57AF80AA2D1B12FAC830338 md5RSA 2048 RTM
VeriSign Comodo 1/7/2010 4463C531D7CCC1006794612BB656D3BF8257846F md2RSA 1024 RTM
CyberTrust Baltimore aTrust Root 5/12/2025 D4DE20D05E66FC53FE1A50882C78DB2852CAE474 sha1RSA 2048 RTM
CyberTrust GTE CyberTrust Global Root 8/13/2018 97817950D81C9670CC34D809CF794431367EF474 md5RSA 1024 RTM
VeriSign Class 2 Public Primary Certification Authority 8/1/2028 6782AAE0EDEEE21A5839D3C0CD14680A4F60142A md2RSA 1024 RTM
VeriSign Thawte Premium Server CA 12/31/2020 627F8D7827656399D27D7F9044C9FEB3F33EFA9A md5RSA 1024 RTM
VeriSign Thawte Server CA 12/31/2020 23E594945195F2414803B4D564D2A3A3F5D88B8C md5RSA 1024 RTM
VeriSign Class 3 Public Primary Certification Authority 8/1/2028 742C3192E607E424EB4549542BE1BBC53E6174E2 md2RSA 1024 RTM
Entrust Entrust.net Certification Authority (2048) 12/24/2019 801D62D07B449D5C5C035C98EA61FA443C2A58FE sha1RSA 2048 RTM
Comodo AAA Certificate Services 12/31/2020 D1EB23A46D17D68FD92564C2F1F1601764D8E349 sha1RSA 2048 RTM
Comodo AddTrust External CA Root 5/30/2020 02FAF3E291435468607857694DF5E45B68851868 sha1RSA 2048 RTM
Entrust Entrust.net Secure Server Certification Authority 5/25/2019 99A69BE61AFE886B4D2B82007CB854FC317E1539 sha1RSA 1024 RTM
Equifax Equifax Secure Certificate Authority 8/22/2018 D23209AD23D314232174E40D7F9D62139786633A sha1RSA 1024 RTM
Geo Trust GeoTrust Global CA 5/20/2022 DE28F4A4FFE5B92FA3C503D1A349A7F9962A8212 sha1RSA 2048 RTM
Go Daddy Go Daddy Class 2 Certification Authority 6/29/2034 2796BAE63F1801E277261BA0D77770028F20EEE4 sha1RSA 2048 RTM
Go Daddy ValiCert Class 2 Policy Validation Authority 6/25/2019 317A2AD07F2B335EF5A1C34E4B57E8B7D8F1FCA6 sha1RSA 1024 RTM
Go Daddy Starfield Class 2 Certification Authority 6/29/2034 AD7E1C28B064EF8F6003402014C3D0E3370EB58A sha1RSA 2048 RTM
DigiCert DigiCert High Assurance EV Root CA 11/9/2031 5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25 sha1RSA 2048 CU10
Entrust Entrust Root Certification Authority 11/27/2026 B31EB1B740E36C8402DADC37D44DF5D4674952F9 sha1RSA 2048 CU11
Entrust Entrust.net Certification Authority (2048) 7/24/2029 503006091D97D4F5AE39F7CBE7927D7D652D3431 sha1RSA 2048 CU11
DigiCert DigiCert Assured ID Root CA 11/9/2031 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 sha1RSA 2048 CU11
DigiCert DigiCert Global Root CA 11/9/2031 A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436 sha1RSA 2048 CU11
GlobalSign GlobalSign Root CA 1/28/2028 B1BC968BD4F49D622AA89A81F2150152A41D829C sha1RSA 2048 CU11
Entrust Entrust Root Certification Authority – G2 12/7/2030 8CF427FD790C3AD166068DE81E57EFBB932272D4 sha256RSA 2048 CU11
GeoTrust GeoTrust Global CA 2 3/3/2019 A9E9780814375888F20519B06D2B0D2B6016907D sha1RSA 2048 CU11
GeoTrust GeoTrust Primary Certification Authority – G3 12/1/2037 039EEDB80BE7A03C6953893B20D2D9323A4C2AFD sha256RSA 2048 CU11
GeoTrust GeoTrust Primary Certification Authority 7/16/2036 323C118E1BF7B8B65254E2E2100DD6029037F096 sha1RSA 2048 CU11
Go Daddy Go Daddy Root Certificate Authority – G2 12/31/2037 47BEABC922EAE80E78783462A79F45C254FDE68B sha256RSA 2048 CU11
Starfield Starfield Root Certificate Authority – G2 12/31/2037 B51C067CEE2B0C3DF855AB2D92F4FE39D4E70F0E sha256RSA 2048 CU11
Thawte thawte Primary Root CA – G3 12/1/2037 F18B538D1BE903B6A6F056435B171589CAF36BF2 sha256RSA 2048 CU11
Thawte thawte Primary Root CA 7/16/2036 91C6D6EE3E8AC86384E548C299295C756C817B81 sha1RSA 2048 CU11
VeriSign VeriSign Class 3 Public Primary Certification Authority – G3 7/16/2036 132D0D45534B6997CDB2D5C339E25576609B5CC6 sha1RSA 2048 CU11
VeriSign VeriSign Class 3 Public Primary Certification Authority – G5 7/16/2036 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5 sha1RSA 2048 CU11
VeriSign VeriSign Class 4 Public Primary Certification Authority – G3 7/16/2036 C8EC8C879269CB4BAB39E98D7E5767F31495739D sha1RSA 2048 CU11


From a brief glance at the above table a few things should be apparent:

  • In versions older than CU10 nearly half of the cached certificate are expired or revoked.
  • If the phone is not running at at least the January 2014 Cumulative Update 11 (4.0.7577.4420) then it is not aware of a host of new CA certificates.

Root Cause

Where the problem introduced earlier comes into play is when a Lync environment is using a public certificate issued from one of the vendors in the table above that have made changes to the originally trusted certificates.  Older server certificates assigned to Lync server might have been signed by the original CA, but as those certificates approach their expiration dates any good administrator will preventively update them prior to that date.  So when these new certificate requests are generated on the Lync server and sent out to the same public CA for signing they are coming back issued from a different CA chain, and one that the older phone firmware is not aware of.  When the servers are updated with these new certificates then phones running that older firmware will no longer be able to register to Lync.

If there are plans to update an public Lync server certificates in the near future and there are any Lync IP Phones in the environment then now would be a good time to get those phones on a newer release.

It is required to upgrade to at CU11 (4.0.7577.4420) at a minimum to avoid this problem, but it is always recommended to move to the most recent firmware currently available.


If the Lync server certificate has already been changed, or new phones running older firmware have been introduced into the environment, and they cannot successfully register then the following workaround can be used to address this problem.

Note that the hardcoded pre-authentication download attempt against the ‘ucupdates-r2’ hostname which was carried over from the original Office Communications Server Tanjay devices is not applicable here.  The issue is not that the phone is failing to register to the Lync server, but that it cannot even get to that step due to the underlying TLS requirement not being available.  This out-of-the-box update process requires TLS for a portion of the communication, even though the internal URL provided by the device update service uses HTTP.  So without a working TLS connection the device update service is not reachable.

While the following approach is not new to Lync Phone Edition this guidance may not be something that newer Lync administrators are often aware of.  Prior to the introduction of the current Aries family of LPE devices designed for Lync 2010 the older Tanjay devices introduced with OCS 2007 did not support the simplified PIN Authentication based on DHCP Option 43 as that feature was introduced in Lync Server 2010.  In OCS if public certificates where assigned to internal server roles then Active Directory could be used as a central distribution point for the required public CA certificates.  Because the current LPE firmware is based on that older platform then this behavior is still active in all LPE versions.

The process of publishing third party certificates into Active Directory was originally covered by Rui Jose Silva and references to this process can be found in various other articles, some of which appear to have vanished over the years.

Throughout the directions in this article the example scenario is a Lync 2013 Server utilizing the following newer DigiCert SLL certificate for all three usages on the Front End Server:


To clarify this is not an issue related specifically to DigiCert certificates, but any public CA unknown to the phone’s older firmware.  DigiCert has a great program for active Microsoft MVPs which allows them to utilize public certificates in personal test labs for researching and writing articles like this.

Retrieve Root Certificates

Before any certificates can be imported into Active Directory they must first be saved into a Base-64 encoded X.509 file.

This can be accomplished by either locating and downloading the file(s) from the Internet or manually exporting them from the Lync server.  The fastest method can be to just get them directly from the vendor’s website, but most public CAs have multiple root and subordinate/issuing servers so finding the correct certificate chain can sometimes be a daunting task.

  • If already familiar with this process and the exact certificates have been identified then locate and download them from the vendor.  Make sure to get all files in the certificate chain in the event that the Lync server certificate was not issued directly by a root server but was instead signed by a subordinate server.  (This is most common as third party CAs rarely have the all-important root CA online and available to sign requests directly.)

Alternatively to ensure that the correct certificates are retrieved it is recommended to validate the current server certificate and then manually export the chain.

  • On the Lync Server use the Lync Server Management Shell to execute the follow cmdlet which will list the currently assigned server certificate(s).

PS C:\> Get-CsCertificate | fl Issuer,Use,Thumbprint


Focusing on the Default, WebServiceInternal, and WebServicesExternal usages (and ignoring the OAuthTokenIssuer certificate) a  typical configuration will have the same certificate assigned to all three client-facing usages.  This Lync Server is utilizing a single certificate issued by DigiCert as made evident by the same Thumbprint value being reported for each.

  • On the same Lync Server open a Microsoft Management Console window (mmc.exe) and then add the Certificates snap-in for the local Computer Account.


  • Browse to the Certificates (Local Computer) > Personal > Certificates store and then locate the certificate which is most likely the one referenced in the previous output.


  • To confirm that the correct certificate was selected switch to the Details tab to compare the Thumbprint value with what was reported by the Get-CsCertificate cmdlet (e.g. 3DFB6A83366BAD70DC4427565A64A07A0733EA49).


  • Change to the Certificate Path tab to view the certificate chain for this certificate.  Highlight the root server (e.g. DigiCert) at the top of the tree and click the View Certificate button.


  • In the next Certificate window switch to the Details tab and then click the Copy To File button to export the certificate to a text file.


  • In the Certificate Export Wizard select the Export File Format as Base-64 encoded X.509 (.CER).


  • Save the file (e.g. C:\Temp\DigiCertRootCA.cer) to the local disk and complete the wizard.

At this point the root CA certificate, which is essentially the public key of the certificate, is now in a format suitable for importing into Active Directory.  Because this example includes a 2-tier CA chain the same steps must be repeated for the subordinate certificate.

  • Return to the Certification Path tab of the original server certificate, highlight the subordinate CA entry (e.g. DigiCert SHA2 Secure Server CA), and click View Certificate.


  • On the Details tab use the Copy To File button to perform the same export procedure as before, saving the file with a unique name (e.g. C:\Temp\DigiCertSubCA.cer).

Import Root Certificates into Active Directory

The next step is to import these files into the proper Active Directory store location so that the Lync Phone Edition devices will attempt to download them the next time they are powered-on.

Prior to importing these though files first that a look at where they will be stored in Active Directory.

  • On the Lync server launch ADSI Edit (adsiedit.msc) and connect to the Configuration Naming Context and browse to Services > Public Key Services.

CN=Public Key Services,CN=Services,CN=Configuration, DC=schertz,DC=name





Notice that the only object currently stored in these container is for the existing Windows Enterprise Certificate Authority which is AD-integrated by default when deployed in the domain.  If there is no internal Enterprise CA in the environment then these stores will typically be empty.

To import the two DigiCert CA certificates into this store the certutil.exe Windows command can be used, which will place each certificate file in both the CN=CertificationAuthorities and CN=AIA stores located under the Public Key Services container.

  • From the same domain-joined Lync server open a Windows Command Prompt window and issue the following command.

certutil -f -dspublish c:\Temp\DigiCertRootCA.cer RootCA


If the action is successful then the CA certificate should be reported as added to both DS store locations in the AD Configuration container.

  • Repeat the step for any additional certificates in the chain.

certutil -f -dspublish c:\temp\DigiCertSubCA.cer RootCA


  • Refresh the ADSI Edit window to verify that the new certificates are displayed in the stores as reported.



The final step is to attempt to sign-in on the phone using the USB-tethering approach so that the AD credentials can be supplied to the phone.  If any older CX700 models are in the environment they are not required to be tethered as the AD credentials can be entered directly on the phone.

If the phone is still unable to register at this point then try one or both of the following tips:

  • Perform a soft reset on the phone to clear any cached credentials and certificates and reattempt signing in.

  • When signing-in enter the User Name in the odd-looking format of the DNS Domain instead of the NetBIOS name in this format: domain.com\username (e.g. schertz.name\jeff).


MSTurnPing Bug

October 14, 2014 by · 5 Comments 

The MsTurnPing.exe application included in the Lync Server 2013 Resource Kit Tools package contains a bug that may have inadvertently triggered some incorrect practices related to the configuration of Edge server certificates.

Remember that the officially supported, best practice covered in this previous article is that an Edge Pool must utilize a single, identical certificate on all servers for the internal Edge interface which only includes the Edge Pool FQDN as the Common Name.  The individual Edge Server’s unique FQDNs are not, and should not be included as these certificate should not include any SAN entries.


When running MsTurnPing.exe against a single Edge server it should not report any issues as the certificate’s Common Name is the single Edge Server’s FQDN (e.g. edge.schertz.name).

But when run against a multiple server Edge Pool in a DNS Load Balanced arrangement it will not function accurately.  The tool will incorrectly report a problem with the certificate because it is hardcoded to utilize the Edge Server’s internal FQDN (e.g. edge1.schertz.name) during the test.  But that FQDN should not be included in the certificate, thus causing the tool to report a problem establishing a secure connection to the server.  The actual Lync Servers do not utilize the same method as they properly use the Edge Pool name.

  • The tool will resolve the Edge Pool FQDN (e.g. edgepool.schertz.name) which is reported as the Cluster Name in the output.  But as it connects to each server in the pool the Machine FQDN is reported

Cluster Name: edgepool.schertz.name

Machine FQDN edge1.schertz.name
Exception Message: Operation failed because the network connection was not available.
Cause:             Lync Server Audio/Video Authentication service is not started

Cluster Name: edgepool.schertz.name

Machine FQDN edge2.schertz.name
Exception Message: Unable to establish a connection.
Cause:             Lync Server Audio/Video Authentication service is not started

In this environment there are actually no problems with the Lync Server A/V Authentication service and all ICE/STUN/TURN capabilities are functional. 

  • Checking the System log on the local server where the tool was executed should report an Schannel error explaining why the previous test connection failed.

Log Name:      System
Source:        Schannel
Event ID:      36884

The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is edge1.schertz.name. The SSL connection request has failed.


As the tool reports a false-positive in this scenario this unfortunately has caused some administrators to go down the incorrect route of replacing the internal Edge certificates with SAN certificates containing both the Computer and Pool FQDNs.  The problem here is that every computer FQDN would need to be in the SAN as the same exact certificate must be applied to all servers so that the same public and private keys are used by all server nodes, yet there should not be a SAN field contains on the certificates.

The proper guidance is to leave the certificates as Lync intended, with only the Pool FQDN assigned to the single shared certificate and no other FQDNs are included.

October 2014 Lync Users Group

October 7, 2014 by · 3 Comments 

The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.


Event Details

This meeting will be conducted in our familiar two-session format:

The first session presented by Aruba Networks will cover Software Defined Networking (SDN) and Wi-Fi scenarios with Lync.

The second session presented by a local subject matter expert will discuss Lync Online within Office 365.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync.  Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group and its official sponsors.

Our ever-growing LUG family has adopted two new regions this quarter in Baltimore and Kansas City.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.


For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group.  For current members if your region’s event is not yet scheduled you just make sure that your notification options are configured so that you’ll get an alert when the new event is posted.  For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.

Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00

Date Location Address
Wednesday, October 22th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago UC Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

Configuring QoS for Lync IP Phones

October 6, 2014 by · 13 Comments 

This article covers various aspects of configuring a complete Quality of Service (QoS) design in a Lync environment which utilizes various models of IP handsets for Lync.  Prioritization of both signaling and media communications will be covered by addressing the following topics:

  1. Designing and configuring a network QoS plan
  2. Enabling QoS on network devices
  3. Enabling QoS for Lync desktop clients
  4. Enabling QoS on Lync Qualified IP Phones
  5. Updating QoS for Lync Phone Edition devices

The term Quality of Service (QoS) can refer to a variety of technical approaches for prioritizing specific traffic over an IP network.  For the purposes of Lync the applicable solutions covered in this article are (a) leveraging Differentiated Services Code Point (DSCP) identification of specific traffic types and (b) defining separate custom port ranges for the various media payloads in Lync.  Using this combination of traffic classification, commonly referred to as DiffServ, and organization will provide network routers and switches the ability easily identify real-time communication traffic and then prioritize each category as desired.

While there exists various modes of thought on these approaches the example guidance in this article will closely mimic real-world best practices which many production deployments of Lync share in common.  Not all of the options shown here are necessarily critical; for example some administrators prefer to only prioritize the media payloads of Lync while others will also include the signaling traffic.  Or in some cases only the audio traffic is tagged while other times audio, video, desktop sharing, or other traffic types like peer-to-peer file sharing are all individually categorized with unique values to create a layered approach to handling critical and non-critical data streams.

Design a QoS Plan

Providing end-to-end QoS in a Lync environment starts with defining port ranges for specific traffic to always be sent to and then includes the ability for the client sending that traffic to tag it with proper DSCP values so that the network devices place the traffic into the appropriate QoS queues.

This article is not intended to serve as a complete guide to all aspects of enabling QoS for Lync Server.  A proper QoS approach is to address both client-to-server and server-to-server topologies by configuring Windows operating system policy settings and Lync Server settings applicable to both Windows desktop clients and servers.  Various existing articles like the official TechNet guidance and this excellent article by Lync MVP Elan Shudnow are great resources to also read through.  Keep in mind that although the official TechNet guidance covers how to configure some of the same settings as shown in this article their examples do not always represent the common practices used in the field.

Addressed here are only bi-directional peer-to-peer media sessions between any internal Lync endpoint including desktop clients and both types of Lync Optimized and Qualified phones.  A complete QoS plan should also take into account the media port ranges and DSCP values for client-to-server and server-to-server media for conferencing and media relay call flows.  The articles linked to in the previous paragraph include those details and can be used to complete the configuration started in this article.

DSCP Tagging

The ‘tagging’ or ‘marking’ mentioned earlier is in reference to the DSCP value set on the outgoing packets from a client.  By default this value is null and would be seen in a packet capture like this:

Differentiated Services Field: 0×00 (DSCP 0×00: Default)

This previous article explains the different levels of classifications and the supported marking values for each.  The actual values which should be used must coincide with what the networking devices are configured to support, so it is critical to first understand how DSCP may already be defined on the network.  For the purposes of this article it is assumed that QoS is not yet defined on the network and the next section will outline the actual configuration on an example switch.

Port Ranges

It should be understood that it is not required to define media port ranges in order to utilize DSCP traffic prioritization on the network.  But without doing so it is not possible to assign different types of traffic to different DSCP queues on the network as all traffic from the Lync desktop clients would be tagged, and thus prioritized the same.  the easy way would be to simply tag all traffic from the Lync client application but then signaling, media, DNS requests, web service connections, and any other type of traffic would be prioritized no differently as the network device would not be able to tell one packet from the next.

The proper approach is to separate the different media types into their own unique port ranges so that the network devices can properly identify them and place each into the proper queue providing a layered approach.  For example audio traffic is traditionally treated as the most critical payload and these packets are the last to be dropped on a saturated network, while less important (or higher bandwidth) traffic like video or non real-time communications like the signaling traffic or file transfers can still be prioritized over generic unclassified packets, but in a lower class or queue than the audio.

While defining media port ranges is used in conjunction with DSCP tagging for QoS there is another common reason outside of QoS for defining custom client media port ranges.  By default all peer-to-peer media between Lync clients will utilize destination ports on both endpoints on a random high port between 1024 and 65535.  In the event that internal clients are separated from each other by any firewalls then direct media sessions will usually not be possible and the clients will need to leverage ICE/STUN/TURN provided by the Edge Server to communicate with each other even though they are both internal clients.  To avoid this undesirable load on the Edge Server it is recommended to define a much smaller port range for peer-to-peer media than the default of 64,511 ports (which no firewall administrator in their right mind would open up) to something much smaller (like 100 ports or less) which can be allowed through these firewalls between any internal network where Lync clients and devices may reside.

  • To validate this default behavior in Lync simply capture a packet trace with a tool like Wireshark to view the source and destination ports used on a peer-to-peer media sessions between two Lync endpoints.


The example above shows a Polycom VVX 600 ( and a Lync 2013 desktop client ( in a peer audio call utilizing a UDP media session.  Note that the source and destination ports are randomly selected within the 1024-65535 range (and that the DSCP flag is null).

The recommended custom port ranges for each media modality had traditionally been advertised by Microsoft as a minimum of 40 but that is older, outdated guidance.  The latest guidance shown in TechNet correctly reflects the required minimum of at little as 20 ports per modality.  Note that the exact math behind this number is related more to the audio and video modalities and a behind-the-scenes look at this was presented in the July 2014 Lync Users Group meetings.  Utilizing the default range of 20 port per modality means that at most a single range of 100 ports would need to be opened on the internal firewalls.  Also these ports are not actively listening and are only opened dynamically during media establishment between two clients.

The example port ranges in this article are arbitrary and realistically any unused range of ports can be defined.  The approach used here roughly follows the same guidance seen in various other articles with one important exception related to supporting the Polycom Qualified IP phones (e.g. VVX).  While the Lync clients and Lync Phone Edition devices can be defined with an exact range of any number of ports the VVX phones do not have the same configuration flexibility.  These devices are hardcoded to use a range of up to 48 ports (24 for audio and 24 for video) and only the starting port can be defined, thus is the Lync policy is defined to use on 20 ports then it would be possible for the VVX phones to request media from the Lync clients to be sent in an out-of-scope port which would fail to be properly tagged.

To provide a complete QoS solution in which all Lync clients, optimized devices, and qualified devices will always communicate within the correct ranges then it is recommended to increase the defined port ranges for audio and video to at least 24 ports.  Rounding these up to 25 ports can make the configuration easier to manage when derailing with a larger contiguous block.  Adding one additional port to round it out will not cause any problems if a Lync client or LPE device uses that single destination port above 24 when receiving media from a VVX phone as the VVX phone will still tag all outbound media correctly.  The VVX in turn will only utilize one of the defined 24 ports for its own destination (listening) port when accepting peer connections from a Lync client or LPE device, which is also still in the defined range.  So in short increasing the range from 20 to 25 ports can provide for a simple to manage policy that will work for all clients.  In fact it is perfectly fine to assign an even larger port range like 100 contiguous ports to make the plan very simple to read.  As long as the Lync-defined port range is larger than the static port range on the VVX phones the traffic will be properly tagged in both directions.  The only difference is how many ports must be  opened between internal firewalls, as network administrators may be accepting of 100 ports in total but maybe not 500 ports.

Example Configuration

As explained the DSCP values are a reflection of what are commonly used in the field but are in no way the only values which can be used.  Any existing DSCP configuration on a network should be leveraged as the network administrator may already have defined classifications for certain types of traffic.  The actual port numbers used are arbitrary and the 60xx range in this article is only only an example.  Various TechNet documentation uses 20000 or 50000 but high ports can be used as long as they do not overlap with other traffic, like 5061.

Also understand that while the focus of this article is on IP phones in which only audio (and for some models video) are applicable each peer-to-peer media modality should be included in the design even if there are no plans to prioritize that traffic.  Once custom client port ranges are enabled then all modalities will be enabled and the default values need to be changed for each (explained further in a later section).

Traffic Type DSCP Value Protocol Port Range
Audio 46 – Expedited Forwarding (EF) UDP & TCP 6000 – 6024
Video 34 – Assured Forwarding (AF41) UDP & TCP 6025 – 6049
Signaling 24 – Class Selector (CS3) TCP 5061
Application Sharing 0 – Unclassified TCP 6050 – 6074
File Transfer 0 – Unclassified TCP 6075 – 6099

When selecting the port ranges do not forget that the starting port counts as the first port so when beginning with ‘0’ ports like 6000 that is why the ending port is only 6024 as that range includes 25 actual ports.  If this seems confusing then just start on the ‘1’ digit for ranges like 6001-6025.  Or if the network administrator doesn’t mind dealing with non-contiguous port ranges for all traffic then something like 6001-6025, 6101-6125, and so on can be even easier to manage.  Aligning the different media ranges end-to-end is better practice though as then a single contagious range (e.g. 6000-6099) can be opened in firewalls if required to support internal peer-to-peer client sessions.

Setup the Network

This section is included to provide a complete story but will differ greatly depending on the type of network equipment in the environment as well as how it may already be configured.  The environment used for this article is the same Lync 2013 lab used for all past articles which includes a NetGear Pro-Safe GS110TP switch that will be used for managing QoS on the network.

The default configuration on this switch indicates that there are 4 different hardware queues available for prioritizing traffic differentially.

  • Review the default DSCP Queue configuration to see which of the desired DSCP values are mapped to which hardware queues. 


Note that in this example the queue values are displayed in binary so converting them to decimal will make it much easier to understand.  Interestingly this specific switch has both EF and AF41 assigned to the same hardware queue which would not actually prioritize audio and video traffic differently based on the previously selected DSCP values.

DSCP Value Decimal
Class Selector (CS 3) 24 18 011000 1
Assured Forwarding (AF 41) 34 22 100010 2
Expedited Forwarding (EF) 46 2E 101110 2

In a typical production environment any existing network DSCP configuration would dictate the values used in Lync, but for this example the switch configuration will be modified to retain the desired DSCP values.

  • Modify the configuration as necessary to provide the required design.  For this example the Expedited Forwarding value was reassigned to the highest hardware queue (e.g. 3) to ensure this traffic is forwarded ahead of any other classified data in the switch’s buffer.


With this configuration in place then in the event of network congestion any unclassified traffic will first be delayed or dropped, then the signaling traffic, then video traffic, and finally audio traffic as a last resort.

Configure Lync Clients

What follows are the necessary steps for turning on QoS for Lync clients which are disabled by default, configuring policies to enable Windows desktop Lync clients to tag packets with a designated value, and finally defining a custom port range for media traffic for all QoS-capable registered Lync clients to utilize.  Note that mobility clients will not utilize this QoS capability as it is only applicable to Windows and Mac desktop clients and desktop IP phone devices which are registered directly to an internal Lync pool on managed networks; QoS is not applicable for traffic routed over the Internet.

Media Port Ranges

By default Lync Server has port ranges already defined for peer-to-peer media sessions but they are not enabled, thus the default client behavior of using random high ports.  The first step is to enable the static port ranges so that Lync clients and devices will receive this information in-band during registration.  Yet the default values for the different media ports are actually not configured correctly and all overlap, which is not ideal and should be changed prior to actually enabling QoS.

  • Using the Lync Server Management Shell execute the Get-CsConferencingConfiguration cmdlet to display the default Lync Server configuration.

PS C:\> Get-CsConferencingConfiguration | fl client*


Note that the starting port for each type of media is the same port (5350) which means that if the default configuration was simply enabled then all clients would attempt to use the same 40 ports for all modalities.  That would prevent any QoS compatible network devices from being able to identify between different payload types and putting them in different queues.

The ClientMediaPort and ClientMediaPortRange parameters are not used by Lync clients but are meant for older Office Communicator 2007 clients which were only able to define a single media port range for all media payloads (audio, video, and application sharing).  The parameters highlighted in yellow are used by Lync 2010 and 2013 clients for separate port ranges for each peer-to-peer media modality. 

The two ClientSipDynamicPort parameters do not actually do anything and can be ignored (these may be left over from LCS).  SIP traffic in Lync 2013 is always client-to-server (not peer-to-peer) and is always TCP 5061 on internal networks to the Lync Front End servers.

  • Enter the following Set-CsConferencingConfiguration cmdlet to configure the desired custom port ranges, which were defined in the table earlier in this article, and then enable Lync desktop clients to use these settings.

PS C:\> Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled $true
-ClientAudioPort 6000 -ClientAudioPortRange 25 -ClientVideoPort 6025
-ClientVideoPortRange 25 -ClientAppSharingPort 6050 -ClientAppSharingPortRange 25
-ClientFileTransferPort 6075 -ClientFileTransferPortRange 25

  • Re-run the Get-CsConferencingConfiguration cmdlet to verify the proper configuration was applied to the global policy.

PS C:\> Get-CsConferencingConfiguration | fl client*


If any older Office Communicator clients are still in use in this topology than the ClientMediaPort parameters should also be configured with another unique port range of at least 40 ports to cover the multiple modalities included in that range.  This articles assumes that only Lync clients are utilized internally in the environment and thus these parameters will be ignored.

DSCP Tagging

To enable DSCP tagging for Windows desktop Lync clients the host operating system is what needs to be configured to perform this action; this is not configured anywhere on the Lync Server.  The steps for configuring this on Windows 7 and Windows 8 workstations can be found in the official TechNet documentation on this specific page.  As mentioned earlier the guidance in this article will differ slightly in a few spots which will be explained in detail.

For the purposes of this lab, and as a general recommendation to test any major changes before applying them to every domain-joined workstation in the network, the following configuration uses a new Organizational Unit (OU) created in the Active Directory domain to store the computer account of the test workstation running the Lync desktop client.

These same steps can be completed locally on a workstation in the event domain-joined computers are not available for testing in a given environment.  Simply use the Lync workstation’s Local Group Policy Editor (gpedit.msc) to define the following Policy-based QoS settings instead of the Group Policy Management tool (gpmc.msc) used for domain controllers.

  • On the Lync Front End Server or Domain Controller launch the Group Policy Management tool (gpmc.msc) and then create a new GPO called Lync Client QoS Policy in the desired location.  In this example the test workstation’s computer object in Active Directory has been moved into a new OU called ‘Workstations’.


  • Select the newly created Group Policy Object and select Edit to launch the Group Policy Management Editor and then browse to Computer Configuration > Policies > Windows Settings > Policy-based QoS.

  • Create a new policy in this container entitled Lync Audio and set the Specify DSCP Value option to 46.


  • Advance to the next window and select Only applications with this executable name and then enter lync.exe as the application name.


As mentioned earlier the TechNet guidance will differ in a few place, this being one of them. In TechNet the QoS Policy is shown as being applied to any application on the workstation instead of ideally limiting the tagging behavior to only the lync.exe application.  The latter practice will prevent other applications (rogue or intended) on the same workstation from accidentally having their traffic prioritized in the event that a randomly selected port happened to fall into a range defined for Lync traffic.

  • Advance to the next window and leave the default options selected for Any source IP address and Any destination IP address.

  • In the next window select TCP and UDP for the protocol and then select From this source port number or range.  Enter the defined port range for audio traffic as the starting port and ending port separated by a colon. (e.g. 6000:6024).


Here is another area where the guidance can differ depending on the source.  TechNet outlines the exact guidance shown above, in that only the source port is used to identify traffic and apply the assigned DSCP value to the outbound audio packets.  Other directions will often state to set both source and destination ports but this is unnecessary if the QoS configuration is correct in all areas. Also in the event other Lync endpoints which do not not support custom media port ranges are used then the approach above will allow the Lync desktop client to still tag its outbound media even if it’s destined for a port outside of the defined range.

Now that the audio policy is complete repeat these same steps to create new policies for video, and signaling traffic as detailed in the QoS design for this example environment.  If additionally prioritizing application sharing and/or file transfer media sessions is desired then create policies for those as well and assign the desired DSCP value.

  • Using the defined QoS Policy create new policies for Lync Video and Lync Signaling.  Take note that the signaling policy needs to be configured slightly different in that the Protocol is only TCP and the Destination Port (and not the Source Port) needs to be set to 5061 as the Lync client will use a random source port for signaling traffic sent to the Lync Front End Server.


If these changes were applied to the AD domain’s Group Policy (and not the local workstations Group Policy directly) then forcing a refresh of the domain policy on the workstation may be required prior to testing the configuration changes.

  • Issue the following command on the test workstation to force an immediate update of the domain global policy changes to be applied to the workstation.

gpupdate.exe /force

Test Configuration

To validate the new configuration on a Lync desktop client exit the Lync application on a workstation and restart it to trigger a registration connection which will refresh any policy settings.  (Make sure that the Lync user is assigned to the proper client policy in the event that the previous configuration changes where not applied to the Global conferencing configuration container.)

  • Browse to the current user’s Tracing folder to locate the Lync-UccApi logs file to search for the latest provisioning data passed in-band to the client during the registration process.


  • Open the Lync-UccApi-0.UccApilog file in a text editor like Notepad and go to the end of the file.  Search for a previous instance of the string ucPortRangeEnabled to look for the most recent settings provided in the <provisionGroup name="ServerConfiguration" > section.



The output above shows the various custom port ranges which were defined earlier. If the default settings still appear here then wait a few minutes and then repeat the process until the correct configuration appears on the client.

Next the Windows registry can be viewed to verify that the defined Policy-based QoS parameters have also successfully been imported into the workstation with the Lync desktop client.

  • Open the Registry Editor (regedit.exe) on the Lync desktop client’s workstation and browse to the following location to verify the existence of the custom QoS policies.



A new test call between this Lync client and a Polycom VVX phone will show that the Lync client is now using the defined range. 

  • Capture a new trace on traffic between the Lync client and a VVX phone during a Lync audio call for a few seconds to capture some UDP media traffic in both directions.


Notice that the destination port on UDP media traffic (the audio payload) to the Lync client ( now falls within the expected port range (6018).  The Polycom VVX phone on the other hand still needs to be configured as an out-of-range dynamic port (2230) was still used for the media sent by the Lync client to the phone.

Also seen is the successful DiffServ tagging of outgoing media packets from the Lync client as confirmed by DSCP 0x2e Expedited Forwarding reported in the packet, which equals 46 in decimal.  Even though the Polycom VVX device is not yet configured for QoS the Lync client still tagged traffic that it sent to the phone on a destination port of 2230.  Because the Lync QoS policy was configured to use source ports for media then because that traffic left UDP port 6018 on the Lync client the traffic was properly tagged.

The next test is to verify that the signaling traffic from the Lync client to the Lync Front End Server is also classified correctly.

  • Capture a trace on the traffic between the Lync client and the Lync Front End server that it is currently registered to.  Perform any basic action like placing a call to another Lync user which will generate some SIP traffic to the server.  In the following example Microsoft Network Monitor was run directly on the Lync Front End Server to capture the traffic.


The results above show that signaling traffic from the Lync client  ( to the Lync Server ( is properly tagged with a DSCP value of 24 which would put this type of traffic into a lower priority hardware queue than the media in the previous test based on the configuration enabled on the network switch in this scenario.

Configure VVX Devices

This section is applicable to all 3PIP Qualified Polycom handsets which run on the Unified Communications Software (UCS) firmware.  Although the modern Polycom VVX devices are the focus of this section the SoundPoint IP, SoundStation IP, and SoundStructure models can also utilize the identical configuration shown here.

It is unknown if the other currently qualified handsets from Audiocodes and Snom support custom port ranges and if so what their behavior is.  An article from Lync MVP Matt Landis briefly shows how to set DSCP values on these other models.

The following configuration settings for the Polycom UCS-based qualified devices can either be manually imported into the phones individually for testing by using the embedded web management interface or in bulk to all devices using a custom provisioning server as detailed in this past article.

Media Port Ranges

As was mentioned earlier these qualified devices do not currently adhere to the in-band media port ranges in Lync so a separate configuration step is require to make sure they utilize listening ports for media in the proper custom port ranges.

  • Define the following parameters on the Polycom VVX phones to set the proper starting port for each range of supported media traffic.




In most cases only the first parameter for audio needs to be defined but in the event that some of the VVX models are equipped with the supported USB video camera then it is possible to perform phone-to-phone video calls via Lync.  (Phone-to-Lync peer video calling is not yet supported due to the lack of any common video codec between Lync clients and the phones.)

DSCP Tagging

DiffServ values can be individually configured for signaling, audio, and video using another set of parameters.

  • Define the following parameters on the Polycom VVX phones to set the desired DSCP value for each mode of supported traffic.




The qos.ip.rtp.dscp parameter applies to all media if it is the only one defined but if the video parameter is also defined then only audio will be tagged using the general qos.ip.rtp.dscp setting.  The callControl parameter applies to signaling traffic sent to the Lync Front End server.

Phone Configuration

A single XML provisioning file can be created with both the custom port ranges and DSCP tagging parameters defined, which would look like the following:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!–Schertz Home Lab Shared configuration file –>
  <qos qos.ip.rtp.dscp="46" qos.ip.rtp.video.dscp="34" qos.ip.callControl.dscp="24" tcpIpApp.port.rtp.mediaPortRangeStart="6000" tcpIpApp.port.rtp.videoPortRange.enable="1" tcpIpApp.port.rtp.videoPortRangeStart="6025"></qos>


  • Copy the text above into a new text file and save it with a .cfg file extension (e.g. qos.cfg).

  • Connect to the embedded web management interface on a Polycom VVX phone from a web browser.

If the device is running UCS firmware version 5.1.1 or newer and the Lync Base Profile is enabled then the web interface may not function as it is disabled by default when used in Lync environments.  To temporarily re-enable this feature perform the following steps directly from the phone (as usual this can also be performed programmatically for all phones using a centralized provisioning server).

  • Press the Home key and then navigate to Settings > Advanced (enter the administrator password which is ‘456’ by default) > Administration Settings > Web Server Configuration (located at the bottom of the menu).

  • Select Web Server and then choose Enabled.

  • Select Web Config Mode and then choose either HTTP Only, HTTPS Only, or HTTP/HTTPS.

After the phone reboots the web management interface will again be available.  For security purposes it may be desirable to disable this feature again after the configuration file has been imported.

  • Connect to the phone’s IP address using a web browser and then go to the Utilities > Import & Export Configuration menu.

  • Under Import Configuration select Choose File and then locate the previously created configuration file ( e.g. qos.cfg).

  • Click the Import button to confirm the action and then trigger a reboot of the phone.


Test Configuration

Now that both the port range and DSCP parameters have been imported into the phone it should behave identically to the configured Lync clients and both QoS features should be functioning in either direction for all media.

  • Capture a new trace on traffic between the the Lync client and the VVX phone during a Lync audio call for a few seconds to capture some UDP media traffic in both directions.


The results above indicate that media sent from the phone (  to the Lync client ( is now assigned to the correct port range for its source port  (6000) and destination port (6016). This outbound UDP audio traffic from the VVX phone is also properly classified using the configured DSCP value of 46 (0x2E) which is Expedited Forwarding (EF).

The return traffic sent from the Lync client is still allocated within the proper port range as was configured earlier in this article, so now media is successfully defined in the proper ranges and with the ideal DiffServ markings bi-directionally.

The last test is to verify that the signaling traffic from the VVX phone to the Lync Front End Server is also classified correctly.

  • Capture a trace on the traffic between the VVX phone and the Lync Front End server that the phone is currently registered to.  Perform any basic action like placing a call to the Lync client which will generate some SIP traffic to the server.


The results above show that signaling traffic from the VVX phone ( to the Lync Server ( is properly tagged with the DSCP value 24 which will drop this type of traffic into a lower hardware queue than the media in the previous test based on the previous configuration enabled on the network switch.  Note that the DSCP value will not be defined on the traffic from the server to the Lync client yet as this article does not cover the QoS configuration on the servers as was explained earlier.

Configure LPE Devices

This section is applicable to all Optimized Lync Phone Edition devices from any of the four current manufacturers.

The previously completed configuration for defining media port ranges for Lync clients applies to LPE devices as well, so no additional steps are required for addressing the media ports. 

By default Lync Server already has QoS enabled for any Lync Phone Edition device registered to it.  This default behavior is covered in detail along with a primer on DSCP in the previous article Lync Quality of Service Behavior.  As was pointed out in that article Microsoft has set the default DSCP value as 40 which is not commonly used for audio traffic in most networks.  Since the Expedited Forwarding classification of 46 is used for audio throughout this article then this value needs to be updated to configure LPE devices accordingly.

Be aware that the signaling traffic for LPE devices cannot be prioritized as the following behavior is hardcoded to only apply to the audio traffic leaving the phone.

  • Using the Lync Server Control Panel browse to the Clients > Device Configuration section.

  • Either edit the existing Global or custom device configuration if one exists, or create a new Site level configuration object if so desired.
  • Set the Voice Quality of Service (QoS) value to 46 and the Commit the change.


This modification as well as the previous changes applied to the media port ranges will not automatically be applied to any currently registered LPE devices until a maximum of 8 hours as each device’s own schedule of refreshing Lync policy changes occurs.

  • To push the change immediately to one or more devices simply reboot the phone(s) to force a new registration to the Lync server.

To validate the configuration change perform the same steps as in the previous sections to review the audio source port and DSCP marking values in a network trace.


At this point the environment should be correctly configured to support QoS on all signaling and media traffic involved with peer-to-peer media sessions between any internal Lync desktop client, Lync Phone Edition device, or Polycom VVX phone.  This includes all peer-to-peer media traffic as well as all signaling traffic between these clients and their registered Lync Front End Server(s).

As mentioned at the beginning of the article to complete the entire QoS story for all internally routed media make sure to additionally configure QoS policies on the Lync Servers so that multiparty conferences will also have their media protected when these same Lync endpoints are instead sending their media sessions directly to the server instead of in a peer-to-peer model.  For more details on these different call-flow scenarios have a look at the previous article Understanding Lync Modalities.

Updating CX5100 and CX5500 Firmware

September 21, 2014 by · 5 Comments 

An earlier article entitled Polycom CX5100 for Lync 2013 introduced the newest RoundTable device for Lync, briefly discussing the firmware update process.  As this product was brand new at the time there had been no newer firmware updates yet released to warrant covering that process in detail.


Now that the CX5100 and the nearly identical CX5500 have been out for some time a few firmware updates have been made available for them.  As usual it is always a best practice to utilize the latest device firmware version available to provide for the best experience possible.  And like the other Updates articles on this blog site the following table will be updated over time to capture any future releases for these two new products.  For details on the older CX5000 models head over to this older article.

Firmware Versions

The same software release package is applicable to both the CX5100 and CX5500 models so there are no separate download files to worry about.  The CX5500 does include additional Polycom UC software similar to what is found in the VVX phones which is already included in the package, but this additional code is simply unused by the CX5100 model.

For details on specific issues addressed in each update check the ‘Resolved Issues’ table listed near the end of the Release Notes for that specific version.  Some of the new features provided in future releases are also covered at the end of this article.

Version Date Details Links
1.0.0 December 2013 Initial Release of CX5100 model
1.1.0-10114 May 2014 Hotfixes and support added for the CX5500 model Release Notes
1.1.1-10117 September 2014 Hotfixes and security related patches Release Notes
1.1.2-32157 October 2014 Hotfixes and new functionality:
- CX5500 touch interface call control options when USB tethered to Lync
- CX5500 embedded UCS firmware upgraded to
Release Notes


Update Processes

These new models include a few different available methods for updating the firmware on the device.  Older models were basically limited to a single process which was not all that user-friendly.  It required installing an application on a Windows PC, physically connecting a Windows computer via USB, reading the documentation  to find a little known default device password, and then finally copying the package files to the device using a complicated command line utility.

The newest models have completely redesigned the upgrade process to provide for different requirements.  For one-off, hands-on updates the software can simply be dropped on a standard USB flash drive and inserted into the system to trigger an instant upgrade.  Yet for bulk updates the software can be retrieved from a central location and scheduled for periodic updates to automatically be applied. 

The multicolored LEDs surrounding the three Mute buttons on the camera base of either model are used to indicate the current readiness status of the device when powered on.

  • No Light - Device is ready to be used and mute is not enabled.  (Or it is powered off.)
  • Solid Red – Device is ready to be used and the microphones are muted.
  • Flashing Green – Device is powering on or rebooting.
  • Flashing Red/Green – Device is performing a firmware update process.

USB Flash Drive

By far the simplest method, and a welcome change over the previous generation device, a single file can be copied to a USB flash drive and inserted in the camera base to trigger an automatic update.  This process can be used to perform either an upgrade or a downgrade as the device will apply whatever version firmware is provided.  Do not store more than one firmware package on the drive, only copy over the desired version.

  • Download the desired firmware package form the table above and then save the .tar file to the root of a USB flash drive.  (Do not decompress the package or extract the files.)

  • The USB drive should be formatted as FAT32 .  (FAT partitions are also compatible but NTFS-formatted volumes are not.)


  • Insert the USB drive into the USB Type-A slot located at the base of the tabletop camera unit.


The secondary USB port on the Power/Data Box can also be used but this port is typically the blocked with a small rubber plug.  It is simply easier to just use the more accessible port on the camera base.

After inserting the USB flash disk the device (when idle and not actively in a Lync call) will look at the root directory of the volume and search for a valid firmware update package.

  • On a CX5100 if a valid firmware file is located then the upgrade process begins automatically within a few seconds.  The three mute buttons will begin to alternately flash red and green to indicate that the process has begun.

  • On a CX5500 the display will report a successful discovery of the firmware package on the USB disk, prompting to either cancel or proceed with the upgrade.  This screen will automatically advance to the upgrade process within a few seconds so there is no requirement to confirm by actually selecting OK.  Tapping Cancel within those first few seconds though will interrupt the automatic process and return to the main menu.


On either model the process is the same from this point forward as the blinking red and green lights indicate the firmware is being updated and the process should not be interrupted..  The CX5500 will additionally report the current upgrade status on the integrated display


From this point on do not attempt to use the device, disconnect, or connect anything. Removing the USB flash drive could corrupt the firmware and damage the system.

The device will first download the files from the USB disk and then perform a reboot within one to two minutes.  After the first reboot completes it will begin installing individual files in the firmware packages which typically takes about 10 minutes for the first batch of components.  A second reboot may be triggered mid-way through this process potentially a third reboot to complete then entire process.  The entire process should only take about 15-20 minutes.

After the final reboot the blinking lights will stop and the main screen will be displayed on a CX5500.

  • Remove the USB drive.

Although not necessary, if desired the firmware version can be checked to validate the expected version was successfully applied.  This is very easy on the CX5500 as it can be looked up on the device itself or via the integrated UCS web management interface (covered later in this article).  But on the CX5100 only way to check without connecting from a separate PC would be to review the device log files. (Additionally the control panel application can also be used on either model as an alternative method, covered in the next section.)

The following process is valid for either model (CX5100 or CX5500).

  • Connect the same USB flash drive which was just used for the update to a computer and look for a folder on the root directory named with the device’s Serial Number (e.g. 88142541B785DB).

  • Open this folder and look for the most recent log file package (e.g. log_1411222116678.tgz) which should have been written to the USB drive after the last boot up process.

  • Open the desired .tgz file with a compatible application (like WinRar) and then open the data\log\system_properties.txt file.

  • Search for the string “polycom.ver” to locate the reported version (ro.build.polycom.ver) and build number (ro.build.polycom.num) strings in the file.  In the example below the device’s current firmware is the 1.1.0-10117 release.

[ro.build.polycom.num]: [10117]
[ro.build.polycom.ver]: [1.1.0]


As mentioned a much easier way to do this on the CX5500 is to use the touch interface to browse to the Phone status menu.

  • On the device’s home screen select Settings > Status > Platform > Phone and review the Device Software Version value.


Control Panel

Also briefly mentioned in a previous article was the new Polycom CX5100/CX5500 Control Panel application which provides the ability to manage, update, customize, and troubleshoot the devices in ways not possible with the older generation RoundTable models.

Fellow Lync MVP and Polycom employee Brennon Kwok has already posted an excellent article covering the various options in the Control Panel application so all aspects of the utility do not need to be rehashed here.  As the focus of this article is on updating the firmware then only the Software Update sections will be covered.

Note that the update processes triggered by the control panel require that the CX5100 or the CX5500 is connected to an Ethernet network, the device has a valid IP address, and has access to the Internet (or to the network location of a custom update server if one is defined).

Also this process cannot be used to downgrade a device as it will only apply newer updates that are stored on the configured update server.  The only supported method to downgrade a device is via the USB process shown in the previous section.

Version Date Details Links
1.1.0-42 December 2013 Initial Release of the Control Panel application Download
1.1.2-74 October 2014 Added USB 3.0 optimization option for reduced cabling arrangements Download


The control panel can be used to update the firmware in one of two ways: either immediately or scheduled for a future, reoccurring time.

  • Download and install the latest version of the CX5100/CX5500 Control Panel Application from the Polycom Support site on an Windows workstation.

  • Connect the CX device using the blue USB 3.0 Type A-to-B cable from the tabletop camera base to the workstation.

  • Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and default to the System Information screen under the System section. 


Note that the current Device Software Version is displayed in the screen above.  Clearly this is a much easier way to verify the current firmware on a CX5100 than the log-based approach shown in the previous section.

Update Now

The following steps walk through the process of trigging an immediate update over the Internet and without having to download the firmware to a USB drive first.

  • Switch to the Software Update menu under the System section and select the Update Now button to initiate an upgrade process.


The device will then connect to the currently configured update Server source and look for a package different than what is currently installed.  By default the central Polycom update server which is available over the Internet is defined which always contains the latest publically available firmware package.  The exact location is not listed on this menu but is simply shown as ‘polycom’.  The next section of this article will show how to point the device to a custom distribution point instead of using the default Polycom server.

  • Once the update process begins the control panel will change to show on the update status.  Disconnecting the USB cable from the PC at this point will not cause any problems as the device is using it’s own Ethernet connection to retrieve the package directly from the server.  The only thing the control panel is doing at this point is reporting the upgrade status.


The remainder of the upgrade process is exactly as described in the USB Flash Drive section earlier in this article.  Once complete the control panel will reconnect to the device.

  • If the focus changes to the Profile Editor section the device password may be prompted for.  Simply hit Cancel and then switch back to the System > System Information screen where the new version can easily be confirmed.

Update Later

These steps show how to schedule an automatic update using software currently posted to the Polycom update server.

In order to modify the configuration of the device the device password will be required. The default password is the serial number of the unit, but be aware that the tabletop camera unit and the main box typically placed on the floor have different, unique serial numbers. The serial number located on the main floor box is what should be entered here, not the serial number found on the camera base.  An easier method to retrieve the serial number is to simply use the control panel as shown in the following steps.

  • Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and show the System Information screen under the System section. 

  • Record the Product Serial Number (e.g. 88142541B785DB) as this is also the default device password which will be prompted for in the next step.


  • Switch to the Profile Editor section and the control panel application should request the device password.  If it does not then either exit the control panel application and restart it, or go to the Load Profile menu in the bottom left corner and select Load from Device.

  • Enter the current device password.

  • Select the Software Update menu and then select a day under the Update Frequency menu and as well as a time under the Update Time menu. 


The example above shows that at 4:00AM device local time every Tuesday the public Polycom update server will be contacted to check for any updates. If at that time a newer version is found on the update server then the same update process and behavior documented earlier in this article will begin.

  • To optionally change the firmware distribution point simply replace the text ‘polycom’ with a valid URL of a web server hosting the desired firmware package (e.g. http://server.domain.com/directory/)


Point to the directory where the desired firmware package has been expanded.  To prepare the source directory extract the .tar file into the desired location so that the ‘millennium’ folder created by the extraction process is located in the directory that pointed to.  Do not point directly to the millennium directory in the update Server path as that is what the device looks for.

For example a subdirectory named ‘update’ was created at the root of the web server in this example and then the latest firmware package was extracted into that directory which automatically created a millennium subdirectory.  For future updates make sure to delete all previous files before extracting the new package.


Note that if the Update Server path is changed this also changes the location that the device will go to get updates when the previously discussed  Update Now process is manually triggered.

To return the configuration to the default Polycom server simply enter ‘polycom’ as the Update Server value and the device will recognize that name and utilize the hardcoded distribution URL.

  • Click the Apply to Device button to write the configuration changes to the device.  The update process will begin at the scheduled date and time.

Web Management Interface

This approach is only valid for the CX5500 model as the embedded UC Software stack includes the same web service that the Polycom VVX phones models utilize.  Just as with those phones the CX5500 can be updated remotely by accessing the embedded web interface, signing as as an administrator, and then updating the device.

Note that the password used to remotely connect as an Admin or User to the Polycom Web Configuration Utility is not the same as the device password used in the previous step for the control panel application.  The embedded UCS stack utilizes its own separate password which is identical to the VVX phones.  The default Admin password is ‘456’ and the default User password is ‘123’.

  • Connect to the device’s IP address in a web browser.

  • Leave the Login As selection on Admin, enter the password (e.g. 456), and click Submit.

  • Select the Utilities > Software Update menu.


Note that the options shown above are the same as what the control panel application provides.  Whereas the control panel has the immediate update and scheduled update options in different locations the web management utility has them both on the same page.

  • To trigger an immediate update process identical to what was covered in the previous section simply click Update Now.

  • Alternatively to schedule the update process to be triggered at a later date and/or time configure the Update Frequency and Update Time as desired and click Save.

Additionally the Update Server URL can be changed here, as instructed in the control panel, when needing to utilize a central destitution server other than the public Polycom update server.

New Features

This section will include details on some of the more important capabilities added throughout the various updates.

Version 1.1.2-32157

  • When a CX5500 model is USB tethered to a Windows workstation running the Lync 2013 desktop client the touch panel on the device can now be used to Answer or Reject an incoming Lync call.  The established call can also be placed on Hold or Ended directly from the device.

image  image

  • When simultaneous audio calls are active on both the tethered Lync client and via the embedded SIP telephony client then the calls can be individually managed using  new Calls and PC Lync buttons at the top of the screen.

image image

  • The CX5500 model also contains newer embedded Unified Communications Software (UCS) to bring it in line with the current VVX firmware release of 5.2.0.  Be aware that selecting the Lync Base Profile in this new release will disable the embedded web management interface as described in this previous article.


Understanding Lync Modalities

August 31, 2014 by · 8 Comments 

There are multiple ways to initiate communications sessions in Lync across different modalities and features.  These various options can utilize a few different network paths to reach the intended destination(s).  The path that each takes depends primarily on the type of communication involved and is also influenced by the number of parties involved.

In Lync, and going all the way back to Office Communications Server, there are a few constants that can be defined.

  1. All communication data can be categorized as either Signaling data where the session setup and handling is performed, or as Payload which would be be the actual content itself (e.g. media, instant messages, shared files).

  2. For signaling data Lync clients will always be connected to a Lync Server and this traffic will always go from client to server to client.  Lync clients do not and cannot send signaling messages directly to each other. 

  3. For payload data all modalities can utilize either a two-party Peer-to-Peer (P2P) model or a Multiparty Conferencing Unit (MCU) model.  Again the primary signaling path is always handled by the Lync Server as previously defined, but the payload can take different routes depending the scenario.  While most modalities can leverage either model depending on the type of call in session, some of them only support a single model and will always communicate in that fashion.

Using these constants the various ways that sessions can be initiated and how the different modalities are utilized can all be defined to understand exactly what is sending network data to where, and what actions trigger changes in these paths.


The following table can be used to quickly reference which types of modalities support which of the two communications models. For the purposes of simplicity media traversal through and Edge Server is not included here but regardless of the model the Edge server may be involved in transparently proxying one or both of the two data streams.

  Peer-to-Peer (P2P) Model Multiparty Conferencing Unit (MCU) Model
  image image
Instant Messaging   X
Audio Calls X X
Video Calls X X
Desktop Sharing X X
Application Sharing X X
File Transfer / Images X  
PowerPoint   X
Whiteboarding   X
Meeting Poll / Q&A   X
Attachment Upload   X


As noted some only support a single model while other can work in either model depending on the type of session currently in use when the specific modality is added.  Modalities which only support the MCU model will trigger an immediate escalation from an existing P2P session up to an MCU session when selected.


For example say that a basic audio call has been established between two Lync clients which utilizes the P2P model by default.  Then one of Lync users decides to add whiteboarding to the session, which requires the MCU as it is not a modality that is supported directly between the Lync clients.  The act of enabling the Whiteboard modality will automatically escalate the audio call to a conference call and at this time the P2P media payload session will be stopped and both Lync clients will then negotiate media paths directly to the MCU on the Lync Front End server.  This escalation can happen only once per session and is permanent.  From this point on the addition of any more participants or MCU-only modalities are seamless as the session has already been moved to the MCU.  Regardless of how many other participants or modalities are added to the call removing all of these will never trigger any sort of de-escalation back to a P2P session.  So even if there are only two participants remaining in the conference call and audio is the only modality left in use the call remains hosted on the MCU.

Instant Messaging


The most basic communications type simply invites the user to an instant message conversation.  The act of locating the other user, showing their presence, and sending the initial IM message as basically an invitation is all handled by the signaling path through the Lync server.  The payload, or the instant messages themselves, are embedded in the SIP signaling traffic for instant messaging and thus are one in the same.

This is the only modality in which the payload is included in the signaling path as SIP messages.  Additional features like sending files or pasting images into the IM window will trigger a different type of session establishment.  Only text and emotions (which are represented by their text values) are included in this single stream.

  • Internal clients connect directly to the primary Lync Front End server in the user’s home pool.  This traffic is always sent as TCP traffic to port 5061 on the Front End server, encrypted using TLS.

  • Externally connected clients connect to an Edge Server via TCP to port 443 (by default) on the Access Edge external IP, also encrypted as TLS.

  • Federated, Lync Online, and other supported public IM platforms will connect to the same Access Edge external IP but on port 5061 (by default) which is used for federation communications.

  • If a third Lync client is added to an active IM conversation window then the session is automatically escalated to the Lync Front End server and is handled by the IM Conferencing service.  Because the IM session and payload was already handled by the server end-to-end then there is no change in the communications path between the original two clients.

Audio Calling


Selecting an entry on the phone menu will place an outgoing audio call to the contact, depending on which option or number is selected.  Just hitting the button will place a call to either the only option (e.g. Lync Call) or to the last used option when the contact contains more than one choice.  As is true with all the actions in Lync the server is handling the signaling traffic so this includes the call invitation, reply, media establishment instructions, and anything else involved in the call setup.  Once a secondary media connection is established then the payload may be delivered to a few different locations.

Signaling traffic is sent to the same servers as defined in the previous section for either internal or external clients.  This is consistent throughout the rest of the scenarios covered in this article and from this point forward only the payload traffic patterns will be discussed specifically.

Among the multiple calling options which may be available on a Lync contact they will all fall into one of three categories: a native Lync Call, a Telephone Call, or Voice Mail.

Lync Calls

Lync Calls to other Lync clients in the same environment, federated companies, Lync Online, and soon even Skype clients will utilize native media establishment rules which dictate that a direct connection between both parties is negotiated whenever possible, otherwise the Internet Connectivity Establishment (ICE) protocol will be utilized to provide fallback assistance by leveraging the Edge Server.

  • In the event that a direct connection is available between both clients then the media payload will be delivered to randomly selected UDP or TCP ports on both clients somewhere between 1024 and 65535 by default.  It is possible to reduce this port range via Lync Server client policy configuration as documented here by selecting a custom range of contiguous ports.  This approach provides the ability to open a much smaller range (no less than 40 ports) on any firewalls which may sit between internal client subnetworks.  For audio streams UDP is the default protocol but if that cannot be established then Lync can fallback to using TCP, which is less desirable for delivery of real-time media over IP networks.

  • If direct connectivity between the two clients fails for any reason then ICE will be used to leverage the Edge Server for assistance.  Each leg of the bidirectional audio stream could potentially used different paths, whichever is the most efficient for each side.  Clients will either negotiate media connections directly to the client through one or more firewalls (STUN) or be forced to send media directly to the Edge Server (TURN).  For STUN connections the media payload would again be sent to any range of high-ports (1024-65535) on the remote client’s firewall.  For TURN connections the client would establish a media session with the Edge Server directly.  Internal clients would prefer to send media to UDP 3478 on the Edge Server’s internal interface, or to TCP 443 for media fallback if UDP connectivity to the Edge Server is not available.  External clients would negotiate media in the same UDP-before-TCP preference to the Edge Server’s external A/V interface over a dynamically-assigned port in the range of 50000-59999.  Fallback attempts in the event that ports in this range are not reachable can also utilize 3478 and 443.  Realistically ICE is a complex topic that is difficult to summarize in a single paragraph, so the important concept here is that the payload delivery will always attempt to be delivered directly and if that is not possible then there are many different options available to insure that the call is completed somehow.

Telephone Calls

Calls placed to telephone numbers can be routed a few different ways.

  • First, if the called Work number belongs to another Lync user who is actively signed into Lync then the server will leverage reverse number lookup to simply perform a Lync call as there is no need to send this call to any outbound PSTN destination.  This call routing will be identical to the scenario just covered n the Lync Call section above.

  • If the resolved Lync user is offline then the call will be forwarded to another destination based on the rule defined for that user (Call Forwarding, Simultaneous Ring) or sent to an Exchange UM server for voice mail.

  • If the called number is an external number like a cell phone or other PSTN destination then the signaling path is still client to server but the Lync Server will handle the reset of the call out through an mediation services to the PSTN.  The media payload for this call may be sent to a Mediation Server over either UDP or TCP to a dynamically assigned port in the range of 49152-57500.  Alternatively if Media Bypass is enabled and available for this call then the payload would not go to the Mediation Server but instead directly to a media gateway.

  • For external Lync clients the media payload session would need to travel to the Mediation Server by way of the Edge Server to first get into the internal network and then reach the mediation services, before be routed back out to the PSTN.

Voice Mail

Calls to voice mail are essentially a P2P session even though a server is technically involved.  The Exchange Unified Messaging service is not an MCU though and is really just another client in this communications path.  So calls to the Subscriber Attendant are categorized as a peer call between a client and server as these are the only two parties involved.

  • Calls placed to Voice Mail will be routed to the appropriate Exchange Unified Messaging server and will utilize the same UDP and TCP rules for RTP media as any other Lync audio call.

  • The Exchange UM service be default will dynamically assign a port in the 1024-65535 range just as Lync clients do, but this can also be configured although it is not technically supported by Microsoft.

Video Calling


Video calls will follow the exact same behavior as audio calls in Lync except that the additional video modality will is also included in separate media sessions.  From the signaling to the media payload delivery both audio and video utilize the same paths, protocols, and selection logic explained in the previous section.


Additional Modalities

Once a session has been established there are a number of additional modalities when can be added or certain features which leveraged will trigger additional sessions in the background.  Some of these additional options will retain the existing P2P communications pattern while others are capabilities provided only in multi-party conference calls be one of the Lync Server services, which will automatically escalate the existing P2P session to a conference up on the Lync Front End server even if there are still only two parties connected.


The layout of the content menu in the Lync 2013 client incidentally makes it very easy to understand which options fall into which category.

  • The Desktop and Application sharing options on the top row will respect the current call model, either establishing additional P2P sessions for the payload, or when already in a multiparty conference call simply connecting to the MCU directly.

  • The options along the bottom row will all trigger the creation of a conference call and move the current peer session up to the server.

Although these concepts are not new to  Lync (or OCS, or even LCS for that matter) when moving over from a different type of collaboration platform it is important to understand the models that Lync adheres to when planning for or troubleshooting an existing environment.

Updating Lync 2013

August 20, 2014 by · 4 Comments 

Upon looking at visitor statistics for this blog one of the reoccurring trends is the amount of traffic to articles like Updating Lync Phone Edition Devices after Microsoft releases a new round of Lync updates.  It can sometimes be difficult to successfully navigate through the various updates which follow different release schedules which are sometimes bundled together with other Office releases, so hopefully this article can bring some additional clarity to the subject.

This article will continually be updated to serve as both a source of new update information as well as a history of all past updates for both client and server platforms.  Releases for Qualified IP Phones will continue to be tracked in their original articles so this article will only cover the Microsoft-released server and client releases. The ‘Updates’ tag can be used as a quick route to all of these articles.  Keeping this data up-to-date and accurate is an ongoing process feel free to leave comments regarding any errors or dead links.

One thing to understand is that for some products Microsoft will continue to leave multiple previous versions online on their download sites, while others (namely Lync Phone Edition) are removed an only the latest cumulative releases are provided.

Lync 2013 Server Updates


As Microsoft only provides the latest releases for the server components then the following two links are always updated with the most recent information and can be used as a definitive source of the latest server updates.

Typically one does not need worry about the individual components as the LyncServerUpdateInstaller.exe is the ideal package to download and run on any servers.  This tool will locate and upgrade only the applicable components on each Lync server it is executed on locally.



At this point in the product cycle there is no real value in documenting the steps which have been already covered on various other websites for basic installations (like here and here) to more complex articles covering Enterprise Edition pools with mirrored databases.

The important points to understand are the following:

  • Use the LyncServerUpdateInstaller referenced above to make life easy.
  • Start inside-out and work from Front End servers toward Edge servers.
  • Do not forget to update and verify the backend SQL database for each Enterprise Edition pool that is patched

Component History

For occasions when working with the individual packages is desired then the following table covers each cumulative update release with links to the original Knowledge Base articles for each new component.

This matrix provides a visual aid to when and how often some of the various Lync components are updated as cumulative releases will typically not refresh every single server component.  The official package version numbers will always be in the format of 5.0.8308.xxx but the 5.0 has been truncated fro the following table for spacing purposes.

Release Nomenclature
Version: 5.0.8308.xxx
Release Date
CU5 HF2 
CU5 HF7.1
Core Components
2781550 2835432 2881682 2905040 2937305 2987511
3003358 3018232 3027553
Front End Server and Edge Server
2781547 2819565 2881684 2905048 2937310 2987510
3001616 3018158  
UC Managed API 4.0 Runtime
2781555 2835437 2881685 2905047 2937311 2995717 3018162  
Web Components Server
2781564 2835435 2881688 2905042 2937297 2995718
3018161 3027552
Web Conferencing Server
2787570 2835507 2937314    
Conferencing Server
2781551 2835434 3011902  
Mediation Server
2796554 2796554 2881699    
Call Park Service
2781549 2835440 2881703      
Persistent Chat
UC Managed API 3.0 Workflow
Administrative Tools
2837510 2967485    
Conferencing Announcement
Conferencing Attendant
2881700 2995716 3010050  
Central Management Server
2883679 2910244    
Backup Service
Windows Fabric
Response Group Service
Bandwidth Policy Service


Lync 2013 Windows Client Updates

The following table lists major client update packages with links directly to the download pages for both the client and any prerequisite components, which are only represented again when they themselves are updated.

Release Date Version Number KB Article Client MSO MSORES IDCRL Lynchelp
October 2012 RTM 15.0.4420.1017
February 2013 CU1 15.0.4454.1509 KB2812461  x86 | x64  x86 | x64
March 2013 15.0.4481.1000 KB2760556  x86 | x64
July 2013 CU2 15.0.4517.1004 KB2817465  x86 | x64  x86 | x64  x86 | x64  x86 | x64
August 2013 15.0.4517.1504 KB2817621  x86 | x64
September 2013 15.0.4535.1002 KB2825630  x86 | x64
November 2013 CU3 15.0.4551.1005 KB2825630  x86 | x64  x86 | x64  x86 | x64  x86 | x64  x86 | x64
December 2013 CU4 15.0.4551.1007 KB2850057
February 2014 SP1 15.0.4569.1503 KB2817430  x86 | x64
March 2014 15.0.4569.1508 KB2863908  x86 | x64
April 2014 15.0.4605.1003 KB2880474  x86 | x64  x86 | x64
May 2014 15.0.4615.1001 KB2880980  x86 | x64
June 2014 15.0.4623.1000 KB2850074  x86 | x64
August 2014 CU5 15.0.4641.1000 KB2881070  x86 | x64  x86 | x64  x86 | x64
September 2014 CU5 15.0.4649.1000 KB2889860 x86 | x64 x86 | x64      
October 2014   15.0.4659.1001 KB2889929 x86 | x64 x86 | x64      
November 2014   15.0.4667.1000 KB2899507 x86 | x64        
December 2014   15.0.4675.1000 KB2910927 x86 | x64 x86 | x64      


  • Releases denoted with ‘CU’ refer to the unofficial but commonly used Cumulative Update nomenclature for Lync.
  • Releases denoted with ‘SP’  refer to a Service Pack release for Microsoft Office.
  • 32-bit downloads are recorded as ‘x86’ while links to 64-bit download are labeled as ‘x64’
  • Items in strikethrough text have been pulled and replaced by the following update but have been left in this table for posterity.

Lync for Mac 2011 Client Updates

The following table includes each client update package for the latest generation Mac client, with the most recent entry’s description containing a link to the download page for the cumulative update.

Date Version Number Description KB Article
October 2011 14.0.1 Description of the Microsoft Lync for Mac 2011 14.0.1 update KB2634523
April 2012 14.0.2 Description of the Microsoft Lync for Mac 2011 14.0.2 update KB2690036
August 2012 14.0.3 Description of the Microsoft Lync for Mac 2011 14.0.4 update KB2726395
February 2013 14.0.4 Description of the Microsoft Lync for Mac 2011 14.0.4 update KB2778095
June 2013 14.0.5 Description of the Microsoft Lync for Mac 2011 14.0.5 update KB2844274
October 2013 14.0.6 Description of the Microsoft Lync for Mac 2011 14.0.6 update KB2888920
December 2013 14.0.7 Description of the Microsoft Lync for Mac 2011 14.0.7 update KB2909662
May 2014 14.0.8 Update for the Microsoft Lync for Mac 2011 14.0.8 KB2952672
June 2014 14.0.9 Update 2963369 for Lync for Mac 2011 14.0.9 KB2963369
October 2014 14.0.10 October 2014 update for Lync for Mac 2011 14.0.10 (KB3007876) KB3007876
December 2014 14.0.10 HF1 December 2014 hotfix for Lync for Mac 2011 14.0.10 (KB3019983) KB3019983


Lync Phone Edition Firmware Updates

The following table was moved from a previous article to lessen the burden of updating multiple articles each time a different client or server update is released.  For details on the actual device firmware update process see the original article entitled Updating Lync Phone Edition Devices.

Version Date System Details Size KB Article
1.0.199   OCS 2007 Beta Beta version pre-installed on some devices.  Not available for public download.
1.0.452.0 OCS 2007 Beta Beta version pre-installed on some devices.  Not available for public download.
1.0.522.101 7/30/2008 OCS 2007 Microsoft Office Communicator 2007 Phone Edition 10.8 MB KB952693
1.0.522.103 OCS 2007 Microsoft Office Communicator 2007 Phone Edition (Interim build included in Device Update Service)
1.0.522.115 12/10/2009 OCS 2007 Microsoft Office Communicator 2007 Phone Edition (for devices manufactured post August 2009) 10.8 MB KB972640
3.5.6907.222 11/19/2010 OCS 2007 R2 Office Communicator Phone Edition 2007 R2 13.0 MB KB2466291
4.0.7457.0 10/22/2010 Lync 2010 Release Candidate version pre-installed on some devices.  Not available for public download.
4.0.7576.0 11/14/2010 Lync 2010 Microsoft Lync 2010 Phone Edition (RTM)
4.0.7577.107 1/20/2011 Lync 2010 Microsoft Lync 2010 Phone Edition (Cumulative Update 1)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
4.0.7577.250 4/4/2011 Lync 2010 Microsoft Lync 2010 Phone Edition (Cumulative Update 2)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip

4.0.7577.296 7/26/2011 Lync 2010 Microsoft Lync 2010 Phone Edition (Cumulative Update 3
)* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip

4.0.7577.4047 11/21/2011 Lync 2010 Microsoft Lync 2010 Phone Edition (Cumulative Update 4)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

4.0.7577.4066 3/1/2012 Lync 2010 Microsoft Lync 2010 Phone Edition (Cumulative Update 5)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

14.9 MB
24.7 MB
24.5 MB
24.5 MB

4.0.7577.4100 6/16/2012 Lync 2010 Microsoft Lync 2010 Phone Edition (Cumulative Update 6)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

14.9 MB
24.7 MB
24.5 MB
24.5 MB

12/20/2012 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 7)
* Polycom CX700 and LG-Nortel IP Phone 8540 (.4363)
* Polycom CX500, CX600, and CX3000 (.4372)
* Aastra 6721ip and 6725ip (.4366)
* HP 4110 and 4120 (.4366)

15.9 MB
27.0 MB
26.8 MB
26.8 MB

4.0.7577.4387 4/18/2013 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 8)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

15.9 MB
27.0 MB
26.8 MB
26.8 MB

4.0.7577.4397 7/15/2013 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 9)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

15.9 MB
27.0 MB
26.8 MB
26.8 MB



Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 10)
* Polycom CX700 and LG-Nortel IP Phone 8540 (.4411)
* Polycom CX500, CX600, and CX3000 (.4414)
* Aastra 6721ip and 6725ip(.4414)
* HP 4110 and 4120(.4414)

15.9 MB
27.0 MB
26.8 MB
26.8 MB

4.0.7577.4420 1/8/2014 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 11)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

15.9 MB
27.0 MB
26.8 MB
26.8 MB

4.0.7577.4444 4/28/2014 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 12)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

15.9 MB
27.0 MB
26.8 MB
26.8 MB

4.0.7577.4450 7/18/2014 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 13)
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

27.0 MB
26.8 MB
26.8 MB

4.0.7577.4451 8/20/2014 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 14)
* Polycom CX700 and LG-Nortel IP Phone 8540
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

15.9 MB
27.0 MB
26.8 MB
26.8 MB
4.0.7577.4455 10/21/2014 Lync 2013
Lync 2010
Microsoft Lync Phone Edition (Cumulative Update 15)
* Polycom CX500, CX600, and CX3000
* Aastra 6721ip and 6725ip
* HP 4110 and 4120

27.0 MB
26.9 MB
26.8 MB



  • Be aware that although the KB articles are still online for earlier Cumulative Update releases the download pages are the same page for each successive release.  Thus previous CU releases are no longer available for download as the new package replaces each previous version.

Lync Room System

The following table lists the history of Lync Room System updates for the Crestron RL / Polycom CX8000 product.

LRS Version Crestron Version Release Date Microsoft Links Crestron Links
15.05 January 2014 KB2920616
15.09 April 2014 KB2929207 Release Notes
15.10.0 June 2014 KB2962967 Release Notes
15.11.0 September 2014 KB2988623 | Office Blog Release Notes | Download
15.12.01 November 2014 KB3011144 | Office Blog Release Notes | Download

Next Page »