Skip to main content
Understanding the Nearest Connection Point Feature
Reisbel Machado avatar
Written by Reisbel Machado
Updated over 3 years ago

In a CAS deployment, itopia offers the Nearest Connection Point feature that can automatically configure a user to connect to the optimal Google Cloud (GCP) region that is hosting their Collection Pool. When you a create a Collection Pool across more than one GCP region, the Cloud VDI Portal (portal.cloudvdi.net) will automatically configure a user's RDP configuration file with the RD Gateway and RD Broker that is geographically closest to their current location.

How It Works

When a user navigates to the Cloud VDI Portal, the portal detects their public IP address. The portal determines the user's approximate location using IP geolocation, a database that provides a physical location for public IP addresses; the location is stored as a longitude/latitude coordinate. When the user logs in, the portal performs the following tasks:

  • Determines the Collection Pools to which the user is assigned

  • If the Collection Pool is deployed in multiple GCP regions, the portal will retrieve the longitude/latitude coordinates of each GCP region's datacenter

  • The portal compares the user's physical coordinates with the coordinates of each GCP region to determine which region is physically nearest to the user.

  • If the nearest region is marked as Active in the Collection Pool, that region is set as the primary region for the session, and the user's custom RDP file is populated with the RD Gateway and RD Connection Broker addresses for that region. If the region is marked as Inactive (for example, due to planned maintenance or a GCP issue in the region), the portal determines the next-nearest region that is active and populates the user's custom RDP file with the RD Gateway and RD Connection Broker addresses for that region instead.

  • When the user clicks Connect, the RDP file is pre-configured to connect to the recommended region

The process takes only a few moments and requires no configuration. If the user's Collection Pool is deployed to a single GCP region, the connection information for that region is used automatically regardless of geographical proximity.

If the user's Collection Pool is deployed to multiple regions, users can select an alternate region to connect to by clicking the dropdown menu on their desired Collection Pool:

Example Scenarios

Scenario 1 - Basic Functionality

In this example, consider the following scenario:

  • The RD Collection Pool is deployed in two GCP regions - us-west1 ( Oregon) and us-east1 (South Carolina). Both regions are marked as "Active" in the Collection Pool settings

  • The user, Laura, is located in Atlanta, GA

When Laura navigates to the Cloud VDI Portal and enters her username, the portal detects that her public IP is mapped to a location in the metro Atlanta area (the precision of the mapping is generally within 10-15 miles, depending on the ISP). The longitude/latitude coordinates are estimated for her IP address.

The portal retrieves the information about Laura's CAS Deployment and determines that both regions in her RD Collection Pool are marked active. The portal compares the geographical coordinates of each datacenter with Laura's coordinates and determines that the us-east1 region is the closer location.

The portal generates an RDP file for Laura using the RD Gateway and RD Connection Broker addresses in the us-east1 region, and presents the file for download.

Scenario 2 - Inactive Region Routing

In this example, consider the following scenario:

  • The Collection Pool is deployed in two GCP regions - us-west1 ( Oregon) and us-east1 (South Carolina). Due to a network outage in the us-east1 GCP datacenter, an administrator has marked the us-east1 region as "Inactive" in their Collection Pool via the itopia CAS portal

  • The user, Laura, is located in Atlanta, GA

Laura had previously used Cloud VDI Portal to configure her RDP client to connect to her RD Collection Pool in the us-east1 region. When she tries to connect today, the connection is unsuccessful. Laura navigates to the Cloud VDI Portal (portal.cloudvdi.net) to generate a new configuration file.

As before, the portal detects her public IP address and maps it to a coordinate in the metro Atlanta area. However, when the portal enumerates the regions in her Collection Pool, the us-east1 region has been marked Inactive and is thus excluded from the list of regions. Thus, the next-nearest active region is the us-west1 region, so it is selected as the current region for Laura.

The portal generates an RDP file for Laura using the RD Gateway and RD Connection Broker addresses in the us-west1 region, and presents the file for download. Laura's RDP client uses the configuration file to connect to us-west1 and she resumes working as normal.

After the maintenance has completed, the administrator marks the us-east1 region as "Active" and sends an email to end-users and instructs them to download a new configuration file. Laura again navigates to the Cloud VDI Portal and downloads a new configuration file. However, because the us-east1 region is active, the portal determines this to be the nearest location and generates the configuration file with the connection information for this region. Laura's RDP client uses the configuration file to connect to us-east1 and she resumes working as normal.

Scenario 3 - User Travel and Relocation

In this example, consider the following scenario:

  • The Collection Pool is deployed in two GCP regions - us-west1 ( Oregon) and us-east1 (South Carolina). Both regions are marked "Active" in the Collection Pool settings

  • The user, Laura, has relocated from Atlanta to Vancouver, BC

Similar to the previous scenario, Laura navigates to the Cloud VDI Portal to generate a new configuration file. The portal detects her public IP address and maps it to a coordinate in the Vancouver area. The portal then enumerates the active regions in her Collection Pool; because both regions are marked as "Active," the portal compares Laura's coordinates with the coordinates of each region's datacenter and determines that us-west1 is the nearest region, so it is selected as the current region for Laura.

The portal generates an RDP file for Laura using the RD Gateway and RD Connection Broker addresses in the us-west1 region, and presents the file for download. Laura's RDP client uses the configuration file to connect to us-west1 and she resumes working as normal.

Limitations of the Nearest Connection Point Feature

The Nearest Connection Point feature is a simple way to provide users with the best remote computing experience by helping to minimize network latency due to geographical distance. However, it is important to consider the following:

  • In a multi-region Collection Pool, each region is configured as a separate RDS Collection. When a Deployment is configured to use User Profile Disks (UPDs) for managing user profile data and documents, a user's UPD is constrained to a single RDS Collection; that is, if a user logs in to two different RDS Collections, they will have a different UPD for each Collection. This affects the portability of the user's profile data and documents. If a user needs access to their profile data and documents across multiple regions, it is recommended to implement an alternative solution to UPD, such as roaming profiles and folder redirection or a third-party solution such as Liquidware's ProfileUnity.

  • Nearest Connection Point relies on the end-user's public IP address and a public IP geomapping database; while the results are generally very accurate, there is a small chance that the user's location may be mismapped. This is sometimes caused by inefficient routing by the user's ISP, either because of misconfiguration or a temporary rerouting due to an issue on their network. If this occurs and a user experiences high latency, they can try generating a new RDP file from myrdp.download or an administrator can manually edit their RDP file to direct them to the correct region.

  • The Nearest Connection Point feature only applies to RDS-based Collection Pools. Windows 10-based Collection Pools can only be deployed to a single GCP region; therefore, the user is always presented with the connection information for the same region.

Did this answer your question?