AzureDiagnostics

Hello DennisS

Thank you for posting your query on Microsoft Q&A platform.

AzureDiagnostics events are not the root cause of the VM becoming unresponsive or RDP hanging.

AzureDiagnostics is a log table / log source used by Azure Monitor to store diagnostic and telemetry data collected from Azure services and virtual machines. These logs are output data only and do not execute workloads inside the VM.

Diagnostics logs are collected data, not processing activity that impacts VM responsiveness.

Why the VM shows “Running” in Azure but RDP and monitoring are unstable?

There is a difference between Azure infrastructure state and guest OS health:

• Azure portal “Running” status only reflects the hypervisor and host availability
• Ping success only validates basic ICMP connectivity
• RDP, automation agents, and monitoring tools depend entirely on guest OS services
• A VM can be running and reachable but still have RDP failures or hangs due to guest OS issues
• Ping success does not guarantee RDP (TCP 3389) or OS responsiveness .

Why ConnectWise Automate intermittently shows the VM as offline:

Third‑party monitoring agents (such as ConnectWise Automate) run inside the guest OS and require:

• Stable OS networking
• Running agent services
• Outbound HTTPS connectivity

If the guest OS is under resource pressure or services are stalled:

• Azure continues to show Running
• Ping still works
• The monitoring agent goes offline

Azure does not monitor guest OS service health.

RDP can hang due to RDP service issues, TLS / certificate problems, Local firewall or endpoint protection blocking connections

Please have a look into below workarounds:

1. Review Boot Diagnostics: Used to confirm whether the OS is responsive or stalled.
2. Reset RDP from Azure: This as a valid remediation when RDP hangs

• Re‑enables RDP firewall rules
• Resets RDP registry configuration

3. Use Azure Serial Console:

Microsoft recommends Serial Console specifically when:

• RDP is unavailable
• OS is partially responsive

Used to validate services, firewall, and OS health.

4. Run Azure Performance Diagnostics (PerfInsights):

This is Microsoft’s recommended and supported tool to identify:

• CPU pressure
• Memory exhaustion
• Disk latency

Reference: https://dotnet.territoriali.olinfo.it/en-us/azure/azure-monitor/vm/performance-diagnostics?tabs=windows

Thanks,

Suchitra.

AzureDiagnostics events themselves are usually just telemetry/diagnostic output and not the root cause of RDP unresponsiveness. Given the symptoms (VM up in Azure, ping works, but RDP intermittently hangs and the server appears offline to monitoring tools), the issue is more likely with the RDP stack or OS/network configuration inside the VM.

Use the following targeted checks and fixes:

1. Confirm the VM is healthy and reachable
   • In the Azure portal, verify the VM is in a Running state and review Boot diagnostics for any OS boot errors or blue screens.
   • Since ping works, basic network connectivity is present, but this does not guarantee RDP (TCP 3389) or OS responsiveness.
2. Reset RDP configuration from Azure
   • Use the documented RDP reset process for Windows VMs. This operation:
     • Enables the Remote Desktop Windows Firewall rule (TCP 3389).
     • Sets HKLM\System\CurrentControlSet\Control\Terminal Server\fDenyTSConnections to 0 to allow RDP.
   • After the reset completes, try RDP again.
   • If RDP still fails or is intermittent, continue with deeper checks.
   Reference: Detailed troubleshooting steps for remote desktop connection issues to Windows VMs in Azure
3. Check RDP service and port inside the VM If possible, use Azure Serial Console or another remote tool as described in the detailed RDP troubleshooting article to log on locally and verify:
   • Remote Desktop Services are running.
   • The RDP service is listening on TCP port 3389.
   • No local firewall or security software is blocking outbound or inbound RDP traffic.
   • No intrusion detection or endpoint protection is dropping RDP connections.
   The detailed RDP article lists these as common causes when the VM is running but RDP fails or is unstable.
4. Investigate certificate and TLS-related RDP issues Intermittent RDP failures with a running VM can be caused by TLS/certificate problems on the VM: a) Self-signed RDP certificate / MachineKeys issues
   • On the VM (via Serial Console or other remote access), check the System event log for:
     • Source: Microsoft-Windows-TerminalServices-RemoteConnectionManager
       • Event ID 1058 or 1057 (errors creating/replacing the self-signed RDP certificate).
     • Source: Schannel
       • Event ID 36870 or 36872 (errors accessing TLS server credential private key).
   • These indicate problems with the local RSA keys in the MachineKeys folder (permissions, corruption, or missing keys).
   • When present, they can cause RDP to fail even though the VM is otherwise running.
   Reference: Troubleshoot Azure VM RDP connection issues by Event ID b) Custom TLS/SSL certificate thumbprint mismatch
   • If the VM is configured to use a custom TLS/SSL certificate for RDP, verify the thumbprint in the registry matches the actual certificate:

          reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash
     

   • If it does not match, update or delete the value so RDP can use a valid certificate or fall back to the self-signed certificate.
   Reference: Troubleshoot Azure VM RDP connection issues by Event ID – Scenario 1 c) TLS version / security policy
   • If security policies have disabled older TLS versions, check for Schannel event ID 36871 (fatal error creating TLS server credential, internal error state 10013) in the System log.
   • RDP uses TLS; misconfigured TLS policies can cause RDP to fail or behave intermittently.
   • For TLS-related RDP authentication issues, follow the guidance in the linked article.
   Reference: Troubleshoot Azure VM RDP connection issues by Event ID – Scenario 2
5. Correlate AzureDiagnostics with OS logs
   • Use Event Viewer on the VM to review:
     • Windows Logs → System for RDP, Schannel, and networking errors.
     • Windows Logs → Application for application-level issues that might hang the OS.
   • If AzureDiagnostics is surfacing these events, the underlying cause will still be visible in the standard Windows logs.
   Reference: Microsoft Azure IaaS VM logs
6. Consider OS-level hangs or resource exhaustion
   • If ConnectWise Automate intermittently shows the server as offline while Azure shows it running, the OS may be:
     • Under heavy CPU/memory pressure.
     • Experiencing disk or driver issues.
     • Hanging during logon (for example, user profile or service initialization problems).
   • Review Application and System logs around the times of RDP freezes for crashes, resource exhaustion, or service failures.
7. If RDP remains unstable
   • After checking/resetting RDP, certificates, TLS, and OS logs, and confirming no local firewall or security software is blocking connections, consider:
     • Redeploying the VM to new Azure hardware (if not already done).
     • Opening a support case so that platform-level diagnostics (including IaaS VM logs and configuration) can be collected and analyzed.

These steps focus on the likely causes when a VM is up and pingable but RDP and monitoring agents intermittently lose connectivity, with AzureDiagnostics events acting as indicators rather than the root cause.

References:

• Troubleshoot Azure VM RDP connection issues by Event ID
• Detailed troubleshooting steps for remote desktop connection issues to Windows VMs in Azure
• Microsoft Azure IaaS VM logs
• Windows Azure platform as a service (PaaS) compute diagnostic data
• Unable to Access or Connect to VM - Microsoft Q&A