Wednesday, 24 July 2024

Network connections in Quick Deploy

 

Network connections in Quick Deploy

This article provides details about how to create network connections to your corporate resources when using a Citrix Managed Azure subscription.

When using your own customer-managed Azure subscription, there is no need to create a network connection.

When creating a Quick Deploy catalog, you indicate if and how users access locations and resources on their corporate on-premises network from their Citrix desktops and apps. When using a connection, you must create the connection before creating the catalog.

When using a Citrix Managed Azure subscription, the choices are:

You cannot change a catalog’s connection type after the catalog is created.

Requirements for all network connections

  • When creating a connection, you must have valid DNS server entries.
  • When using Secure DNS or a third-party DNS provider, you must add the address range that is allocated for use by Citrix DaaS (formerly Citrix Virtual Apps and Desktops service) to the DNS provider’s IP addresses on the allow list. That address range is specified when you create a connection.
  • All service resources that use the connection (domain-joined machines) must be able to reach your Network Time Protocol (NTP) server, to ensure time synchronization.

No connectivity

When a catalog is configured with No connectivity, users cannot access resources on their on-premises or other networks. This is the only choice when creating a catalog using quick create.

No connectivity to other networks

About Azure VNet peering connections

Virtual network peering seamlessly connects two Azure virtual networks (VNets): yours and Citrix DaaS VNet. Peering also helps enable users to access files and other items from your on-premises networks.

As shown in the following graphic, you create a connection using Azure VNet peering from the Citrix Managed Azure subscription to the VNet in your company’s Azure subscription.

Deployment scenario with customer on-premises network

Here’s another illustration of VNet peering.

VNet peering diagram

Users can access their network resources (such as file servers) by joining the local domain when you create a catalog. (That is, you join the AD domain where file shares and other needed resources reside.) Your Azure subscription connects to those resources (in the graphics, using a VPN or Azure ExpressRoute). When creating the catalog, you provide the domain, OU, and account credentials.

Azure VNet peering custom routes

Custom, or user-defined, routes override Azure’s default system routes for directing traffic between virtual machines in a VNet peering, on-premises networks, and the Internet. You might use custom routes if there are networks that Citrix DaaS resources are expected to access but aren’t directly connected through VNet peering. For example, you might create a custom route that forces traffic through a network appliance to the Internet or to an on-premises network subnet.

To use custom routes:

  • You must have an existing Azure virtual network gateway or a network appliance such as Citrix SD-WAN in your Citrix DaaS environment.
  • When you add custom routes, you must update your company’s route tables with Citrix DaaS’s destination VNet information to ensure end-to-end connectivity.
  • Custom routes are displayed in Citrix DaaS in the order in which they are entered. This display order does not affect the order in which Azure selects routes.

Before using custom routes, review the Microsoft article Virtual network traffic routing to learn about using custom routes, next hop types, and how Azure selects routes for outbound traffic.

You can add custom routes when you create an Azure VNet peering connection or to existing ones in your Citrix DaaS environment. When you’re ready to use custom routes with your VNet peering, refer to the following sections in this article:

Azure VNet peering requirements and preparation

  • Credentials for an Azure subscription owner. This must be an Azure Active Directory account. This service does not support other account types, such as live.com or external Azure AD accounts (in a different tenant).
  • An Azure subscription, resource group, and virtual network (VNet).
  • Set up the Azure network routes so that VDAs in the Citrix Managed Azure subscription can communicate with your network locations.
  • Open Azure network security groups from your VNet to the specified IP range.
  • Active Directory: For domain-joined scenarios, we recommend that you have some form of Active Directory services running in the peered VNet. This takes advantage of the low latency characteristics of the Azure VNet peering technology.

    For example, the configuration might include Azure Active Directory Domain Services (AADDS), a domain controller VM in the VNet, or Azure AD Connect to your on-premises Active Directory.

    After you enable AADDS, you cannot move your managed domain to a different VNet without deleting the managed domain. So, it’s important to select the correct VNet to enable your managed domain. Before proceeding, review the Microsoft article Networking considerations for Azure AD Domain Services.

  • VNet IP range: When creating the connection, you must provide an available CIDR address space (IP address and network prefix) that is unique among the network resources and the Azure VNets being connected. This is the IP range assigned to the VMs within Citrix DaaS’s peered VNet.

    Ensure that you specify an IP range that does not overlap any addresses that you use in your Azure and on-premises networks.

    • For example if your Azure VNet has an address space of 10.0.0.0 /16, create the VNet peering connection in Citrix DaaS as something such as 192.168.0.0 /24.

    • In this example, creating a peering connection with a 10.0.0.0 /24 IP range would be considered an overlapping address range.

    If addresses overlap, the VNet peering connection might not be created successfully. It also does not work correctly for site administration tasks.

To learn about VNet peering, see the following Microsoft articles.

Create an Azure VNet peering connection

  1. From Manage > Quick Deploy, expand Network Connections on the right. If you have already set up connections, they’re listed.

    List of connections

  2. Select Add Connection.
  3. Click anywhere in the Add Azure VNet Peering box.

    Add VNet peering connection

  4. Select Authenticate Azure Account.

    Authenticate your Azure subscription

  5. Citrix DaaS automatically takes you to the Azure sign-in page to authenticate your Azure subscriptions. After you sign in to Azure (with the global administrator account credentials) and accept the terms, you are returned to the connection creation details dialog.

    VNet peering connection creation fields

  6. Type a name for the Azure VNet peer.
  7. Select the Azure subscription, resource group, and the VNet to peer.
  8. Indicate whether the selected VNet uses an Azure Virtual Network Gateway. For information, see the Microsoft article Azure VPN Gateway.
  9. If you answered Yes in the previous step (the VNet uses an Azure virtual network gateway), indicate whether you want to enable virtual network gateway route propagation. When enabled, Azure automatically learns (adds) all routes through the gateway.

    You can change this setting later on the connection’s Details page. However, changing it can cause route pattern changes and VDA traffic interruptions. Also, if you disable it later, you must manually add routes to the networks that VDAs will use.

  10. Type an IP address and select a network mask. The address range to be used is displayed, plus how many addresses that the range supports. Ensure that the IP range does not overlap any addresses that you use in your Azure and on-premises networks.

    • For example, if your Azure VNet has an address space of 10.0.0.0 /16, create the VNet peering connection in Citrix DaaS as something such as 192.168.0.0 /24.
    • In this example, creating a VNet peering connection with a 10.0.0.0 /24 IP range is considered an overlapping address range.

    If addresses overlap, the VNet peering connection might not be created successfully. It also won’t work correctly for site administration tasks.

  11. Indicate whether you want to add custom routes to the VNet peering connection. If you select Yes, enter the following information:
    1. Type a friendly name for the custom route.
    2. Enter the destination IP address and network prefix. The network prefix must be between 16 and 24.
    3. Select a next hop type for where you want traffic to be routed. If you select Virtual appliance, enter the internal IP address of the appliance.

      Custom route creation fields

      For more information about next hop types, see the Custom routes section in the Microsoft article Virtual network traffic routing.

    4. To create another custom route for the connection, select Add route.
  12. Select Add VNet Peering.

After the connection is created, it is listed under Network Connections > Azure VNet Peers on the right side of the Manage > Quick Deploy dashboard. When you create a catalog, this connection is included in the available network connections list.

View Azure VNet peering connection details

VNet peering connection details

  1. From Manage > Quick Deploy, expand Network Connections on the right.
  2. Select the Azure VNet peering connection you want to display.

Details include:

  • The number of catalogs, machines, images, and bastions that use this connection.
  • The region, allocated network space, and peered VNets.
  • The routes currently configured for the VNet peering connection.

Manage custom routes for existing Azure VNet peer connections

You can add new custom routes to an existing connection or modify existing custom routes, including disabling or deleting custom routes.

IMPORTANT:

Modifying, disabling, or deleting custom routes changes the traffic flow of the connection and might disrupt any user sessions that might be active.

To add a custom route:

  1. From Manage > Quick Deploy, expand Network Connections on the right.
  2. Select the connection you want to delete.
  3. From the connection details, select Routes and then select Add Route.
  4. Enter a friendly name, the destination IP address and prefix, and the next hop type you want to use. If you select Virtual Appliance as the next hop type, enter the internal IP address of the appliance.
  5. Indicate whether you want to enable the custom route. By default, the custom route is enabled.
  6. Select Add Route.

To modify or disable a custom route:

  1. From Manage > Quick Deploy, expand Network Connections on the right.
  2. Select the connection you want to delete.
  3. From the connection details, select Routes and then locate the custom route you want to manage.
  4. From the ellipsis menu, select Edit.

    Routes tab in VNet peering details page

  5. Make any needed changes to the destination IP address and prefix or the next hop type, as needed.
  6. To enable or disable a custom route, in Enable this route?, select Yes or No.
  7. Select Save.

To delete a custom route:

  1. From Manage > Quick Deploy, expand Network Connections on the right.
  2. Select the connection you want to delete.
  3. From the connection details, select Routes and then locate the custom route you want to manage.
  4. From the ellipsis menu, select Delete.
  5. Select Deleting a route may disrupt active sessions to acknowledge the impact of deleting the custom route.
  6. Select Delete Route.

Delete an Azure VNet peering connection

Before you can delete an Azure VNet peering connection, remove any catalogs associated with it. See Delete a catalog.

  1. From Manage > Quick Deploy, expand Network Connections on the right.
  2. Select the connection you want to delete.
  3. From the connection details, select Delete Connection.

About SD-WAN connections

Citrix SD-WAN optimizes all the network connections needed by Citrix DaaS. Working in concert with the HDX technologies, Citrix SD-WAN provides quality-of-service and connection reliability for ICA and out-of-band Citrix DaaS traffic. Citrix SD-WAN supports the following network connections:

  • Multi-stream ICA connection between users and their virtual desktops
  • Internet access from the virtual desktop to websites, SaaS apps, and other cloud properties
  • Access from the virtual desktop back to on-premises resources such as Active Directory, file servers, and database servers
  • Real-time/interactive traffic carried over RTP from the media engine in the Workspace app to cloud-hosted Unified Communications services such as Microsoft Teams
  • Client-side fetching of videos from sites like YouTube and Vimeo

As shown in the following graphic, you create an SD-WAN connection from the Citrix Managed Azure subscription to your sites. During connection creation, SD-WAN VPX appliances are created in the Citrix Managed Azure subscription. From the SD-WAN perspective, that location is treated as a branch.

SD-WAN connections


Troubleshoot Cloud PC Azure Network Connection Error


Troubleshoot Cloud PC Azure Network Connection Error


In this post, let’s learn how effectively you can troubleshoot Windows 365 Cloud PC Azure network connection error. Troubleshooting network connection errors on Windows 365 Cloud PC involves a systematic approach to diagnose and resolve issues affecting connectivity.

Windows 365 provisioning failures may occur if the Desired State Configuration (DSC) extension isn’t signed and the PowerShell Execution policy is set to Allsigned in the Group Policy Object (GPO). Other potential causes of connection errors include resource issues on your Cloud PC and network configuration settings. In such cases, reviewing network configuration settings can help.

Windows 365 Cloud PC leverages Azure network connections for its operations. However, users may sometimes encounter network connection errors. The Azure network connection (ANC) periodically checks your environment to ensure all requirements are met and are in a healthy state.

If any check fails, error messages can be seen in the Microsoft Intune admin center. An Azure network connection (ANC) is an object in the Intune admin center that provides Cloud PC provisioning profiles with the required information to connect to network-based resources.

Patch My PC

ANCs are used when a Cloud PC is initially provisioned, and when Windows 365 periodically checks the connection to the on-premises infrastructure to ensure the best end-user experience.

Supported Checks for Azure Network Connection

There are two kinds of ANCs based on their join type. Both let you manage traffic and Cloud PC access to network-based resources, but they have different connectivity requirements. You will get the details of running checks in the Azure Network Connection tab.

When a Cloud PC is provisioned, the information in the ANC is used by the provisioning policy to provide the Cloud PC. It performs the following checks depending on the join type, Microsoft Entra ID or Hybrid Microsoft Entra Join.

Troubleshoot Cloud PC Azure Network Connection Error Fig.1
Troubleshoot Cloud PC Azure Network Connection Error Fig.1
  • DNS can resolve Active Directory domain: Resolve the provided Active Directory domain name.
  • Active directory domain join: A domain join using the credentials, domain, and OU provided.
  • Endpoint connectivity: Connectivity to the required URL/endpoints.
  • Microsoft Entra device sync (warning): Device ID sync is enabled on the Microsoft Entra tenant, and the computer object is being synced within 90 minutes.
  • Azure subnet IP address usage: Sufficient IP addresses are available in the provided Azure subnet.
  • Azure tenant readiness: The defined Azure subscription is enabled and ready for use. No Azure policy restrictions are blocking Windows 365 resources from being created.
  • Azure virtual network readiness: The defined vNet is in a Windows 365 supported region.
  • First party app permissions exist on Azure subscription: Sufficient permissions exist on the Azure subscription.
  • First party app permissions exist on Azure resource group: Sufficient permissions exist on the Azure resource group.
  • First party app permissions exist on Azure virtual network: Sufficient permissions exist on the Azure vNet.
  • Environment and configuration is ready: Underlying infrastructure is ready for provisioning to succeed.
  • Intune enrollment restrictions allow Windows enrollment: Verify that Intune enrollment restrictions are configured to allow Windows enrollment.
  • Localization language package readiness: Verify that the operating system and Microsoft 365 language packages are reachable. Also verify that the localization package download link is reachable.
  • UDP connection check: Network configuration allows the use of UDP direct connection (STUN).
  • Single sign-on configuration: Determine if the network is properly configured for single sign-on to Microsoft Entra hybrid joined Cloud PCs by ensuring a Kerberos Server object exists.

Cloud PC Azure Network Connection Checks Failed

In the Azure network connection tab, every ANC created displays a status that helps you determine if new Cloud PCs can be expected to provision successfully and that existing end-users have an optimal Cloud PC experience.

Adaptiva
  • Checks successful with warnings: All critical health checks passed. However, at least one non-critical check may have issues.
  • Checks failed: One or more required checks failed. An ANC can’t be used if it’s in a failed state. You’ll have to resolve the underlying issue and Retry the health checks.
Troubleshoot Cloud PC Azure Network Connection Error Fig.2
Troubleshoot Cloud PC Azure Network Connection Error Fig.2

Every failed ANC or success with a warning error state includes the technical details behind the failure. Select the View Details link for each failed check to view more information on the failure.

A required DSC script cannot be accessed or run.
During provisioning, some PowerShell DSC scripts are executed on the Cloud PC. We were unable to either download these DSC scripts or execute them. Please ensure your vNet has unrestricted access to the required endpoints, and that PowerShell is not blocked in your environment or Group Policy.
Troubleshoot Cloud PC Azure Network Connection Error Fig.3
Troubleshoot Cloud PC Azure Network Connection Error Fig.3

Possible Solutions to Fix Cloud PC Azure Network Connection Error Unable to Run DSC Script

There could be several reasons why you are unable to run a DSC script. Here are some possible solutions for resolution or validating the steps for troubleshooting:

Review the applied configuration or Group Policy on the OU where you are moving your Cloud PC to ensure the policy is not blocking. It is recommended to initiate the testing by excluding the Group policy from OUs to check your experience.

The next step would be to block Group Policy object inheritance over the OU isolated for Cloud PC provisioning. You can perform the action by opening Group policy management, Expanding the Forest and domain, right-clicking over the OU, and selecting Block Inheritance.

Ensure the VNET has access to the URLs/ports defined for Windows 365 Services allowed, You must allow traffic in your network configuration to the service URLs and ports to support provisioning and management of Cloud PCs and for remote connectivity with Cloud PCs. You can refer to more details in this article, Network Requirements for Windows 365.

Ensure the Powershell execution policy setup in your environment is not blocking or preventing the running of PowerShell scripts; it is recommended to set the execution policy to Remote Signed for Cloud PC provisioning or reset the PowerShell Execution to Unrestricted.

Azure network connection (ANC) might also fail with the error: An internal error occurred. The virtual machine deployment timed out. If the PowerShell Execution set to AllSigned, If it is, either remove the GPO or reset the PowerShell Execution to Unrestricted.

To see the effective execution policy for your PowerShell session use Get-ExecutionPolicy with no parameters. Here you can find more details on Configure PowerShell Execution Policy With Intune.

Troubleshoot Cloud PC Azure Network Connection Error Fig.4
Troubleshoot Cloud PC Azure Network Connection Error Fig.4

Windows PowerShell Desired State Configuration (DSC) depends on WinRM. If the WinRM isn’t enabled or allowed by default. You can set up the default configuration for remote management with the command winrm quickconfig.

Retry Azure Network Connection Health Check

After you have fixed the underlying issue, Retry the health check to rerun the tests. To retry the health check, you must have the Intune Administrator, Windows 365 Administrator, or Global Administrator role.

To manually trigger a full health check, in the Microsoft Intune admin center, select Devices > Windows 365 (under Provisioning) > Azure network connection > select an Azure network connection. Click on Retry.

Troubleshoot Cloud PC Azure Network Connection Error Fig.5
Troubleshoot Cloud PC Azure Network Connection Error Fig.5

The Azure network connection was successfully retried. The Connection checks were successful for some time. In the Azure network connection tab, every ANC created displays a status that helps you determine if new Cloud PCs can be expected to provision successfully and that existing end-users have an optimal Cloud PC experience.

  • Running checks: The health checks are currently running. The ANC list view automatically refreshes every five minutes. Wait for the checks to complete before attempting to assign them to a provisioning policy.
  • Checks successful: All health checks passed. The ANC is ready for use.
Troubleshoot Cloud PC Azure Network Connection Error Fig.6


Alternate Azure Network Connection for Windows 365 Cloud PC

 

Alternate Azure Network Connection for Windows 365 Cloud PC

Alternate ANCs (Azure Network Connections) are secondary or backup connections to the Microsoft Azure network used to provide redundancy and high availability for Windows 365 Cloud PC provisioning of new desktops. Alternate ANCs can be used when a primary connection fails or experiences connectivity issues, ensuring access to Windows 365 Cloud Provisioning continues for the desktops uninterrupted using the backup ANC.

Introduction

Alternate ANCs can be used when a primary region availability fails, ensuring access to Windows 365 Cloud Provisioning continues for the new desktops uninterrupted using the backup ANC. As long as the first ANC in the list is Healthy, it will always be used for provisioning Cloud PCs using this policy. If the first ANC is not healthy, the policy will use the next ANC in the list that is healthy.

My Scenario

I have an Azure VNET in the region (Australia East) and a dedicated subnet for the Windows 365 Cloud PC desktops in my environment. Now imagine a scenario if the Azure region Australia East had issues. It will directly impact the provisioning of the new Cloud PC desktops.

How will we increase HA/DR capability during Cloud PC Provisioning Issues

Create a backup VNET in different region (Asia Pacific East Asia – HK)

Go to you Azure Portal and create a new VNET in a different region of you choice (Azure Portal — Virtual Networks – Create Network)

Create a dedicated subnet for Windows 365 Cloud PC

Go into the newly created VNET – W365-Bckup-VNET01 and select Subnet and click + Subnet and create a dedicated subnet for the Windows 365 Cloud PC.

Add the additional Azure Network Connection in Intune Portal

I have a previous blog post on creating the the PowerShell – Create Azure Network Connection (ANC) for Windows 365 Cloud PC you can either use that or create one in the Microsoft Intune admin center. We are creating an Azure Network Connection that includes the following:

  • Display Name of the network – Win365-Bckup-ANC01
  • Azure Subscription Name – Azure subcription 1
  • Type – There are two types we are selecting Azure AD join – azureADJoin
  • Resource Group ID – The resource group within Azure – W365-AVD-RG01
  • Virtual Network ID – The VNET within Azure – W365-Bckup-VNET01
  • Subnet ID – The subnet for W365 within VNET – Win365-ASE-Bac-Sub01

Cloud Provisioning Policy

Go into your Cloud PC Provisioning Policy and select Edit. Under the Azure Network Connection you will be able to see the newly added ANC – Win365-Bckup-ANC01 make sure you choose that. It will automatically assign the priority as 2 and will come into effect during network outages in the region.

In the above scenario, at all times, it will use the ANC-W365-Sub01 (Priority 1) network for provisioning all Cloud PC. If there is a contention or issues with the primary ANC, then the backup Win365-Bckup-ANC01 (Priority 2) network will kick in and continue provisioning the new desktops in that region/network.