When is this applicable?
You are using direct to machine connectivity, not the gateway.
Your previously registered machines appear offline when they are booted up and connected to the network.
Runs fail with either of these errors:
ConnectionNotEstablished - None of the connected listeners accepted the connections within the allowed timeout. Check that your machine is online.
NoListenerConnected - The endpoint was not found. There are no listeners connected for the endpoint. Check that your machine is online.
Direct to machine connectivity uses Azure WCF relays to allow the Microsoft cloud to connect to on-premises machines and schedule desktop flow runs. The Power Automate Windows service that runs on-premises opens a relay listener that connects to the Azure cloud by opening web sockets.
The most common cause of relay connectivity issues is the machine losing connection to the network. This can be caused by your machine not being powered on or losing network when no user is signed onto the machine for instance.
The Power Automate service runs under its own Windows account (NT Service\UIFlowService by default) which must have access to the network and be able to connect to *.servicebus.windows.net (see here for full network requirements).
If the machine and Power Automate service have reliable access to the network, the next likeliest source of issues is the on-prem network blocking or interfering with Azure relay connections.
How to investigate
To help you investigate these issues, make sure to engage your network administrators who will have the knowledge required to understand what is happening.
Understand the topology of the network: what network devices does the traffic hop through before being handed off to the public internet: NAT, firewalls, proxies etc. Get logs from these devices during impacted runs, as well as log from the outermost network device attesting that the traffic to *.servicebus.windows.net is handed off to the public internet.
Get WCF logs from UI flow service, see the Enabling WCF tracing section below.
Make sure your network configuration allows web socket traffic and long-running connections: a common pattern is proxies or other network devices killing connections after a set time.
What information to include when opening a support ticket
Your network topology: what are the devices that traffic goes through. (see the bullet #2 in the section above)
Logs from your network devices showing that the traffic is indeed handed off to the public internet. Please include times of the issues and the time zones used by the logs.
WCF traces from the impacted machines (see Enabling WCF tracing section below).
Desktop flow run ids of impacted runs.
Local logs from the impacted machine: they can be extracted using the Power Automate machine runtime app's troubleshooting pane.
Enabling WCF tracing
In the PAD install folder (typically C:\Program Files (x86)\Power Automate Desktop) edit the UIFlowService.exe.config file, this requires running your text editor as administrator.
Add this config section:
<trace autoflush="true" />
You can substitute the "c:\logs\PADwcfTraces.svclog" value with any valid path you’d like but the folder ('c:\logs' in this example) MUST exist, otherwise it won't be created and logs won't be written.
The Power Automate service must have permission to write in the chosen folder, granting the ‘Everyone’ user full control over the folder works. You can get the service user's Sid by running sc showsid UIFlowService in a command line if you want to give permissions to only that user.
This config section needs to be added between </system.net> and <appSettings>, see capture:
After saving the config file, restart the Power Automate service. This can be done using the ‘services’ tool found by typing services in the start menu, finding Power Automate Service, right clicking it and choosing restart, see capture:
Traces will then be written to the file chosen in the config.