SOLVED

Session Host showing unavailable in host pool or new created session hot is not showing in host pool

Copper Contributor

I Have created a new host pool and added a new session host in the host pool. session host is created but it is not showing in host pool.

2 Replies
best response confirmed by pksony88 (Copper Contributor)
Solution

• Solution 1: Verify URL Accessibility
• Access the Session Host via RDP:
o Take the Remote Desktop Protocol (RDP) connection to the created session host.
• Check URL Accessibility:
o Open Command Prompt (CMD) with administrator privileges.
o Navigate to the directory: C:\Program Files\Microsoft RDInfra\RDAgent_1.0.8431.2300.
o Run the command: .\WVDAgentUrlTool.exe.
• Verify Endpoint Access:
o Follow the guidelines provided by Microsoft: Check access to required FQDNs and endpoints for Azure Virtual Desktop.
o If the URL is not accessible, ensure it is allowed through your network or firewall settings.
• Solution 2: Re-register the Session Host in the Host Pool
• Access the Session Host via RDP:
o Take the RDP of the created session host or the problematic server with administrative privileges.
• Download Necessary Agents:
o Download the required agents from the following links:
 Azure Virtual Desktop Agent
 Azure Virtual Desktop Agent Bootloader
• Unblock Downloaded Files:
o For each downloaded file (agent and bootloader), unblock them:
 Right-click on the file, select Properties, click Unblock, and then select OK.
• Generate a New Registration Key:
o Sign in to the Azure portal.
o Search for "Azure Virtual Desktop" and select the corresponding service.
o Navigate to Host pools and select the name of the host pool containing your session host VM.
o In the Overview blade, select Registration key to generate a new key.
• Install the Bootloader:
o Run the bootloader installer on the session host.
• Restart the Session Host VM:
o Restart the virtual machine to complete the re-registration process.
• By following these steps, you should be able to resolve the common issues associated with Azure Virtual Desktop session hosts. If problems persist, further investigation into network configurations or additional Azure support may be required.
1 best response

Accepted Solutions
best response confirmed by pksony88 (Copper Contributor)
Solution

• Solution 1: Verify URL Accessibility
• Access the Session Host via RDP:
o Take the Remote Desktop Protocol (RDP) connection to the created session host.
• Check URL Accessibility:
o Open Command Prompt (CMD) with administrator privileges.
o Navigate to the directory: C:\Program Files\Microsoft RDInfra\RDAgent_1.0.8431.2300.
o Run the command: .\WVDAgentUrlTool.exe.
• Verify Endpoint Access:
o Follow the guidelines provided by Microsoft: Check access to required FQDNs and endpoints for Azure Virtual Desktop.
o If the URL is not accessible, ensure it is allowed through your network or firewall settings.
• Solution 2: Re-register the Session Host in the Host Pool
• Access the Session Host via RDP:
o Take the RDP of the created session host or the problematic server with administrative privileges.
• Download Necessary Agents:
o Download the required agents from the following links:
 Azure Virtual Desktop Agent
 Azure Virtual Desktop Agent Bootloader
• Unblock Downloaded Files:
o For each downloaded file (agent and bootloader), unblock them:
 Right-click on the file, select Properties, click Unblock, and then select OK.
• Generate a New Registration Key:
o Sign in to the Azure portal.
o Search for "Azure Virtual Desktop" and select the corresponding service.
o Navigate to Host pools and select the name of the host pool containing your session host VM.
o In the Overview blade, select Registration key to generate a new key.
• Install the Bootloader:
o Run the bootloader installer on the session host.
• Restart the Session Host VM:
o Restart the virtual machine to complete the re-registration process.
• By following these steps, you should be able to resolve the common issues associated with Azure Virtual Desktop session hosts. If problems persist, further investigation into network configurations or additional Azure support may be required.

View solution in original post