You can easily see how many response groups have been mapped successfully by RGS service by collecting Logs for the RGSHostingFramework Component while the service is restarting and then in the logs search for string 'Successfully Registered Endpoint' So if you have 10 Response Groups in your Company then the RGS service while restarting should successfully map 10 Contact objects to 10 Workflows giving you a Total of 10 Successfully Registered Endpoints. In this case in a perfect world When the RGS service starts on the FE it should be able to detect that there are 10 Contact Objects in AD representing 10 response groups and it should also find 10 corresponding Workflows mapping to these 10 Response groups.Įvery time the RGS service finds a Contact object for RG in AD and its corresponding Workflow it considers this a We call this Successfully registering Endpoint. Once it finds all the Entries the next thing a FE is supposed to do is Find out the corresponding Workflows for these 10 Response Groups in order to create a 1:1 mapping of Response group and its workflow. In that case when RGS service is starting it should find 10 contact objects in your AD that have the MSRTCSIP-OwnerURN attribute set to 'urn:Application:RGS' Let's Assume in your Organization you have 10 Response Groups created. ' This basically means that FE tries to find how many response groups do you have. It will first reach out to Active directory and find all the Contact Objects that have When it is starting the RGS service will do the following tasks Now Whenever You Restart the RGS services on any FE server, or if you Restart the FE server Itself. In addition, Every RG will have a workflow associated with it. So Every Response group in your Organization will have a Contact Object in Active directory and the above two attributes will be populated for them. MSTRCSIP-UserEnabled - 'TRUE' -> This Tells the FE server that This Object is actually Enabled and a Valid Object.Įvery Response group also has a WORKFLOW assigned to it, this dictates what actions to take or what options to present to the caller whenever this RG is being called. MSRTCSIP-OwnerURN - 'urn:Application:RGS' This Tells a FE server that this Object is actually a Response Group, This Contact Object Has two specific attributes that are very important, The Attributes are To Understand why we see this issue we have to look into how RGS works and how does it gets initialized.Ī response Group has a few important components that are related to it,Įvery Response group has a Contact Object that gets created for it in Active Directory This articles may help you understand the one of the causes of this issue and the corresponding solution.

We Recently came across an issue where calls to ONLY certain Response groups were failing with an Error '500 Internal Server Error' while calls to other response groups would work. First published on TECHNET on May 09, 2016

Skype call internal error