Getting Started with Azure

This document shows you how to set up a comprehensive Workspot Test Drive environment within Microsoft Azure. We have streamlined and automated the process as much as possible by using Terraform to minimize the manual customization.

For speed and simplicity, the deployment is isolated rather than integrated with your production environment. For example, it includes its own AD domain controller VM to avoid the complexity of connecting to your organization’s production domain controllers.

All the VNETs and virtual machines are created under your existing Azure subscription, so they’re under your control at all times.

High-Level Design

This simple design concept is a highly scalable foundation. In other words, this makes a good starting point that can easily be extended.

Subnets

Three Azure VNET subnets are used:

• Management Subnet. This is where the Domain Controller and Workspot Enterprise Connector are placed.

• VDI/VM Subnet. This is where the Workspot templates, desktops, and application servers are created.

• DMZ Subnet. This is where the Gateways and jump server will be.

  • The Gateways are built using Workspot Control.

  • The Jump Server provides access to the virtual machines during provisioning. It should be kept locked down to the public IP of the admin connecting to it and should always be off when not in use. The Jump Server can be deleted once Pools are created.

Sign Up for a Workspot Test Drive

This will sign you up for a free 30-day Workspot test drive including access to:

• Workspot Control to manage your deployment, including the creation of desktop pools, application pools, and RD gateways.

• Workspot Watch and Trends to monitor your deployment

• Workspot Clients for end-user access to your Workspot desktops and applications.

Procedure

1. In a browser, go to https://service.us.workspot.com/#/signup.

2. Fill in the form. Critical fields:

   • The “Corporate Email” address will be used as the administrative account for your Workspot Deployment. Domains such as “gmail.com” are not allowed.

   • Set “Company Headquarters” to your actual corporate headquarters location, not your personal location.

   • Set the “Control Deployment Location” to “European Union” if your HQ is the EU, and “United States” otherwise.

3. Press “Sign Up.”

4. Wait for the email sent to the address you provided. This may take a few minutes.

5. Click the link. You will see a second form:

1. Fill in the form. Notable fields:

   • The Company Identifier:

     • Is used by all your end-users when they use the Workspot Client for the first time.

     • Is part of the URLs you use to access Workspot Control, Watch and Trends.

     • Should be a version of your organization’s name.

     • Cannot contain punctuation or special characters except for a hyphen.

   • The password will be used along with the email address you provided in the previous form when you sign into Workspot Control.

2. Press Register.

3. You will be signed in automatically to the “Add Public Cloud” page of Workspot Control.

4. Leave this browser tab open. We will return to it soon.

Azure Prerequisites

You will need an Azure account and Administrative access to an Azure Tenant and Subscription.

Tenant-Level Permissions for Entra ID (If Used)

• To create a Subscription: Global Administrator

• Only for App Registration for SPN: Cloud Application Administrator (At least)

Subscription-Level Permissions

• RBAC Administrator: To manage access to Azure resources by assigning roles using Azure RBAC.

• Contributor: To manage resources in the Subscription.

  For information on creating a new subscription see Microsoft’s Create a subscription as a partner for a customer.

Preparing for Test Drive Installation

Install Terraform

We will use Terraform to automate the creation of the test drive network.

1. Select an appropriate machine from which to run Terraform, such as the administrator’s corporate desktop.

2. Download the Terraform file from https://developer.hashicorp.com/terraform/install

3. Extract the file at c:\Terraform. 

Configure Environment Variables

1. Go to “System Properties > Advanced > Environment Variables > User Variables.” 

2. Select “Path > Edit > New”

3. Enter the path where you have the terraform.exe copied (c:\Terraform) 

4. Open a Windows command prompt and type terraform -version.

5. This will return the version of Terraform if the environment variable was set correctly. 

Download the Terraform Script Files

1. Download this zip file:

2. Extract the files to the folder where you want the project files to be located. The folder will contain the files shown in the figure below.

PowerShell Configuration

The next step is to use PowerShell to acquire the parameters needed to connect Workspot Control to your Azure account.

1. You need to have the PowerShell AZ Module installed on your device. To install it:

   • Launch PowerShell as an Administrator

   • Run the command:

Install-Module -Name Az -Repository PSGallery -Force

2. Also, set the execution policy to Unrestricted if it isn’t already, as shown below.

3. Go to the directory into which you extracted the zip file above.

4. Open a new PowerShell prompt, this time in normal mode (not as an administrator), and navigate to the folder.

5. Run the SetEnvForTF_Azure.ps1 script.

6. This will prompt you to input your Azure Tenant ID and Subscription ID. Provide this information and click “OK.”

7. You will be prompted to sign into Azure on your web browser. Do this.

8. After the execution completes, you will see the Azure Cloud parameters for your subscription in the PowerShell window.

9. Copy these and paste them into a file for later use.

Configure Terraform variables.tf File

Customize the variables in the variables.tf file.  The variables are described below.

1. Open the variables.tf file in Notepad or Notepad++.

2. For Test Drive, most variables can be left as-is because the environment is isolated.

3. Make sure you only edit the value of “default” in the variable body.  

4. Once all the variables are set properly, save and close the variables file.

Variables

• my-publicIP is the public IP of your local Windows device, the one on which you just ran PowerShell and will soon run Terraform and Remote Desktop Connection. This is added to the Utility server (jump server) NSG rule to allow RDP access only from your PC.

• resource_group1_location is the Azure region of the deployment.

• Local_Admin_Name, Local_Admin_Password are the default username and password for the Virtual machines (Domain Controller, Enterprise Connector, and the Utility servers).

  • Note that the default values are also used in the Domain Controller PowerShell script in the AD Domain Controller section, so if you change them here, change them there, too.

Based on your requirements, you may wish to update the other variables in the variable.tf file.

Note: The “group2” definitions are not used.

Running Terraform to Deploy Azure Landing Zone

1. Open the command prompt and go to the directory with the variables.tf Terraform file.  

2. Initialize Terraform with terraform init

3. Once initialization is completed, type terraform plan -out TFPlan.txt

4. This will list the changes (Addition, Modification, and Destroy) that will be applied.

5. Once the plan is completed, type terraform apply. This will list the changes that will be applied.

6. If you are ready to proceed, answer “yes” (must be in lowercase) to “Do you want to perform these actions?” This will apply the changes.

In Case of Errors or Warnings

If you see only warnings, the installation can proceed. You can:

• Choose to fix them by hitting ENTER instead of answering yes to the question about proceeding.

• Choose to continue by answering yes to the question.

If errors are encountered during the deployment, the script will exit automatically.

• If there are errors with only one or two components, and the rest have deployed successfully, try running terraform apply again. This usually creates the remaining components.

• If this doesn’t work, try to identify and fix the errors.

  • After fixing the problems, remove the failed partial Azure deployment and run the Terraform steps again

    • See the “Destroying the Infrastructure” section below.

Summary of the Actions Performed by Terraform

• Create Resource Group MyTFResourceGroup1.

• Create VNet workspot-vnet-1.

• Create Subnets in the VNet:

  • vdi (vdi subnet)

  • DMZ (DMZ subnet)

  • mgmt subnet

• Create Default NSG rules for Enterprise Connector and Domain Controller Servers.

• Create an NSG for Utility Server (Jump Server) - Open port 3389 for the public IP of the user to allow signin via Remote Desktop.

• Create NIC for Utility and Enterprise Connector Servers.

• Create a Static Public IP for the AD Domain Controller server: 10.0.255.230 in the Management subnet.

• Create a NIC for the AD Domain Controller server with the above Static IP.

• Attach the NSG Rules to NICs.

• Create an Enterprise Connector Server in the management subnet.

• Create a Utility Server in the DMZ subnet.

• Create an AD Domain Controller server in the management subnet.

• Create a peering for the two VNets.

• Add the DNS IPs 10.0.255.230 and 8.8.8.8 to the 'DNS servers' list.

Workspot Control Configuration

To add the Azure Cloud to Workspot Control:

1. Return to the “Add Cloud” page in Workspot Control or sign into Workspot Control and go to  “Control > Setup > Add Cloud.”

2. Name. Choose a name for Control to use for your Azure Cloud. “Azure” is fine.

3. Configuration Type. Select “Microsoft Azure Commercial.”

   Subscription ID, Application Client ID, Application Key, and Tenant ID: Copy the fields you saved after running the PowerShell script, as shown in the figure below.

4. Secret Expiry Date: Optional, can be left blank.

5. Region: Select the same region listed in variables.tf

6. Click “Save.”

For additional details, see Creating a Service Principal in Azure.

AD Domain Controller Configuration

The AD server was created with the Terraform script with a default name of “zzztfwsdc01," but has not yet been configured as a Domain Controller. This is done below.

Note: Ensure that Active Directory (AD) is configured before advancing with other components such as Gateways, Enterprise Connector, or Templates.

Sign Into the AD Server via the Utility Server

We use the Utility Server as a jump server.

Find the Utility Server’s External Address

1. Sign into the Azure Console.

2. Go to the “Compute Engine > VM Instances” page and locate the “zzztfwsutl01 (Utility Server).”

3. Note its external IP or DNS address.

   • Note: If you have entered your public IP address in the Terraform variable file, your local device’s IP address will be allowed to access the utility server over RDP (3389)

Connect to the Utility Server via RDP

4. Connect to the Utility Server through mstsc (Remote Desktop Connection) from the PC with the external IP address you configured in the variables.tf file.

Connect to the AD Server

5. From the Utility Server, open mstsc and connect to the AD server at 10.0.255.230 (or whatever non-default IP you assigned to it).

Download and Run the Domain Controller PowerShell Script

6. On the AD Server, download the Domain Controller PowerShell script:

7. Open PowerShell ISE with Administrator privileges. (The script work well on ISE with Admin mode. It might fail on regular PowerShell.)

8. Run Get-ExecutionPolicy -List to ensure that the ExecutionPolicy for CurrentUser is “Unrestricted.”

   • If it isn’t, run Set-ExecutionPolicy -Scope CurrentUser Unrestricted

9. Execute the script with Install-Configure-AD.ps1 to install Active Directory Role & Features on the server and to configure the AD Forest.

10. A window will pop up and ask for a domain name.

    1. (This was not set in variables.tf, so it can be anything.)

    2. Enter the domain name, such as example.local, and click “OK”.

11. The Domain Controller is configured with the name  provided.

12. Once the execution is completed, the server is rebooted automatically 

Configure the Domain Controller in Windows

13. After reboot, log in again via RDP, this time with credentials using the new domain. Default credentials are shown below:

• Username: wsadmin@<domainname> 

• Password: Workspot@1601 

14. From the Start menu you can access “Active Directory Users & Computers” (ADUC). You will be using this quite a bit, so feel free to make a shortcut. This screenshot is the default AD view in ADUC:

Create OU’s

15. Add Organizational Units (OU) for this project. To keep it simple, create these at the root level. As per this example, right-click on the domain name (wspoc.cloud), and navigate to “New…Organizational Unit.”

16. Provide a name and click OK to create the OU. Three OUs are used for this project:

    • Virtual Desktops (Cloud PCs)

    • Workspot Servers

    • Workspot Users (optional).

Create the Workspot Service Account User

In the Domain Controller, create the Workspot service account and delegate the permissions that the Workspot desktop and server OUs need.

1. In ADUC right-click on the Workspot Users OU, select “New > User,” and step through the wizard to create the service account user.

Delegate AD permissions for Desktop Agent

The same process will be done for the Cloud PCs and Workspot Servers OU.

2. Right-click on the “Cloud PCs OU > Delegate Control” to open the Delegation wizard.

3. Click “Next” on the Intro screen and then click on “Add” to bring up the search box.

4. Locate and select the Workspot Service account you just created.

5. Click “Next,”  then select “Create a custom task to delegate.”

6. In the “Active Directory Object Type” page, make the highlighted selections.

7. Click “Next” to select the specific permissions that will need to be delegated to this service account.

8. Scroll down to select the six permissions required.          

9. AD is now configured for this Test Drive.

Configuring Enterprise Connector

A server has already been created for Workspot Enterprise Connector (“zzztfwsec01”), but Enterprise Connector has not been installed.

1. Sign into the Utility Server.

2. From there, sign into “zzztfwsec01“ via Remote Desktop, using the default credentials below (or whatever you changed them to in the configuration files):

   • Username: wsadmin

   • Password: Workspot@1601 

3. Follow the instructions in Create Workspot Enterprise Connector.

Configure the AD Domain in Workspot Control

Workspot Control needs to know the domain we are using. Control will add new Workspot Client users automatically if they sign in with valid credentials on the AD domain you configured above.

The Control Administrator can also sign in with the credentials you provided when signing up.

You can declare multiple email domains.

1. Sign into Workspot Control.

2. Go to “Setup > Configuration > Authentication and Registration > Email Domain List.”

3. Enter the domain name of your AD Directory Controller.

   • Select “Self-Registration".”

   • Select “Use AD.”

4. Enter the domain name of your Control Administrator account.

   • Deselect “Self-Registration” (you are already registered).

   • Select “Default User Group.”

5. At the bottom of the page, click “Save.”

9. Create a Managed Gateway

Create an RD Gateway Cluster of one or more Gateways. These Gateways allows Workspot Client users to reach their Workspot Desktops and Apps. Follow the instructions in Creating a Gateway Cluster.

Notes:

• Deploy your Gateways in the DMZ subnet.

• Once the Gateways are created, remember to “Publish” the cluster and “Enable” the gateways to allow end-user connections.

Configure a Workspot Template

To build a Template from the Azure Marketplace image, follow the instructions in Creating Workspot Templates in Azure

Note: Make sure to select the network (VDI/VM Subnet) that ends with “VM” to deploy the pool Virtual Desktops.

Prerequisites Before Accessing Desktops

Adding Users or Groups to the Remote Desktop Group of VDI through GPO

Self-registered users need to belong to the Windows “Remote Desktop Users” Group. There are two ways in which we can achieve this:

Add Users or Groups through Group Policy (Recommended)

For a Test Drive deployment (only):

1. Create a few users in AD.

2. Create a new GPO in AD

3. Go to “Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups”

4. Within this setting, right-click in the empty white area and select “All Tasks” > “Add”.

5. Select “Update” in the “Action:” drop-down.

6. Select “Remote Desktop Users (built-in)” from the “Group name:” field.

7. Under the “Members:” section click the “Add…” button.

8. Add “Domain Users” to the “Name:” field.

9. Select “Add to this group” from the “Action:” field.

10. That will add Domain Users to the Remote Desktop Users group for any computer you apply this policy to.

Add Users or Groups during the Template creation process.

For the Test Drive setup, we are using a non-customized Azure template. Thus, we did not cover the Workspot Agent configuration options available for a customized template.

For a more flexible approach, see The Workspot Desktop Agent.

Configure the Named User Group

With the Enterprise licensing model, there are only two license types:

• A “named” license, which entitles the user to persistent desktops, non-persistent desktops, and applications.

• A “concurrent” license, which entitles the user to non-persistent desktops and applications only.

By default, Workspot users receive a concurrent license, which entitles them to any number of Workspot non-persistent desktops and applications. Only users who are present in a particular AD group receive named licenses to access persistent desktops, Control calls this the “Named License Group.” The Named License Group is an AD Security Group.

See Per-User Licensing Model (Enterprise and Enterprise Plus).

Configuring The Named User Group on the Domain Controller

1. On your Domain Controller, create a new AD Security Group on your Domain Controller. For example, “WS_NAMED_USERS.”

   • This group must have a Global scope.

2. Assign users whom you wish to receive persistent desktops to this group.

3. In Workspot Controll, Assign this group to the “Named License Group” in Control on the “Resources > Groups > Configure Named License Group” page.

   • Warning: Once set, you cannot change the Named License Group.

   • Warning: DO NOT use the default “Domain Users” group.

Note: AD security group is to assign a desktop to the user; this group is DIFFERENT than the one being used for the “Named License Group”. To create a separate AD Security Group on your Domain Controller. For example, “WS_NAMED_USERS” to manage persistent desktops licenses.

Creating a Desktop Pool

Follow the instructions in Creating Workspot Cloud Desktop Pool on Azure.

Note:  Make sure to select the network (VDI/VM Subnet) that ends with “VM.”

Shut Down the Utility Server

For security and to reduce costs, shut down the Utility Server from the Azure Portal. It is used only as a jump server, and we rarely need it.

Test Drive Deployment is Complete

Using the Workspot Client

The next step is to install a Workspot Client (Workspot Windows Client, Workspot Web Client, etc.) and register it as the Control Admin user or one of the AD users you created above. If you do not see any Workspot resources in the Client dashboard, assign the desktop pool manually by clicking on “Users > username > Entitlements > Cloud Desktops.”

Note: Persistent desktop pools require that the user be in the “Named Users” AD group AND have a desktop entitlement, which is either assigned manually as described above or automatically by group membership. See Active Directory (AD) Groups.

Adding More Desktop and Application Pools

Destroying the Infrastructure

At the end of your Test Drive, or to use a different configuration, we can use Terraform to remove the deployment.

NOTE: The “Terraform Destroy” command will only delete what was created by Terraform. Resources created outside Terraform, like Gateway, Template, Pool VDIs or any other need to be deleted manually first.

1. In Workspot Control, delete any Desktops, Desktop Pool, Cloud Server, Cloud Server Pools, Templates, and Gateways.

2. On the system where you ran Terraform previously, open the command prompt and go to the directory with your Terraform files.

3. Enter terraform init

4. Enter terraform destroy to list he infrastructure details that will be destroyed.

5. Answer “yes” if you are ready to make the changes. This will apply all the changes.

6. If you see Errors during the deployment, the script will automatically exit.

   • Try rerunning Terraform destroy again, this should usually delete the remaining components.

   • Otherwise, try to fix the errors or remove the components manually:

     • Delete All Control resources (Templates, Cloud Desktops, Cloud Pools, etc.).

     • Delete the Control Account.

     • Delete Azure Subscription.

Recommended Documents

• Microsoft Azure: Create a subscription as a partner for a customer.

• Create Workspot Enterprise Connector.

• Creating a Gateway Cluster.

• Creating Workspot Templates in Azure.

• The Workspot Desktop Agent.

• Per-User Licensing Model (Enterprise and Enterprise Plus).

• Creating a Workspot Cloud Desktop Pool on Azure.

• Active Directory (AD) Groups.