Problèmes de connectivité directe dans Power Automate pour le bureau

2025-05-20

Cet article fournit plus d’informations sur la résolution des problèmes de connectivité directe dans Microsoft Power Automate pour le bureau.

S’applique à : Power Automate
Numéro de base de connaissances d’origine : 5016345

Symptômes

Lorsque vous tentez d’exécuter vos flux de bureau à partir d’un flux cloud ou gérez vos machines de flux de bureau, vous pouvez rencontrer l’un des problèmes suivants :

Scénario 1

Vos ordinateurs précédemment inscrits apparaissent hors connexion lorsqu’ils sont démarrés et connectés au réseau.
Les exécutions échouent avec l’un des messages d’erreur suivants :
- ConnectionNotEstablished : aucun des écouteurs connectés n’a accepté les connexions dans le délai d’expiration autorisé. Vérifiez que votre machine est en ligne.
- NoListenerConnected : le point de terminaison est introuvable. Aucun écouteur n’est connecté au point de terminaison. Vérifiez que votre machine est en ligne.

Scénario 2

Les flux de bureau s’exécutent sur un ordinateur inscrit tant qu’une session utilisateur est en cours d’exécution (exécutions suivies) ou même pendant quelques minutes après la déconnexion du dernier utilisateur (exécutions sans assistance).
La connexion à la machine est perdue après quelques minutes (par exemple, 15 minutes).
La connexion est rétablie une fois qu’un utilisateur se connecte à l’ordinateur.

Scénario 3

Lorsque vous vous déconnectez de votre ordinateur Windows, l’état de l’ordinateur s’affiche comme déconnecté dans le portail Power Automate.

La cause

La connectivité directe à la machine utilise les relais Azure Windows Communication Foundation (WCF) pour permettre au cloud Microsoft de se connecter à des machines locales et de planifier des exécutions de flux de bureau. Le service Windows Power Automate qui s’exécute localement ouvre un écouteur de relais qui se connecte au cloud Azure en ouvrant des sockets web.

La cause la plus courante des problèmes de connectivité de relais est la perte de connexion de l’ordinateur au réseau. Cela peut être dû à l’absence de mise sous tension ou à la perte du réseau quand aucun utilisateur n’est connecté à l’ordinateur.

Le service Power Automate s’exécute sous son propre compte Windows (NT Service\UIFlowService par défaut) qui doit avoir accès au réseau et être en mesure de se connecter à *.servicebus.windows.net. Pour plus d’informations, consultez Configuration exigée pour le réseau.

Remarque

Si vous utilisez une machine virtuelle Azure pour exécuter Power Automate pour le bureau, vérifiez que le point de terminaison Microsoft.ServiceBus est désactivé au niveau du sous-réseau où se trouve la machine virtuelle Azure. Il s’agit d’une limitation connue. Pour plus d’informations, consultez Azure Relay ne prend pas en charge les points de terminaison de service réseau.

Si la machine et le service Power Automate disposent d’un accès fiable au réseau, la source de problèmes la plus semblable est le blocage du réseau local ou l’interférence avec les connexions de relais Azure.

Un coupable courant dans les deux scénarios est un proxy réseau ou un pare-feu qui restreint le trafic sortant.

En particulier, les proxys authentifiés qui utilisent les informations d’identification de l’utilisateur Windows connecté, étant donné que le service Power Automate s’exécute sous son propre compte dédié.

Vous pouvez faire référence à la configuration du proxy si vous déterminez que vous devez remplacer les paramètres de proxy par défaut utilisés par le service Power Automate. Vous devrez peut-être également modifier le compte de service local.

Pour qu’Azure Relay fonctionne correctement, il est nécessaire de configurer les paramètres de proxy et de pare-feu pour autoriser les passerelles de relais associées aux espaces de noms principaux et secondaires. Il garantit que la communication entre ces passerelles n’est pas bloquée par les paramètres de sécurité réseau.

Comment examiner

Engagez vos administrateurs réseau.

Impliquez vos administrateurs réseau pour analyser les configurations et les journaux réseau.
Comprendre la topologie du réseau.
- Tracez le chemin du trafic via des appareils réseau (par exemple, NAT, pare-feu et proxys) vers l’Internet public.
- Collectez les journaux d’activité des appareils pendant les exécutions affectées et confirmez le trafic vers *.servicebus.windows.net atteint l’Internet public.
Si votre trafic réseau s’exécute via un proxy, envisagez de modifier le compte local utilisé par le service Power Automate (UIFlowService).
Obtenez les journaux WCF à partir du service Power Automate (UIFlowService). Pour plus d’informations, consultez Activer le suivi WCF.
Vérifiez que votre configuration réseau autorise le trafic de socket web et les connexions longues. Certains périphériques réseau, comme les proxys, peuvent mettre fin automatiquement aux connexions après une certaine période, ce qui peut perturber la communication.
Assurez-vous que le pare-feu autorise les connexions aux passerelles Azure Relay :

Étape 1 : identifier les espaces de noms de relais Azure

Deux espaces de noms relais Azure peuvent être utilisés pour connecter une machine aux services cloud Power Automate. Pour identifier les espaces de noms utilisés par un ordinateur :
1. Lancez l’application d’exécution de machine Power Automate et connectez-vous.
2. Recherchez la section Diagnostiquer les problèmes de connectivité pour le runtime cloud , puis sélectionnez Lancer l’outil de diagnostic.
3. Attendez que les diagnostics se terminent.
4. Sélectionnez Générer le rapport.
5. Ouvrez le fichier XLS généré et recherchez la colonne Données .
6. Extrayez la partie espace de noms des URL de PrimaryRelay et SecondaryRelay. Par exemple, https://<namespace>/guid_guid.
Étape 2 : Configurer le pare-feu avec les noms DNS requis pour les relais principaux et secondaires
1. Configurez vos pare-feu avec les noms DNS (Domain Name System) de toutes les passerelles Relay.
  
  Les noms DNS sont disponibles en exécutant le script. Ce script résout les noms de domaine complets (FQDN) de toutes les passerelles auxquelles vous devez établir une connexion.
2. Configurez les règles de pare-feu pour autoriser les noms DNS sur le port 443 au lieu d’adresses IP.
Étape 3 : Effectuer des tests de connectivité manuels

Le suivi WCF peut être activé sur l’ordinateur en cas de problème de connectivité cloud. Pour plus d’informations, consultez Activer le suivi WCF.

Le journal WCF doit contenir des exceptions liées à la connectivité pour une adresse DNS ou IP spécifique, ou pointer vers une configuration proxy manquante.

Pour tester la connexion entre l’ordinateur et le point de terminaison, exécutez un test ping TCP à partir de PowerShell à l’aide de la commande suivante :
```
Test-netconnection \<ipaddress or dnsname> -port 443
```
Si TcpTestSucceeded affiche False, il est probable que le pare-feu n’autorise pas la connexion. Engagez votre équipe réseau à comprendre si un proxy ou un pare-feu peut empêcher l’accès. Il peut y avoir plusieurs pare-feu et proxys entre la machine et les services Azure Relay. Veillez donc à vérifier chaque configuration de sous-réseau.

Informations à inclure lors de l’ouverture d’un ticket de support

Si le problème persiste, vous pouvez ouvrir un ticket de support auprès de Microsoft en fournissant les détails suivants :

Topologie de votre réseau : quels sont les appareils qui transitent par le trafic. Pour plus d’informations, consultez la étape 2 de Comment enquêter.
Que le service Power Automate (UIFlowService) sur votre ordinateur s’exécute en tant que compte par défaut (NT Service\UIFlowService) ou s’il a été modifié pour s’exécuter en tant que compte différent.
Journaux d’activité de vos appareils réseau montrant que le trafic est effectivement transmis à l’Internet public. Incluez les heures des problèmes et les fuseaux horaires utilisés par les journaux.
Traces WCF des machines concernées. Pour plus d’informations, consultez Activer le suivi WCF.
ID d’exécution de flux de bureau des exécutions affectées.
Journaux locaux de l’ordinateur concerné : ils peuvent être extraits à l’aide du volet de résolution des problèmes de l’application runtime de machine Power Automate.

Activer le suivi WCF

Dans le dossier d’installation (généralement C :\Program Files (x86)\Power Automate Desktop), modifiez le fichier UIFlowService.exe.config . Il nécessite l’exécution de votre éditeur de texte en tant qu’administrateur.
Ajoutez la section de configuration suivante entre </system.net> et <appSettings> :
```
<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" 
            switchValue="Information,ActivityTracing"
            propagateActivity="true">
      <listeners>
        <add name="wcfTraces"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\PADwcfTraces.svclog" />
      </listeners>
    </source>
  </sources>
 <trace autoflush="true" />
</system.diagnostics>
```
- Vous pouvez remplacer la c:\logs\PADwcfTraces.svclog valeur par n’importe quel chemin valide souhaité, mais le dossier (c:\logs dans cet exemple) doit exister. Sinon, il n'est pas créé et les fichiers de logs ne sont pas écrits.
- Le service Power Automate a besoin d'autorisations pour écrire des fichiers de log dans le dossier spécifié. Vous pouvez accorder un contrôle total à l’utilisateur Everyone , ce qui permet à n’importe quel utilisateur ou service d’écrire dans le dossier. Vous pouvez également restreindre les autorisations au service Power Automate uniquement, rechercher l’identificateur de sécurité de l’utilisateur de service (Sid) en exécutant sc showsid UIFlowService, puis accorder des autorisations à cet utilisateur.
Après avoir enregistré le fichier de configuration, redémarrez le service Power Automate.
1. Recherchez « services » dans le menu Démarrer pour ouvrir l’outil Services Windows.
2. Recherchez le service Power Automate, cliquez dessus avec le bouton droit, puis sélectionnez Redémarrer.

Les traces sont enregistrées dans le fichier spécifié, fournissant des journaux détaillés pour diagnostiquer les problèmes de connectivité.