We are facing an issue with a Windows Server 2022 Datacenter Azure Edition v2 VM where Remote Desktop (RDP) port 3389 is not listening, despite all expected configurations being in place. This prevents RDP connections to the system.

Question

System Context

• OS: Windows Server 2022 Datacenter, Azure Edition (v2)
• Scenario: The original VM failed to allow RDP. A rescue VM was created with Hyper-V, and the original VM’s OS disk was attached as a passthrough disk. The affected OS boots and functions inside the Hyper-V guest.
• Edition-Specific Note: The guest VM is booted using the Azure Edition image, not within Azure (which may impact IMDS-based activation or Azure Benefits).

RDP Config:

• RDP enabled via sconfig (Option 7 shows: “Enabled (all clients)”)
• Port 3389 is set correctly under : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
• SecurityLayer value is 2 (SSL/TLS), tested with values 0, 1, and 2.

1. Service State:
   • TermService and UmRdpService are both running.
   • RDP listener RDP-Tcp is present in the registry.
   • qwinsta shows an active console session for azureuser.
2. Firewall:
   • All RDP firewall rules (TCP-In/UDP-In) are enabled and allow traffic.
   • No 3rd party security products are installed or interfering.
3. Port Binding Failure:
   • netstat -an | findstr ":3389" returns nothing — port 3389 is not bound.
   • Test-NetConnection -ComputerName localhost -Port 3389 fails.
   • Get-NetTCPConnection -LocalPort 3389 shows no bindings.
   • No events in the System/EventLog clearly identify binding failure.
4. RDP Certificate (RCM): HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM
   1. both Certificate and CertificateOld REG_BINARY values were present.
   2. Deleting both keys and restarting TermService did not resolve the issue — RDP still failed to bind to 3389.
5. ProfileList Registry : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList No corrupt or orphaned profile entries were found, suggesting no FSLogix or profile-related blockages.

Action Taken :

1. Verified all registry entries related to RDP port and listener.
2. Set AllowTSConnections = 1 using WMI.
3. Set SecurityLayer = 0 for negotiation fallback.
4. Confirmed no alternate services were using port 3389.
5. Deleted Certificate and CertificateOld entries in RCM, restarted RDP service.
6. Restarted the guest OS and verified again with netstat, qwinsta, and Test-NetConnection.
7. Checked firewall rules in detail – all enabled and unrestricted.
8. Verified that no RDS licensing misconfigurations, GPOs, or RDS role services were blocking listener registration.
9. Ran DISM and CBS scans – no errors affecting RDP functionality found.
10. Reviewed subinacl permissions on TermService — matched with a working reference machine.

We seek clarification and guidance on:

1. Why the RDP listener on port 3389 is not registering despite services running and all registry, firewall, and certificate configurations being present?
2. Are there RDP/SSL binding constraints specific to Azure Edition v2 images, especially when not running in Azure?
3. Are there additional certificate requirements (e.g., from IMDS or Windows Activation Services) that block listener registration?
4. Are there any hidden logs, ETW providers, or advanced diagnostics that can reveal why the listener registration is failing silently?