none
WorkflowDataExchangeException: Microsoft.ResourceManagement.WebServices.Exceptions.PermissionDeniedException: ResourceIsMissing RRS feed

  • Question

  • 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.

    Monday, September 7, 2015 2:52 AM

Answers

  • 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.


    Thanks, Brian

    • Marked as answer by mck_stu Tuesday, September 8, 2015 6:21 AM
    Tuesday, September 8, 2015 4:51 AM
    Moderator
  • 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 8, 2015 6:21 AM
    • Edited by mck_stu Tuesday, September 8, 2015 6:22 AM
    Tuesday, September 8, 2015 6:21 AM

All replies

  • 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.

    Thanks, Brian

    Monday, September 7, 2015 9:07 PM
    Moderator
  • 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

    Tuesday, September 8, 2015 1:18 AM
  • 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.


    Thanks, Brian

    • Marked as answer by mck_stu Tuesday, September 8, 2015 6:21 AM
    Tuesday, September 8, 2015 4:51 AM
    Moderator
  • 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 8, 2015 6:21 AM
    • Edited by mck_stu Tuesday, September 8, 2015 6:22 AM
    Tuesday, September 8, 2015 6:21 AM