Response Group not ringing all available agents


Hello all,

This may be a time bound article. Yet you should be aware of the potential issue. Skype for Business may have a reproduced issue where the Response, group, depending on the method of call distribution, may not offer calls, as expected. I am not going to go to much into the troubleshooting of this issue, except to say that there is a few things you can collect to cross reference to your sip stack logs to test out a failure.

So of course you cant run logging all the time, but you can, when it’s the always on log. If the issue occurs where longest IDLE is not getting the call, you can go back and get the timeframe with the always on logs in Skype.

  • Open CLSLogger.exe from the installation location (Default is “C:\Program Files\Skype for Business Server 2015\Debugging Tools”).  Note:  Ensure to Run as Administrator.
  • Select the Edit Scenarios tab and then click the Create Scenario button.
  • Name the scenario and click OK.
  • Ensure the newly created scenario is shown in the drop-down window under Scenarios.
  • Add the following components with the corresponding Level and Flags settings.
      • RgsMatchMakingService:  Level:  Verbose; Flags:  All
      • S4:  Level:  Verbose; Flags:  All
      • SIPStack:  Level:  Verbose; Flags:  All
      • UserServices:  Level:  Verbose; Flags:  Check all flags with exception of TF_XMLSERIALIZER and All.
  • Click Save Senario
  • Proceed to collect the logs and save the data.

Next get your Documentation started by getting your facts:

  • Source Number:
  • RGS Workflow Number:
  • RGS Workflow SIP URI:
  • RGS Workflow Name:
  • Agent Group Name:
  • Agent SIP URI:

So now you have your Server Sip logs and your Response group Information. Next your going to query the Skype Database for some of your presence settings, from a local perspective. Collect and Interpret what you can. What you cannot comprehend will have to go to Microsoft or your technical support team, for analysis.


Run the following SQL query in SQL Management Studio against the backend instance of SQL for the FE pool


Script 1.


Run the following query against the RTCLOCAL instance on each Front End server in the pool.  Copy the results with headers.  You can paste the results in line below in a response email.


Other Shell command include:


Get-CsApplicationEndpoint | Where-Object {$_.DisplayName -match “RGS Presence Watcher” -AND $_.RegistrarPool -match “”} | Select DisplayName,RegistrarPool,SipAddress,Identity

Get-CsRgsAgentGroup | Where-Object {$_.AgentsByUri -match “” | Select *


Return these values to support, Or try do determine if the Presence is actually showing available, at the time the call should have been routed from the response group to the user. If you can get this information to show that the user was available for the call, but you don’t see that in the Skype logs, then you have your bug captured. Send this to support or contact Microsoft to work this issue into a patch.

At this time, as of Sept 14th 2016, if your having problems with Longest Idle, then your only recourse is to use the Attendant mode, as a work around, until this issue can be fleshed out.

If your Response group is working great then good! We hope it is that way. If its not, Hold on, Hopefully something is coming.




4 thoughts on “Response Group not ringing all available agents

  1. soder says: –> this bug cinformedly affects presence-based RGS routing (why? because the presence data gets corrupted in pool pairing scenario thanks to this bug). So you must apply this patch, then move RGS agents between the pools to trigger data cleanup. There is also a utility mentioned in the KB article if you must perform some data cleanup manually. There were also other SQL deadlock patches in the past 2-3 months for Sfb / Lync2013 server, those worth checking also.


  2. carlosdlra says:

    We have same problem. 1 pool with 4 servers.
    We’re going to apply….If the problem persists, we’ll open a Microsoft case, because we have problem with away and out-of-office presense status issues…


  3. Chris says:

    Current customer setup 2 Sfb EE Pools with 3 FE’s each in pool pairing. Users distributed on all 6 servers, RGS service running on primary datacenter. Some users in RGS with presence dependent Routing methods (specially parallel, serial) dont get anRGS call. Current workaround, change to “attendant” or restart RGS service from time to time. Thanks for the detailed article… i’ll check that out


  4. Paul says:

    We have this bug for a while now. we found that rebooting the backend SQL brings the RGS service back to life. Would love to know if anyone is still having this issue.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s