Problèmes connus dans Workflow Manager 1.0

  • Article

 

Date de publication : juillet 2016

Cette section décrit les problèmes connus dans Workflow Manager 1.0.

  • La configuration échoue lorsque le groupe d’administrateurs du serveur contient des comptes appartenant à un autre domaine

  • La configuration échoue lorsque le groupe Administrateurs du serveur contient des SID ne pouvant pas être résolus.

  • La cmdlet Add-WFHost ne fonctionne pas sur des domaines

  • Si les autorisations d'une étendue de workflow sont définies sur BUILTIN\Administrateurs, les applications clientes doivent être exécutées à l'aide d'autorisations élevées

La configuration échoue lorsque le groupe d’administrateurs du serveur contient des comptes appartenant à un autre domaine

Lorsqu’une batterie est configurée, le groupe Administrateurs du serveur de la batterie est énuméré afin de déterminer si l’utilisateur exécutant la configuration dispose d’autorisations d’administrateur. Cette énumération échoue si le groupe Administrateurs contient des comptes appartenant à un autre domaine que celui de l’utilisateur appelant. Pour contourner ce problème, procédez comme suit :

  1. Supprimez les comptes supplémentaires du groupe Administrateurs.

  2. Exécutez la configuration.

  3. Rajoutez les comptes une fois la configuration terminée.

La configuration échoue lorsque le groupe Administrateurs du serveur contient des SID ne pouvant pas être résolus.

Lorsqu’une batterie est configurée, le groupe Administrateurs du serveur de la batterie est énuméré afin de déterminer si l’utilisateur exécutant la configuration dispose d’autorisations d’administrateur. Cette énumération échoue si le groupe Administrateurs contient des identificateurs de sécurité (SID) ne pouvant pas être résolus. La solution de contournement consiste à supprimer les comptes ne pouvant pas être résolus du groupe Administrateurs.

La cmdlet Add-WFHost ne fonctionne pas sur des domaines

Lorsque vous utilisez un certificat généré automatiquement, la cmdlet Add-WFHost ne fonctionne pas sur plusieurs domaines. Toutefois, la cmdlet Add-SBHost fonctionne dans ce scénario.

Si les autorisations d'une étendue de workflow sont définies sur BUILTIN\Administrateurs, les applications clientes doivent être exécutées à l'aide d'autorisations élevées

Si les autorisations d'une étendue de workflow sont définies sur BUILTIN\Administrateurs (paramètre par défaut), une exception semblable à l'exception suivante est levée si l'application cliente n'est pas exécutée à l'aide d'autorisations élevées.

L'appelant ne dispose pas des autorisations requises pour cette opération. Autorisations octroyées : Aucun. Autorisations requises : WriteScope. En-têtes HTTP reçus du serveur - ActivityId : AC318A5F-7B96-4DA1-A632-F175372BB8E1. NodeId : MACHINENAME. Étendue : /ExternalVariableSampleScope. ActivityId du client : 4DD1EBC2-54C6-46ED-BD87-5CFE7BFFDDF4.

Ceci est dû au fait que Windows n'accorde pas le jeton Admin à l'utilisateur actuel, sauf si ce dernier est exécuté dans un processus élevé, indépendamment de son appartenance ou non au groupe Administrateurs.

Pour résoudre ce problème, deux solutions sont possibles.

  1. Exécutez l'application cliente à l'aide d'autorisations élevées.

  2. Mettez à jour le p:microsoft.workflow.client.security.windowssecurityconfiguration.WorkflowAdminGroupName de l'étendue en le définissant sur un autre groupe qui ne soit pas un groupe Administrateur auquel l'utilisateur appartient, tel que BUILTIN\Utilisateurs. Pour ce faire, vous pouvez exécuter le script PowerShell suivant.

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

    Pour plus d'informations, consultez Configuration de Workflow Manager 1.0 à l'aide de PowerShell