In SCSM when a Configuration Item that is discovered by a connector is deleted it should be marked as Deleted and moved to Deleted Items under the Administration wunderbar. This will only happen if all the connectors that have discovered that object determine that the object is deleted. For example, if my SCOM, SCCM, and Active Directory CI connectors all discover a computer object then all three of those connectors would have to tell SCSM that it is deleted before it would be marked as deleted and moved to the deleted items view. Sounds pretty straight forward, right?

Well… Except for the AD Connector.

Our documentation on configuring the AD connector has you define a Run As Account “that has rights to read from AD DS”. What we usually do is define a Domain User account here (most customers use the SCSM Service account) and the AD connector runs just fine. This is because a Domain User account has enough permissions to read from AD.

The issue we have is when we delete an object in AD. The object is then moved to the AD Recycle Bin which, by default, a Domain User cannot read from. The SCSM AD Connector is then never able to determine that an object has been deleted and it stays in SCSM as if nothing has changed.

What we need to do is to grant the Run As account we specified in the connector rights to read the Active Directory Recycle Bin:

https://technet.microsoft.com/en-us/library/dd392260(v=ws.10).aspx#BKMK_3

and

https://technet.microsoft.com/en-us/library/cc816824(WS.10).aspx

While logged into a Domain Controller in my lab with a Domain Admin account I run the following command to grant my Run As account (scsm-service) the rights to view the AD Recycle Bin’s contents:

dsacls "CN=Deleted Objects,DC=Contoso,DC=com" /G CONTOSO\scsm-service:LCRP

Now synchronize your AD connector and you will see that items that are in the AD Recycle Bin will be moved to Deleted Items, or in some cases, deleted entirely.

Also, don’t run your AD Connector with a Domain Admin specified as the Run As account to get around this issue.

Kevin Holman blogged about this issue for SCOM 2012 but many of our customers don’t know that it is also applicable to SCSM 2012 as well. It is one of the most frequent issues we find in our SCSM RAP as a Service offering here in Microsoft.

The issue is documented here: https://support.microsoft.com/kb/2913046/en-us

For each of your SCSM Management Servers and your DW Management Server please create the registry keys as Kevin show’s in his blog post: https://blogs.technet.com/b/kevinholman/archive/2014/03/12/opsmgr-2012-management-servers-might-not-reconnect-to-sql-after-a-sql-outage.aspx

Incidents By Support Group – Last 30 Days

SELECT Strings.DisplayName AS "Support Group", COUNT(*) AS Incidents
FROM IncidentDimvw Incident
Join IncidentTierQueuesvw Tier ON Incident.TierQueue_IncidentTierQueuesId = Tier.IncidentTierQueuesId
Join DisplayStringDimvw Strings ON Tier.EnumTypeId = Strings.BaseManagedEntityId
WHERE Strings.LanguageCode = 'ENU'
and Incident.CreatedDate > DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), dateadd(day, -30, getdate()))
GROUP BY Strings.DisplayName
ORDER BY Incidents DESC

Incidents By Classification (Top 10) – Last 30 Days

SELECT TOP (10) Strings.DisplayName AS Classification, COUNT(*) AS Incidents
FROM IncidentDimvw Incident
Join  IncidentClassificationvw Classification ON Incident.Classification_IncidentClassificationId = Classification.IncidentClassificationId
Join  DisplayStringDimvw Strings ON Classification.EnumTypeId = Strings.BaseManagedEntityId
WHERE Strings.LanguageCode = 'ENU'
and Incident.CreatedDate > DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), dateadd(day, -30, getdate()))
GROUP BY Strings.DisplayName
ORDER BY Incidents DESC

Incidents By Affected User (Top 15) – Last 30 Days

SELECT TOP (15) U.UserDimKey, U.DisplayName, WIAU.IncidentCount
FROM
( SELECT WIAU.WorkItemAffectedUser_UserDimKey, Count(*) AS IncidentCount
FROM WorkItemAffectedUserFactVw AS WIAU
where wiau.CreatedDate > DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), dateadd(day, -30, getdate()))
--and WIAU.WorkItemAffectedUser_UserDimKey != '3515'
--and WIAU.WorkItemAffectedUser_UserDimKey != '3516'
GROUP BY WIAU.WorkItemAffectedUser_UserDimKey

) AS WIAU
INNER JOIN UserDimVw AS U ON U.UserDimKey = WIAU.WorkItemAffectedUser_UserDimKey
--WHERE WIAU.IncidentCount > 2
ORDER BY WIAU.IncidentCount DESC

Incidents By Assigned To User – Last 30 Days

SELECT U.UserDimKey, U.DisplayName, WIAU.IncidentCount
FROM
( SELECT WIAU.WorkItemAssignedToUser_UserDimKey, Count(*) AS IncidentCount
FROM WorkItemAssignedToUserFactvw AS WIAU
where wiau.CreatedDate > DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), dateadd(day, -30, getdate()))
and wiau.DeletedDate is null
GROUP BY WIAU.WorkItemAssignedToUser_UserDimKey

) AS WIAU
INNER JOIN UserDimVw AS U ON U.UserDimKey = WIAU.WorkItemAssignedToUser_UserDimKey
--WHERE WIAU.IncidentCount > 2
ORDER BY WIAU.IncidentCount DESC

I then went to run a report to ensure everything was working and this is what I saw:

Where are all my reports???

Thinking this might be just a permissions issue I then logged in with my SCSM_Admin account which I installed Service Manager with. Everything looks great:

I logged back in with the regular user account and it’s still having the issue. Looking at the Operations Manager event log on the console machine see the following warning event:

Operations Manager Event ID 33568 “The permissions granted to user” … “are insufficient for performing this operation”

OK, it’s a permissions issue! But wait… he’s a member of SCSM_Admins which has rights to EVERYTHING. This shouldn’t be happening. First thing I go check now is the permissions of the data warehouse management group:

Well, that look’s good.

Next I start looking into permissions on the SQL Reporting Services server. I open up https://localhost/reports while logged in with my SQL Admin account. I drill down into the Home > SystemCenter > ServiceManager folder in SRS. From there I click Folder Settings and then Security:

Hmm… Everything looks good here.

Now I start to Bing the issue and see if anyone else has run into this. J Not much out there other than some customers had to add the user to Local Administrators on the Reporting Services server to get it to work. In the screen shot above BUILTIN\Administrators is defined… I think I’m on to it now!

Now I start to work my way up the folder structure to see what the parent permissions here in SRS look like:

Up one level to SystemCenter and what do we see?!?!?!

I click “Edit Item Security” and get the following error:

OK, let’s not change inheritance here and just go up a level and check permissions at Home. It’s exactly the same at SystemCenter which is expected. At Security for Home I click “New Role Assignment”:

I enter my group (contoso\scsm_admins) and grant them the Content Manager role.

Security for the Home folder on the SRS instance should look like this now:

I go back to my console PC, restart the Service Manager console, and select the Reporting wunderbar:

SUCCESS!!!

My blog will primarily focus on System Center Service Manager as it is the product I’m focused on currently. I’m still supporting Operations Manager though so I’m sure there we be things here and there for it pop up as well.

Thanks!

Brian