SCSM: UR7 Bug & Fix: Activity Implementers Unable to Complete Manual Activities
By Gabriel Taylor
Published June 9, 2016
Estimated Reading Time: 5 minutes

Summary

SCSM 2012 R2 Update Rollup 7 introduced a bug with the permissions of Activity Implementers. This post contains a script used to create a workaround until the bug is addressed.

Introduction

 

In a previous post (link), I discussed why SCSM 2012 R2’s Update Rollup 7 was essential to any organization using SCSM. That remains true. However, the SCSM product team are mere humans, and as such mistakes sometimes happen. Recently I discovered a bug introduced in UR7 which breaks the Activity Implementers user role and any user roles based on it. It has been confirmed by the product team and a fix is forthcoming (likely in SCSM 2016). Users suffering from the bug need a workaround presently, though, so I developed a script (with some assistance from Mihai Sarbulescu) that provides a workaround for the UR7 bug until a fix is released.

 

This post describes the UR7 bug and provides the workaround script.

The UR7 Bug

 

One of the fixes introduced by UR7 is that Service Manager now properly sets values into the ActualStartDate and ActualEndDate properties of work items when they are opened and resolved, respectively. This is really useful for a number of organizations who wish to track metrics based on those stats and, prior to UR7, we needed to create custom workflows to set the values, which is a less optimal solution than having the product do it out of the box. UR7 fixed that, which is good.

 

However, one thing that was unfortunately overlooked is the permissions granted to the ActivityImplementer user role profile (the base set of permissions granted to the Activity Implementer user role and any custom user roles based on it). Referring to the User Role documentation on TechNet (link), we can see that the Activity Implementer user role has permissions to update only two properties – the “Status” and “Notes” fields of the Manual Activity class – and that no permissions are granted to update the “ActualEndDate” property. This is unfortunately not a case of the documentation being out of date; the permissions for the user role were not extended to support the changes made in UR7. As such, post-installation of UR7, you will find that any SCSM user who is a member of an Activity Implementer user role will be unable to save Manual Activities after marking them as “Completed” or “Failed”, since saving also triggers an update of the “ActualEndDate” property. The user instead gets an Access Denied error message, all due to the UR7 bug.

The Workaround

 

Fortunately, we are able to make (minor) modifications to the access permissions of user role profiles by interacting with the SCSM SDK via PowerShell. Unfortunately, there are no Cmdlets that provide this ability; to make this change, one has to have an understanding of the underlying SDK and security model SCSM uses. To say this is not well documented would be an understatement – aside from a small collection of scattered blog posts, there is no guidance on performing these tasks via PowerShell.

 

That reason is why I decided to write and provide a script that is pre-configured to make the necessary changes. If you are in need of implementing the workaround in your environment, all that is needed is to download the script and have an SCSM administrator run it on an SCSM management server. The script will load the SCSM SDK, extend the permissions of the ActivityImplementer user role profile with the ability to update the “ActualEndDate” property, and return a verbose message to inform you that it worked. No parameters are needed, since the script must be run on a management server anyway, though you can use the -Verbose switch to view status as the script proceeds.

 

A link to download the script can be found at the end of this post. Alternately, you can simply copy and paste the code below into a PowerShell console:

<#
    .SYNOPSIS
    Modifies SCSM permissions to allow Activity Implementers to edit the ActualEndDate property

    .DESCRIPTION
    SCSM 2012 R2 UR7 introduced a fix due to which SCSM will properly set the "ActualEndDate" property on work items at time of resolution.
    
    Unfortunately, Activity Implementers' permissions were not modified to give them permission to set the "ActualEndDate" property, resulting in the Activity Implementers user role being broken after the update was applied - members of the user role could no longer perform the one action their user role was meant to allow, that being the Completion of Manual Activities.

    A fix for the bug will be released as part of SCSM 2016. However, until that time and for those who are unable to upgrade, this script provides a workaround.

    This script will grant the Activity Implementers user role (and any user role based on it) permissions to update the "ActualEndDate" property of work items, allowing them to properly complete Manual Activities.

    A Service Manager administrator only needs to run the script on a Service Manager management server and the permissions will be added.

    .NOTES
    Written by Gabriel Taylor and Mihai Sarbulescu, 2016
#>

#region Parameters
[CmdletBinding()]
param ()
#endregion

#region Variables
[datetime]$StartTime = Get-Date
[string]$SMServer = 'localhost'
[string]$RoleName = 'ActivityImplementer'
[string]$ClassName = 'System.WorkItem'
[string]$PropertyName = 'ActualEndDate'
[string]$SMModule = 'System.Center.Service.Manager'
[string]$SMNamespace = 'Microsoft.EnterpriseManagement.EnterpriseManagementGroup'
[string]$RelEndPoint = 'Microsoft.EnterpriseManagement.Security.RelationshipEndpoint'
[string]$OperationImplicitScope = 'Microsoft.EnterpriseManagement.Security.OperationImplicitScope'
#endregion

#region Start up
Write-Verbose "ImplementUR7ActivityImplementerWorkaround.ps1" -Verbose
Write-Verbose "This script will extend the permissions of Activity Implementers to enable them to complete manual activities." -Verbose
Write-Verbose "This is a workaround for a bug introduced in SCSM 2012 R2 UR7." -Verbose
Write-Verbose "This script MUST be run on an SCSM management server." -Verbose
Write-Verbose "This script MUST be run by an SCSM administrator." -Verbose
Write-Verbose "If errors occur, validate that the above requirements are true and that no other custom permissions have been configured, then try again." -Verbose
Write-Verbose "Beginning permissions configuration ..." -Verbose
#endregion

#region Retrieve the SCSM install directory
Write-Verbose -Message "Retrieving SCSM install path from the registry ..."
$SCSMRegistryKey = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Setup"
$InstallDirectory = $SCSMRegistryKey.InstallDirectory.TrimEnd('\')
#endregion

#region Connect to the SCSM Management Group
## Add the SCSM DLL in order to interact with the SDK
Write-Verbose -Message "Loading the SCSM SDK ..."
$SDKDLLPath = $InstallDirectory + '\SDK Binaries\Microsoft.EnterpriseManagement.Core.dll'
Add-Type -Path $SDKDLLPath

## Connect to the Management Group
Write-Verbose -Message "Connecting to the management group on $SMServer ..."
$EMGType = $SMNamespace + '.EnterpriseManagementGroup'
$EMG = New-Object -TypeName $EMGType -ArgumentList $SMServer
#endregion

#region Identify the Profile and Class
## Get the user profile that should be changed
Write-Verbose -Message "Retrieving information for user role profile $RoleName ..."
$Profile = $EMG.Security.GetProfiles() | ?{$_.Name -eq $RoleName}

## Get class
Write-Verbose -Message "Retrieving information for class $ClassName ..."
$Class = $EMG.EntityTypes.GetClasses() | ?{$_.Name -eq $ClassName}
#endregion

#region Add permissions to update a class property
## Retrieve the property information
Write-Verbose -Message "Retrieving information for property $PropertyName ..."
$Property = $Class.GetProperties() | ?{$_.Name -eq $PropertyName}

## Get the Object__Set implicit scope
Write-Verbose -Message "Configuring custom permissions ..."
$ObjSet = $Profile.Operations | ?{$_.Name -eq "Object__Set"}

## Create the new implicit scope object for the class + property combination
$OIObject = New-Object $OperationImplicitScope -ArgumentList @($Class.Id,$Property.Id)

## Add the new scope object to the array of scopes, then update the profile
Write-Verbose -Message "Setting custom permissions ..."
$ObjSet.ImplicitScopes.Add($OIObject)
$Profile.Update()
#endregion 

#region Wrap-up
Write-Verbose -Message "Permissions configuration complete!" -Verbose
Write-Verbose -Message "Total time: $(New-TimeSpan -Start $StartTime -End Get-Date)" -Verbose
#endregion

Conclusion and Link

 

This script described a bug introduced in SCSM 2012 R2 Update Rollup 7. It also provided a script that implements a workaround for the UR7 bug until such time as a fix is released.

 

Please do be aware that this script is NOT an official solution and will not be supported by Microsoft. You should always test changes in a dedicated Test environment before implementing in Production.

 

The script can be downloaded from the following link:

ImplementUR7ActivityImplementerWorkaround.zip

Article By Gabriel Taylor
With over 12 years of experience in the IT industry, Gabriel brings a focus on repeatable processes, solution design, and quality execution to Model’s Project Services practice. He believes the true value of technology is how it enables businesses to gain efficiencies, increase productivity, and achieve their goals. He is proud to work with Model’s team of experts to bring those benefits to Model’s clients.

Related Posts