Removing a Service Manager WorkItem using native PowerShell cmdlets and confirming what happens to the user relationship

Hi everyone, this is Austin Mack from the Microsoft Service Manager support team. Recently I was asked how to remove a Service Manager WorkItem (Incident, Service Request, Change Request, Release Record, Problem). I was also asked to verify that the relationships associated with the WorkItem did not get orphaned. Service manager relationships have two end points, and if you look at a SQL table such as ServiceManager.dbo.MT_System$WorkItem$Incident
you will notice that the user account for “Affected User” and “Assigned to user” are not stored in the incident table.  Service Manager creates a relationship to the user object which contains a lot of information instead of just recording a user string in the WorkItem. 

Below is what happens under the covers to the existing relationship when a WorkItem is deleted. This example uses an incident (IR78) that has the Affected user of  CONTOSO\GlenJohn148“. First we need to get the relationship ID for “Affected User” so we’ll run the following in PowerShell:

# Automatically import the Service Manager cmdlets
import-module (((Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\System Center\2010\Service Manager\Setup”).InstallDirectory)+”Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1″)
# Display relationship ID types
Get-SCRelationship | ?{$_.DisplayName -like “*User”| FT ID, DisplayName, Name -autosize

This shows the following:

ID
DisplayName Name
dec8d54a-6284-0f9d-cafb-8373f4dc865a  Has Working User System.WorkItem.BillableTimeHasWorkingUser
76bc6c3b-a77b-2468-0a63-169d23dfcdf0 Closed By User System.WorkItem.TroubleTicketClosedByUser
f7d9b385-a84d-3884-7cde-e2c926d931a5  Resolved By User  r System.WorkItem.TroubleTicketResolvedByUse
dff9be66-38b0-b6d6-6144-a412a3ebd4ce
Affected User System.WorkItemAffectedUser
15e577a3-6bf9-6713-4eac-ba5a5b7c4722  Assigned To User System.WorkItemAssignedToUser
ba8180d3-5bf9-1bbd-ae87-145dd8fc520f  Closed By User System.WorkItemClosedByUser
df738111-c7a2-b450-5872-c5f3b927481a  Created By User System.WorkItemCreatedByUser
f6205e94-82f9-9a97-3b4f-c7127afb43a8  Requested By User System.WorkItemRequestedByUser
40927c76-8993-7427-dd76-6245e8482ae7  Created By User System.PolicyItemCreatedByUser
ffd71f9e-7346-d12b-85d6-7c39f507b7bb  Added By User System.FileAttachmentAddedByUser
90da7d7c-948b-e16e-f39a-f6e3d1ffc921  Is User System.ReviewerIsUser
9441a6d1-1317-9520-de37-6c54512feeba  Voted By User System.ReviewerVotedByUser
aaf7adeb-920c-3d3f-2184-1de2a2cba5a0  Primary User System.ComputerPrimaryUser
cbb45424-b0a2-72f0-d535-541941cdf8e1  Owned By User System.ConfigItemOwnedByUser
dd01fc9b-20ce-ea03-3ec1-f52b3241b033  Serviced By User System.ConfigItemServicedByUser
fbd04ee6-9de3-cc91-b9c5-1807e303b1cc  Affects User System.ServiceImpactsUser
4a807c65-6a1f-15b2-bdf3-e967e58c254a
Manages User System.UserManagesUser

Next we’ll display the relationships for “CONTOSO\GlenJohn148″ that are of type “Affected User”:

## Display relationships in use by CONTOSO\GlenJohn148.  GlenJohn148 was a new account with only one IR as the affected user ##
$ADUserClass Get-SCClass -Name Microsoft.AD.User
$user=Get-SCClassInstance -Class $ADuserclass ?{$_.username -like “GlenJohn148”}
Get-SCRelationshipInstance -TargetInstance $user ?{$_.RelationshipId -eq “dff9be66-38b0-b6d6-6144-a412a3ebd4ce”}

Sample Output:

SourceObject:
IR78 – My Parent Incident request
TargetObject: CONTOSO\GlenJohn148
RelationshipId: dff9be66-38b0-b6d6-6144-a412a3ebd4ce
IsDeleted: FALSE
Values: {}
LastModified: 9/7/2016 19:31
IsNew: FALSE
HasChanges: FALSE
Id: ac3fd46d-a76f-8b74-6f42-9943e15a8a04
ManagementGroup: SM_mgmt_group_name
ManagementGroupId: 508488d4-edd9-3568-f10c-3a94e835587c

Because every relationship has two endpoints, let’s also display the other side of the relationship. An incident will have many relationships and one of them is the affected user (dff9be66-38b0-b6d6-6144-a412a3ebd4ce):

$WorkItemClassType Get-SCClass -Name System.WorkItem.Incident
$workitems Get-SCClassInstance -Class $WorkItemClassType;  
$workitem = $workitems | ?{$_.id -like “IR78”}
$workitems_RI=Get-SCRelationshipInstance -sourceInstance $workitem  foreach ($workitemRel in  $workitems_RI)
{
”  Name:  ” $workitemRel.TargetObject.Name + ”     RelationshipID:” $workitemRel.RelationshipId.ToString()
}

Sample Output:

Name:  MA79                                   
RelationshipID:2da498be-0485-b2b2-d520-6ebd1698e61b
Name:  CONTOSO.GlenJohn148        RelationshipID:dff9be66-38b0-b6d6-6144-a412a3ebd4ce
Name:  72e077d1-0386-414a-a525-b110fab4b67e    RelationshipID:a860c62e-e675-b121-f614-e52fcbd9ef2c

We can see the Affected User relationship present, and IR78 points to GlenJohn148. Using the previous PowerShell block with $Workitem defined to the single Incident, we can use PowerShell to remove (delete) incident IR78:

$workitem Remove-SCClassInstance

We can no longer get to the relationships for WorkItem IR78 because it is now gone. However, every relationship has two endpoints, so what happened to the relationship displayed by the user object? We can see the user
relationship that GlenJohn148 has by running the initial PowerShell script:

## Display relationships in use by CONTOSO\GlenJohn148.  GlenJohn148 was a new account with only one IR as the affected user ##
$ADUserClass Get-SCClass -Name Microsoft.AD.User
$user=Get-SCClassInstance -Class $ADuserclass ?{$_.username -like “GlenJohn148”}
Get-SCRelationshipInstance -TargetInstance $user ?{$_.RelationshipId -eq “dff9be66-38b0-b6d6-6144-a412a3ebd4ce”}
 
Sample Output:

SourceObject:
_____________________                                
TargetObject: CONTOSO\GlenJohn148
RelationshipId: dff9be66-38b0-b6d6-6144-a412a3ebd4ce
IsDeleted: TRUE
Values: {}
LastModified: 9/7/2016 19:50
IsNew: FALSE
HasChanges: FALSE
Id: ac3fd46d-a76f-8b74-6f42-9943e15a8a04
ManagementGroup: SM_mgmt_group_name
ManagementGroupId: 508488d4-edd9-3568-f10c-3a94e835587c

You will notice that the SourceObject that previously pointed to IR78 is now blank and the IsDeleted flag for the relationship is set to True and ready for Service Manager to groom the
relationship. Grooming occurs are regular intervals. Some items are not groomed for 2 days (at 2:00am) to allow the IsDeleted flag which is set to True to migrate to the Data Warehouse.

If you want to work with one of the other WorkItem classes, you can update the line below in your PowerShell command with the corresponding class:

$WorkItemClassType Get-SCClass -Name System.WorkItem.Incident

Below is the list of WorkItem classes that correspond to Release Record, Problem, Change Request, Service Request and Incident:

System.WorkItem.ReleaseRecord
System.WorkItem.Problem
System.WorkItem.ChangeRequest
System.WorkItem.ServiceRequest
System.WorkItem.Incident

Austin Mack | Senior Support Escalation Engineer