Archive | Service Manager RSS for this section

Service Manager PowerShell Workflow: The operation has timed out

Recently I was working on a PowerShell Workflow for Auto Group Assignment for Service Requests and Incidents for a customer and ran into a snag… Effectively, although the script appeared to be running as it should and the Support Group would auto-assign I received the following error:

System.TimeoutException: The operation has timed out.
at Microsoft.EnterpriseManagement.TaskRuntimeManagement.ExecuteTaskInternal[T](IEnumerable`1 targets, Guid taskId, TaskConfiguration configuration)
at Microsoft.EnterpriseManagement.TaskRuntimeManagement.ExecuteTask[T](IEnumerable`1 targets, ManagementPackTask task, TaskConfiguration configuration)
at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.TaskExecutor.RunTask(String sdkServerName, Guid taskId, IList`1 taskTargetIds, Dictionary`2 taskArguments, Int32 taskTimeout)
at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.RunTaskActivity.Execute(ActivityExecutionContext executionContext)
at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
at System.Workflow.Runtime.Scheduler.Run()

Multiple re-creations of my workflow using the authoring tool and manual script execution showed the script was working as intended.  It turns out the issue was that the SQL Broker wasn’t enabled for the ServiceManager Database, thankfully an easy fix.

  • Stopped the SQL Server Agent
  • Stopped all Service Manager related services
  • Checked the Broker Enabled Status via SQL Query: SELECT is_broker_enabled from sys.databases WHERE name = ‘ServiceManager’.  This returned 0 (it wasn’t enabled)
  • Ran the Query ALTER DATABASE ServiceManager SET ENABLE_BROKER.  Note:  If it times out due to a lingering connection, “alter database ServiceManager set enable_broker with rollback immediate;” does the trick too.
  • Restarted the SQL Server Agent and all Service Manager services and Workflows now run as expected!

Unable to start “System Center Data Access Service” on Service Manager Data Warehouse

I was recently faced with an issue for a customer where their Service Manager Data Warehouse Service would start but not stay running in their lab environment.  The following three events were logged in the Operations Manager event log:
14-04-2015 12-33-51 p-m-
Event ID: 26325
An authorization store exception was thrown in the System Center Data Access service. Exception message: Unable to perform the operation because of authorization store errors.

14-04-2015 12-36-04 p-m-
Event ID: 26339
An exception was thrown while initializing the service container.
Exception message: Initialize
Full exception: Feature of type ‘Microsoft.EnterpriseManagement.ServiceDataLayer.IAuthorizationFeature, Microsoft.EnterpriseManagement.DataAccessService.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ cannot be added to the container.
14-04-2015 12-36-15 p-m-
Event ID: 26380
The System Center Data Access service failed due to an unhandled exception.
The service will attempt to restart.

Microsoft.EnterpriseManagement.ConfigurationReaderException: Feature of type ‘Microsoft.EnterpriseManagement.ServiceDataLayer.IAuthorizationFeature, Microsoft.EnterpriseManagement.DataAccessService.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ cannot be added to the container. —> System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnknownAuthorizationStoreException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Microsoft.EnterpriseManagement.Common.UnknownAuthorizationStoreException: Unable to perform the operation because of authorization store errors. —> System.Runtime.InteropServices.COMException (0x80070539): The security ID structure is invalid. (Exception from HRESULT: 0x80070539)
at Microsoft.Interop.Security.AzRoles.AzAuthorizationStoreClass.Initialize(Int32 lFlags, String bstrPolicyURL, Object varReserved)
at Microsoft.EnterpriseManagement.Mom.Sdk.Authorization.AzManHelper.Initialize(String pathToStore, String appName, AzManHelperModes helperMode, String storeDesc, String appDesc)
— End of inner exception stack trace —
— End of inner exception stack trace —
at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.ReadFeatures(XPathNavigator navi, IContainer container)
at Microsoft.EnterpriseManagement.ConfigurationReaderHelper.Process()
at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.Initialize(InProcEnterpriseManagementConnectionSettings configuration)
at Microsoft.EnterpriseManagement.ServiceDataLayer.DispatcherService.InitializeRunner(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart(Object obj)
Thankfully I came across the following blog post which pointed me in the right direction:

I checked the SQL security method and discovered it was set to mix Windows/Sql Auth.  I then found a sqltest user that was set as db_owner for all three of the Service Manager Data Warehouse Databases.  Removed the DB_Owner role from each DB for the sqltest user and restarted the System Center Data Access service with no further issues.

14-04-2015 12-36-31 p-m- 14-04-2015 12-37-33 p-m-

14-04-2015 12-43-17 p-m-

SCSM: “An error was encountered while running the task”

I recently came across an unusual issue with Service Manager were all of the connectors stopped functioning.  Any time I went into the properties or attempted to create a new connector (in particular when starting to create and selecting test authentication), the connector would crash with the following error:

Application: System Center Service Manager
Application Version: 7.5.3079.0
Severity: Error
Message: An error was encountered while running the task.


Really helpful message…

I had seen a similar issues previously with the Exchange Connector due to a corrupted Default SR or IR Template.  As this was in the sandbox environment, I started removing custom Management Packs as a test – all that had been created since the connector had stopped working.  None of this resolved the issue.

The issue it turned out was with the System Center Operations Manager Agent installed on the SCSM server.

The Microsoft SCOM Agent is bundled in with Service Manager by default.  I have ran into several random issues before with System Center Operations Manager, where I needed to rebuild the Health Service State folder by stopping the “Microsoft Monitoring Agent” and renaming this folder.  On the SCSM server, the service is still the same but the Health State is in a different location.

First, stop the service:

Rename the SCOM Health Service State Folder (Located: C:\Program Files\Microsoft System Center 2012 R2\Service Manager\Health Service State)
Restart the Microsoft Monitoring Agent (this will recreate the Health Service State folder).

You should now be able to create connectors!

Remove assigned user from Service Manager Incident or Service Request with Orchestrator

I was recently given a customer request to remove the assigned user on an Incident or Service Request (in order to place it back into the unassigned job queue) in SCSM 2012 R2 when their external support returned their Service Manager job back to them via e-mail.  As the external vendor was utilizing their own ticketing system, all of this transfer was occurring via email communication and the Exchange Connector for SCSM.  Standard Exchange connector keywords were being utilized (ie. [Resolved], [Completed]), etc. but to remove via any non-standard keyword we needed to use Orchestrator and the SC 2012 Service Manager Integration Pack.
First step (Monitor Analyst Comments) was to create a monitor task for new Trouble Ticket Analyst Comments, with a filter for specific Keyword – in this case: “Assignee Group: Internal IT Department”

Next step (Get Parent IR) was to create an SCSM Relationship between the Trouble Ticket Analyst Comments and the Parent Incident

Next we Get the Relationship between the parent incident and the Active Directory User (Get Assigned User from IR)

Finally (Remove Assigned User Relationship from IR) we remove the relationship for the AD User from the Incident, which places the job back as unassigned
Simply repeat the steps above for Service Requests, changing the class where appropriate from Incident to Service Request.

Now whenever the Analyst Comments are added that contain the words “Assignee Group: Internal IT Department” to an Incident or Service Request, either via comment or e-mail the assigned to user is removed. Done!

Manually Remove Incidents, Service Requests, etc. from Service Manager 2012/2012 R2

With System Center Service Manager 2012/2012 R2, you may find you need to delete various Incident Requests, Service Requests before waiting for them to prune out of the database.  This could apply in a testing situation, when you are generating lots of test tickets, etc. (Or if you find you have a Operations Manager alert storm!).  From PowerShell with the Service Manager module loaded, run the following commands:
#Remove IR from Database.  Replace IRx with corresponding Incident Request number (ie. IR16, etc.)
Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.Incident) | Where-Object {$_.ID -eq “IRx”} | Remove-SCSMClassInstance
#Remove SR from Database.  Replace SRx with corresponding Service Request number (ie. SR16, etc.)
Get-SCSMClassInstance -Class (Get-SCSMClass -Name System.WorkItem.ServiceRequest) | Where-Object {$_.ID -eq “SRx”} | Remove-SCSMClassInstance

Refresh your SCSM Console and it should now be gone from the list.

The Service Manager data warehouse SQL Reporting Services server is currently unavailable

Recently, while rolling out System Center Service Manager 2012 R2 for a customer, I received the following error when opening Service Manager as it attempted to load the SQL Reporting Services plugin: “The Service Manager data warehouse SQL Reporting Services server is currently unavailable.  You will be unable to execute reports until this server is available.”


The even log showed Event ID 33569:

Cannot connect to SQL Reporting Services Server.  Message= An unexpected error occurred while connecting to SQL Reporting Services server: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

The last line was the key.  Ideally you would want to put a trusted cert from your CA onto the SQL Reporting Services Server but the work around would be to make the certificate trusted on the machine running the Service Manager Console.

Browse to the SQL Reporting Services web page, click past the cert error.

Click on the certificate icon at the top and “View Certificate”

Install the certificate into your local machine Trusted Root Certification Authorities.

Now go back and re-open the SCSM Console and all should be good!