Lync 2010 had a very limited set of options for controlling the use of mobile clients. This has been extended in Lync 2013 and it is worth reviewing before deploying. The defaults are generally sensible but may be too “free” in some environments. You may find that a single policy works for all users, or some may have specific needs or regulations that apply that require a special policy.
Beyond the global policy, new policies can be created for sites or users. As with all Lync policies, these are not cumulative – only a single policy applies to a particular site or user and all of the settings within it are the ones to be used.
The best place to start – if set to True, users can sign in and use Lync mobile. If set to False, they are prevented from doing so.
When set to True, users can make and receive VOIP audio and video calls using the mobile client. When set to False, it will behave much like the 2010 mobile client – IM & presence and calls made via OutsideVoice / Call via Work (explained below) if allowed.
Telephony – Call Via Work
This is probably the most misunderstood setting, and one of the few that also existed in Lync 2010. It is set to True by default.
The other name for this functionality is “Call via work”. As the Lync 2010 mobile client did not have the ability to make a VoIP call, this was the workaround and is still useful in many situations now.
If the user tries to make a call but doesn’t have a method to do it via VoIP (eg. they have RequireWifiForIPAudio enabled and are on 3G), Lync Server will establish a call to their mobile telephone number – this goes via the PSTN, not Lync. The user picks up the call, and Lync Server makes another call to the number or contact they were trying. Once established, Lync Server joins the two calls together and they can start the conversation.
When is this useful? Really any time that network conditions mean a PSTN call would be better.
- Your work (Lync) number is presented to the other party, instead of your mobile
- Unless you pay for incoming calls, there is no cost to the user – good in BYOD scenarios
- This also works with any Lync contacts, including those not enabled for Enterprise Voice, or federated contacts who you may not have a number for!
- You will be on the move during the call – a VoIP call cannot be handed off between wifi and 3G.
This requires the mobile client to be capable of receiving a phone call – so most tablets such as iPads will not work for this. The user also needs a voice policy that is enabled for simultaneous ring, and is allowed to call their mobile number as well as the number they’re calling.
Concerns around this feature are normally driven by cost. A call made this way involves two PSTN calls from Lync – one to the user’s mobile phone, one to the number they’re contacting. In Europe at least, mobile phone contracts tend to have generous allowances, so companies would rather force staff to make a mobile call if necessary instead of using this Lync feature. It is worth piloting and seeing if the functionality is worth the extra cost for your organization.
If set to False, and a call is attempted that can’t be made via VoIP, the Lync client will pass the number to the phone’s dialler to make the call instead.
Within the mobile clients, the user has options to force use of Wifi for different types of call. They may not want to use up their mobile data allowance, or may want to ensure that wifi is used for best quality.
The administrator can override these settings and prevent the user from changing them via the following:
They are all set to False by default (user can decide). If set to True, the options are still seen but the sliders are greyed out.
Note that a video call is actually an audio and video call – if RequireWifiForIPAudio is true and RequireWifiForIPVideo is false, then video calling over 3G will not work!
In this example, RequireWifiForIPVideo is set to True and the others set to False:
For connection into the user’s Exchange mailbox, to retrieve voicemail and show the meetings for today and tomorrow, the client uses Exchange autodiscover to find the Exchange Web Services (EWS) address. The default value is True, which will allow this to be attempted and will display the information if successful. If this functionality is not allowed, or will not work (eg. if EWS is not published), then it can be disabled by changing this to False.
These are set to True by default, and the client will keep around 100 entries of either. If the saving of this data is not allowed, set the values to False.
This option is set to True by default, and like the “RequireWifi” settings, allows the user to choose. Even when the user signs out, the password field is pre-populated with their saved password. Setting to False means the option is not shown.
I have a separate post coming, detailing how authentication works in Lync 2013 mobile. Recent clients make use of client certificates to authenticate, making the saving of AD credentials redundant. In most environments, I would recommend setting this to False.