Read time

What We Built for You

By Rob Waggoner

Architecture Overview 

MyCloudIT offers several different deployment architectures and I would like to take a few minutes to share the purpose and configuration of each.  First, we offer two Basic Architectures, the Basic RDS and the Basic RemoteApp architecture.  These are designed to be low cost as they run on only two VMs within Azure, but using just two VMs for a deployment limits their ability to scale.  They both can “scale up” as you add more users, but there is no “scale out” capability with these offerings.  Scale up means that you can increase the size of the two VMs to support additional users, scale out means that you can add additional VMs as your user load increases.  The Basic architectures are typically the most cost effective model when you are supporting fewer than 8 simultaneous users.  Due to the architecture of both the Basic offerings, they do not offer scale out and are limited to one collection per deployment.

For those that want to create a deployment that can scale up and scale out to support hundreds of users, we offer our Standard architectures.  The Standard RDS and the Standard RemoteApp architectures are our most popular architectures and provide both “scale up” and “scale out” capabilities.  The Standard RDS architecture supports both RDS and RemoteApp deployments, while the Standard RemoteApp architecture is limited to just RemoteApp delivery.  I find customers that only want to deploy RemoteApp capabilities, often leverage the Standard RDS deployment with one Remote Desktop machine in a Remote Desktop collection so they can leverage this Remote Desktop to manage their RemoteApp infrastructure.  Once the RDS infrastructure is built, you can easily add additional Remote Desktop and RemoteApp collections to the deployment.

MyCloudIT automates the Installation, Management and Monitoring of your Remote Desktop Session (RDS) deployments within Azure.  You take 10 minutes to describe how you want it built and our automation takes the next ~90 minutes to build your RDS solution in Azure.  Once it’s built, you have a fully functional RDS deployment. 

Below, I’ve described each of our architectures.  Please take note of our color coding.  We will use the green box color coding to designate the RD Gateway Servers, the purple box color coding to designate the RD Management Server, and the red box color coding to designate the one or more RD Session Host Servers.

 

 Basic RDS Architecture

This is the architecture for the Basic RDS offering.  This architecture can theoretically support over 100 users with some of the new Azure VM sizes, but it can only support increased user demand by “scaling up” the Gateway / Session Host Server.  If you want to “scale out” please refer to our Standard RDS offering.  The Standard RDS offering is designed to scale out to several hundred users while giving you the ability to take unused Session Hosts offline when not needed.  Please note that the Basic RDS offering is restricted to a single Session Host and a single collection.

 

 Basic Remote Apps Architecture

This is the architecture for the Basic Remote App offering.  This architecture can theoretically support over 100 users with some of the new Azure VM sizes, but it can only support the increased user demand by “scaling up” the Gateway / Session Host Server.  If you want to “scale out” please refer to our Standard Remote App offering.  The Standard Remote App offering is designed to scale out to several hundred users while giving you the ability to take unused Session Hosts offline when not needed.  Please note that the Basic Remote App offering is restricted to a single Session Host and a single collection.

 

 Standard RDS Architecture

This is our Standard RDS architecture, and by far our most popular architecture, due to its ability to support multiple Remote Desktop and RemoteApp collections simultaneously.  This architecture is designed to scale out to hundreds of users by adding additional Remote Desktop Session Host Servers to the RD Session Hosts Farm.  The benefit of this scale out architecture is that MyCloudIT leverages auto-scaling to scale the necessary Session Hosts up when needed, and scale the Session Hosts down after hours when they are no longer needed.  The Remote Desktop model uses dual core VMs by default, but of course the MyCloudIT offering allows you to change the size of all the VMs supporting your deployment through our management portal.

 

 Standard Remote Apps Architecture

This is our Standard RemoteApp architecture.  This architecture is designed to scale out to hundreds of users by adding additional RD Session Host Servers to the RD Session Hosts Farm.  This architecture supports multiple RemoteApp collections, but does not support any Remote Desktop collections.  The benefit of this scale out architecture is that MyCloudIT leverages auto-scaling to scale the necessary Session Hosts up when needed, and scale the Session Hosts down after hours when they are no longer needed.  This architecture is identical to the Standard RDS architecture, except for the size of the RD Session Host servers.  The RemoteApp model uses single core VMs by default, but of course the MyCloudIT offering allows you to change the size of all the VMs supporting your deployment through our management portal.

 

 Domain Joined RDS Architecture

The Domain Joined RDS Architecture is like the Standard RDS architecture except the Domain Controller / DNS functionality is provided by an existing Windows Server Active Directory Domain Controller in the customers’ existing Windows Server Active Directory Forest.  This architecture is used if you want to install RDS and Remote App functionality into an existing Windows Server Active Directory.  This architecture requires that the existing Windows Server Domain Controller exist within the Azure subscription.  We do not support access to Domain Controllers connected via Site-to-Site VPNs due to the latency issues.

 

 Domain Joined Remote Apps Architecture

The Domain Joined Remote App Architecture is like the Standard Remote App architecture except the Domain Controller / DNS functionality is provided by an existing Windows Server Active Directory Domain Controller in the customers’ existing Windows Server Active Directory Forest.  This architecture is used if you want to install Remote App into an existing Windows Server Active Directory. This architecture requires that the existing Windows Server Domain Controller exist within the Azure subscription.  We do not support access to Domain Controllers connected via Site-to-Site VPNs due to the latency issues.

 

Gateway Server (RDSGW)

The Gateway Server is deployed in both the Standard RemoteApp and Standard Desktop deployments.  The Gateway Server holds the RD Gateway and RD Web Server 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 actual resources.  This role can be used in conjunction with additional security capabilities if you want to add additional security to your RDS deployment. The Gateway Server also holes the RD Web Server role.  The RD Web Server role enables users to access both the RemoteApp and Remote Desktop capabilities from the Windows Start Menu or from a Web Browser.  The most visible part of this role is the RDWeb page that users can log into to initiate access to the shared resources. 

For Basic RemoteApp and Basic Remote Desktop deployments, the Gateway Server also holds the RD Session Host role.  I will leave the RD Session Host section for full details on this role, but for these Basic deployments, only one Session Host is allowed.  This means that as you scale up your user count, the Gateway Server must be increased in size to accommodate the additional user load.  For this reason, if you have more than 6-8 users, a Standard RemoteApp or RDS deployment will most likely be more cost efficient. 

Normal users never access resources from the Gateway Server, the Gateway Server “routes” the users’ connections from the Internet to the Session Host Servers.

 

Management Server (RDSMgmt)

The Management Server is deployed in all RDS deployment models and contains multiple RDS roles as well as some Windows Server roles.  For all instances of the Management Server, the File Server, RD Connection Broker, and RD Licensing roles will be installed. 

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 are available.  The Management Server usually has additional storage capacity to serve as a File Server for user applications and data as well.  While the Management Server may have the storage capacity needed by end users, it may not have the CPU capacity to support all of the file transactions, if the File Server role is over utilized.  If the File Services role consumes too much CPU capacity, the File Services role may need to be deployed on a separate Virtual Machine to ensure the File Services capacity does not negatively impact the other roles on the Management Server. 

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.  This is a critical role to ensure that if there are two or more Session Host Servers available, as users log in, they are evenly distributed among the two or more Session Host Servers; as opposed to all users connecting to a single Session Host Server.  For MyCloudIT deployments, we offer Auto-Scaling 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.

The RD Licensing Role manages the licensing portion of the RDS deployment.  Each user within a deployment needs a RDS CAL Plus Software Assurance, or a 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 MyCloudIT through our portal.  If the RD Licensing Server is not configured, users will not be allowed to log into the RDS deployment. 

Each RDS deployment requires access to a Windows Server Active Directory Domain Controller.  For non-Domain Joined deployments, 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 Domain created within the RDS deployment.  For Domain Joined deployments, the AD DS and DNS roles are not installed on the Management Server.  An existing Active Directory Domain Controller must be installed and available within Azure.  Please note that currently, Azure Active Directory Services is not supported as an Active Directory Domain Controller for the MyCloudIT implementation of RDS.  Connecting to a Domain Controller over a Site-to-Site VPN has been problematic and is also not supported due to latency and the bandwidth demand.

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. 

 

Session Host Server(s) (RDSSH-)

The Session Host Server(s) provide the end user delivery portion of RDS.  As I mentioned earlier, for the Basic RemoteApp and Remote Desktop deployments, this role is included in the Gateway Server VM.  For all Standard deployments, the Session Host Role is installed on one or more individual VMs.  Having multiple Session Host Servers (or a Session Host Server Farm) 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 RDS 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 a Golden Image and MyCloudIT supports the concept of a Golden Image.  This Golden Image should be created before you create a RDS deployment and will be used as the base image for all your Session Hosts.  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 before the RDS deployment is created, then the RDS deployment creation process uses this Golden Image template for all the Session Hosts deployed within your deployment.  You can also update this Golden Image as additional applications and patches need to be deployed to your end users.

 

Virtual Network

Every MyCloudIT deployment is created in a Virtual Network within your Microsoft Azure Subscription. The Virtual Network provides a logical isolation of the Azure Cloud within your subscription. This means the Virtual Network can act as a security boundary for your deployment.  Your subscription can have multiple Virtual Networks, and unless specifically configured, Virtual Machines within different Virtual Networks cannot communicate with each other. By default, all VMs within your Virtual Network have outbound access to the internet, but there is no inbound access enabled by default.  All Virtual Machines must be created within a Virtual Network in ARM.  Of course, MyCloudIT creates the Virtual Network and Virtual Machines for you, and MyCloudIT enables inbound Access to the RDSGW and RDSMgmt servers within your deployment so our platform can provide ongoing management of your infrastructure.

 

Domain Controller

The Domain Controller is automatically created during the creation of a MyCloudIT deployment for all non-Domain Joined deployments.  For Domain Joined deployments, an existing Domain Controller with DNS installed, should be running within Azure.  When MyCloudIT creates the Domain Controller, it will be created as the FSMO master for all five roles in a new Windows Server Active Directory Forest.  During the creation of your deployment, the provisioning wizard will ask for the user name and password of the first user within the new deployment.

 

Office 365 connectivity 

All MyCloudIT deployments can integrate with existing Office 365 tenants.  We provide this capability by automating the installation and configuration of the Azure AD Connect application on the RDS Management Server.  Please note that the minimum hardware requirement for Azure AD Connect is a dual core VM because Azure AD connect also installs SQL Server 2012 Express on the Management Server.  Within the MyCloudIT portal, you can enable the Azure AD Synchronization or the ability to just copy users from Azure AD to the Windows Server Active Directory Domain.

Want Future News and Updates Emailed Right to Your Inbox?
Subscribe to Our Blog

Tags: MyCloudIT Product Updates

azure cost optimization