RDS Build Overview

MyCloudIT deploys RDS for you taking the complexity and time consuming nature out of such operations. Below is an overview of what we built for you

Overview

This article applies to MCIT RDS modern (v3), and does not apply to MCIT classic (v2).

MyCloudIT (MCIT) RDS deployments can “scale up” and “scale out”. Scale up means that you can increase the size of the VMs to support additional users, scale out means that you can add additional VMs as your user load increases.  

MCIT automates the Installation, management and monitoring of your RDS deployments within Azure.  You take 10 minutes to describe how you want it built and our automation takes the next 1 (approximate) hour to build your RDS solution in Azure.  Once it’s built, you have a fully functional RDS deployment. 

Example Deployment

We will show "what we build" for an example small business called "Freds Fruit Farms". Below are the deployment options the customer selected. 

MCIT RDS network topology

(click for full image) 

Note: The "Farms" resource-name-prefix was selected in deployment. 

Default network configurations:

• Name: Farms-Core-SUB
  • Address Range: 10.10.10.0/24
  • DNS server: 10.10.10.10
  • Purpose: Primary infrastructure

• Name: Farms-Workload-SUB
  • Address Range: 10.10.20.0/24
  • DNS server: 10.10.10.10
  • Purpose: Session hosts and other client services

• Name: Farms-DMZ-SUB
  • Address Range: 10.10.99.0/24
  • DNS server: 10.10.10.10
  • Purpose: Public facing infrastructure

  Naming Convention: Postfixes used to denote resources

• NET: Azure Virtual Network
• SUB: Azure Virtual Network Subnet
• PIP: Azure Public IP address
• NLB: Azure Network Load Balancer
• LBE: Azure Network Load Balancer Back End
• NSG: Azure Network Security Group
• NIC: Azure Network Interface Card
• SET: Azure Availability Set
• OsDisk: Azure managed disk with the Windows partition
• DataDisk: Azure managed disk for other data such as user profiles
• Note: We do not put a postfix on Azure Virtual Machines as they are limited in name length

  VM and Windows  Configurations

• VM and AD Computer Name: Farms-MSDC-001
  • MS Server Roles: 
    • Active Directory Domain Services (ADDS)
    • Microsoft DNS Server (MDNS)
    • File Server (FS)
    • Remote Desktop Connection Broker (RDCB)
    • Remote Desktop Licensing (RDLS)
  • Other Notes:
    • Windows Defender running
    • Promoted to ADDS DC holding all FSMO roles
    • MCIT RDS agent installed
    • RDS configured with one desktop collection with UPD's
  • Default IP address: 10.10.10.10
  • Public IP address: Yes, however direct access not allowed by default
  • Attached Disks: 1x 128GB OS Disk and 1x Data Disk
  • Security Group: Yes via subnet
  • Availability Set: Farms-Core-SET
    
    
• VM and AD Computer Name: Farms-RDGW-001
  • MS Server Roles: 
    • IIS Web Server
    • Remote Desktop Gateway (RDGW)
    • Remote Desktop Web Access (RDWA)
  • Other Notes:
    • Windows Defender running

• • • RDGW and RDWA configured
    • Certificate created and installed
    • Has a public RDWA URL: https://farms.autords.com/rdweb

• • Default IP address: 10.10.99.4
  • Public IP address: Yes, but via NLB

• • Attached Disks: 1x 128GB OS Disk
  • Security Group: Yes via subnet
  • Availability Set: Farms-RDGW-SET
    
    
• VM and AD Computer Name: Farms-RDSH-n (where n is 0 - 999)
  • MS Server Roles: 
    
    • Remote Desktop Session Host (RDSH)
  • Other Notes:
    • Windows Defender running

• • • Added to the first desktop collection as a session host
  • Default IP address: 10.10.20.n (where n is 4 to 253)
  • Public IP address: No
  • Attached Disks: 1x 128GB OS Disk
  • Security Group: Yes via subnet
  • Availability Set: Farms-RDSH-SET

Overview Description of Roles

RDGW-001 server RDS Roles:

This server holds the RDS Gateway and RDS Web Access roles.  These two roles provide access to the RemoteApp and Desktop Sessions provided by the RDS deployment.  The RD Gateway role enables authorized remote users to connect to resources within the RDS deployment.  This role manages the security model and which resources users can connect to.  This role also routes traffic from the public internet to the backend Session Hosts via RDP over HTTPS to ensure a secure and encrypted connection between users on the Internet and the internal RDS Session Hosts that deliver the resources.  This role can be used in conjunction with additional security capabilities if you want to add additional security to your RDS deployment. The RDS Web Access role enables users to access both the RemoteApp and Remote Desktop "landing portal" from a web browser.

RDSH-n

The Session Host Server(s) provide the end user delivery portion of RDS.  The Session Host Role is installed on one or more individual VMs.  Having multiple Session Host Servers is the ideal way to scale your deployment based on user demand.  The Session Host Servers are the VMs that deliver resources to the end users.  You can customize each Session Host Server after your RDS deployment is created, but it is critical that all Session Host Servers within the same collection be configured identically. This concept is so important, that MCIT allows you to create an initial image of the Session Host Server as a template to be used by all Session Host Servers in a deployment.  This is referred to as clone and Golden Image. This Golden Image should be configured for the end user experience you want to deliver to your end users.  All the end user applications, like Office and other 3rd party applications should be installed on the Golden Image. You can also update this Golden Image as additional applications and patches need to be deployed to your end users.

MSDC-001 (A.K.A Management Server)

The File Server role manages the shares created on the Management Server.  Every Management Server has an additional volume attached to it, usually it is the “F:” drive and contains the Active Directory database and the User Profile Disk (UPD) share. UPDs are used to ensure that whichever Session Host a user is connected to, their personal settings and documents are available (Windows user profile).  The Management Server has additional storage capacity to serve as a File Server for user applications and company shares as well. 

The RD Connection Broker role is responsible for connecting new users to the appropriate Session Host Server.  This role is responsible for load balancing users (as they log in) across the Session Host Servers supporting the collection the user is connecting to. The RDCB role can be considered the brain of RDS. MCIT deployments offer autoscaling to provide a balance between the user experience and runtime cost of your deployment. This ensures that your users are provided with an excellent user experience without using more resources than necessary for your deployment depending on the load at any point in time.

The RDS Licensing Role manages the licensing portion of the RDS deployment.  Each user within a deployment requires an RDS CAL or an RDS Subscriber Access License (SAL). If the customer already owns RDS CALS with Software Assurance, they will be properly licensed to use RDS within Azure. If they do not already own the RDS CALs with Software Assurance, the customers can purchase RDS SALs from either a SPLA partner or directly from MCIT. 

Each RDS deployment requires access to a Windows Server Active Directory Domain Controller.  The AD DS and DNS roles are installed on the management server, and the Management Server is promoted to a Domain Controller of the new Active Directory root forest created within the environment.

Normal users never log into the Management Server, but users may access File Shares shared from the Management Server.  The Management Server “manages” user connections and connects the user to one or more Session Host servers depending upon the resources the user is accessing. 

Overview of How we integrate into Azure

Services Topology

OAuth 2.0 authentication with Azure AD