Introduction
If you are running Power Automate Desktop flows on an Azure Virtual Desktop (AVD) session host, you may have encountered a frustrating problem: everything works perfectly while the AVD session is open and visible, but the moment you minimize the remote desktop window, the RPA flow stops, fails, or freezes.
This is not a bug. It is expected behaviour rooted in how Windows handles remote desktop rendering. However, it creates a significant operational challenge for teams that rely on desktop automation to run business-critical processes.
In this article, we explain why this happens, walk through the recommended enterprise solution using Unattended RPA, and provide a proven registry-based workaround for organisations that do not yet have the required licensing in place.
Understanding the Problem
Power Automate Desktop is a UI-based robotic process automation (RPA) tool. It automates tasks by interacting with on-screen elements — clicking buttons, reading text, filling forms, and navigating applications. To do this, it requires an active, visible, and rendered desktop session.
When you connect to an Azure Virtual Desktop session host and run a Power Automate Desktop flow, the automation operates within the interactive Windows session. It can see the screen, identify UI elements, and execute actions.
The problem occurs when you minimize the AVD client window on your local machine. When the Remote Desktop window is minimized, Windows switches the remote session into a GUI-less mode. In this state, the operating system suppresses image rendering to conserve system resources. Windows and controls are no longer displayed or rendered in memory the way they are during an active session.
Because the UI no longer exists in a renderable state, Power Automate Desktop cannot locate or interact with any on-screen elements. The flow either pauses, throws an error, or stops entirely.
Root Cause
The root cause is the RDP rendering suppression behaviour built into the Windows Remote Desktop Protocol client. When the RDP client window is minimized:
- The client stops requesting screen updates from the remote host.
- The remote session transitions into a state where the GUI is not actively rendered.
- UI elements that Power Automate Desktop depends on become invisible to the automation engine.
- Any action that requires visual interaction — mouse clicks, element detection, image recognition — will fail.
This behaviour is consistent across all UI-based RPA tools, not just Power Automate Desktop. It affects any automation that relies on an interactive desktop session delivered over RDP or a similar remote protocol.
Recommended Solution: Use Unattended RPA
The correct, enterprise-grade solution to this problem is to run your Power Automate Desktop flows in Unattended mode.
What Is Unattended RPA?
Unattended RPA allows desktop flows to execute on a machine without a user being logged in. The Power Automate cloud service manages the session lifecycle: it signs into the machine, creates a Windows session, runs the desktop flow, and signs out when complete — all without any human interaction.
Because the session is managed server-side and does not depend on an RDP client window being open on a user’s local machine, minimizing, disconnecting, or closing the remote desktop client has no effect on the running flow.
Why Unattended RPA Is the Right Choice
- Session independence: Flows run regardless of whether a user is connected or the client is minimized.
- Scheduled execution: Flows can be triggered on a schedule, by an event, or from a cloud flow — no manual intervention needed.
- Production reliability: Designed for enterprise workloads with proper error handling, retries, and monitoring.
- Scalability: Multiple bots can run across multiple machines or hosted machine groups.
- Security: Credentials are managed through secure machine connections, reducing the risk of exposed passwords.
Licensing Requirements
To run Unattended RPA in Power Automate, you need the appropriate licensing. As of 2026, Microsoft offers the following relevant plans:
| License | Price | Key Capability |
|---|---|---|
| Power Automate Premium | $15 / user / month | Cloud flows + attended desktop RPA |
| Power Automate Premium with RPA | $40 / user / month | Cloud flows + attended and unattended desktop RPA |
| Power Automate Process | $150 / bot / month | Unattended RPA on your infrastructure |
| Power Automate Hosted Process | $215 / bot / month | Unattended RPA on Microsoft-hosted VMs |
For most organisations running RPA on Azure Virtual Desktop, the Power Automate Process license at $150 per bot per month is the most common choice. It provides unattended execution on your own AVD session host without requiring Microsoft-managed infrastructure.
How to Set Up Unattended RPA on AVD
- Install Power Automate Desktop on the AVD session host.
- Install and configure the Power Automate Machine Runtime.
- Register the machine in the Power Automate portal under Machines.
- Configure a machine connection with the credentials of a local or domain account on the AVD host.
- In your cloud flow, use the “Run a desktop flow” action and set the run mode to Unattended.
- Ensure the AVD session host is powered on and reachable. No user needs to be signed in.
This is the approach Microsoft recommends for production automation workloads.
Workaround: Registry Fix to Keep the Session Active When Minimized
If your organisation does not currently have an Unattended RPA license, there is a well-known registry-based workaround that can allow Power Automate Desktop flows to continue running even when the AVD or RDP session window is minimized.
How It Works
By default, the Windows Remote Desktop client suppresses rendering when minimized. The registry value RemoteDesktop_SuppressWhenMinimized controls this behaviour. Setting it to 2 instructs the RDP client to continue rendering the remote session even when the client window is minimized.
This keeps the remote desktop GUI active in the background, allowing Power Automate Desktop to continue interacting with UI elements.
Important: This registry change must be applied on the client machine — the computer you use to connect to the AVD session host — not on the remote host itself.
Step-by-Step Configuration
Step 1: Close All Remote Desktop Sessions
Before making changes, close all active RDP or AVD sessions on the client machine.
Step 2: Open the Registry Editor
Press Win + R, type regedit, and press Enter. Run as administrator.
Step 3: Navigate to the Registry Key
Navigate to the following path:
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
Step 4: Create the Key If It Does Not Exist
In some environments, the Terminal Server Client key may not exist. This is common on freshly provisioned machines or clean Windows installations. If the key is missing:
- Right-click on the Microsoft key.
- Select New > Key.
- Name the new key
Terminal Server Client.
Step 5: Create the DWORD Value
Inside the Terminal Server Client key:
- Right-click in the right panel.
- Select New > DWORD (32-bit) Value.
- Name it
RemoteDesktop_SuppressWhenMinimized. - Double-click the value and set the Value data to
2. - Click OK.
Step 6: Apply to Wow6432Node (64-bit Systems)
If you are running a 64-bit version of Windows (most modern systems), repeat the same process under the Wow6432Node path:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal Server Client
Create the Terminal Server Client key if it does not exist, then add the same DWORD value:
Name: RemoteDesktop_SuppressWhenMinimized
Type: DWORD (32-bit)
Value: 2
Step 7: Restart the Client Machine
Reboot the client machine for the registry changes to take effect. The changes will not apply until after a restart.
Alternative: Command Line Method
You can also apply the registry change using an elevated command prompt:
reg add "HKLM\Software\Microsoft\Terminal Server Client" /v RemoteDesktop_SuppressWhenMinimized /t REG_DWORD /d 2 /f
reg add "HKLM\Software\Wow6432Node\Microsoft\Terminal Server Client" /v RemoteDesktop_SuppressWhenMinimized /t REG_DWORD /d 2 /f
Behaviour After Applying the Workaround
| Action | RPA Flow Status |
|---|---|
| Minimize AVD / RDP window | Flow continues running |
| Restore AVD / RDP window | No interruption |
| Disconnect the session | Flow may stop |
| Lock the remote session | Flow may stop |
| Close the AVD / RDP client | Flow will stop |
Recommended Solution vs. Workaround: A Comparison
| Criteria | Unattended RPA (Recommended) | Registry Workaround |
|---|---|---|
| Requires license | Yes (Process or Hosted Process) | No |
| Survives minimize | Yes | Yes |
| Survives disconnect | Yes | No |
| Survives session lock | Yes | No |
| User needs to be logged in | No | Yes |
| Suitable for production | Yes | Interim only |
| Supports scheduling | Yes | Limited |
| Reliability | High | Medium — varies by environment |
Limitations of the Registry Workaround
- This workaround addresses only the minimize scenario. It does not protect against session disconnection, session lock, or client closure.
- Behaviour may vary depending on the Remote Desktop client version and whether you are using the classic
mstsc.execlient, the Windows App, or the Azure Virtual Desktop client. - This is not an officially supported method by Microsoft for running Power Automate Desktop in production.
- The registry change must be applied on every client machine that connects to the AVD session host for RPA purposes.
- It is not a replacement for the Unattended RPA license. It should be treated as a temporary or interim solution.
Best Practices
- Test in a non-production environment first. Validate that the workaround functions correctly with your specific RPA flows and AVD configuration before deploying it to live processes.
- Use a dedicated AVD session host for RPA. Avoid running automation on a machine that users access for daily work. User interaction during attended runs can interfere with the flow.
- Document all registry changes. Ensure your IT operations and support teams are aware of the modification. Include it in your change management process.
- Plan for Unattended RPA. If your organisation relies on desktop automation, budget for the appropriate licensing. The registry workaround is not a long-term strategy.
- Disable idle session timeouts on the AVD host to prevent the session from being automatically disconnected during long-running flows.
- Apply the registry change to both paths (standard and Wow6432Node) on 64-bit systems to ensure full coverage.
Frequently Asked Questions
Why does Power Automate Desktop stop when the AVD session is minimized?
When the Remote Desktop client window is minimized, Windows suppresses UI rendering for the remote session. Power Automate Desktop requires a visible, rendered desktop to interact with UI elements. Without it, the automation engine cannot detect or click on anything, causing the flow to stop or fail.
Is RemoteDesktop_SuppressWhenMinimized an official replacement for Unattended RPA?
No. This registry setting is a workaround that prevents the RDP client from suppressing rendering when minimized. It is not an official Microsoft solution for running Power Automate Desktop in production. The recommended approach is to use Unattended RPA with the appropriate licensing.
What if the Terminal Server Client registry key does not exist?
This is common in clean or newly provisioned environments. Simply create the key manually. In the Registry Editor, right-click on the Microsoft key under HKEY_LOCAL_MACHINE\Software\Microsoft, select New > Key, and name it Terminal Server Client. Then add the DWORD value inside it.
Does this registry change go on the AVD host or the client machine?
The change must be applied on the client machine — the computer from which you connect to the AVD session host. It controls how the local RDP client handles the remote session when minimized.
Can this workaround survive a session disconnect or lock?
No. This workaround only addresses the minimize scenario. If the session is disconnected, locked, or the client is closed, the remote desktop GUI is no longer active and the RPA flow will likely stop.
Do I need to reboot after applying the registry change?
Yes. A reboot of the client machine is required for the registry changes to take effect.
What is the best long-term solution?
The best long-term solution is to use Power Automate Unattended RPA with either a Process license ($150/bot/month) or a Hosted Process license ($215/bot/month). This eliminates dependency on an active user session entirely and is the approach Microsoft recommends for production automation.
Conclusion
Power Automate Desktop stopping when an Azure Virtual Desktop session is minimized is a well-documented and expected behaviour. It stems from how the Windows Remote Desktop Protocol client manages rendering for minimized sessions.
For organisations building production-grade automation, Unattended RPA is the clear recommendation. It provides session independence, scheduled execution, and the reliability required for enterprise workloads.
For teams that do not yet have the Unattended RPA license, the RemoteDesktop_SuppressWhenMinimized registry workaround offers a practical interim solution. It is straightforward to implement, effective for the minimize scenario, and can bridge the gap while licensing is being procured.
Whichever path you choose, the key takeaway is this: understand the limitation, implement the appropriate solution for your situation, and plan toward the recommended architecture as your automation practice matures.
This article was published on blog.core365.cloud. We cover practical solutions for Microsoft 365, Azure, and Power Platform challenges faced by real-world IT teams. If you found this article helpful, share it with your team or bookmark it for future reference.

