Hello All,

When I attempt to submit a service request with an automation runbook attached, the portal fails to submit the request.

I can create service requests that have no connected activities. In the SCSM event log I found an error related to the user not having sufficient permissions.

If I add the user to the Workflow group, they can submit the request, but they can also see Offerings that should be restricted for their account.

I would appreciate any help that can be provided.

Thanks,
Michael

Here is the Error in the event log.

An exception was thrown while processing ProcessDiscoveryData for session ID .

Exception message: The user -----\***** does not have sufficient permission to perform the operation.

Full Exception: Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The user -----\***** does not have sufficient permission to perform the operation.

   at Microsoft.EnterpriseManagement.Mom.DiscoveryDatabaseAccess.ManagementStoreAuthorization.Authorize(DiscoveryDataInstance discoveryDataInstance, IAuthorizationService authService, Boolean useProcessContext, WindowsIdentity identity, DatabaseConnection databaseConnection)

   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler.AuthorizeEntityObjects(DatabaseConnection databaseConnection, Guid discoverySourceId, IContext context, IList`1 packets)

   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler.ProcessIncrementalDiscoveryData(DatabaseConnection databaseConnection)

   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.DiscoveryPackageIncrementalProcessingHandler.Process()

   at Microsoft.EnterpriseManagement.Mom.DiscoveryDatabaseAccess.DiscoveryPackageProcessor.ProcessWithRetry(HandleProcessing handleProcessing, RetryPolicy retryPolicy)

   at Microsoft.EnterpriseManagement.ServiceDataLayer.DiscoveryDataManager.ProcessDiscoveryDataWithRetry(DatabaseConnection dbconnection, Guid discoverySourceId, IList`1 sdkEntityInstances, IDictionary`2 streams, IContext context)

   at Microsoft.EnterpriseManagement.ServiceDataLayer.ConnectorFrameworkConfigurationService.ProcessDiscoveryData(Guid discoverySourceId, IList`1 entityInstances, IDictionary`2 streams, ObjectChangelist`1 extensions)

A little more info in the hopes that someone recognizes the problem.

1. I created a End User role that contains only my Test User. For testing I allowed the user role access to all queues, CI's and Offerings.

2. I have a single service request that has one Orchestrator runbook activity attached. The runbook template is set to start automatically and by using an administrative user I have tested that it works.

3. I have not made any changes to the Default Roles or security assignments. The database permissions are also how SCSM set them up.

4. The user is in a portal group that has read-only access to the sharepoint team site. The portal is unchanged except for one or two tweaks to the UI (Scrolling fix, and hiding the title) I have tested to make sure that an Admin user can login to the portal and submit the same service request.

5. The user can create a default incident, or a service request with no activities. (I haven't tested to see if manual activities fail as well. I will test that next)

The problem is that when a user in the enduser role tries to create a new automated service request, the portal gives them an error saying that it could not submit the ticket, and I get the above message in the eventlog.

Anyone else having this problem?

Just had a chat with a Microsoft support rep.

She spotted the problem very quickly.

In my runbook I had put a return task at the end in order to return a variable "Outcome". Because this was not mapped upon request creation, SCSM checked to see if the user had access to come back and change it and since the user was just in the EndUser role, they did not. If the user was an admin, they had access to change it later.

The fix is to remove any returned data from runbooks that will be directly accessed using SCSM.

• Marked as answer by ND_Michael Wednesday, July 25, 2012 9:34 PM
• Unmarked as answer by ND_Michael Monday, October 15, 2012 2:51 PM

Just had a chat with a Microsoft support rep.

She spotted the problem very quickly.

In my runbook I had put a return task at the end in order to return a variable "Outcome". Because this was not mapped upon request creation, SCSM checked to see if the user had access to come back and change it and since the user was just in the EndUser role, they did not. If the user was an admin, they had access to change it later.

The fix is to remove any returned data from runbooks that will be directly accessed using SCSM.

• Marked as answer by ND_Michael Wednesday, July 25, 2012 9:34 PM
• Unmarked as answer by ND_Michael Monday, October 15, 2012 2:51 PM

The problem re-emerged after a couple weeks. I had been busy and was not able to look at it for a while. I just found a bug in Service Manager that breaks the service request automation.

If you set the designer field through the service request template activity selector, an end user does not have permissions to create a request from that template.

Since I set the designer field in the runbook template, whenever I added an activity to the service request the designer field was filled in by default. This meant that no end user was able to submit requests, even though it worked fine for Administrators.

The workaround is to clear the designer fields for the activity.

• Marked as answer by ND_Michael Monday, October 15, 2012 2:55 PM

The problem re-emerged after a couple weeks. I had been busy and was not able to look at it for a while. I just found a bug in Service Manager that breaks the service request automation.

If you set the designer field through the service request template activity selector, an end user does not have permissions to create a request from that template.

Since I set the designer field in the runbook template, whenever I added an activity to the service request the designer field was filled in by default. This meant that no end user was able to submit requests, even though it worked fine for Administrators.

The workaround is to clear the designer fields for the activity.

• Marked as answer by ND_Michael Monday, October 15, 2012 2:55 PM

3 years later, and i found myself in the same position; spent hours trying to figure out what the deal was. Thanks for posting this.