In part four, we performed the last of the procedures in completing our redundant RDS farm. We installed SQL 2016, prepped the connection brokers, went through the high availability wizard, added our second connection broker server and finally, we created our external load balancing virtual server. Here in part five and the final of this mini series, we can at last test our setup! We’ll connect to it via a couple of devices as well as testing the load balancing and high availability pieces of our Netscaler and RDS back-end server components. Let’s go!
Part 5: External Connection and Testing of High Availability and Load Balancing
Connecting Externally from a PC
The moment of truth. From a Windows computer, you’ll want to head over to https://site.yoursite.com/rdweb. For now, it’s best to use Internet Explorer from a computer that is completely separate from your RDS lab network. This aims to prove that we are 100% connecting to our servers from a remote location and no network dependencies are required for it to work. The FQDN is based on the SSL certificate name you’ve used to secure the gateway and RD Web Access roles. If everything has been configured correctly by following the steps I’ve laid out, you should now be staring at the Microsoft’s default login screen for RD Web Access! If you do see this page, then it is definitely a good sign as it shows you are able to connect to your back-end servers through the Netscaler!
Login in with one of your test user accounts that have been assigned permissions to access your session collection.
You should now see the resources the user is allowed to connect to. In this scenario, the user have access to a session desktop that is being load balanced behind the scenes on our two remote desktop servers.
Now here comes the true test. Click on the resource to launch it. Because we’ve secured our connection broker roles with a self-signed SSL certificate, you should see two warning/caution prompts regarding this. As this is only our lab, we should be okay to proceed so hit the Connect button and then the Yes button at the second prompt afterwards.
If everything has been configured accordingly, you should now be logged in to one of the two session hosts in your lab! You can see here that I’m connected to rds02.lab.local. Also noticed in the RDP window that I haven’t made a direct RDP connection to the server itself but rather to the connection broker FQDN instead.
Another thing to check is whether you’re connecting to your session via the UDP protocol or not. Click on the Connection Info icon on the top status bar and it will let you know. If you see the screenshot below, then you’ll know that you’re connecting over UDP and that you’ve configured your port forwarding rules correctly on your router. If however the message doesn’t include the ‘UDP is enabled’ portion, then that means you’re connecting only via TCP. By default UDP is enabled on a newly built RDS farm so you’ll want to check your port forwarding rule.
Testing Connection Broker Load Balancing
To test the load balancing portion of your session servers, simply login to a different user account from a second computer. Chances are that this second user will be placed on the other server. Here, my lab\userb user got dumped on rds01.lab.local while usera was still connected to rds02.lab.local. This here shows the connection broker load balancing at work by directing users to a session host they should connect to when they want to connect remotely.
Testing Connection Broker Session Re-connection
To test the session re-connection feature of the connection broker, in your session simply open up a couple of apps and files. Rather than signing/logging out of your session, disconnect it by clicking on the X button in your remote desktop window. A caution prompt will then appear letting you know that your session will still be available the next time you reconnect. Hit OK.
Logout of RD Web Access and re-authenticate. Launch your session host resource again and you should then be redirected back to your original server that you’ve disconnected from. This can be confirmed as the files and programs you’ve opened previously are right where you’ve left them a couple of moments ago.
Testing RD Gateway Load Balancing
Being that we have two RD Gateways in our setup, we’d naturally want to use both for load balancing. We configured exactly that when we configured our Netscaler in the previous articles. With a RD Gateway, all user traffic will flow through the gateway. With load balancing in the setup, it may be a little difficult to track which gateway a particular user is using. Luckily this is a lab and so we have the benefit of logging on one user into the farm to generate traffic. We can then look at the ethernet adapter performance on both of our gateway servers to see which one has the higher traffic. Whichever one this is will be the gateway used by our lab user. To test the load balancing aspect, simply login as a second user and if UserA was using the first server as the gateway, then UserB should then being using the second server.The Remote Desktop Gateway Manager also provides this information for you. It is a good idea to get familiar with this utility as you’ll be using it a lot in the future to manage your gateway policies and connected users.
Testing Gateway and Connection Broker High Availability
To test the high availability of our RD Gateway and Connection Broker pieces, I simply connect as a user, stream a video and then proceed to shutdown the gateway server the user is currently using. Because both of my servers has both the gateway and connection broker role installed, either one should be able to pick up the slack when either one of them goes out of commission either planned or unplanned. First you’ll need to determine which gateway server the user is using by looking at the ethernet adapter performance on both of the servers. Once you determine the server being used, simply power it down to simulate an outage. If all goes accordingly, your session will get disconnected for a brief moment but will then reconnect automatically to the second gateway server. In my Youtube stream test, the video continued playing as soon as connectivity was restored to the second gateway. Very cool!
To test the connection broker part, simply login as another user while the first server is still powered off. Because the database has been moved to a dedicated SQL instance, the remaining connection broker uses that to direct clients rather than using a local database. If the second user is able to successfully connect, then this proves the connection broker HA portion is working as well.
Testing Netscaler High Availability
Testing this part is very simple. Well technically if you think about it, breaking things is a lot simpler than creating them! You can either completely power off the Netscaler VPX virtual machine or perform a forced failover in the configuration GUI. I usually like to test the worst case scenario possible so I like to opt for powering off the VM completely. Doing so will provide no warning to the underlying operating system at all that it will be shutting down. In a production environment, this power off procedure can simulate a physical host failure. This allows you to not only see if the high availability portion is working properly when a true failover scenario occurs but it also allows you to time how long it would take before HA takes over and all components are back working as intended. In my testing, it literally took just one second after powering off my primary Netscaler node and the secondary kicking in for my remote session to be full reconnected!
Connecting From Other Devices
OK, so we got connected from our Windows PC via Internet Explorer without any issues. Now we turn to connecting to our RDS farm via other devices and methods.
Connecting from Android
With Android based smartphones and tablets, we need to download the Microsoft RD Client app from the Google Play Store.
What you want to add is a “Remote Resource Feed” and NOT a “Desktop”. You’ll use the same URL to connect but this time, you can safely omit the /rdweb portion at the end. So, if your RD Web Access external page is https://gateway.yoursite.com/rdweb, you’ll type in just https://gateway.yoursite.com. The client will then ask you to either select an existing user account or create a new one. It will then connect to your site using the user credentials you’ve provided and it will then present your resources.
Connecting from Apple iOS
For users with Apple based devices such as MacBooks, iPads and iPhones, connecting to your RDS farm is a similar affair as connecting from Android based devices so I won’t be attaching the same screenshots. In the Apple Store, download the Microsoft RD Client to get started.
Integrating Remote Resources into Windows Start Menu
A really cool way to allow your remote users to consume remote resources is to publish them right in their local start menu! This method blends in pretty smoothly with the users locally installed applications so as to better hide the fact that the apps a user launches can appear “local” when it’s really not. Instead of having to direct a user to first visit a specific website, login with their credentials and then launch the resource, you can now just tell them to launch the app in their start menu or taskbar. This feature is made possible with Windows RemoteApp and Desktop Connections. It is a one time setup affair but I’m certain you can configure this in Group Policy. Find this program in your local Windows OS to add a remote resource.
By default, the URL you want to use when adding a resource is: https://gateway.yoursite.com/RDWeb/Feed/webfeed.aspx.
Direct RDP Connection File
Want a even more simple method to connecting to your remote session server with the least amount of clicks? Well, you can simply save the RDP file used! For this to work, I used a different browser than Internet Explorer. Something like Chrome or Firefox should do the trick. When you login to your RD Web Access site and launch a resource, web access actually provides the actual RDP file used by your device to connect. When you save this file, you should be able to reuse it to connect to your RDS farm resources. This works when connecting to session based desktops and remote apps.
Because it is a RDP file, you can view its content in a text editor such as Notepad++ or Wordpad and see the connection info.
Here are a couple of items that may be of interest to you regarding your RDS farm.
RD Web Access URL Redirect
Typing in https://gateway.yoursite.com/rdweb can be a hassle. Well, the semi good news is that we can at least get rid of having to type the /rdweb part in the URL by instructing IIS to perform a redirect. Having to tell users to type https://gateway.yoursite.com without the /rdweb part sounds less confusing.
All you need to do is open IIS, drill down to your default website, select the HTTP Redirect option and type in your current full URL to your web access page. Also make sure to select the checkbox “Only redirect requests to content in this directory (not subdirectories)”. Then open a command prompt and type in ‘iisreset”. Because we have two RD Web Access servers, repeat the same steps on your other server.
Viewing Public IP of Remote Users
By default, the Netscaler connects to the back-end servers via the Subnet IP Address you configured. This can be a problem because to the back-end servers, the IP will be the same for all users. In my scenario, you can see that the gateway server thinks that my user is coming in from the 10.40.77.210 IP address.
To change it so that the client’s source IP shows up as the Client IP Address in the Gateway Monitoring column, we simply need to make two changes. First, we need to change the services on the Netscaler to use SourceIP mode. The two services we are looking to change are the ones bounded to our external virtual server. For me, this would be the ‘any_rdws01’ and ‘any_rdws02’ services. In the Service Settings menu, select the ‘Use Source IP Address’ checkbox and hit OK.
Next we need to actually change the gateway IP addresses on both of our gateway servers to point to the IP of one of the subnet IP address. Once we do so, the client’s public IP address should now show up in the monitor.Setting the gateway IP to our Netscaler is fine in lab environments but in production, your servers most likely would go out via a production firewall managed by your network admins. This is so that they can control network traffic flow with rules, filters, inspecting traffic, etc. Definitely consult with your network team to see what are the consequences for doing so before rolling out to production.
Publishing Both Session Desktops and Remote Apps
This “issue” has got to be one of the more frustrating one’s I’ve encountered and sadly, it’s beyond my control! I call it a issue because I can’t for the life of me understand why Microsoft either overlooked this or made it to behave this way. When we first created our RDS farm and created a session collection, we choose to just allow the user to launch a session based desktop from either of two servers we had. Here is the crazy part: if you then choose to publish remote applications instead, users will no longer have the ability to launch the session desktop because the icon to do so in RD Web Access disappears! Basically you are forced to choose either to publish session desktops OR remote apps, not both. It’s ridiculous! I can confirm that this happens in both Server 2012 RDS and here in Server 2016 RDS. Below is what it looks like once I published the Calculator app in the collection. Notice how my previous desktop icon disappeared!
For the users to see both remote apps and session desktop icons, a registry key (ShowInPortal) must be changed from a value of 0 to 1. The problem is that every time the session collection is modified, the value resets back to 0. Therefore, you’ll need to use Group Policy Preferences or another method of your choice to constantly monitor this value and change it back to 1 if it changes.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\collectionname\RemoteDesktops\collectionname
In the End…
I hope everyone that went through this series learned as much about Remote Desktop Services as I have! What we did here barely scratches the surface of what RDS can provide in today’s highly remote user workforce. I do hope it was enough to get you interested and to go out and learn more about it. Coming from XenApp 6.5, we are looking to making the switch to RDS simply due to cost factors and easier administration. I dislike a lot of things in XenApp 7.x and one of them is management. It strays very far from what most administrators have been used to in 6.5 and I highly believe it’s not for the better due to Citrix wanting to merge XenApp and XenDesktop.
RDS paired with Netscaler is a pretty good combo but it’s not the only load balancer out there. How we configured Netscaler in this lab is as basic as it can get. Basically, it’s acting as just a traffic passthrough device sitting in the middle of the clients and back-end servers. At the time of finishing this article, I’m still learning of different ways to tweak RDS. Every environment is different so we must make the product to work in our favor. I personally can’t wait to pilot this out to a group of small clients to test! Have fun and good luck with your lab!