New Azure Local MC to AX Issue

Question

New Azure Local MC to AX Issue

Vince Dies 0

Hello, Dell migrated 2 of my 4 nodes from MC to AX nodes. I was able to migrate my server workloads over without issue. I created a new Session host and downloaded win 11 enterprise. I can connect to the avd with failover cluster manager but can;t with the thin clients or RDP. I have exhausted all of my ideas on what could be causing this issue. I'm not sure if I should abandon and redownload a new Win 11 instance and try again. I don't see any logs that show rdp crashing, yesterday I did see if was unable to create a secure connection with the DC, today that error is missing. Any help would be greatly appreciated, I need to rebuild all of the AVD's on the old cluster so Dell can finish the other 2. Thanks in advance.

kagiyama yutaka 4,915 Reputation points

2026-07-26T07:59:04.86+00:00

Could you add a bit more detail about the session host’s current state? Without that, I can’t identify the exact root cause from the current information. For example, whether it shows as Available in the host pool, how the recent AVD agent and BootLoader logs look, and if domain/DNS connectivity stayed stable after the MC→AX migration.
Allan Solomon Mejia 3,840 Reputation points

2026-07-26T17:50:09.3066667+00:00

Thanks, Kagiyama. I agree that more information is needed to identify the exact root cause.

Hello @Vince Dies could you confirm the following?

Is the session host showing Available or Unavailable in the AVD host pool?

What is the current registration state of the session host?

After the MC→AX migration, were the Azure Virtual Desktop Agent and Boot Loader services running without errors?

Are there any errors in the RDAgentBootLoader, RDAgent, or Windows Event Viewer logs?

Has domain/DNS connectivity remained healthy (for example, successful name resolution and communication with the domain controllers)?

Since the VM is accessible through Failover Cluster Manager, the issue appears more likely to be related to AVD registration or connectivity rather than the migration itself. These details should help narrow down the root cause.

1 answer

Your answer

kagiyama yutaka 4,915 Reputation points

2026-07-26T07:59:04.86+00:00

Could you add a bit more detail about the session host’s current state? Without that, I can’t identify the exact root cause from the current information. For example, whether it shows as Available in the host pool, how the recent AVD agent and BootLoader logs look, and if domain/DNS connectivity stayed stable after the MC→AX migration.
Allan Solomon Mejia 3,840 Reputation points

2026-07-26T17:50:09.3066667+00:00

Thanks, Kagiyama. I agree that more information is needed to identify the exact root cause.

Hello @Vince Dies could you confirm the following?

Is the session host showing Available or Unavailable in the AVD host pool?

What is the current registration state of the session host?

After the MC→AX migration, were the Azure Virtual Desktop Agent and Boot Loader services running without errors?

Are there any errors in the RDAgentBootLoader, RDAgent, or Windows Event Viewer logs?

Has domain/DNS connectivity remained healthy (for example, successful name resolution and communication with the domain controllers)?

Since the VM is accessible through Failover Cluster Manager, the issue appears more likely to be related to AVD registration or connectivity rather than the migration itself. These details should help narrow down the root cause.

Answer 1

Hi Vince,

Since you can connect to the session host through Failover Cluster Manager but not via RDP or the AVD client, this suggests the VM is running and the issue is likely related to AVD registration, networking, or RDP connectivity rather than the Azure Local migration itself.

I'd recommend checking:

Whether the session host is registered and showing "Available" in the AVD host pool.

That the Azure Virtual Desktop Agent and Boot Loader are installed and running correctly.

Network connectivity to the domain, Azure Virtual Desktop service endpoints, and required outbound ports.

Windows Firewall and any NSG rules that could be blocking RDP (TCP 3389) or AVD traffic.

Event Viewer logs under WVD-Agent, RDAgentBootLoader, and RDInfraAgent for registration or connectivity errors.

If the session host isn't registering successfully, sharing the AVD agent logs or the session host status from the host pool would help narrow down the root cause.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.