Known Issues in Workflow Manager 1.0
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:
Remove the extra accounts from the administrator group.
Run the configuration.
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.
Run the client application using elevated permissions.
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