Known Issues in Workflow Manager 1.0

  • Article

 

Updated: November 5, 2012

This section describes known issues in Workflow Manager 1.0.

  • Configuration fails when server’s administrator group contains accounts in a different domain

  • Configuration fails when server’s administrator group contains unresolvable SIDs

  • Add-WFHost cmdlet does not work across domains

  • If the permissions of a workflow scope are set to BUILTIN\Administrators, Client Applications must run using elevated permissions

Configuration fails when server’s administrator group contains accounts in a different domain

When a farm is configured, the administrator group of the farm server is enumerated to determine whether the configuring user has administrator permissions. This enumeration fails if the administrator group contains accounts from a different domain from the calling user. The workaround for this issue is as follows:

  1. Remove the extra accounts from the administrator group.

  2. Run the configuration.

  3. Add the accounts back when configuration is complete.

Configuration fails when server’s administrator group contains unresolvable SIDs

When a farm is configured, the administrator group of the farm server is enumerated to determine whether the configuring user has administrator permissions. This enumeration fails if the administrator group contains unresolvable security identifiers (SIDs). The workaround is to remove the unresolvable accounts from the Administrators group.

Add-WFHost cmdlet does not work across domains

When using an auto-generated certificate, the Add-WFHost cmdlet does not work across domains. However, the Add-SBHost cmdlet works in this scenario.

If the permissions of a workflow scope are set to BUILTIN\Administrators, Client Applications must run using elevated permissions

If the permissions of a workflow scope are set to BUILTIN\Administrators, which is the default setting, an exception similar to the following is thrown if the client application is not run using elevated permissions.

The caller does not have the necessary permissions required for this operation. Permissions granted: None. Required permissions: WriteScope. HTTP headers received from the server - ActivityId: AC318A5F-7B96-4DA1-A632-F175372BB8E1. NodeId: MACHINENAME. Scope: /ExternalVariableSampleScope. Client ActivityId : 4DD1EBC2-54C6-46ED-BD87-5CFE7BFFDDF4.

This is because Windows doesn’t grant the current user the Admin token unless the user is running in an elevated process, regardless of whether that user belongs to the Administrators group.

To resolve this issue, there are two choices.

  1. Run the client application using elevated permissions.

  2. Update the p:microsoft.workflow.client.security.windowssecurityconfiguration.WorkflowAdminGroupName of the scope to another non-Administor group to which the user belongs, such as BUILTIN\Users. One way to do this is to run the following PowerShell script.

    $sec = New-Object Microsoft.Workflow.Client.Security.WindowsSecurityConfiguration("All Users")  
$sec.WorkflowAdminGroupName = "Users"

    For more information, see Configuring Workflow Manager 1.0 using PowerShell