WorkflowDataExchangeException: Microsoft.ResourceManagement.WebSe rvices.Exceptions.PermissionDenied Exception: ResourceIsMissing

Hi 

I use a custom workflow to create account names in the portal... at some stage the workflow stopped working producing the below error in the portal requests...

Microsoft.ResourceManagement.WorkflowDataExchangeException: Microsoft.ResourceManagement.WebServices.Exceptions.PermissionDeniedException: ResourceIsMissing
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteGetAction(RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction(RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction[ResponseBodyType](RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request, Guid requestIdentifier, Object redispatchSingleInstanceKey, Boolean isRedispatch)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request)
   at Microsoft.ResourceManagement.Workflow.Hosting.RequestWorkItemProcessor.DispatchRequest[TResponseType](RequestType request, Boolean applyAuthorizationPolicy)
   at Microsoft.ResourceManagement.Workflow.Hosting.RequestWorkItemProcessor.ProcessGetWorkItem(ReadRequestWorkItem readWorkItem)
   at Microsoft.ResourceManagement.Workflow.Hosting.RequestWorkItemProcessor.ProcessWorkItem(WorkItem workItem)
   at Microsoft.ResourceManagement.Workflow.Activities.ReadResourceActivity.ProcessRequestResponse(Object sender, QueueEventArgs e)
   at System.Workflow.ComponentModel.ActivityExecutorDelegateInfo`1.ActivityExecutorDelegateOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
   at System.Workflow.Runtime.Scheduler.Run()

Permission denied suggests an MPR but im not entirely sure which one.
The workflow runs under the context of the built in admin account as evidenced by the code snippet from the cs file below...

  const string FIMADMIN_GUID = "7fb2b853-24f0-4498-9534-4e10589723c4";

Any guidance appreciated.

September 6th, 2015 10:53pm

Can you paste in the code that is causing this? My guess is that you are trying to set an attribute that either doesn't exist or it is not cased correctly. The object type and attribute name fields are all case sensitive.
Free Windows Admin Tool Kit Click here and download it now
September 7th, 2015 5:09pm

Thanks Brian

The solution has previously worked before and only users firstName lastName to create an accountName.

None of the code has changed.

However the code runs under the context of the fim installation account, which was deleted from the portal.

The thought was to bring the account back into the portal but it looks as if it isint recognized as the fim installer account anymore, hence the workflow fails.

Do you know of a way to reinstate the fim portal installer account to the well known guid of: 7fb2b853-24f0-4498-9534-4e10589723c4

September 7th, 2015 9:20pm

Make sure you have the right casing on those attributes. It's FirstName, LastName, etc.

There is a way to get the account back with the right GUID. It's not something I'm comfortable explaining in a venue like this, though. You would be will served to open a case with Microsoft. They can guide you through the process as it's a number of steps in SQL.

Free Windows Admin Tool Kit Click here and download it now
September 8th, 2015 12:53am

thanks brian

i have a case open right now for that exact reason, looks like solution is either modifying the resourceID (with the MS script) or potentially re-running the stored procedure that sets the admin installer account in the first place, so we can add the admin account back in.

So we should have a resolution soon.


  • Marked as answer by mck_stu 59 minutes ago
  • Edited by mck_stu 58 minutes ago
September 8th, 2015 2:23am

thanks brian

i have a case open right now for that exact reason, looks like solution is either modifying the resourceID (with the MS script) or potentially re-running the stored procedure that sets the admin installer account in the first place, so we can add the admin account back in.

So we should have a resolution soon.


  • Marked as answer by mck_stu Tuesday, September 08, 2015 6:21 AM
  • Edited by mck_stu Tuesday, September 08, 2015 6:22 AM
Free Windows Admin Tool Kit Click here and download it now
September 8th, 2015 6:21am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics