Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Home
- System Center
- System Center Blog
- Removing a Service Manager WorkItem using native PowerShell cmdlets and confirming what happens to the user relatio...
Removing a Service Manager WorkItem using native PowerShell cmdlets and confirming what happens to the user relationship
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Published
Feb 16 2019 11:47 AM
1,100
Views
Feb 16 2019
03:47 AM
Feb 16 2019
03:47 AM
First published on TECHNET on Sep 19, 2016
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:
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:
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:
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:
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
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
1 Comment
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.