RDP Troubleshooting: The Complete IT Helpdesk Guide for Windows 11 and Server 2025

Why RDP Issues Dominate Your Helpdesk Queue

If you've worked any amount of time on an IT helpdesk, you already know this: RDP tickets are relentless. Remote Desktop Protocol is still the backbone of IT support and remote work, and when it breaks, everything grinds to a halt. Whether your team manages a fleet of Windows 11 workstations, a terminal server farm, or some hybrid cloud setup that nobody fully understands, RDP connection failures are guaranteed to be among your highest-volume tickets.

Here's the thing — with Windows 11 24H2 rolling out across enterprises and Windows Server 2025 hitting production, Microsoft has changed a lot under the hood. Updated security defaults, new UDP transport behavior, stricter TLS requirements. I've seen these changes catch even experienced admins off guard.

This guide gives your team a systematic, copy-paste-ready approach to diagnosing and fixing every common RDP issue. No fluff, just solutions.

Quick-Reference: RDP Error Codes and What They Mean

Before we get into the weeds, bookmark this table. It'll save you a ton of time when tickets start flying in.

Error Message / Code	Likely Cause	Jump To
"Remote Desktop can't connect to the remote computer"	Network, firewall, or RDP disabled	Connection Refused
"An authentication error has occurred" (CredSSP)	CredSSP / NLA mismatch after patching	Authentication Errors
"The connection was denied because the user account is not authorized"	User not in Remote Desktop Users group	Permission Issues
"Your credentials did not work"	NLA failure, password change, cached credentials	Credential Failures
Black screen after connecting	Display driver, profile corruption, UDP issue	Black Screen Fixes
"The remote session was disconnected because there are no Remote Desktop License Servers available"	RDS licensing not configured	Licensing Issues
"An internal error has occurred" (0x4)	TLS/certificate misconfiguration	TLS and Certificates
Slow performance / lag	Bandwidth, UDP blocked, experience settings	Performance Tuning

Step 1: Verify RDP Is Enabled on the Target Machine

I know it sounds obvious, but the single most common cause of "Remote Desktop can't connect" is that RDP simply isn't turned on. Windows 11 ships with Remote Desktop disabled by default, and — this is the frustrating part — Windows Update or feature updates can sometimes reset this setting silently.

Always check this first. You'll thank yourself later.

Check via Settings (Interactive Access)

1. Open Settings → System → Remote Desktop
2. Toggle Remote Desktop to On
3. Confirm the PC name shown matches what the user is connecting to
4. Under Advanced settings, verify "Require devices to use Network Level Authentication" is set to your organization's policy

Check via Registry (Remote or Scripted)

If you've got remote access through another channel — PowerShell Remoting, SCCM, Intune — check the registry directly:

# Check if RDP is enabled (0 = enabled, 1 = disabled)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections

# Enable RDP remotely
Invoke-Command -ComputerName TARGET-PC -ScriptBlock {
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
    Restart-Service -Name TermService -Force
}

Check via Group Policy

Group Policy can override local settings, which trips people up all the time. Verify these GPO paths:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections
  → "Allow users to connect remotely by using Remote Desktop Services" = Enabled

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security
  → "Require use of specific security layer for remote (RDP) connections" = SSL
  → "Require user authentication for remote connections by using NLA" = your policy

Step 2: Network and Firewall Diagnostics

So RDP is enabled but connections still fail? Nine times out of ten, it's a network or firewall issue. Run these checks in order.

Test Basic Connectivity

# Test if port 3389 is reachable from the client
Test-NetConnection -ComputerName TARGET-PC -Port 3389

# Expected output for a working connection:
# TcpTestSucceeded : True

# If DNS isn't resolving, test by IP
Test-NetConnection -ComputerName 192.168.1.50 -Port 3389

If TcpTestSucceeded returns False, the issue is between the client and the host — not RDP itself. Here's what to check:

• Windows Firewall on target: Run Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Format-Table Name, Enabled, Direction, Action
• Network firewalls / NSGs: Make sure TCP 3389 (and UDP 3389 for better performance) is open
• VPN or routing: If the client is on VPN, verify the route to the target subnet actually exists
• Hostile networks: Some hotel or public Wi-Fi networks block 3389 outright — always worth asking the user about

Windows Firewall Quick Fix

# Enable all Remote Desktop firewall rules on target machine
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -Enabled True -Profile Any

# Verify the rules are active
Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
    Select-Object Name, Enabled, Direction, Action, Profile |
    Format-Table -AutoSize

Check if Another Service Is Using Port 3389

This one's rare, but I've seen it happen — especially on servers running third-party remote access tools.

# On the target machine, verify TermService owns port 3389
Get-NetTCPConnection -LocalPort 3389 -State Listen |
    Select-Object LocalAddress, LocalPort, OwningProcess, @{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

Step 3: Fix Authentication and Credential Errors

Authentication failures are the second most common RDP ticket category, and honestly, they can be the most annoying to troubleshoot because the error messages are often vague. Here are the specific scenarios you'll run into.

CredSSP "An authentication error has occurred" (Encryption Oracle Remediation)

This one drives helpdesk teams crazy. It typically surfaces after Windows Updates patch CredSSP vulnerabilities. When the client and server are at different patch levels, the default "Force Updated Clients" policy blocks the connection entirely.

# Temporary workaround (client-side) — reduces security, use only for emergency access
# Set via registry:
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f

# Or via Group Policy:
# Computer Configuration → Administrative Templates → System → Credentials Delegation
#   → "Encryption Oracle Remediation" = Vulnerable (temporary only!)

# PERMANENT FIX: Ensure both client and server have the same cumulative update installed

Important: That temporary workaround reduces your security posture. Always follow up by patching the server-side and reverting the client to "Force Updated Clients" or "Mitigated." Don't let the temporary fix become permanent — I've seen this happen more than I'd like to admit.

"Your credentials did not work"

This error has multiple root causes, which is why it's so frustrating:

1. User recently changed their password and cached credentials on the client are stale. Fix: In the RDP client, click "More choices" → "Use a different account" and enter credentials manually.
2. NLA is enabled but the client is sending local credentials instead of domain credentials. Fix: Prefix the username with the domain — DOMAIN\username or [email protected].
3. The machine has lost its trust relationship with the domain. Fix: Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
4. Microsoft Entra joined devices: When connecting to Entra-joined machines, use the format AzureAD\[email protected] or connect using the Remote Desktop app from the Microsoft Store (which supports Entra authentication natively).

User Not Authorized for Remote Desktop

# Check who is in the Remote Desktop Users group on the target
Invoke-Command -ComputerName TARGET-PC -ScriptBlock {
    Get-LocalGroupMember -Group "Remote Desktop Users"
}

# Add a user to the group
Invoke-Command -ComputerName TARGET-PC -ScriptBlock {
    Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\jsmith"
}

# For bulk operations via Active Directory group nesting:
# Add an AD security group to the local Remote Desktop Users group via GPO
# Computer Configuration → Preferences → Control Panel Settings → Local Users and Groups

Step 4: Resolve Black Screen and Display Issues

Ah, the dreaded "RDP connects but shows a black screen." Users absolutely hate this one because it looks like the connection worked but then... nothing. Let's walk through the causes.

Cause 1: UDP Transport Conflict

Windows 11 24H2 and Server 2025 use UDP transport by default for better performance. The problem? Some firewalls, VPNs, and network configurations silently drop or corrupt UDP packets, resulting in a black screen.

# Disable UDP transport temporarily to test
# On the CLIENT side, add this registry key:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /t REG_DWORD /d 1 /f

# Or in the .rdp file, add this line:
# use multimon:i:0
# use redirection server name:i:0
# networkautodetect:i:0
# bandwidthautodetect:i:0
# connection type:i:6

Cause 2: Display Driver Issue

The remote machine's GPU driver can conflict with RDP's display rendering — this happens more often than you'd think, especially on machines with dedicated GPUs.

# Connect with reduced display settings
mstsc /v:TARGET-PC /w:1024 /h:768

# If that works, the issue is display-driver related. Fix:
# 1. Update the GPU driver on the target machine
# 2. Or disable hardware graphics acceleration for RDP:
#    GPO: Computer Configuration → Admin Templates → Windows Components →
#    Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment
#    → "Use hardware graphics adapters for all Remote Desktop Services sessions" = Disabled

Cause 3: User Profile Corruption

If only one user gets the black screen while others connect fine, it's almost certainly a corrupted profile.

# On the remote machine, check for stuck sessions
query user /server:TARGET-PC

# If the user has a disconnected session, log it off
logoff SESSION_ID /server:TARGET-PC

# If profile corruption is suspected, rename the profile folder
# and let Windows create a fresh one on next login:
Rename-Item "C:\Users\jsmith" "C:\Users\jsmith.old"
# Also update the registry:
# HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
# Find the SID, rename or delete the key, let Windows recreate it

Step 5: Fix RDP Licensing Issues (Server Environments)

For Remote Desktop Services on Windows Server, licensing errors are extremely common — especially after server migrations or certificate renewals. If you manage RDS, you've probably seen these more times than you can count.

"No Remote Desktop License Servers Available"

# Check current licensing mode and server
Get-WmiObject -Class Win32_TerminalServiceSetting -Namespace root\cimv2\terminalservices |
    Select-Object LicensingType, LicenseServerList

# Verify the license server is reachable
Test-NetConnection -ComputerName LICENSE-SERVER -Port 135

# Force the RD Session Host to find the license server
# GPO: Computer Configuration → Admin Templates → Windows Components →
# Remote Desktop Services → Remote Desktop Session Host → Licensing
#   → "Use the specified Remote Desktop license servers" = LICENSE-SERVER.domain.com
#   → "Set the Remote Desktop licensing mode" = Per User (or Per Device)

Grace Period Expired

RDS gives you a 120-day grace period without licensing configured. Sounds generous, right? It goes by fast. If this expires and licensing isn't set up, all non-admin connections get refused.

# Check grace period status
$GracePeriod = (Invoke-WmiMethod -Path "Win32_TerminalServiceSetting" -Namespace root/cimv2/TerminalServices -Name GetGracePeriodDays)
Write-Output "Grace period remaining: $($GracePeriod.DaysLeft) days"

# If expired, you MUST configure proper RDS licensing
# There is no supported way to reset the grace period

Step 6: Troubleshoot TLS and Certificate Problems

Windows 11 24H2 and Server 2025 have raised the minimum TLS bar for RDP connections. If you're seeing "An internal error has occurred" (error code 0x4), TLS should be your prime suspect.

Check the RDP Certificate

# View the current RDP certificate on the target machine
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices |
    Select-Object SSLCertificateSHA1Hash

# Check if the certificate is valid
$Thumbprint = (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices).SSLCertificateSHA1Hash
Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq $Thumbprint} |
    Select-Object Subject, NotBefore, NotAfter, Thumbprint

Force TLS 1.2 Minimum (Recommended for 2026)

At this point, there's really no reason to keep TLS 1.0 or 1.1 around. Here's how to lock things down properly:

# Ensure TLS 1.2 is enabled system-wide (should be default, but verify)
# Check current settings:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -ErrorAction SilentlyContinue

# Disable TLS 1.0 and 1.1 (if not already done)
@("TLS 1.0", "TLS 1.1") | ForEach-Object {
    $Protocol = $_
    @("Client", "Server") | ForEach-Object {
        $Path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\$Protocol\$_"
        New-Item -Path $Path -Force | Out-Null
        Set-ItemProperty -Path $Path -Name "Enabled" -Value 0 -Type DWord
        Set-ItemProperty -Path $Path -Name "DisabledByDefault" -Value 1 -Type DWord
    }
}

Step 7: RDP Performance Optimization

Users complaining about laggy or slow RDP sessions? This is one of those issues where there's often a quick win hiding in the settings. Here's a systematic approach.

Enable UDP Transport (If Your Network Supports It)

RDP over UDP dramatically reduces latency and improves the overall experience, especially over WAN connections. Windows 11 24H2 enables this by default, but your network infrastructure might be blocking it without anyone realizing.

# Verify UDP transport is active during an RDP session (run on the server)
Get-NetUDPEndpoint -LocalPort 3389 | Select-Object LocalAddress, LocalPort, OwningProcess

# Ensure UDP 3389 is open in Windows Firewall
New-NetFirewallRule -DisplayName "RDP UDP" -Direction Inbound -Protocol UDP -LocalPort 3389 -Action Allow -Profile Domain,Private

# Verify the GPO allows UDP:
# Computer Configuration → Admin Templates → Windows Components →
# Remote Desktop Services → Remote Desktop Session Host → Connections
#   → "Select RDP transport protocols" = "Use both UDP and TCP"

Optimize Visual Experience for WAN Connections

For users connecting over slow links — VPN, satellite, cellular — you can reduce the visual overhead quite a bit:

# In the .rdp file, add or modify these settings:
# session bpp:i:16                    (16-bit color instead of 32-bit)
# compression:i:1                     (enable compression)
# videoplaybackmode:i:0               (disable video optimized remoting)
# audiocapturemode:i:0                (disable audio capture)
# encode redirected video capture:i:0 (disable video capture encoding)
# networkautodetect:i:1               (let the client auto-tune)
# bandwidthautodetect:i:1             (auto-detect bandwidth)
# connection type:i:2                 (hint: low-speed broadband)

Server-Side Performance Tuning

# Limit visual effects in RDP sessions via GPO:
# Computer Configuration → Admin Templates → Windows Components →
# Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment
#   → "Limit maximum color depth" = 16 bit
#   → "Configure compression for RemoteFX data" = Optimized to use less network bandwidth

# Monitor per-session resource usage
Get-Process -IncludeUserName | Where-Object {$_.SessionId -gt 0} |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 20 UserName, SessionId, ProcessName,
    @{N="Memory(MB)";E={[math]::Round($_.WorkingSet64/1MB,1)}}, CPU

Step 8: Helpdesk Diagnostic Script — Copy and Run

This is honestly one of the most useful things in this entire guide. It's an all-in-one PowerShell diagnostic script that checks the most common RDP issues on a target machine. Have your L1 techs run this as a first step for any RDP ticket — it'll save everyone a lot of back-and-forth.

# RDP Diagnostic Script for Helpdesk
# Usage: .\Test-RDPHealth.ps1 -ComputerName TARGET-PC

param(
    [Parameter(Mandatory=$true)]
    [string]$ComputerName
)

Write-Host "=== RDP Diagnostics for $ComputerName ===" -ForegroundColor Cyan

# 1. Test network connectivity
Write-Host "`n[1] Testing network connectivity..." -ForegroundColor Yellow
$NetTest = Test-NetConnection -ComputerName $ComputerName -Port 3389 -WarningAction SilentlyContinue
if ($NetTest.TcpTestSucceeded) {
    Write-Host "  TCP 3389: OPEN" -ForegroundColor Green
} else {
    Write-Host "  TCP 3389: BLOCKED or UNREACHABLE" -ForegroundColor Red
    Write-Host "  Ping result: $($NetTest.PingSucceeded)"
    Write-Host "  Check: Firewall rules, network path, VPN routing" -ForegroundColor Yellow
}

# 2. Test DNS resolution
Write-Host "`n[2] Testing DNS resolution..." -ForegroundColor Yellow
try {
    $DNS = Resolve-DnsName -Name $ComputerName -ErrorAction Stop
    Write-Host "  DNS resolves to: $($DNS.IPAddress -join ', ')" -ForegroundColor Green
} catch {
    Write-Host "  DNS resolution FAILED: $($_.Exception.Message)" -ForegroundColor Red
}

# 3. Check RDP service status (requires remote access)
Write-Host "`n[3] Checking RDP service on remote host..." -ForegroundColor Yellow
try {
    $SvcResult = Invoke-Command -ComputerName $ComputerName -ScriptBlock {
        $RDPEnabled = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server").fDenyTSConnections
        $TermService = Get-Service TermService
        $NLA = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").UserAuthentication
        $FirewallRules = Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object Enabled -eq True

        [PSCustomObject]@{
            RDPEnabled      = ($RDPEnabled -eq 0)
            ServiceStatus   = $TermService.Status
            NLAEnabled      = ($NLA -eq 1)
            FirewallRules   = $FirewallRules.Count
            OSVersion       = (Get-CimInstance Win32_OperatingSystem).Caption
            LastBoot        = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
        }
    } -ErrorAction Stop

    Write-Host "  OS: $($SvcResult.OSVersion)" -ForegroundColor Cyan
    Write-Host "  Last Boot: $($SvcResult.LastBoot)" -ForegroundColor Cyan

    if ($SvcResult.RDPEnabled) { Write-Host "  RDP Enabled: YES" -ForegroundColor Green }
    else { Write-Host "  RDP Enabled: NO — enable via Settings or registry" -ForegroundColor Red }

    Write-Host "  TermService: $($SvcResult.ServiceStatus)"
    Write-Host "  NLA Required: $($SvcResult.NLAEnabled)"
    Write-Host "  Active Firewall Rules: $($SvcResult.FirewallRules)"

} catch {
    Write-Host "  Could not connect via PowerShell Remoting: $($_.Exception.Message)" -ForegroundColor Red
    Write-Host "  Hint: Try enabling WinRM on the target or use Intune/SCCM" -ForegroundColor Yellow
}

# 4. Check for active/disconnected sessions
Write-Host "`n[4] Checking active RDP sessions..." -ForegroundColor Yellow
try {
    $Sessions = query user /server:$ComputerName 2>&1
    Write-Host $Sessions
} catch {
    Write-Host "  Could not query sessions: $($_.Exception.Message)" -ForegroundColor Red
}

# 5. Check RDP certificate
Write-Host "`n[5] Checking RDP certificate..." -ForegroundColor Yellow
try {
    Invoke-Command -ComputerName $ComputerName -ScriptBlock {
        $Thumbprint = (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices).SSLCertificateSHA1Hash
        $Cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -eq $Thumbprint}
        if ($Cert) {
            [PSCustomObject]@{
                Subject   = $Cert.Subject
                Expires   = $Cert.NotAfter
                IsExpired = ($Cert.NotAfter -lt (Get-Date))
            }
        } else {
            [PSCustomObject]@{ Subject = "Self-signed (default)"; Expires = "N/A"; IsExpired = $false }
        }
    } -ErrorAction Stop | Format-Table -AutoSize
} catch {
    Write-Host "  Could not check certificate remotely." -ForegroundColor Red
}

Write-Host "`n=== Diagnostics Complete ===" -ForegroundColor Cyan

Step 9: Windows 11 24H2 and Server 2025 — What Changed for RDP

If your organization is rolling out Windows 11 24H2 or Windows Server 2025, heads up — there are several RDP-specific changes that will probably trigger new helpdesk tickets. Better to know about them now than to find out the hard way.

Key Changes in 24H2 / Server 2025

• UDP transport is now on by default — Older firewall rules that only allow TCP 3389 will cause connection issues or degraded performance. You'll need to open UDP 3389 alongside TCP.
• Improved RDP connection bar — The connection bar UI has changed, which will confuse end users accustomed to the old layout. Expect tickets about "RDP looking different."
• Enhanced RDP security defaults — TLS 1.2 is now the minimum. Machines still configured for TLS 1.0/1.1 won't be able to connect until they're upgraded.
• GPU acceleration improvements — RDP now leverages GPU hardware more aggressively. This is great for performance but can cause black screen issues on machines with outdated GPU drivers.
• Remote Desktop app replacing MSTSC — Microsoft is actively pushing the "Remote Desktop" app from the Microsoft Store as a replacement for the classic mstsc.exe client. The new app supports Entra ID authentication, Azure Virtual Desktop, and modern connection features. It's worth encouraging users to make the switch.
• Kerberos enforcement — Server 2025 enforces Kerberos authentication more strictly. Make sure SPNs are registered correctly and that NTLM fallback policies are configured appropriately.

Step 10: RDP Troubleshooting Decision Tree

When a ticket comes in, use this decision tree to quickly route it to the right solution. Print it out, pin it to the wall — whatever works for your team.

1. Can the user ping the target machine?
   • No → Check network path, VPN connection, DNS resolution
   • Yes → Continue to step 2
2. Is TCP port 3389 open? (Use Test-NetConnection -Port 3389)
   • No → Check Windows Firewall, network firewalls, NSGs, port conflicts
   • Yes → Continue to step 3
3. Does the RDP client show an authentication error?
   • CredSSP error → Patch mismatch between client and server
   • "Credentials did not work" → Check domain prefix, NLA settings, trust relationship
   • "Not authorized" → Add user to Remote Desktop Users group
   • No auth error → Continue to step 4
4. Does the session connect but show a black screen?
   • Yes → Try disabling UDP, check GPU driver, check for disconnected sessions
   • No → Continue to step 5
5. Is the session slow or laggy?
   • Yes → Verify UDP transport is working, reduce visual settings, check bandwidth
   • No → Check RDS licensing, TLS certificates, event logs

Frequently Asked Questions

How do I enable Remote Desktop on Windows 11 without physical access?

If the machine has PowerShell Remoting (WinRM) enabled, run: Invoke-Command -ComputerName TARGET-PC -ScriptBlock { Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0; Enable-NetFirewallRule -DisplayGroup "Remote Desktop" }. You can also use Microsoft Intune to push a device configuration profile that enables Remote Desktop, or deploy via Group Policy if the machine is domain-joined.

Why does RDP keep disconnecting after a few minutes?

Frequent disconnections usually point to network instability, aggressive idle timeouts, or keep-alive settings. Check the GPO setting at Computer Configuration → Admin Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections → "Set time limit for disconnected sessions". Also verify your VPN or firewall isn't dropping idle TCP connections. Enable keep-alive packets: Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name KeepAliveEnable -Value 1.

Can I use RDP to connect to a Microsoft Entra ID (Azure AD) joined device?

Yes, but it takes some specific configuration. The connecting user needs to use the format AzureAD\[email protected] when prompted for credentials. For a smoother experience, use the Remote Desktop app from the Microsoft Store instead of the classic mstsc.exe client — it handles Entra authentication natively. Just make sure the target device's local policy allows RDP connections from Entra-joined accounts, and that the connecting account is in the Remote Desktop Users group on the target machine.

What is the default RDP port and should I change it?

The default port is TCP 3389 (and UDP 3389 for improved performance). You can change it via the registry (HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber), but honestly, it only adds a thin layer of obscurity — it's not a real security measure. Focus your energy on proper security instead: enable NLA, enforce MFA via Conditional Access, restrict RDP access by IP using firewall rules, and consider using Azure Bastion or a jump server rather than exposing RDP directly to the internet.

How do I fix "An internal error has occurred" when connecting via RDP?

This generic error (code 0x4) usually comes down to a TLS or certificate problem. Start by restarting the Remote Desktop Services service on the target: Restart-Service TermService -Force. If that doesn't help, check the RDP certificate — it may be expired or misconfigured. You can delete the self-signed certificate and restart TermService to let Windows generate a fresh one. Also verify that TLS 1.2 is enabled on both client and server, since Windows 11 24H2 no longer supports TLS 1.0/1.1 for RDP connections.