You'll see how to access your deployment, size your VM, add/edit users, and add/install apps.
This article refers to the MyCloudIT Gen 2 platform, which was launched in 2015. Look for MyCloudIT Gen 3 to be launched in Summer 2020.
You’ve created your first MyCloudIT RDS deployment, so what’s next?
We talk to a lot of customers who request a checklist of topics to review as they are getting started to ensure they are familiar with their new deployment AND are maximizing both cost and performance. So here’s a list we’ve put together for anyone new to our platform or those just looking for a refresher.
Access to Your Deployment
How to Access VMs as an Admin
As an administrator, you can always access the cloud desktop from the same RDWeb page as a user. However, a good best practice is to create a separate admin collection so a connection to a production deployment does not interfere with normal users. You can also use this separate desktop collection to connect to the Session Host, even if you only have a RemoteApp collection for users. With this approach, you can easily jump to different VMs within the deployment and update applications as needed. We have created a video that shows you how you can connect to various Session Hosts within your deployment. You can watch the video below.
How to Access VM as a User
There are multiple ways users can access their RemoteApps or Remote Desktops. Here are the most common:
- Access via the RD web page. Although the actual URL varies per deployment, it can always be found at the bottom of the deployment details page.
- Save a shortcut of the actual RDP file (within the RDWeb page) to their desktop.
- Add remote resources to the Windows Start Menu of the users’ workstation. Instructions for how to do that are here.
- For deployments that have the preview version of the HTML 5 User Experience, all applications can be accessed by using just an HTML 5 browser. Click here to read the update.
Sizing Your VM’s
First and foremost, our sizing recommendations for Session Host servers and user counts are only a recommendation. For full remote desktops, we create enough VMs in each collection to support 4 users per vCPU (virtual CPU). For RemoteApps, we size the VMs to support 6 users per vCPU. This model is assuming a light-duty user that uses office applications and very little browser activity. If your users use their browser a lot, especially with multiple add-ins and tabs, performance for all users on that Session Host could suffer. This is because all browsers consume a lot of RAM and CPU. Be sure to understand the demand of your users before assuming that your users will be happy with 4 users per vCPU for the full desktop experience.
Best Practice: Fewer Users per Session Host instead vs. Increasing Size
Sizing the Session Host servers for your users does require some trial and error until you understand how your users will use their cloud desktops. We encourage you to keep the size of your Session Hosts as small as possible and to reduce the number of users per Session Host if you encounter vCPU limitations. Typically, we suggest the D2_v2 as the default RDS Session Host size. If your vCPU performance is acceptable, but you need additional RAM for your VM, check out the section titled What if a VM needs additional memory. We suggest reducing the user count per Session Host as opposed to increasing the Session Host vCPU size so that auto-scaling can shut down unused VMs faster as people start logging out. You can read more about the difference between 1 session host vs many session hosts here.
What if a VM needs additional memory?
If your Session Host server has adequate vCPU resources, but it needs additional RAM, there are additional dual-core VMs that include additional memory at a minimal cost per hour. You can resize to the D11_v2 if the default size of the D2_v2 does not include enough memory. The D11_v2 cost is only ~$.05 / hour more. If your Azure region supports the new E_v3 series VMs, you could leverage those VMs for the additional memory at a lower cost than the D11_v2 VM.
Changes to New Azure VM Sizes as Available
We try to keep up with the new VM sizes. The newest sizes that impact our customers are the new D_v3 and E_v3 VM sizes. These D_v3 & E_v3 sizes do not offer a single vCPU size, so we still leverage the D1_v2 when possible. But if your deployment uses the D2_v2 VM size, once the deployment is created, you can resize to the D2_v3 VM size, if it is available in your Azure Region. The v3 series VMs include newer (faster) vCPUs and cost less than their v2 counterparts.
Scale Up/Down On-Demand with our Auto-Scaler
The auto-scaler can be leveraged on a per-collection basis for any collections that have more than one Session Host server in it. Auto-scaling gives you the ability to configure your collection to scale up based on user demand and then scale down after hours when users log out.
Automatically Stop/Start/Restart VM’s or Deployments with our Scheduler
Are you using the scheduler to start and stop some or all your VMs? The scheduler has a cost to it of $0.002 / minute of execution. Charges are only incurred when the automation scripts are actually running. Since the scripts only take a few minutes to run each day, the typical scheduler cost is less than $1.00 per month per deployment, but, can increase in cost for more complex schedules. We have not seen the scheduler cost more than $2.00 per month per deployment. Use the scheduler to start and stop your deployments when you aren’t using them. Best Practice: Typically when we build a test deployment, we go in and immediately create a daily schedule to stop all VMs at 7:00 pm every day. We don’t create the automatic start event each day, so the deployment stays off unless we turn it on. This way we know it gets shut down at the end of the day, even if someone forgets to turn it off.
How to Create/Add Users to Deployment?
We have a great document in our user guide that provides the details, but remember to add each new user you create to the actual collection you want them to be able to access. If you add users from the Domain Controller with Active Directory Users and Computers, be sure to add them to the Security Group associated with each collection.
When Creating Additional Users, be sure to Create New Session Hosts as Necessary
One of the pieces of feedback we receive from customers is that as they add users, performance declines. If you haven’t increased the number of Session Host servers supporting your users, that means more users are being connected to each Session Host server and that will degrade performance. It’s very easy to add additional Session Host servers and when you leverage auto-scaling, the great part about auto-scaling is that the additional Session Host servers are only turned on when additional users log on.
How to Add/Install Applications in Deployment
There are a couple ways to add additional applications to a deployment. If you are using a Golden Image, you can update your image, then re-deploy new Session Hosts based on your new image. If you are not using a Golden Image, we’ve included details on how you can add additional applications to your Session Host servers. Keep in mind that every Session Host within a collection should have the same applications installed on them.
Still Have Questions?
How to Engage MyCloudIT Support
When you log into our portal, support is only a mouse click away! Check out the left side of our management console and choose Support Tickets. This lets you create tickets specific to your subscription and is the most efficient way to interact with our support team.
Where can I find more information?
Throughout this article, we have referenced sections of our blogs and user-guide. You can access our complete user guide by going to www.mycloudit.com/user-guide and our blogs can be accessed by going to http://blog.mycloudit.com/.
If you have any questions about getting started, feel free to email us at firstname.lastname@example.org.