Lync 2013 Mobile and Desktop Click-to-Join for Non-Enterprise Voice Users

Recently I blogged about  the available options in Lync 2010 for non-voice enabled users. Basically there are two different administrative options in 2010 depending if it’s the mobile client or the desktop client in 2010. For the mobile client the click to join configuration was superior to the desktop/web client which relied on static routes and had very little control over gateway selection and call authorization. 2013 this has changed dramatically with an improved more flexible configuration that better adheres to voice policies. Now in the conferencing policy you are able to select “Allow participants not enabled for Enterprise Voice to dial out”.

Below is a blurb in the Lync Wiki page for 2013 new features:

Conference Dial-Out for Users Not Enabled for Enterprise Voice

While this was possible in earlier versions of Lync using a static route it was always less than an optimal solution fortunately Lync Server 2013 makes it much easier for Administrators to enable users who are not enabled for Enterprise Voice to initiate dial-outs from a conference. This means that meeting organizers who use this Conferencing Policy setting can accommodate participants for conference dial-outs. The meeting organizer can also initiate a conference dial-out, even if he or she is not enabled for Enterprise Voice.

The screen shot above shows the new policy option. Of course if you allow this configuration to be enabled then you also need to apply a voice policy to the non- voice user that wants to host conferences. So users trying to dial-out are controlled as per the flow diagram below:

The important things to remember for non-voice users are as follows-

1. Is the host part of a conferencing policy that allows non-voice users to dial-out?

2. Has the host got a voice policy assigned?

If you have a high demand for mobile clients (which nearly everyone does) applying a default voice policy as part of the initial user configuration regardless of voice enablement seems to make a lot of sense. If you automate through PowerShell the initial enablement would mean the addition of a line to assign a voice policy. I see this as an easier way to apply the policy rather than going back after the fact and assigning a voice policy.

Hopefully this helps shed some light on a configuration that was problematic in 2010 and now a lot easier in 2013. The experience across mobile and desktop/web applications in 2013 is consistent from an administrative and user point of view which makes everyone's lives a lot easier.

VoIPNorm