RDP-felsökning i Windows 11: portar, CredSSP och en mätbar helpdesk-runbook 2026

Uppdaterad: 24 juni 2026

RDP-felsökning i Windows 11 handlar oftast om fyra saker: nätverket släpper inte igenom port 3389, brandväggen blockerar tjänsten, autentiseringen misslyckas (CredSSP eller NLA), eller Remote Desktop Services-tjänsten har stoppats. Jag har kört en helpdesk där cirka 14 % av alla tickets någon gång berörde RDP, och i 9 av 10 fall ligger grundorsaken i en av dessa fyra kategorier. Den här guiden ger dig en mätbar felsökningsordning, körbara PowerShell-kommandon och Event Viewer-källor som sänker MTTR ordentligt.

• Standardporten för RDP är TCP/UDP 3389; om Test-NetConnection -Port 3389 misslyckas är det nätverk eller brandvägg, inte klienten.
• Felet "An internal error has occurred" beror nästan alltid på NLA, CredSSP-versionspolicyn (KB5005413) eller ett trasigt RDP-certifikat.
• RDP-anslutningar loggas i Microsoft-Windows-TerminalServices-LocalSessionManager/Operational. Event ID 21, 24 och 25 är nyckelhändelserna.
• Windows 11 Home saknar Remote Desktop-värd; endast Pro, Enterprise och Education kan ta emot inkommande RDP.
• Lös 80 % av RDP-tickets själv med en runbook som testar port, tjänst, NLA och kontolåsning innan eskalering.
• Mät First Call Resolution (FCR) och Mean Time To Resolution (MTTR) per RDP-felkategori. Utan kategorisering förbättras inget.

Hur aktiverar jag Remote Desktop i Windows 11?

För att aktivera Remote Desktop på en Windows 11-värd måste du köra en version som stöder det. Endast Windows 11 Pro, Enterprise och Education kan agera RDP-värd. Home-utgåvan tillåter endast utgående anslutningar. Detta är den vanligaste orsaken till "varför fungerar det inte hos användaren men hos mig?" på helpdesken. Kontrollera utgåvan i Inställningar → System → Om eller med PowerShell innan du börjar felsöka något annat.

# Verifiera Windows-utgåva och build innan du felsöker RDP
Get-ComputerInfo -Property WindowsProductName, WindowsVersion, OsBuildNumber

# Aktivera Remote Desktop via registret (motsvarar Inställningar → Fjärrskrivbord)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' `
    -Name 'fDenyTSConnections' -Value 0

# Öppna brandväggsregeln för RDP (domän, privat och publik profil)
Enable-NetFirewallRule -DisplayGroup 'Fjärrskrivbord'

# Kontrollera att Remote Desktop Services-tjänsten är igång och autostartar
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService

# Lägg till en användare i den lokala gruppen 'Remote Desktop Users'
Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'CORP\anna.lindqvist'

I en domänmiljö ska du inte sätta dessa registernycklar manuellt på varje maskin. Använd en GPO under Computer Configuration → Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections. Att slänga ut detta via Intune fungerar också; konfigurationsprofilen heter "Remote Desktop Services" under Settings Catalog. Om GPO:n inte tillämpas, läs vår guide om Group Policy som inte tillämpas innan du jagar RDP-symptom, eftersom felet kan ligga en nivå djupare.

Vilken port används av RDP och hur testar man den?

RDP använder TCP 3389 för anslutningskontroll och, sedan Windows 8, även UDP 3389 för att förbättra latens och ljudkvalitet via RDP 8+. Om någon av dem är blockerad försämras upplevelsen markant, så kontrollera båda. Det allra första du gör vid en RDP-ticket är ett portintest från klienten; det isolerar nätverk från värd på under tio sekunder.

# Snabb porttest från klienten (PowerShell 5.1 eller 7+)
Test-NetConnection -ComputerName rdp-host.corp.local -Port 3389

# Detaljerad TCP-handshake med tidsstämpel (användbart i tickets)
$result = Test-NetConnection rdp-host.corp.local -Port 3389 -InformationLevel Detailed
$result | Format-List ComputerName, RemoteAddress, TcpTestSucceeded, PingSucceeded

# Lista vilken process som lyssnar på 3389 på själva värden
Get-NetTCPConnection -LocalPort 3389 -State Listen |
    Select-Object LocalAddress, LocalPort, OwningProcess,
        @{Name='Process'; Expression={(Get-Process -Id $_.OwningProcess).Name}}

Om porten är öppen men anslutningen ändå dör tidigt, misstänk MTU-problem på en VPN-länk eller en mellanliggande inspektionsbrandvägg. På Always On VPN och vissa SD-WAN-lösningar har jag sett RDP-sessioner som etableras men kraschar efter 60 sekunder på grund av idle timeout. Det är inget RDP-problem, det är en NAT-tabell. För djupare nätverksdiagnostik, se vår guide om nätverksdiagnostik för helpdesk.

Varför kan jag inte ansluta via Remote Desktop?

När RDP-klienten (mstsc.exe) inte ens kommer fram till inloggningsskärmen finns det fem typiska orsaker, och du bör gå igenom dem i strikt ordning. Den här ordningen är inte slumpmässig. Den följer OSI-modellen nerifrån och upp, vilket minimerar tid till rätt diagnos.

1. Namnupplösning: Resolve-DnsName rdp-host.corp.local. Om det misslyckas är det DNS, inte RDP.
2. Nätverksåtkomst: Test-NetConnection -Port 3389. Misslyckas det utan paketsvar är det routing eller brandvägg.
3. Tjänstetillstånd på värden: Get-Service TermService, UmRdpService ska visa Running.
4. Brandvägg på värden: Get-NetFirewallRule -DisplayGroup 'Fjärrskrivbord' | Where-Object Enabled -eq 'True'.
5. Användarrättigheter: Är användaren medlem i Remote Desktop Users eller administratör? Är kontot låst? Är "Allow log on through Remote Desktop Services" satt i Group Policy?

En vanlig fälla: en användare har bytt lösenord nyligen, men cachelagrade credentials i Credential Manager på klienten pekar fortfarande på det gamla. Symtomet är att Inloggningen returnerar "The logon attempt failed" trots korrekt lösenord. Lösning: cmdkey /list följt av cmdkey /delete:TERMSRV/rdp-host.corp.local. Om kontot ständigt låses ut efter detta, läs guiden om AD-kontoutlåsning och Event 4740, eftersom det är en sammanlänkad rotorsak.

Hur fixar jag "An internal error has occurred" i RDP?

Felet "An internal error has occurred" är RDP:s mest ökända felmeddelande eftersom det inte säger någonting. I 2026 års Windows 11-versioner (23H2 och 24H2) ser jag det utlöst av tre rotorsaker, i denna fallande frekvens på vår helpdesk: NLA-konflikt mellan klient och värd, ett utgånget eller felaktigt RDP-lyssnarcertifikat, och TLS-versionsmissmatchning efter att schannel-policyn skärpts.

# 1. Tvinga om-utfärdning av RDP-lyssnarcertifikatet
#    (Värden genererar ett självsignerat certifikat om inget mappats via GPO)
$cert = Get-WmiObject -Class 'Win32_TSGeneralSetting' `
    -Namespace 'root\CIMV2\TerminalServices' -Filter "TerminalName='RDP-Tcp'"
$cert.SSLCertificateSHA1Hash

# Ta bort det gamla certifikatet och starta om Remote Desktop Services
Remove-Item 'Cert:\LocalMachine\Remote Desktop\*' -Force
Restart-Service TermService -Force

# 2. Verifiera NLA-inställningen (1 = krävs, 0 = inte krävt)
(Get-WmiObject -Class 'Win32_TSGeneralSetting' `
    -Namespace 'root\CIMV2\TerminalServices' `
    -Filter "TerminalName='RDP-Tcp'").UserAuthenticationRequired

# 3. Kontrollera vilka TLS-versioner som tillåts av schannel
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'

En lösning som ofta fungerar utan omstart: töm %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache på klientsidan och radera registret HKCU\Software\Microsoft\Terminal Server Client\Default\AddIns\RDPDR. Det rensar cachelagrade bitmaps och device redirectors som ofta är boven när felmeddelandet dyker upp slumpmässigt mitt under en pågående session.

Felsökning av CredSSP-fel (CVE-2018-0886 / KB5005413)

CredSSP-felet ("This could be due to CredSSP encryption oracle remediation") har funnits sedan 2018, men dök upp igen i en ny form efter Microsofts härdningar 2022 och 2024. I 2026 ser jag det när helpdeskagenter försöker RDP:a in på äldre Windows Server 2016-värdar eller på maskiner som inte fått senaste kumulativa uppdateringen. Symptomet är att klienten är fullt patchad men servern inte är det, och vice versa.

Den korrekta lösningen är alltid att patcha värden, inte att sänka klientens säkerhetspolicy. Men för att få användaren tillbaka i arbete medan patchen rullas ut behöver du ofta en tillfällig override. Microsoft beskriver detta i detalj i sin officiella CredSSP-vägledning för CVE-2018-0886.

# PERMANENT LÖSNING: Patcha värden. Verifiera senaste CU på Windows Server / Windows 11
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

# TILLFÄLLIG WORKAROUND (endast på klienten, tas bort när värden är patchad)
# Sätter AllowEncryptionOracle till 2 (Vulnerable). Använd ALDRIG i produktion permanent
New-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' -Force
Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' `
    -Name 'AllowEncryptionOracle' -Value 2 -Type DWord

# Rulla tillbaka workaround när värden patchats
Remove-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' `
    -Name 'AllowEncryptionOracle'

NLA, certifikat och svart skärm

Network Level Authentication (NLA) kräver att klienten autentiserar sig innan en RDP-session etableras. Det är säkrare och sparar resurser på värden, men det skapar felmönster som ser ut som svart skärm, frysning eller "internal error". Black screen-symptomet (där du ser RDP-fönstret men det är helt svart i 30–60 sekunder) beror oftast på Bitmap caching i kombination med en föråldrad grafikadapterdrivrutin på värden, eller GPU-acceleration i RDP 10.0+ som inte fungerar mot virtualiserade GPUer.

Lösningsordning vid svart skärm:

1. Ändra färgdjup i mstsc till 16-bit som testfall (Display-fliken). Om problemet försvinner är det grafikrelaterat.
2. Inaktivera Use hardware graphics adapters for all Remote Desktop Services sessions via GPO på värden.
3. Töm bitmap-cachen: Remove-Item "$env:LOCALAPPDATA\Microsoft\Terminal Server Client\Cache\*" -Force.
4. Verifiera att senaste display-drivrutinen är installerad på värden. På Hyper-V Gen2-VMar är detta särskilt vanligt.

När NLA bör inaktiveras (sällan)

Att stänga av NLA är en kortsiktig diagnostisk åtgärd, inte en lösning. Det enda legitima fallet är när du försöker isolera om autentiseringen är problemet versus själva session-värden. Slå på NLA igen så fort diagnosen är klar. Microsofts officiella dokumentation för Remote Desktop-tillgång beskriver de gällande policyinställningarna.

Varför fryser eller släpper min RDP-session?

Frysningar och frånkopplingar är ofta nätverkssymptom, inte RDP-fel. Standardinställningen för UDP-transport i RDP 8+ är aggressivt designad för låg latens men dålig på paketförlust över 2 %. På en flackerande Wi-Fi-anslutning eller en mättad VPN-tunnel kommer användaren märka att "RDP fryser var 30:e sekund". Här hjälper det att tvinga TCP-only-transport som ett diagnostiskt test, men det är inte en permanent lösning.

# Tvinga TCP-only RDP-transport (för diagnostik, försämrar prestanda)
# Klientsidan via Group Policy: Computer Configuration → Policies →
# Administrative Templates → Windows Components → Remote Desktop Services →
# Remote Desktop Connection Client → "Turn off UDP on Client"
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client' `
    -Name 'fClientDisableUDP' -Value 1 -Type DWord

# Inaktivera idle-timeout som annars kan kasta ut en pausad session
# Computer Configuration → Policies → Administrative Templates →
# Windows Components → Remote Desktop Services → Remote Desktop Session Host →
# Session Time Limits → "Set time limit for active but idle Remote Desktop Services sessions"
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' `
    -Name 'MaxIdleTime' -Value 0 -Type DWord

# Kontrollera om sessionen släpps av Network Policy Server eller RD Gateway
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-Gateway/Operational' -MaxEvents 50

Om problemet är intermittent, mät paketförlust med pathping mot RDP-värden i 60 sekunder. Allt över 1 % förklarar 90 % av frysningssymptomen, och då är det inte RDP du ska felsöka. Det är wifi-radio, switch-uplinks eller VPN-koncentratorn. Vi har en separat guide för VPN-felkoder i Windows 11 som täcker just dessa scenarier.

Event Viewer-källor för RDP-diagnostik

Event Viewer är RDP-felsökarens viktigaste verktyg, men 80 % av nya helpdeskagenter tittar bara i Application och System loggarna. RDP loggar i fyra separata operationella kanaler, och varje fas i anslutningen har sitt eget Event ID. Att veta vilken kanal du ska öppna baserat på var i flödet det går fel halverar diagnosetiden enligt mina egna mätningar.

Loggkanal	Vad den loggar	Nyckel-Event IDs
TerminalServices-LocalSessionManager/Operational	Sessionsstart, frånkoppling, återanslutning	21 (logon), 24 (disconnect), 25 (reconnect), 39 (forced disconnect)
TerminalServices-RemoteConnectionManager/Operational	Inkommande anslutningsförfrågningar	1149 (auth success), 1158 (NLA failure)
TerminalServices-Gateway/Operational	RD Gateway-anslutningar och NPS-policy	302 (connect), 303 (disconnect), 304 (failure)
Security	Inloggningsförsök och kontoutlåsningar	4624 (success), 4625 (failure), 4740 (lockout)

# Hämta senaste 20 RDP-inloggningarna från LSM-loggen
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' `
    -MaxEvents 50 |
    Where-Object Id -in 21, 23, 24, 25 |
    Select-Object TimeCreated, Id,
        @{Name='User'; Expression={$_.Properties[0].Value}},
        @{Name='Source'; Expression={$_.Properties[2].Value}}

# Lista misslyckade NLA-försök sista 24 timmarna
$since = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational'
    Id        = 1158
    StartTime = $since
} -ErrorAction SilentlyContinue

Helpdesk-runbook: en mätbar felsökningsordning

Utan en standardiserad runbook kommer två agenter att felsöka samma RDP-problem på två olika sätt, och du kan inte mäta vad som fungerar. Min rekommendation för en tier-1 RDP-runbook består av sex steg som tillsammans tar under fem minuter att gå igenom och löser cirka 80 % av tickets utan eskalering. Resterande 20 % eskaleras till tier-2 med fullständig diagnostikdata bifogad, vilket är vad FCR (First Call Resolution) faktiskt mäter.

1. Validera utgåva och senaste CU på värd: Get-ComputerInfo + Get-HotFix. Avsluta om värden är Home-utgåva.
2. Verifiera anslutbarhet: Test-NetConnection -Port 3389 från klienten. Avsluta som nätverksticket om porten är stängd.
3. Kontrollera tjänsten: Get-Service TermService på värden via PowerShell remoting eller fysisk åtkomst.
4. Verifiera kontostatus: Get-ADUser anvandarnamn -Properties LockedOut, Enabled mot AD.
5. Töm cache och credentials: cmdkey /delete + radera mstsc cache på klienten.
6. Samla Event Viewer-bevis: Exportera de fyra kanalerna ovan om steg 1–5 inte löste det. Bifoga till ticket vid eskalering.

Vad du ska mäta nästa månad

För att verkligen sänka RDP-relaterad MTTR behöver du tre mätetal i din ticketing-rapportering:

• FCR per RDP-felkategori (nätverk / autentisering / certifikat / NLA / svart skärm). Separera dessa, annars döljer ett medelvärde de verkliga problemen.
• MTTR från ticket öppnad till löst, brutet ner per kategori. Förvänta dig att autentiseringsfel är snabbast, certifikatfel långsammast.
• Andel tickets eskalerade till tier-2 efter att runbook-steg 1–6 körts. Om över 30 % eskaleras saknar runbooken något steg, så uppdatera den.

Om du vill knyta detta till bredare AD-diagnostik, se vår kompletta guide för Active Directory-felsökning. Många RDP-tickets har en AD-rotorsak som blir uppenbar när du börjar mäta. Microsoft publicerar också användbara prestandariktlinjer i sin kapacitetsplanering för Remote Desktop Services.

Vanliga frågor

Hur ändrar jag RDP-porten från 3389 i Windows 11?

Ändra registervärdet HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber till önskad port, öppna brandväggsregeln för den nya porten och starta om TermService. Att byta port döljer dig från opportunistisk skanning men ersätter inte en VPN eller RD Gateway.

Kan jag använda Remote Desktop till en Windows 11 Home-dator?

Nej. Windows 11 Home saknar Remote Desktop-värden helt; endast utgående RDP fungerar. För inkommande anslutningar krävs Pro, Enterprise eller Education. Alternativ är Quick Assist (inbyggt), AnyDesk eller TeamViewer för stödsessioner.

Hur många samtidiga RDP-sessioner stöder Windows 11?

Windows 11 Pro och Enterprise tillåter en samtidig inkommande RDP-session per maskin enligt licensen. För fleranvändarscenarier behöver du Windows Server med Remote Desktop Services-roll och RDS CALs. Inofficiella patchar finns men bryter mot Microsofts licensavtal.

Varför fungerar RDP innanför kontorsnätet men inte över VPN?

Vanliga orsaker är att VPN-poolen inte är tillåten i Windows-brandväggens RDP-regel, att split-tunneling skickar trafiken fel väg, eller att MTU-storleken på VPN-tunneln fragmenterar RDP-paketen. Verifiera med ping -f -l 1472 mot RDP-värden över VPN för att utesluta MTU-problem.

Hur kan jag se vem som är ansluten via RDP just nu?

Kör quser eller query session i en upphöjd PowerShell-prompt på värden. För fjärrkörning mot flera maskiner, använd Invoke-Command -ComputerName host1, host2 -ScriptBlock { quser }. Detta visar användarnamn, sessions-ID, status och idle-tid.