Missing indexes in LcsCDR database

I investigated some users complaining over Skype for Business (Lync) Monitoring Reports for Response Groups that timed out and didn't return data.


The query in the report Response Group Usage Data uses the stored procedure CdrRGSUsageTrend in the monitoring database LcsCDR.


I went through the estimated execution plan in SQL for this stored proc

The execution plan showed a number of missing indexes, which I created (listed below)


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing1] ON [dbo].[SessionDetails]
([ReplacesDialogIdTime] ASC,[SessionIdTime] ASC,[ReplacesDialogIdSeq] ASC,[CallFlag] ASC,[MediaTypes] ASC,[User1ClientVerId] ASC,[User2ClientVerId] ASC,[SessionIdSeq] ASC,[SessionStartedById] ASC,[User1Id] ASC,[User2Id] ASC,[CorrelationId] ASC,[ReferredById] ASC)
INCLUDE ([TargetUserId],[ResponseTime],[ResponseCode],[SessionEndTime]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing2] ON [dbo].[SessionDetails]
([CorrelationId] ASC,[SessionIdTime] ASC,[ReplacesDialogIdTime] ASC,[ReplacesDialogIdSeq] ASC,[CallFlag] ASC,[MediaTypes] ASC,[User1ClientVerId] ASC,[User2ClientVerId] ASC,[SessionIdSeq] ASC,[SessionStartedById] ASC,[User1Id] ASC,[User2Id] ASC,[ReferredById] ASC)
INCLUDE ([TargetUserId],[ResponseTime],[ResponseCode],[SessionEndTime]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing3] ON [dbo].[SessionDetails]
([ReplacesDialogIdTime] ASC,[ReplacesDialogIdSeq] ASC,[MediaTypes] ASC) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing4] ON [dbo].[SessionDetails]
([CorrelationId] ASC,[MediaTypes] ASC) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing5] ON [dbo].[SessionDetails]
([ReplacesDialogIdTime] ASC,[ReplacesDialogIdSeq] ASC,[SessionIdTime] ASC,[MediaTypes] ASC)
INCLUDE ([SessionIdSeq],[CorrelationId],[User1Id],[User2Id],[SessionStartedById],[User1ClientVerId],[User2ClientVerId],[CallFlag]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing6] ON [dbo].[SessionDetails]
([ReplacesDialogIdTime] ASC,[ReplacesDialogIdSeq] ASC,[SessionIdTime] ASC,[MediaTypes] ASC)
INCLUDE ([SessionIdSeq],[User1Id],[User2Id],[SessionStartedById],[ReferredById],[User1ClientVerId],[User2ClientVerId],[ResponseCode]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_SessionDetails_Missing7] ON [dbo].[SessionDetails]
([ReplacesDialogIdTime] ASC,[ReplacesDialogIdSeq] ASC,[SessionIdTime] ASC,[MediaTypes] ASC)
INCLUDE ([SessionIdSeq],[CorrelationId],[User1Id],[User2Id],[SessionStartedById],[User1ClientVerId],[User2ClientVerId],[ResponseCode],[CallFlag]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


After creating these indexes, the report was succesfully generated.

Change SIP URI of a response group

A customer wanted me to change the SIP uri of a response group workflow. This is not an option using the Response Group Configuration Tool, so what you must do is delete the existing workflow and create a new with the same parameters, the workflow Name is a unique identifier.

This is not what I wanted, so I turned to Powershell.

Tried:
$wf = Get-CsRgsWorkflow | where-object {$_.Name -eq "RGS test"}
$wf.primaryuri = 'sip:testrgs@sip.dom'
Set-CsRgsWorkflow $wf
But this was, kind of expected, not possible. You cannot change the primary uri of a Response Group Workflow...

Off course I can, I just need to figure out how.

In the backend database of the frontend pool hosting the RGS application, there is a database RGSDYN, I have blogged about that previously here: https://uctales.blogspot.dk/2016/02/response-group-agent-state.html, this database contains all dynamic data on e.g. agents logged in state. There is also a RGSCONFIG database, this database contains all RGS configuration.

Going to SQL Server Management Studio and opening a query window and entered this query:
use rgsconfig
go
Select Name,PrimaryUri from Workflows where PrimaryUri like 'sip:rgstest%'
Shows the Name and SIP uri of the RGS test workflow.

Changing the SIP uri of the workflow using SSMS, from sip:rgstest@sip.dom to sip:testrgs@sip.dom.
use rgsconfig
go
update Workflows
set PrimaryUri = 'sip:testrgs@sip.dom'
where PrimaryUri = 'sip:rgstest@sip.dom'

Now we have changed the SIP uri of the workflow, but this is not enough, we must also change SIP uri and proxy address of the application contact object i Active Directory.

To find the application contact, we go to Powershell again and searches for the endpoints.
Get-CsApplicationEndpoint | Where-Object {$_.sipaddress -like "sip:testrgs*"}
This cmdlet returns the application endpoint identity, which we need to locate the AD object itself.



Go to ADSIedit.msc and open the configuration store -> Services -> RTC service -> Application Contacts and edit the object attributes msRTCSIP-PrimaryUserAddress to sip:testrgs@sip.dom and proxyAddresses to sip:testrgs@sip.dom

Tested workflow and everything works nicely. Job done.

Disclaimer: Editing the database entries and AD objects for Application Contacts, might lead to an undesirable state, unrecoverable failures, unsupported solution or smelly feet. Please only do this at your own risk and if you know what you are doing and are able to recover from these risks.

Response group agent state or how to check RGS agent state

A client recently had an issue with a response group (RGS) queue, where the call came nicely into the queue, but the call was not presented to the agents.

A small query into the Skype4B backend database gave us the answer: The agent were not logged into the RGS.

select T1.Name, T3.DisplayName, T4.[State] 
from [rgsconfig].dbo.AgentGroups as T1
join rgsconfig.dbo.AgentGroupsToAgentsMap as T2
on T1.ID = T2.AgentGroupId 
join rgsconfig.dbo.Agents as T3
on T2.AgentId = T3.ID
left join rgsdyn.dbo.AgentGroupSignInStates as T4
on (T2.AgentGroupId = T4.GroupId and T2.AgentId = T4.AgentId)
where T4.[State] in (0,1) and T1.Name like 'servicedesk 1%'
group by T1.Name,T1.ID,T3.DisplayName,T3.ID,T4.[State]

Gave us a nice little list of the users:

State 0 = not logged in
State 1 = logged in
If the user is not in the list, the user has never signed into the response group.

We can see that there are no users active in Servicedesk 1. line group, so this explains why no calls are presented to the agents