Microsoft has released CU March 2013 for Lync Server 2010 and Lync Mobile 2013 Products

Last week Microsoft released CU March 2013 for Microsoft Lync Server 2010 and the Windows Phone/Apple iOS mobile clients for Lync 2013 (with February’s Cumulative Update). The WP8 app was already discussed on my blog (a quick shout-out) but never the iOS. All the mobile client links are included below (their respective stores could be searched too) as well as the Lync 2010 Cumulative Updates.
Don't forget the required SQL update once the CU has been installed...

INSTALL-CSDATABASE -UPDATE -CONFIGUREDDATABASES -SQLSERVERFQDN <EEBE.FQDN> -USEDEFAULTSQLPATHS

Additional Notes:
Lync Server 2010 build number is 4.0.7577.216
Lync 2010 Client build number is 4.0.7577.4378
Lync Server 2013 build number is 5.0.8308.291
Lync 2013 Client build number is 15.0.4454.1506
Lync Group Chat build number is 4.0.7577.4102
Lync Group Chat Server build number 4.0.7577.4778
Lync Group Chat Admin build number 4.0.7577.4102
Lync Attendee build number is 4.0.7577.4356
Lync Attendant build number is 4.0.7577.4098
Lync Phone Edition Polycom build number 4.0.7577.4372
Lync Phone Editions (other than Polycom) build number is 4.0.7577.4366 (4363 for CX700/8540)
Lync 2013 for Windows Phone build number is 5.0.8250.0
Lync 2013 for iPad build number is 5.0
Lync 2013 for iPhone build number is 5.0
Lync Basic 2013 build number is 15.0.4420.1017
Lync VDI 2013 build number is 15.0.4420.1017

Recently I was involved with an on-premise Lync 2010 deployment that ended up 'breaking' the ability for users to join an externally hosted Lync meeting. The issue arose once Lync was deployed internally and users found they could join their own meetings, external participants could join those same meetings, but if an external company sent a Lync meeting invite - the meeting join failed. My business partner John Lockett and I worked out a matrix to help describe the issue which is found below.

In a nutshell - if on-premise Lync 2010 is deployed with an Edge server, federation is enabled for both the Lync pool and the user, open federation is not utilized (with the external company NOT listed in their allow list), policy kicks in and prevents the meeting join from being successful.

The logic - as far as I can tell - is that an organization and user are authorized to federate, yet the external company the federation is attempting to communicate with is not on the allow list. Therefore, by policy, the join is denied. As a small step-back if you are internal to your LAN - i.e. you can reach your Edge server's internal network card - Lync will proxy your communication for you to the external party. Imagine a meeting join is started, the SIP communication is sent to your front-end server where it asks to communicate with the external SIP meeting. Your Lync server checks/validates that the communication is allowed and if not, the ability for the Lync server (and thus the Edge server) to join on your behalf is denied. Ideally the Lync client would then try the alternative route of joining the external meeting directly but that logic does not seem to currently exist. I have yet to test this same join behavior with Lync 2013 but will do so shortly.

Below is the flowchart that details the logic. A solution for the issue may be one of many:

·          Disable federation for the effected user

·          Disable federation for the pool

·          Add the external company to the SIP Federated Domains in the Lync Control Panel under Federation and External Access

·          Enable Open Federation (Enable partner domain discovery) in the Lync Control Panel under Federation and External Access | Access Edge Configuration