Pushing the RDS limits. A case study.

Last month, a customer located in Norway reached out to us at RDS Gurus, regarding a project they were starting. They had an existing, aging Citrix XenApp 6.5 environment in place and due to the costs to upgrade and maintain such environment, they decided to investigate if a plain Microsoft RDS environment would be able to deliver what they needed.

According to them (please note, these are their own words, not mine) after reaching out to several consultants and consulting firms in Norway, pretty much all of them gave the same verdict: RDS would not be able to deliver it.

So there we were, with a customer certainly moving away from Citrix and being told RDS would not cut it. Before explaining what the project was and the requirements, I want to make one thing very clear: I have nothing against ANY EUC product and/or vendor. That said, I have no formal ties to any of them and the bottom line (one more time) is, sell to your customers the right solution to the job. That is the most important thing. In this particular case, if Citrix had to be the product of choice for whatever reason, I would be the first one telling the customer he was insane and that RDS would suck for that particular case.

With that out of the way, this is what we were presented with…

  • Three types of users:
    • External: connecting from external locations (i.e. home) but using their own clients, therefore considered ‘unmanaged’.
    • External over VPN: connecting from anywhere but in this case using a company (‘Company 1’) provided machine (‘managed’) and establishing a VPN first, before accessing any corporate resource. Updates/etc are enforced/pushed to these.
    • Company 2: these are users from a ‘sister-like’ company. Their network is connected to the ‘Company 1’ network and is considered ‘trusted’. They use machines considered ‘managed’. Like their own endpoints, updates/etc are enforced/pushed to these by ‘Company 2’.
  • Three application ‘sets’.
    • Internal. Applications that are available on the ‘Company 1’ internal network. This is a controlled network but with most things available to the users/apps (i.e. internet access).
    • Secure. Applications considered sensitive. These reside on a separate network segment, with way more restrictions (i.e. no internet access).
    • Secure Restricted. Same as secure but with further restrictions in place and potentially only available to users flagged as ‘Company 2’ users.
  • MFA requirements.
    • Users connecting from the outside with their own machines must have MFA. They only access ‘Internal’ apps. No access to ‘Secure’ ones.
    • Users connecting from the outside with ‘Company 1’ managed machines over VPN should not have MFA, unless they try to access ‘Secure’ applications.
    • Users connecting from the ‘Internal’ network should be able to access ‘Internal’ and ‘Secure’ apps but MFA must be there if trying to reach ‘Secure’ apps only.
    • Users on the ‘Company 2’ networks should be able to access ‘Secure’, ‘Secure Restricted’ and ‘Internal’ apps, with no MFA. Also the FQDN they will use with be something like ‘whatever.company2.com’ with a certificate provided by them.
  • Ideally, have all this in a single ‘RDS’ deployment. Different collections for the different application sets but all under a single deployment. Yep, you read that right.

Note: ‘Company 1’ users will always hit an FQDN like ‘whatever.company1.com’.

With all that in mind, this is what we came up with (and I will explain the logic and tweaks behind it):

First of all, yes, this is indeed a single ‘RDS’ deployment. Two ‘RDS’ Connection Brokers with a SQL back-end for redundancy.

Three ‘RDS Session Collections’. One ‘Internal’, one ‘Secure’ and one ‘Secure Restricted’. Multiple ‘RDS’ Session Hosts to cope with the load and for redundancy purposes as well.

One ‘RDS Web Access’ pair for the ‘Internal’ (managed) users, another one for the ‘Internal’ but unmanaged ones (so for people coming from the internet, no VPN) and another one for the ‘Company 2’ users. The ‘RDS Web Access’ pairs had their code tweaked so when a user connects to the ‘Internal’ RDWA pair over the internet (no VPN), he does NOT see the ‘Secure’ apps, even though he is a member of the required group. When he connects over the VPN using a managed client, even though he uses the same URL (rds.company1.com) due to split-DNS, he reaches another RDWA pair and in this case, after logging in, he sees both ‘Internal’ and ‘Secure’ apps. Users from ‘Company 2’ hit rds.company2.com and after logging in, they see ‘Secure’, ‘Internal’ and ‘Secure Restricted’ apps.

Two ‘RDS Gateway’ pairs for the ‘Internal’ (managed’) users, with MFA enabled in one pair (going to ‘Secure’ apps). Another pair for the ‘Internal’ users (unmanaged) with MFA and finally another pair for the ‘Company 2’ users, with no MFA. Microsoft Web Application Proxy servers are in front of the RDWA/RDGWs used for ‘Company 2’ access (so they handle their certificate and pass traffic back to the servers behind them).

The main trick with the RDGWs, is to use PowerShell to set a specific RD Gateway for a particular collection (Set-RDSessionCollectionConfiguration). This allows you to have a gateway that has MFA for a particular collection and one with no MFA for another.

On the RDWAs as already mentioned, the code had to be modified to hide certain apps depending on the RDWA pair.

The end result is a thing of beauty that does pushes RDS beyond its limits and certainly way beyond what Microsoft ever thought would be possible with its own platform.

If that is supported by Microsoft, it is another story. Also as many will notice, if you do use the RDMS to change anything, you may break the RDGW settings for a particular collection. Therefore the customer has to be aware of these potential drawbacks and may need to use another tool to manage the environment (what many do already, considering the POS that RDMS is).

At the end of the day, this works and works great. Proof that when you have screws there is no need for that hammer.

CR

1,389 total views, 1 views today

Agnostic GSLB – How-to

Before proceeding, a disclaimer: no NetScalers were harmed when writing this post. They were not even used.

Great! No NetScalers, that means cheap as there is no cheap NetScaler. Well, there is a free one, severely bandwidth limited and the NetScaler Gateway SKU that you could buy for USD 995, what I do believe it is still the case. That said, there is still some limitation on the bandwidth but for many environments (Citrix of course if NSG is used) that may suffice.

Knowing that we used no NetScalers, let’s first understand why this is an agnostic solution. The reason is simple: it works with ANYTHING. It can be Microsoft RDS, Parallels RAS, Citrix Virtual Apps/Desktops and even VMware Horizon. For this blog post I used Parallels RAS but again, the exact same idea will apply to any solution. To get this going, this is what you need to do:

  1. Logon to your Azure portal. Yes, this solution relies on Azure Traffic Manager and even though it is not free, it is damn cheap. Once in the portal, create a traffic manager profile. It will ask you the name you want to use. This is the name that will be appended to  trafficmanager.net. This means if you choose rds-gslb, your unique name will be rds-gslb.trafficmanager.net.

2. In my case I selected ‘Priority’ for the routing method. Once that is done, the next step is to add ‘Endpoints’. In my case, I added two external ones, each one pointing to the external IP addresses of my two Parallels RAS environments:

3. Looking at my traffic manager profile configuration this is now what is seen (note I am using a simple TCP monitoring on port 443 as this is the only port opened from the outside to the RAS Secure Gateways. Of course you can use HTTP/HTTPS and then set the expected path/status code to determine the endpoint as healthy):

4. With everything added, yours should look like this:

5. The final step is to go into the DNS settings for your domain and create a CNAME record for the FQDN you will use for your users (i.e. ras.company.com) pointing to the FQDN created for your traffic manager profile (i.e. ras-gslb.trafficmanager.net). Simple.

6. As this is a Parallels RAS environment (but again, could be RDS, Citrix or VMware) on my Parallels RAS client, I configured it to connect to my FQDN, ras-gslb.wtslabs.com. When launching it and logging in, this is what I see:

Going into the endpoints in the Azure portal and disabling the top priority one, once I refresh the Parallels RAS client, this is what I get:

This is done by just refreshing the client. No need to do a DNS flush (as the TTL is set to 10 seconds on Azure) or even close the client! It is that simple.

Now the beauty here and what makes this way more powerful than traditional GSLB IMHO is the fact you can use PowerShell to retrieve metrics from the environment, metrics the NetScaler GSLB is not even aware of. For example, total number of ‘Active Sessions’ for the environment, CPU/Memory utilization on any server part of the environment (i.e. a highly loaded file server or database), etc. Anything really. And still, with PowerShell you can easily flip the endpoints on Azure. This is an example of the code required:

To login to Azure (of course assumes the Azure PS Module is there)
Connect-AzAccount

To get a subscription:
Get-AzSubscription

To set the default subscription:
Select-AzSubscription -Subscription "My Demos"

Adding a profile with two External endpoints:
$profile = New-AzureRmTrafficManagerProfile -Name myprofile -ResourceGroupName MyRG -TrafficRoutingMethod Priority -RelativeDnsName ras-gslb -Ttl 10 -MonitorProtocol TCP -MonitorPort 443
Add-AzureRmTrafficManagerEndpointConfig -EndpointName DC1 -TrafficManagerProfile $profile -Type ExternalEndpoints -Target EnterIP1 -Priority 1 -EndpointStatus Enabled
Add-AzureRmTrafficManagerEndpointConfig -EndpointName DC2 -TrafficManagerProfile $profile -Type ExternalEndpoints -Target EnterIP2 -Priority 2 -EndpointStatus Enabled
Set-AzureRmTrafficManagerProfile -TrafficManagerProfile $profile

Modifying the endpoints:
$profile = Get-AzureRmTrafficManagerProfile -Name myprofile -ResourceGroupName MyRG
$profile.Endpoints[0].Priority = 2
$profile.Endpoints[1].Priority = 1
Set-AzureRmTrafficManagerProfile -TrafficManagerProfile $profile

And as i mentioned on Twitter, if you are running two NetScaler Gateways (the cheap USD 995 ones), one on each datacenter, you can create a GSLB setup using the Azure traffic manager. No need for any SKU that gives you GSLB. Considering how cheap this is on Azure, it will take years and years of Azure charges to make up for the money you save by going with the cheaper SKU.

More than that and as mentioned, this works with RDS Gateways, VMware Horizon Connection Servers and any other solution really.

So give it a try and let me know what you see.

Cheers.

CR

It is here. RDS-to-RAS Migration Tool

As promised earlier, here you have it. Before you download it and give it a try, let me explain a couple things about this v1.0:

  • It is indeed a working progress and I am adding a couple more little things to it.
  • You must run the script/tool on the actual RAS Publishing Agent server (the connection broker) and of course with proper credentials.
  • Make sure the Windows Firewall on the RDS Connection Broker you are pointing to allows that.
  • Things that do work properly:
    • Imports RDS ‘Session Collections’ into RAS ‘Groups’.
    • Imports all the ‘RemoteApps’ in a ‘Session Collection’ as published applications into RAS.
      • If an application is set not to be shown under the RDS Web Access, it will set the application as ‘Disabled’ under RAS.
      • Application folders are supported. It will create on RAS the same folder structure you see on the RDS Web Access (defined using the RDMS).
      • Imports the icon for all RemoteApps.
    • If there are no ‘RemoteApps’ in a ‘Session Collection’ that means a ‘Remote Desktop’ is published (the Citrix ‘Published Desktop’ equivalent). In that case, it does create a RAS ‘Published Desktop’ for that RAS ‘Group’.
  • Things that do not work (yet):
    • I explicitly decided not to install the RAS Agent on the RDS Session Hosts being imported. Firewall could play a role here.

Little warning: I do believe error traps are for wussies. Reason why my script does not check if you entered a proper RDS Connection Broker, RAS PA, etc. I assume you know your shit and can type properly. As you see I have very low standards. Assuming you can type AND you know the server names you have to connect to, the script works great. So if it is not working you can safely assume it is your fault.

Seriously I will add some error checking on the next release. Just wanted to get the tool out so you guys can give it a try.

Any questions, suggestions, feedback, etc, drop me a line or leave a comment.

Cheers.

CR

601 total views, 1 views today

EUC University

In the age of YouTube and the Internet, yes, you can indeed find all the information you need about a particular topic. The thing is, like when I wrote the RDS Complete book, at least for me, the main issue with this approach is the fact the information may be available all over the place, from multiple sources and each one with a different writing/teaching style. That is why being able to find all I need about a particular topic in one spot, is extremely important IMHO.

That brings us to my new community project, the EUC University. The idea is simple: have very short (where possible) videos with accompanying guides (PDF of PPT) about EUC related products. You can about it as a PluralSight in ways but totally focused on RDS and as our first one, Parallels RAS.

Also as I am creating these for people with experience with other products (Citrix/VMware) all the information you need to understand how to translate the components seen with these into RDS/RAS will be clearly explained before you touch anything. That will give you a very good picture on how these two platforms and their components related to the components seen on Citrix Virtual Apps and Desktops and VMware Horizon.

As mentioned, I am starting this first with Parallels RAS and once it is done, get the RDS part finalized. For the RDS the idea is to have the book is the guide you will need (or should) to follow.

Stay tuned.

Cheers.

CR

Microsoft RDS to Parallels RAS Migration Tool

Contrary to what most people may think, I always prefer to use the right tool for the job. Reason why I do believe there is a market for all the EUC products out there. That said, you have to be blind to think any of these are amazing and flawless. Far from that. Citrix Virtual Desktop and Apps has many infuriating things under its belt. The same applies to VMware Horizon, Microsoft RDS and of course Parallels RAS.

That said, if you want a simple and inexpensive product to deliver applications and virtual desktops remotely, and once again, depending on your needs, Parallels RAS may be all you need. As I am quite familiar with the product and I am part of their Parallels VIPP community program, I decided to put together a quick PowerShell based tool, with a proper GUI, to migrate a Microsoft RDS deployment with all its collections, to a Parallels RAS based one.

It is still a work in progress and it should be available quite soon. If anyone is interested on giving it a try, please just let me know and I will contact you.

Cheers.

CR

2,114 total views, no views today