Gateway Clusters (December 17, 2019)

Robert Plamondon -

1. Introduction

Workspot now supports gateway clusters, a group of identically configured Internet authenticating gateways providing secure access to your Workspot desktop and application pools. Each gateway in a cluster is a virtual machine (VM).

This article refers specifically to Workspot’s RD gateway clusters introduced in Workspot Control R11.0 and running in the Microsoft Azure cloud.

Note: This feature is not enabled by default. Contact Workspot if you are interested in gateway clustering.

1.1. What is a Gateway Cluster?

The gateways in a cluster are created and managed as a unit, keeping their configuration in sync.


Network block diagram, showing a Gateway Cluster at the boundary between your Workspot desktops and the Internet.

1.2. How Gateway Clusters Work

 From the point of view of Workspot Control and your IT administrators, gateway clusters act as a unit. From the point of view of the Workspot Client, each gateway is independent. For every Workspot desktop or application pool, Workspot Control sends the Client a list of gateways that can be used to reach the pool.

1.3. How the Workspot Client Chooses a Gateway

Whenever the Client needs to open a connection to a pool, it selects a gateway from the list at random. If the connection fails, it picks another gateway at random. This provides both fault-tolerance and capacity scaling.

This mechanism works both for individually provisioned gateways and gateway clusters. Gateway clusters provide a way of keeping the gateway configurations in sync and are the recommended solution.

Gateway clusters can be created and brought online by the Workspot customer, where the older, non-clustered gateways cannot be managed except by Workspot.

Clustering simplifies the deployment of such gateways by grouping them and making more of their management accessible to your own organization’s IT administrators.

2. Gateway Cluster Navigation

gateway-clusters-main.pngThe main gateway cluster page: “Setup > Gateways.”

Gateway clusters are controlled on the “Setup > Gateways” page. If you do not see a “Gateways” tab under “Setup,” the gateway cluster feature has not been enabled on your account.

Navigation includes two sections: “Gateway Clusters” and “Gateway Status”

2.1. “Gateway Clusters” Section

The “Gateway Clusters” section has information and controls for the gateway cluster as a whole, including:

  • The “Create Gateway Cluster” button.
  • A table listing existing gateway clusters, including:
    • The Azure Region hosting the cluster.
    • Whether the cluster is unavailable, available (one active gateway), or highly available (more than one active gateway).
    • Cluster status: (Provisioning, Preview, Published, and Deleted). Only clusters that with Preview or Published status are used by the Workspot Client.
    • Actions menu for each cluster, allowing you to delete, edit, or publish the cluster.


Gateway Cluster Status



The cluster is being created.


The cluster has been created and is ready for any manual configuration.


The cluster is configured and available to Workspot Clients.


The cluster has been discarded.

Gateway cluster status.

2.2. “Gateways” Section

Each gateway is a VM. The “Gateways” section lists the individual gateways in the selected cluster , including:

  • The name of the gateway. Clicking on the name will show more details (shown below).
  • The public URL of the gateway.
  • The mode of the gateway. Unlike the status, the mode is (mostly) determined by the administrator.
  • The current status of the gateway (Ready, Rebooting, etc.)
  • An Actions menu for the gateway, allowing you to delete, enable, or reboot the gateway, or put it into maintenance mode.

Gateway Mode



The gateway is being created.


The gateway is online (on the private network)  but is not yet ready for user traffic (over the public Internet).


The gateway is ready for user traffic.


The gateway will reject new connections but existing connections continue.

List of gateway modes.

Gateway Status



The gateway VM is being created.


The gateway is online but is not yet ready for user traffic.


The gateway is running configuration tasks.


The gateway is ready for user traffic.


The gateway detected a problem and is not available for user traffic.


The gateway is restarting.

List of gateway statuses.

2.3. “Gateway Details” Page


Gateway details page.

When you click on the name of an individual gateway, you are taken to the gateway details page. In a gateway that is not fully configured, the “Gateway Properties” section of the page is the most important. This shows IP, DNS, geographic, URI, and certificate information about the gateway, plus the OS version of the gateway, the Workspot Gateway Agent version, and a list of the desktop pools and RD apps that use this gateway.

Two other sections, “Operational Details” and “Performance,” are of interest once the gateway is configured.

3. Creating a Gateway Cluster


“Setup > Gateways > Create Gateway Cluster > New Gateway Cluster” page.

  1. Have Workspot enable the Gateway Clustering feature, which is not enabled by default.

  2. Sign into Workspot Control as an Administrative user. Create the cluster via “Setup > Gateways > Create Gateway Cluster. ” The “New Gateway Cluster” page appears.

  3. Fill in the fields as shown below. Note: Fill in the form from top to bottom, since some fields may change according to the selections made so far.

    • Cloud. Select one of the Clouds defined for your account. Usually you will have only one Cloud.

    • Region. Your Cloud has one or more Azure regions and virtual networks. Select the Region/virtual network combination the Workspot pools that will use this gateway cluster. Virtual networks are associated with desktop templates. To verify that you’re using the right virtual network for an existing pool, expand the listing of the templates used by the pool (at “Setup > Cloud > cloudname > templatename”).

    • Cluster Name. This is an arbitrary string that identifies the cluster in listings, reports, and messages.

    • Instances in Cluster. The number of Gateways to create for the cluster. The valid range is 1-5. Cluster VMs can be deleted later, reducing the size of the cluster, and new gateways can be added.

    • VM Name Prefix. Individual gateways are named “vmnameprefix-region-gwnn, where vmnameprefix is the string you specify, region is the abbreviation for the Azure region the gateway resides in, and nn is a sequence number. The VM Name Prefix must consist of character that are valid in an Azure hostname.

    • Override Public Domain. Since the user-facing interface of the gateway is on the public Internet, it needs to be accessible through a valid DNS mapping. By default, the gateways will use one of Workspot’s DNS domains, such as This allows Workspot to manage the public DNS records and install a valid certificate automatically. If you wish to use your own domain and certificate, check the box and enter the domain name you wish to use. This will require that you update your own DNS records manually and install your own certificate on each gateway VM.

    • Description. A note seen by other administrators.

    • Authentication Type. One of Active Directory (AD), Azure Active Directory (Azure AD), or Network Policy and Access Service (NPS). NPS is beyond the scope of this document. Choose AD or Azure AD to match the settings in “Setup > Configuration > Registration and Authentication > Directory Services > Azure AD Authentication.” If it says “Enabled,” select “Azure Active Directory” for “Authentication Type.” Otherwise, choose “Active Directory.” Note: Additional authentication configuration will pop up after you hit “Create” at the bottom of the page.

    • Connection Authorization Policy > General Policy. This specifies a Gateway Policy. Gateway policies are filters on Workspot security policies that can optionally make the policies stricter.

      • Most customers use the “Default Gateway Policy,” which leaves security policies untouched.
      • You can change the gateway policy changed later.
  1. Review your entries, then click “Create.”
  2. Go to Join the Domain (Active Directory Clusters) if you selected Active Directory authentication.
  3. Go to NPS Setup (NPS Clusters Only) if you selected NPS authentication.
  4. Go to Create the Local Admin Account.
  5. Go to Add a Gateway Certificate if you selected “Override Public Domain.”
  6. Go to Register Gateways on DNS.
  7. Publish the Cluster with “Setup > Gateways > gatewayname > Actions > Publish.”
  8. Go to Testing the Cluster.


3.1. Join the Domain (Active Directory Clusters)


Joining an AD gateway to your domain.

Note: For Azure Active Directory, skip to Create the Local Admin Account. Azure Active Directory gateways don’t need to join a domain.

When used with Active Directory, the gateway cluster  must be joined to your domain. To join the cluster to the domain, you will need:

  • The name of your domain.
  • The destination OU (the same OU that you use for the Workspot pools serviced by the cluster).
  • Domain Admin credentials. These are not saved, but are used once to authorize the gateway cluster to join the domain.

Fill in the “Domain Join” form and press “OK.”

3.2. NPS Setup (NPS Clusters Only) (TBD)


3.3. Create the Local Admin Account


Each gateway cluster has a local admin account.

  1. You’ll be asked to create a local admin account for the cluster. These credentials will be the same for all gateways in the cluster and allow you to sign into the gateway VM as an admin (so use robust passwords).
  2. Assign an appropriate username and password for the gateway cluster and hit “OK.”
  3. You will be taken back to the “Setup > Gateways” page, where you can monitor the provisioning progress.

cluster-create-example-aad-3.pngDisplay after the cluster is created but before the gateways are provisioned.

  1. Click your new gateway cluster to ensure that its details are shown in the bottom table on the page.
    • The cluster status will start with “Provisioning” and end with “Preview.” The individual gateways will start with “Not Started” and end with “Online.”
    • In the Preview state, the cluster is already available to end-users, just as it is in the Published state. Whether user traffic actually passes through it is controlled by whether the cluster is listed in any pool definitions. Three management actions are available for the cluster as a whole: “Delete,” “Edit,” and “Publish.”
      • “Delete” deletes the cluster.
      • “Edit” allows you to change cluster parameters. Currently, only the Gateway Policy can be changed.
      • “Publish” marks the cluster as production-ready but this is just a notation: it is identical to Preview otherwise.

3.4. Add a Gateway Certificate

Note: If you use a Workspot domain for your gateway cluster, you can skip to section 3.5, Register Gateways on DNS.

Before the gateway cluster using your own domain can be published, it must have a valid gateway certificate for your organization.

If you try to publish the cluster without installing a certificate first, you’ll get an error message saying that publication failed.

The individual gateways will be marked “Error” or “Failed.” Clicking on their status will pop up a balloon giving the failure reason.


If there is no RD Gateway Certificate, this will be shown under the gateway status.

Certificates are installed individually on the gateway VMs using Microsoft RD Gateway Manager. To do this, you log onto each gateway VM using the local administrator account (set earlier in the procedure) or, for domain-joined gateways, a domain admin account.

3.4.1. To set a Gateway Certificate

  1. Acquire a suitable SSL certificate for an RD Gateway in the configured domain. The certificate properties should be as follows:
    • It should cover the gateway’s public URL and the private resources accessed through the gateway.
    • It should be a wildcard certificate.
    • It should use an authority known to all Client devices.
    • It should be saved in .PFX format.
  2. Perform the following steps for each gateway VM in the cluster:
  3. Because the gateway’s public IP is not accessible at this point, you need to sign into any convenient jump server with access to the same virtual network as the gateway VM. The purpose of this is to give you a platform from which to sign into the gateway.
    • For example, use the Workspot Client to sign into an existing Workspot desktop that is accessed by a gateway other than the cluster you just created.
    • Using Microsoft Remote Desktop Client, sign into the gateway VM as the local administrator you set up in a prior step.
    • You will see a certificate warning from the gateway VM. This is normal. Accept the certificate and continue.
  4. Copy your SSL certificate to the gateway VM by the method of your choice.
    • For example, open Notepad on the gateway VM, paste the certificate text into it, and save.
  5. On the gateway VM, Launch Microsoft RD Gateway Manager and select the local gateway in the left-hand pane. RD Gateway Manager will report that the Gateway is not fully configured and needs a certificate:


RD Gateway Manager before certificate installation.

  1. Right-click the hostname and select “Properties.” The properties sheet appears.
  2. On the “Properties” sheet, click the “SSL Certificates” tab, select “Import a certificate,” and click “Browse and Import Certificate...”


SSL Certificate tab on RD Gateway Manager.

  1. Browse to select the file with the certificate. You will be prompted for the certificate’s private key password. Enter this and press “OK.”


Entering the certificate’s private key password.

  1. Press “OK” twice more to complete the certificate installation.


Completing certificate installation.

  1. In Workspot Control, reboot the gateway from the “Actions” menu for the individual gateway.


Rebooting a gateway after installing the certificate.

  1. Repeat for the other gateways in the cluster.
  2. Once the gateways reboot, Workspot Control should show the status of the cluster as a whole as “Highly Available” if there are two or more VMs, or “Available” if there is only one.


Availability status.

3.5. Register Gateways on DNS

Each gateway must have a DNS entry that resolves to its public IP address, to allow Clients to connect to it.

3.5.1. Using Workspot-Provided DNS

If you are using a Workspot domain such as, this must be set up by Workspot (so contact Workspot for this).

In your request, include:

  1. Screen shots of the details page for each gateway in the cluster.
  2. The Public URI of each gateway (click the “copy” icon next to the Public URI and paste into the request).
  3. The DNS Name of each gateway (click the “copy” icon next to the DNS Name and paste into the request).


Important fields for DNS registration.

3.5.2. Using Your own DNS

If you have specified your own domain, the site name given in the “Public URI” field on the Gateway Details page needs to be added to your public DNS server.

  • The Public URI should be a CNAME record pointing to the DNS Name of the gateway.
  • Repeat for each gateway in the cluster.

3.5.3. Testing DNS Registration

An nslookup on the hostname portion of every Public URI should be performed to test each DNS record in the cluster. The nslookup should return the Public IP address of its gateway.

The nslookup should use a public DNS service such as or to avoid the excessively slow update times and other peculiarities of some DNS resolvers.

If the DNS entry is correct, the nslookup will return the Public Name, DNS Name, and Public IP, as shown in this example:



Non-authoritative answer:


If the DNS entry is not correct, the lookup will not fail due to matching a wildcard record, but the DNS Name Public IP will be obviously incorrect and the correct-looking alias will be subtly wrong:



Non-authoritative answer:



4. Testing the Cluster


  1. In Workspot Control, Create or edit a desktop pool and assign cluster as its gateway.
  2. If the pool is newly created, assign desktops in this pool to a group by editing the group properties, or to individual users by editing the user properties.
  3. Sign in as one of the users using a cluster-aware Workspot Client such as the Workspot Windows Client 3.5.0 (or higher) and launch a desktop from the pool. This should work.
  4. Repeat with other users or by repeatedly closing the desktop and reopening it with the same user. The gateway VMs should be chosen at random. Repeat until you have seen successful sessions pass through every gateway VM in the cluster.

    Note: The Gateways page is updated after a delay. A client may consume one connection (TCP) or two (TCP and UDP).


The cluster should show connected Clients and highly available status.

5. Gateway Policies


Gateway Policies.

Gateway policies allow you to use more restrictive permissions for connections coming in through an RD Gateway (and hence presumably the Internet) than users in a more controlled environment, such as your premises.

Like other Workspot policies, gateway policies are created on the “Policies > Add a New Policy” page and edited on the “Policies > policyname > Edit Policy” page.

Gateway policies override some of the utility rules for the users’ security policies. Security policies are group-dependent, but gateway policies are path-dependent. Each gateway cluster can have its own gateway policy, if desired.

Gateway policies can only place restrictions on end-users. They cannot grant permissions that end-users did not already have. If a feature is disabled in the gateway policy, it is disabled for all the end-users using the gateway, regardless of whether it is enabled in their security policy. If a feature is not disabled in the gateway policy, it is enabled for end-users only if it is also enabled in their security policy.

A gateway policy allows you to disable functions in the Workspot desktops and apps, as follows:

  • Disable printing: Workspot desktops/apps will not print to Client-side printers.
  • Disable copy and paste: Workspot desktops/apps will not copy or paste data to the Client system.
  • Disallow local drive: Data cannot be transferred from Workspot desktops/apps to Client-side drives or vice versa.
  • Disable port redirection: Ports on the Workspot desktop/app cannot be redirected to the Client system. (Typical uses are for access to LPT: or COM: ports on the local system.)
  • Disable plug-and-play: Plug-and-play devices cannot be redirected to the Client system. “Plug-and-play” has its usual Remote Desktop definition.



Have more questions? Submit a request


Powered by Zendesk