A Solution for Skype for Business 2015 “Response groups may stop receiving calls after you run the Enable-CsTopology command”

Response group may stop receiving calls after you run the enable-CsTopology command


Good morning to everyone,

I have the first new ground in some time, for a Response group issue, I found in 2015, documented in 2016 and finally found it had been committed to KB4015898

Or Just SFB CU5!


I wrote this Piece on Response groups not ringing available agents, when the group members were in modes like longest Idle.

I said the only remedy available was to rebuild the response group and you may (or not) get a different result. Another viable step is

to “Use Attendant Mode.” This was my shtick in 2016.


So it turns out there had been an issue dating back 2015. I had personally run into this issue several times. It turns out somthing

you may do every day, turns out to be a “No No”. So if you have a need for “Re-Publishing” the topology Frequently, and you

have response groups, that may no longer be a good Idea, Even if there is a patch in place.


Just be aware, and make sure you update to CU5 or higher.



“Response group may stop receiving calls after you run the enable-CsTopology command


This needs to be installed on any server where you have installed the Skype for business. Back up your

Response groups for CU5.




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 “sfbpool.domain.com”} | Select DisplayName,RegistrarPool,SipAddress,Identity

Get-CsRgsAgentGroup | Where-Object {$_.AgentsByUri -match “User.Lastname@Domain.com” | 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.