Fix RemoteApp/Session Error 0XC02625E0 on Server 2016+
This error means a remote program tried to run outside the console session. You'll see it with RemoteApp or VDI shortcuts pointing to the wrong session type.
Quick answer
Change your RemoteApp or VDI shortcut to use connect to console:v:i:0 instead of 1, or remove that line entirely. That stops the session from trying to attach directly to the physical console.
Why you're seeing this error
You're running a RemoteApp or a remote desktop shortcut on a Windows Server (2016, 2019, 2022) and the program throws ERROR_GRAPHICS_ONLY_CONSOLE_SESSION_SUPPORTED (0xC02625E0). The message says “This function can be used only if a program is running in the local console session.” That's Microsoft's way of telling you the app or the .rdp file is trying to connect to console session 0 (the physical console), but the app isn't actually running there. This usually happens when someone manually edited the .rdp file and set connect to console:v:i:1 or when a RemoteApp deployment was misconfigured to force console mode.
I've seen this a lot in environments where admins copy-paste .rdp settings from old Server 2008 guides. On Server 2012 and later, the console session is handled differently. You can't just force a RemoteApp into the physical console session like you used to.
Fix steps
Step 1: Identify the .rdp file that's triggering the error
If you're launching a RemoteApp from an RDS web feed or a direct .rdp file, find that file. On the client machine, look in C:\Users\YourUsername\Desktop or Downloads. The file name usually matches the app name, like Notepad.rdp.
Step 2: Open the .rdp file in Notepad
Right-click the .rdp file, choose Open with > Notepad. You'll see a list of settings, one per line.
Step 3: Find the console setting
Look for this line:
connect to console:v:i:1If you see it, that's the culprit. That
1 forces the session to attach to the physical console (session 0).Step 4: Change it to 0 or remove it
Change that line to:
connect to console:v:i:0Or just delete the entire line. Removing it lets the Remote Desktop client decide the correct session type.
After that, save the file and double-click to test the app. You should see the app launch normally without the error.
Alternative fixes
Fix via Group Policy on the RDS host
If you're the server admin and you want to stop this from happening for all users, check the RDS session collection settings. On the Remote Desktop Session Host, open Server Manager, go to Remote Desktop Services, then Collections. Select your collection, click Properties, and under Security, make sure Require console session is not checked. That checkbox shouldn't be there in modern Server versions, but you might see it in legacy deployments.
Re-publish the RemoteApp
If the .rdp file was generated by RDS web access, you might need to re-publish the RemoteApp. On the RD Session Host, open RemoteApp Manager, find the misbehaving app, and click Properties. Check the RemoteApp settings and make sure Remote desktop session is set to Do not use any remote desktop session settings. Then regenerate the .rdp file by clicking Create .rdp file in the same manager.
Use mstsc /admin on the client
Some people try to bypass this by running the full remote desktop with mstsc /admin instead of using RemoteApp. That works for a full desktop but kills the purpose of RemoteApp. If you absolutely need a RemoteApp and can't fix the .rdp file, consider switching to a modern VDI solution like Windows 365 or Azure Virtual Desktop.
Prevention tip
Never manually set connect to console:v:i:1 in .rdp files for RemoteApps. That setting is meant for administrative remote desktop connections (the /admin switch). For RemoteApp, always leave that line at 0 or omitted. If you're deploying via RDS web access, let the server generate the .rdp files automatically. If you have to customize them, only change parameters like screen size or drive redirection—don't touch the console flag.
Also, if you're upgrading from Server 2008 R2 to Server 2016 or later, audit all your old .rdp files. The console session behavior changed significantly. Older guides tell you to use connect to console:i:1 to get around licensing checks. That no longer works and just gives you this error.
Was this solution helpful?