Windows VM RDP session latency reproducible daily 9AM-1PM EST — persists after region move from East US to West US 2

Hello,

Thank you for sharing the detailed environment information and the Microsoft Q&A thread. I understand how disruptive it is when all users on both VMs experience severe lag during the same four-hour window each day.

Since the behavior remained unchanged after redeploying from East US to West US 2, the most effective next step is to collect synchronized evidence from the Azure platform, guest operating system, and client network path during both a normal period and the affected 9:00 AM to 1:00 PM EST window.

1. Azure platform and VM resource analysis

Please configure Azure Monitor and VM Insights with the finest available granularity and review the following during the affected period:

• CPU percentage and CPU credits, if applicable
• Available memory and committed memory
• OS disk read/write latency, IOPS, throughput, and disk queue length
• Network In/Out, packets, dropped packets, and retransmission-related guest counters
• VM availability, Resource Health, Activity Log, and Scheduled Events

Inside each VM, please run a continuous Windows Performance Monitor data collector set covering Processor, Memory, PhysicalDisk, LogicalDisk, Network Interface, TCPv4, and System counters. Also review Windows System and Application event logs for Defender scans, Windows Update, backup, inventory, monitoring, or other scheduled tasks beginning near 9:00 AM EST.

Customer-visible Azure metrics can identify VM, disk, or network saturation, but they cannot conclusively expose every physical-host contention condition. If the guest and network evidence does not show a bottleneck, please provide the exact affected UTC timestamps, VM resource IDs, and collected logs so that we can review Azure platform telemetry through a support investigation.

2. Accelerated Networking

Standard_D4s_v3 supports Accelerated Networking. It is recommended where supported because it uses SR-IOV to reduce virtual-switch processing, latency, jitter, and networking CPU overhead.

However, it should be treated as an optimization rather than the primary fix for a multi-minute daily stall. Microsoft documentation notes that its latency benefit can be minimal for traffic crossing virtual networks or connecting from on-premises. Therefore, enabling it may improve RDP responsiveness and consistency, but it would not by itself explain or resolve a recurring four-hour issue affecting both VMs.

Before enabling it, please confirm that the custom image contains the required drivers. The VM must be stopped and deallocated to enable Accelerated Networking on its NIC.

3. Client-to-VM network diagnostics

Because ICMP may be filtered or deprioritized, please use TCP-based testing against the VM’s RDP endpoint instead:

• Configure Azure Network Watcher Connection Monitor for continuous TCP testing to the VM on port 3389. This can record latency, packet loss, reachability, and path information over the affected window.
• From at least one affected client, continuously record TCP connectivity to port 3389, route/path changes, public IP, local interface statistics, and timestamps.
• Capture simultaneous packet traces on the client and VM during a freeze using pktmon or Wireshark. Comparing both sides will help identify retransmissions, delayed acknowledgements, resets, or periods where the network remains responsive while the guest stops processing.
• If possible, repeat one affected-window test from an alternate client network, such as a different ISP or controlled Azure VM. If the alternate path remains healthy while the original client path degrades, this would point toward the customer-side ISP, firewall, proxy, or network path rather than the Azure host.

Recommended isolation sequence

1. Begin Azure Monitor, Connection Monitor, and PerfMon collection before 9:00 AM EST and continue beyond 1:00 PM EST.
2. Record the exact timestamp of each visible freeze and test whether the VM responds to TCP 3389 at that time.
3. Compare both VMs and all affected clients using the same timeline.
4. Run one controlled test from an alternate network path.
5. If guest counters remain normal and the TCP path is healthy during the freeze, provide the timestamped evidence for Azure host-level review.

For reference:

• Azure Accelerated Networking overview
• Manage Accelerated Networking for Azure VMs
• Azure Network Watcher Connection Monitor overview

Once you share the affected timestamps and collected results, we can correlate the Azure, guest, and network evidence and determine the appropriate next troubleshooting path.

Kind regards,

Adithya Prasad Kolisetty

Azure Support EngineerHello,

Thank you for sharing the detailed environment information and the Microsoft Q&A thread. I understand how disruptive it is when all users on both VMs experience severe lag during the same four-hour window each day.

Since the behavior remained unchanged after redeploying from East US to West US 2, the most effective next step is to collect synchronized evidence from the Azure platform, guest operating system, and client network path during both a normal period and the affected 9:00 AM to 1:00 PM EST window.

1. Azure platform and VM resource analysis

Please configure Azure Monitor and VM Insights with the finest available granularity and review the following during the affected period:

• CPU percentage and CPU credits, if applicable
• Available memory and committed memory
• OS disk read/write latency, IOPS, throughput, and disk queue length
• Network In/Out, packets, dropped packets, and retransmission-related guest counters
• VM availability, Resource Health, Activity Log, and Scheduled Events

Inside each VM, please run a continuous Windows Performance Monitor data collector set covering Processor, Memory, PhysicalDisk, LogicalDisk, Network Interface, TCPv4, and System counters. Also review Windows System and Application event logs for Defender scans, Windows Update, backup, inventory, monitoring, or other scheduled tasks beginning near 9:00 AM EST.

Customer-visible Azure metrics can identify VM, disk, or network saturation, but they cannot conclusively expose every physical-host contention condition. If the guest and network evidence does not show a bottleneck, please provide the exact affected UTC timestamps, VM resource IDs, and collected logs so that we can review Azure platform telemetry through a support investigation.

2. Accelerated Networking

Standard_D4s_v3 supports Accelerated Networking. It is recommended where supported because it uses SR-IOV to reduce virtual-switch processing, latency, jitter, and networking CPU overhead.

However, it should be treated as an optimization rather than the primary fix for a multi-minute daily stall. Microsoft documentation notes that its latency benefit can be minimal for traffic crossing virtual networks or connecting from on-premises. Therefore, enabling it may improve RDP responsiveness and consistency, but it would not by itself explain or resolve a recurring four-hour issue affecting both VMs.

Before enabling it, please confirm that the custom image contains the required drivers. The VM must be stopped and deallocated to enable Accelerated Networking on its NIC.

3. Client-to-VM network diagnostics

Because ICMP may be filtered or deprioritized, please use TCP-based testing against the VM’s RDP endpoint instead:

• Configure Azure Network Watcher Connection Monitor for continuous TCP testing to the VM on port 3389. This can record latency, packet loss, reachability, and path information over the affected window.
• From at least one affected client, continuously record TCP connectivity to port 3389, route/path changes, public IP, local interface statistics, and timestamps.
• Capture simultaneous packet traces on the client and VM during a freeze using pktmon or Wireshark. Comparing both sides will help identify retransmissions, delayed acknowledgements, resets, or periods where the network remains responsive while the guest stops processing.
• If possible, repeat one affected-window test from an alternate client network, such as a different ISP or controlled Azure VM. If the alternate path remains healthy while the original client path degrades, this would point toward the customer-side ISP, firewall, proxy, or network path rather than the Azure host.

Recommended isolation sequence

1. Begin Azure Monitor, Connection Monitor, and PerfMon collection before 9:00 AM EST and continue beyond 1:00 PM EST.
2. Record the exact timestamp of each visible freeze and test whether the VM responds to TCP 3389 at that time.
3. Compare both VMs and all affected clients using the same timeline.
4. Run one controlled test from an alternate network path.
5. If guest counters remain normal and the TCP path is healthy during the freeze, provide the timestamped evidence for Azure host-level review.

For reference:

• Azure Accelerated Networking overview
• Manage Accelerated Networking for Azure VMs
• Azure Network Watcher Connection Monitor overview

Once you share the affected timestamps and collected results in the private message , we can correlate the Azure, guest, and network evidence and determine the appropriate next troubleshooting path.