Microsoft #Lync Simple Ring Group for Small Work Groups That Avoids Answer Delay and Is More Survivable


In a small departmental or branch office scenario, users may be averse to the small delay on answering introduced by Lync Response Groups and Lync Phone Edition devices. (more details on the RGS delay: When Can I Say HelloRGS Delay Fix Suggestion; )  If you want a very simple ring group with no bells or whistles that avoids the RGS delay on answer, the below might be a work around for you.

  1. Setup a Lync User to use as your Hunt Group SIP address that you will send calls to (name the user what you want:
  2. Login to the user using the lync2010 client and Options | Call Forwarding | Edit my Team-Call Group Members and add those you want to ring at the same time.
  3. How soon to "0-at the same time"
  4. Now set "Simultaneously Ring" to "My Team-Call Group"

team call setup

You can use the Lync/Exchange/AD user to set the hours via Outlook (or Outlook Web Access)

outlook option

Using a Response Group to Add Flexible After Hours Scheduling

Commentor @AL has made an excellent suggestion on how to use a placeholder Response Group to get around the limitations of Outlook after hours schedule. Basically this methods uses RGS to get scheduling, but bypasses the inefficient RGS group ringing processing. Below are the steps:

Create a Response Group “Group” with no agents in it.

Now create a “Queue”, place the empty “Group” in it, and configure the below settings

  • Enable Queue overflow = enabled
  • maximum number of calls = 0
  • call action = forward to SIP address
  • SIP address = (<-or your “hunt group” lync user)


Now create a Workflow/Response Group and place the above “Queue” in it. Now you will have the snappiness of TeamCall “huntgroups” plus the afterhours configurability of Workflow/Response Groups.

Note that using a Response Group to control your after hours is a benefit in that you have flexible, server based schedule, but it is a failure point if this is a remote branch.

Some Notes/Pros/Cons About The Work Around in this article:
  • Only the member of the Team-Call group that answers gets a call record (good)
  • the Ring Group "hunt group/dummy" user does not need to be logged in (good)
  • Actually avoids some survivability issues that might come with Response Groups  in a SBA WAN down scenario (good) (Read more: Click Here)
  • Avoids “trombone” in a SBA scenario where PSTN comes into remote branch but RGS is hosted on Front End at main site. (good)
  • Simplest way to administrate is log into user using Lync 2010 client (no web administration or Powershell) (not so cool)
  • No dynamic login and logout of Ring Group by group members. (not as good)
  • Open hours will depend on Outlook work hours which are quite a bit more limited than Lync RGS business hours and cannot be administrated via Powershell. (not so cool)
  • There is a hard 20 end point limit in team call. (if a user has an IP phone and Lync client that is 2 end points)  (See:
  • We have tested having the TeamCall “Unanswered Calls” going to an Exchange UM Attendant and this scenario seems to work fine.
  • NOTE: TeamCall Group members cannot transfer TO a TeamCall Group they are a member of. So this means someone who is a part of our “hunt group”/teamcall can NOT transfer or forward calls to this number (not good)
  • NOTE: If the Lync User with TeamCall is not logged in, and call transferred to this user will goto Voicemail.
  • Finally, be very careful and make sure all your objectives are met before implementing and/or recommending this work around.

I suspect there might be some other cons I didn’t think of, so feel free to comment!

Source of Idea:
TechNet user emu78 in this post: Click Here
Thanks to commentor AL for the Response Group idea.


  1. Hi Matt, this could be a nice workaround, I used it on some of our remote sites.
    A big problem (for us) is the lack of a REAL "Call Pickup" feature in Lync 2010, a function often used in small remote office, especially when there are non-DID numbers.

  2. Call Pickup is not the focus of this blog post...but i don't disagree. Here are my comments on Call pickup:

    also, vote on feature at

  3. This is what we've done to get around the delay and it seems to work well for most needs where people don't want the more advanced call routing features.

    Another possible con is that if one of the members of the team call group wants to configure a personal call answering rule which routes to the main number, it doesn't work (at least not for us). I think UM was flagging the call so it couldn't be forwarded.

  4. @bill, appreciate that input. I'll have to test this senario. Is this when an individual lync users wants to forward to our "hunt group"?

  5. Right. So if I'm in a hunt group for the HR department and I want an option in my personal voicemail to route someone back to the main HR number when I don't answer, that's where we had trouble.
    Granted, it's been a while since I've tested it and even then, it could've just been something weird in our environment.

    1. @Bill, we are finding a lot of challenges with transferring to this workaround huntgroup. I suggest it may not be a great fit if you need to transfer call to it. See our updated comments about transferring and team call.

  6. I am very curious about this "working hours" feature for call-forwarding scenarios. This is definitely not detailed in any Microsoft Lync documentation. Does this mean, if I have enabled workinghours-conditional call forward, this forward rule is active only during my working hours? What kind of call-fwd experience my callers will have if they call me outside of my working hours? Does the feature depend on successfully established Outlook integration connection on client-side (I believe Lync registrar has no kind of connection to exchange to retrieve my working hours on server-side)? If I have disabled Outlook integration completely, is working hours still selectable or dimmed out persistently? What about multiple endpoints signed-in in parallel, with different outlook integration state?

  7. @Ricardo, frankly I don't think the Outlook "working hours" is robust enough for most businesses needs, so I didn't spend much time testing it. So if you need this to work you need to test it.

  8. Matt: to keep things simple, I will have only 1 question from the list: "working hours" is a server-side-procured time value, or polled from the exchange CAS directly?

    1. i would guess it uses exchange web services/EWS like it does for UM. (but i didn't test)

  9. Do you happen to know if Lync 2013 has fixed the response group pickup delay?

    1. @brett - answer is that "as of today the issue remains". it will require a fundamental rework of RGS logic but it is planned to address it at some point. No ETA.

  10. Or use the hunt group just for AH functionality (not attendant management):

    1) Have a hunt group that handles AH functionality
    2) Hunt group queue contains an empty "placeholder" group
    3) Hunt group queue configured to forward all calls to attendant after 0 calls in queue (basically all calls)
    4) Attendant has team-call setup

    + We get managed AH functionality
    + We get instant call pickup using team call group

    1. Al, very clever solution, we will edit blog to include this! Would be glad to mention you if i have name.

  11. Sadly more than 4 years later this is still an issue. Is this still the best solution for a small branch office where rgs resides on a standard edition server in another office?


Note: Only a member of this blog may post a comment.