RDSH is a role within Remote Desktop Services that can be used to deploy virtual workstations or applications with the Microsoft technology platform. There was a time when this really wasn’t considered a good option for your virtualization deployment. However, with its advancements over the years, today it can be an extremely viable option right from within your Windows server without any additional tools such as Citrix XenApp or VMWare View. While there are times when Citrix or VMWare may be essentially for successfully deploying a remote desktop, the emphasis of this write-up starts with Microsoft RDSH.
Let’s start by uncovering what makes the use of the technology a good or bad option for virtualization. Then let’s dive into both the good and bad of monitoring your RDSH environment.
How do I know if I should use Microsoft RDSH?
The answer to this question is the typical consulting answer of “It Depends”. Let me explain. Whether an organization chooses to use RDSH will truly vary. So, to help you decide let’s start with laying out the facts that will help you determine what is best for your business needs.
RDSH Checklist of Considerations
|Low Resource Footprint||• Great for use cases where the application footprint doesn’t require a lot of resources
• Low CPU, Memory, Disk I/O, and Disk Space
• Application Examples: Microsoft Office, Adobe, a web browser, and any other less resource intensive applications used by your enterprise
• The lower the resource footprint the more workstations you can run per server
|End User Workstation Look and Feel||• Keep in mind that you are deploying a server operating system to the end user
• Be sure to lockdown the operating system so that users cannot make changes
• Plan to reconfigure the look and feel of the server through active directory profile management or purchase a 3rd party tool that can simplify the process of reconfiguration.
• If you deploy on Windows 2016 then expect to reconfigure the look and feel to be Windows 10.
• Keep in mind Windows 7 is end of support in January of 2020, so going with Windows 2016 RDSH may be suitable option.
|Optimal Performance||• Preserve the configuration you deployed to ensure optimal performance. This can be done by doing the following:
o Do not allow users to install or change anything, or the integrity of the server will become compromised
o Do not allow users to have local administrator
o Control which printer drivers are deployed to the server
o Ensure that the latest security updates are applied
o Backup and test recovery of your server deployment
|Microsoft RDSH simplicity, and when to look at other options||• Compared to other solutions that will allow you to deploy a server desktop as a workstation (i.e. VMWare View or Citrix XenApp), the Microsoft administrator console will feel very simple.
• This simplicity can be good, but leads to the lack of some richer features that can be beneficial to similar deployment types.
• For example, if you want workstation images with versioning or more control over printers/peripherals you just won’t get this with Microsoft RDSH.
As you can now see there isn’t one answer as to whether you should use RDSH over some of the other product offerings out there. It may only work for one of your use cases. If this is true then it may not make sense for you to invest time and energy into learning something new when you may already be using a product offering from Citrix or VMWare already.
What to expect from your RDSH Server? And where are the savings come from
When deploying with an RDSH solution there is a huge savings that comes from the fact that you are not deploying a full operating system for each user. Every user shares the operating system which is a huge win. This is true of any offering you choose to move forward with whether it’s Microsoft RDSH, or if you deploy desktops from your servers on Citrix XenApp or VMWare View.
Another advantage comes from concurrency of users and sharing of resources. You could easily assign 100 users to one server, but the resources will only be used when a user is logged in and doing work. For most organizations when I see this strategy used they typically will not have more than 15-20 users on a server at any one given time. Allowing global organizations to distribute the server resource usage around the clock without having had to issue physical devices to anyone, but they can still do their job successfully.
Going a step further you many ask how many workstations you can deploy on a server with those configured resources? Again, the answer will vary depending on the applications you deploy, and even how the users use their applications. For example, one user may use Microsoft Word for standard word processing, but the next person may be using it to design a graphically intensive marketing brochure with embedded video. So, you are going to need to do some of your own testing to determine how many users will be able to use the new server you just deployed.
Let’s take a closer look the cost of using RDSH Server deployed workstations compared to a Standalone PC based upon some the real-world deployments I have worked with. Below we are analyzing just the base operating system without applications and the resource waste that can be avoided just by looking at an option such as RDSH.
|# of PC’s/Concurrent Sessions||CPU||Memory||Disk Space|
|RDSH Server Deployed Workstation ***||20 Concurrent Desktop Sessions||32 Cores||64 GB||500 GB **|
|Standalone PC||20 Individual Computers||(8 cores *20 PC’s) = 160 Cores||(12 GB/PC * 20 PC’s) = 240 GB of RAM||(500 GB of Disk Space * 20 PC’s) = 9.7 TB|
** If you are keeping a copy of user profiles on the server then you may need more storage to accommodate
*** These numbers reflect the deployment of base workstations only. Be sure to baseline the memory and CPU for the applications your users will need to use. This will likely increase the base resources you need.
The table above we have deployed 20 workstations on RDSH, because the server only has one operating system the base resources for the server do not need to equal that of 20 actual PCs. In return, we can run 20 users successfully on 32 cores of CPU, 64 GB of memory, and 500 GB of disk space.
Now compare that to purchasing 20 standalone PCs. In this case each PC will come with a base level of resources. Whether the user ever consumes all those resources we will with buy them anyway to give them their own workstation. While the typical store boughten PC can vary, I went with the minimum I see most organizations purchasing. As demonstrated by the table above, by going with standalone PCs, the waste of resources is incredible. I can think of better things to do with 320 cores of CPU, 160 GB of RAM, and 9.7 TB of disk space. Most users would not ever consume all the resources on their device.
Challenges of monitoring, what to look for
Monitoring servers can be very time consuming, and when you are especially busy with projects knowing what is going on with your infrastructure is very important. Keep in mind that when you are deploying a technology such as RDSH, the monitoring requirements are even greater. Your server is sharing resources with every single user that is on the server at any one given time.
Let’s look at what it would take to troubleshoot a real-world scenario. Here is the issue I am faced with. I only have 10 users connected to my RDSH server, but I did sizing so that I could run up to 20. The sizing was working great for the past year, and then suddenly, I am receiving alerts that my CPU spiking to almost 100 % on the server. In my case I also have Microsoft SCOM server monitoring in place. SCOM was great at letting me know the CPU spiked through an email notification and which server is having trouble, but it doesn’t tell me why. Let’s look at how to start troubleshooting so that we can find out why this is happening.
The first place I would start looking for this detail would be task manager on the offending server. In this case you logged into the server, opened task manager and quickly learned which user was running resources high on the server. More specifically it appears that Internet Explorer browsing is taxing the CPU. By the time I have logged into the server and found this it could easily have taken about 15 minutes of my time.
Now to continue troubleshooting I need to know which user has the high CPU. So, next I go to the Users tab in task manager I can quickly see in this example that ”tmiller” is the offending user. Now, it’s entirely probable that she is doing something important that is helping with her work day, but we cannot confirm that here. We cannot look at the URLs that she is working with to decide on a course of action. We know more about why, but not the answer. At this point I would call her to discuss, and if she was available this took another 15 minutes of my time, and I might have an answer that will help me decide on a course of action. If she wasn’t available I will need to spend more time later following up with her. Easily 45 minutes just to get an answer when all is said and done.
Process Explorer is a nice tool for troubleshooting too. It will dive a little deeper into some of what you can research when troubleshooting. It is free and can be found here: Process Explorer Again time consuming, because you first you need to download the tool, then extract and install after you logged into the offending server, launch the tool and start researching the issue. First you will notice the screen is constantly refreshing which can make it hard to assess the situation. Once you have identified the process you can right-click and run a dump on the process. In my experience with. dmp files you need a tool such as windmp to be able to view the data, but the analysis can sometimes be a challenge. In some cases, you may need even need to work with Microsoft support to analyze the data. At this point in the process you could have easily lost several hours of your day, and still do not know which websites Theresa Miller was visiting when the CPU spike was occurring.
To me the right monitoring tool for your RDSH environment will ensure that It’s simple to find the answer. This tool will not leave you looking around the server manually for the answers. This is important not only in troubleshooting, but with proactive monitoring as well. Wouldn’t it be great to know exactly when you need to deploy another RDSH server to accommodate load without hacking together a manual process? One that is timely, fast and has you determining which websites were running in minutes instead of hours or even days?
A great monitoring tool will also ensure that its provide you with insights on everything about your environment. It’s more than just CPU, memory, I/O and user processes. It’s about knowing when a user has too many web browser sessions open running YouTube videos, understanding if there is a network bottleneck, if disk space is running out, or if an application process has a memory leak, and more. Understanding where there is an issue is important, but having a tool that will allow you to quickly move to resolution is even more important. Time is money for every organization, and in some cases even a short downtime can result in in lost revenues and destruction to production.
What will you do?
My recommendation on whether to move forward with RDSH is to test it out against the use cases that would benefit your organization. For example, if I am a hospital I probably want a secured virtual workstation at the bedside. This improves security, and prevents patients from making accidental changes to the system. Now this may not be your exact scenario, but I suspect it will work for some of the use cases that would benefit your organization.
Beyond RDSH choose a monitoring tool that will monitor any virtual solution you implement. This will ensure the best system performance and monitoring, but more importantly allow for the proactive and timely monitoring approach is necessary for doing your job successfully in a timely way.