Lync 2013 Group call PickUp and its limitations

Evening All

This is a blog post on the untold ‘gotchas’ surrounding group call pick. Microsoft introduced the Group Call pickup feature as part of Lync Server 2013 Cumulative Update 1 released in February 2013. This is a server side feature which utilises the Call Park service, and basically a number is assigned within the Call Park Orbit Range to Call Pickup Groups.

Users can be assigned only to a group, when an inbound call arrives for a user that is a member of a Call Pickup Group, another user that is a member of that group can answer the call by dialling the call park pickup number which is associated with that group. Users can also answer calls for other users in groups which they are not a member of provided they know the pickup number for that group.

However the following limitations exist in that the call types outlined below cannot be picked up

  • Response Group Calls (in the case of reception, this can be worked around by receptionist enabling team-call for his or her group)
  • Delegated Calls
  • Team Calls
  • Simultaneously Ring Calls

So in my opinion the big gotcha is that a user who is a member of a team call group cannot have his/hers calls picked up as part of a group call pickup. So for an real life example would be the (boss/admin) situation where you have a manager who is set up with team call with his/her secretary on a one to one basis. The problem with this situation is that if a call comes to a manager or his/her secretary then another person outside of the team call doesn’t have the ability to do the group call pickup function to collect that call.

Hope the above makes sense. In my opinion, for me this is a slight oversight from MS.

Regards

Iain Smith

Lync 2013 Client and Proxy Prompting issue

Good Afternoon All

Following the addition and implementation of your Lync 2013 estate.

What is seen to becoming an annoyance for a lot of customers and people is the forthcoming Lync 2013 client deployment and the new adhoc ‘feature’ which is when you log onto the client and your company uses a web proxy OR has a proxy pac working internally, your user is prompted for additional higher privileged credentials. If the user simply ignores this prompt it will continue to plague them until they do enter the higher AD user privileges.

This is a new ‘feature’ which wasn’t seen with Lync 2010, so why is it happening now with Lync 2013.?

Simple answer is Microsoft has changed the logic for the client login routing. Now with Lync 2013 it firstly checks some HTTP addresses to locate the Lync 2013 registrar information, then if that fails it then by design it goes away and looks for the DNS records. (The DNS way is the way Lync 2010 works by default).

So why the change? Im not 100% sure why MS changed the logic, but all I know is the issue, its cause, and more importantly how to fix the issue and stop the prompting.

Firstly how to replicate the issue, so that you can retest after the fix.

Log into the client, then sign out and you will be back at the login page with the option to delete your sign in information like below

Image

Once the users information has been deleted, then sign in again.. at this point you will be prompted with your proxy auth dialogue box.

Now using your proxy pac amend/Match the URLS below to exclude/ignore

http://lyncdiscover.<sipdomain&gt; ie: http://lyncdiscover.northernlync.co.uk

now do the same for the other two addresses, so I total it should look like this

http://lyncdiscover@<sipdomain>

http://lyncdiscoverinternal@<sipdomain>

http://autodiscover@<sipdomain>

If you exclude these from your proxy checking the issue simply goes away.

As for Lync 2010 on start-up the client doesn’t check for any of the above HTTP addresses.

My gut feeling (I could be wrong) is MS have gone with one code base for the 2013 desktop client and the mobile client for windows 8 which would use these settings remotely

****UPDATE 5th July 2013

excluding lyncdiscover, lyncdiscoverinternal and autodiscover from your proxy authentication process is not sufficient in some cases.
You also need to exclude following urls:
– front end pool fqdn
– sip domain
– sqm.microsoft.com
A url http://sqm.microsoft.com/sqm/wm/sqmserver.dll is called during Lync 2013 client startup process.

Regards

Iain Smith