The WVD announcement and how Citrix screwed it.

If you ended up here to read this, two possibilities:

  1. You have heard about the Windows Virtual Desktop (WVD) announcement yesterday by Microsoft.
  2. You work for Citrix.

Great. I love a great audience.

Before we move ahead and discuss the main topic on this post, how I do believe Citrix screwed it one more time, let’s first briefly cover what Microsoft announced yesterday.

My previous post on the subject, was pretty accurate on what was announced. You can read about the whole thing here. In a nutshell, as expected, WVD is indeed RDmi 2.0 and really a cloud service, providing the services that as of now were done by the RDS components we all know about (RDS Broker, Web Access, Gateway). All this done for you on Azure. Your resources (the machines where the user workload will run) connect to the WVD control plane using an agent. Simple.

Just for the record, on top of the announcement, making WVD available to the general public, albeit still in its ‘Technical Preview’ form, Microsoft also announced that FSLogix and its profile container solution will be available to pretty much everyone on earth shortly (what we predicted as well, mentioning that UPD 2.0 would be FSLogix).

With the basis covered, now let’s talk Citrix. And why I believe Citrix did an extremely poor job explaining the value it adds to the whole thing.

First of all, Citrix does NOT extend WVD. No matter what they say, that is NOT the case. It is like someone saying that a Ferrari extends a Volkswagen. It replaces the damn thing. Simple.

As we know WVD is a whole solution, with a Microsoft provided control plane on Azure, controlling several workloads, from Server OSs to Desktop OSs, all hosted on Azure. That now includes the multi-user Windows 10 workload type. Many people still think WVD is Windows 10 multi-user. It is not the case. Again, it is a platform and more than that, with its OWN control plane.

What is Citrix doing then? Simple and I knew you would ask. They are simply supporting under their OWN cloud-based control plane, A.K.A. ‘Citrix Cloud’, the new workload types. This is exactly what the video that Citrix posted shows. You can see it here on YouTube.

It is exactly the SAME thing they have been doing for ANY workload. Simple. That new workload shown on the video, yes the hot-off-the-press Windows 10 multi-user, is running on Azure but it is NOT a WVD workload. Again, WVD means Microsoft control plane, RDP and so on. If you are using the ‘Citrix Cloud’ and HDX, that is NOT WVD. Period.

By saying it extends WVD, IMHO, Citrix is just making the industry, its customers and even shareholders confused. All the sudden, and thanks to the wrong message, people start wondering if they should then put their ‘Citrix Cloud’ projects on hold and wait until WVD goes GA as they will be able to hop on the Citrix bandwagon as Citrix wrote all over the place that it is ‘extending’ WVD.

The correct message here is simple. Citrix and its ‘Citrix Cloud’ is a much more flexible cloud-hosted control plane (note the word ‘hosted’ instead of ‘based’ – big difference) than WVD as of today. It allows you to host your resources anywhere (on-premises, in the cloud – any cloud, and even using physical PCs) and on top of that, brings its class-leading remote protocol, HDX, not to mention additional bells and whistles like WEM, AppLayering and so on to the table. And can add support for new workload types when another major vendor, in this case Microsoft, releases them. As it did for the new Windows 10 multi-user one.

The paragraph above clearly shows that Citrix is embracing the new workload types under its own cloud solution and how it differs from the Microsoft one. No confusion and right to the point, clearly showing its advantages (in case you need them).

You may or may not agree with what I just wrote but I am certain that we do have a lot of people confused by what Citrix announced/wrote. If it were me, the person behind such a confused and again, IMHO, inaccurate message, would be gone by now. But hey that is just me.

To Citrix, please do a better job when hopping on the hot news announced by a major partner like Microsoft. Make it clear and simple for your customers to understand it. Simple as that.

If I want to be confused, leave it with me; I can certainly call Microsoft and ask about RDS Licensing.


2,022 total views, no views today

What we know so far about Windows Virtual Desktops. Yes, here we go again.

My last blog post about WVD created a huge discussion on Twitter and in less than a couple days already reached close to 1,500 views and for the Twitter specialists out there, over 6,500 impressions with a healthy 17% engagement rate.

All that was written in that post was based off what we knew from Microsoft Ignite and further interactions on Twitter with several people, Scott Manchester included. If you do not know Scott, he is the Group Manager for RDS within Microsoft.

Of course given the fire that was out due to that post, he read it and a couple days later replied to my tweet with the following:

And right after, he replied to someone else’s question:

With that in mind, what did we learn and what can we deduct from all this?

  • Windows Virtual Desktop (WVD) seems to be what RDS (or more precisely RDmi) will be called moving forward. So it is more like a brand name for an umbrella of solutions running under it. That includes Windows Server 2012 R2 to 2019 (with the RDSH role we assume) and any desktop OS from Windows 7 (assumed to be SP1) to the latest Windows 10 build, with or without its new multi-user capabilities enabled.
  • If you decide you do need Windows 10 with multi-user capabilities, you can have it, as long as that machine is running on Azure.
  • Why did I mention RDmi (what stands for ‘Remote Desktop Modern Infrastructure)? If you do not know what RDmi is, the short version is, it was supposed to be an Azure service that replaces all the RDS components (except RDSH). With RDmi, the control plane (brokering, web access, gateway) runs as a service on Azure. Then, on all the machines you want to make available to your users, you load an ‘agent’, similar to what the Parallels Agent or the Citrix VDA does. Based on Scott’s reply, it seems that WVD will be that. All the control plane made available on Azure. You then load this ‘VDA’ on any machine you have either on-premises or in the cloud. As he does not mention anything regarding physical vs virtual machines or even which clouds, I have to assume that you could even load the ‘VDA’ on a physical box (server or desktop OS) and even on VMs running on different clouds (i.e. AWS). The only exception to this, as per his second reply, seems to be Windows 10. If multi-user, it has to run on Azure. Otherwise, as long as you bring your own licenses AND reach the minimum number required, it seems that you could host Windows 10 single-user on AWS, with the control plane on Azure.

I think this is exactly what WVD is and what it means for everyone trying to understand the mess created given the information relayed during Ignite and the lack of information thereafter. As I mentioned to Scott on Twitter, the key thing is proper communication with the industry and their own customers. After all they are not Mickey-Mouse software house, even though sometimes it appears to be the case.

So resuming:

  • WVD seems to be a much bigger thing, an umbrella for all what we know today as RDS (RDSH or VDI).
  • Its control plane will be potentially an Azure thing, with no need anymore for the traditional RDS roles (broker/web access/gateway).
  • If you need Windows 10 multi-user, you need Azure.

Keep in mind this is what we know as of February 2019 and as I am no longer an MVP I may be completely wrong. On top of that, as before, there is nothing that prevents Scott from going on Twitter and posting that I am insane and that WVD will run on any cloud and on-premises as well. And support Windows XP as long as you pay huge amounts to Microsoft.

Until then, take all this with a grain of salt. A bag actually.


1,171 total views, no views today

The Windows Virtual Desktop (WVD) BS.

Of course after all these years listening to the doomsday fanboys that every year would be the year of VDI, people got tired of that joke. Knowing the EUC industry likes a good joke, Microsoft had to come up with something.

So for your amusement, Ladies and Gentlemen, Microsoft brings you Windows Virtual Desktops! WVD for short or just Windows Virtual Delusion as I decided to call it.

If you follow the right people on Twitter, you will notice that my ol’pal Steve Greenberg tweeted this:

” Well Thin Client/Server Based Computing has come full circle. Excessive application resource requirements and various compat issues, mostly with OS patches, are introducing scalability issues and stability problems on shared server OS pushing VDI to be increasingly preferable “

Translating this to plain English, he is implying that due to compatibility issues and patches in a SERVER OS platform (i.e. Window Server 2016, Windows Server 2019), VDI is growing. We can logically imply that if VDI is being used for that, this means VDI has way less compatibility issues AND is virtually immune to OS patches. This is not my analysis though; this is simply what is written in that tweet.

Now, where is the problem? First of all, if you are using Windows 10, you probably noticed the damn thing is updated more often then you recharge the battery on your Windows 10 device. In other words, a nightmare for users (and therefore, to IT). Sure you can stick to Windows 7 for VDI, Assuming you do that, then the compatibility issue should be either bogus or non-existent as the apps in this case are so old that it is almost certain people already found ways to run these apps on a Server OS either by using something like App-V or by fixing whatever had to be fixed with the stupid app.

But what about Windows 10 and app compatibility? If we leave Office out of the picture for now, most LOB apps were NOT developed specifically for Windows 10 and should either work just fine on Windows Server multi-user or require minor tweaks to get it working.

Regarding resource requirements, Windows Desktop OS or Server OS should not matter. Worst case I simply give a single server VM to the user, what VDI does. Simple.

Now bringing Office to the picture, the story changes. Before we get to that, let’s take a look at the whole WVD thing that by now you know it is an Azure thing only.

If you remember, a couple years ago Microsoft brought us another joke: ARA. If you are not aware of what this is, you can stop reading here and close this post. Azure RemoteApp (ARA) was Microsoft’s attempt on having an Azure based service to host applications for companies out there. When it was being planned, many people in the industry (mostly Microsoft MVPs), when asked by Microsoft about their thoughts regarding it, explicitly told them it would fluke. It would fail like the Titanic did.

Thinking that most MVPs are idiots, Microsoft told us (at the time I was an MVP) we were wrong and that ARA was the next big thing. In ways they were right. It was the next big thing that would fail miserably, pretty much a cloud-based Microsoft Bob.

Fast forward to 2018, with Microsoft and a pile of other companies trying to shift their revenue model to a cloud-based one, Microsoft now brings us WVD. With it, it brought requirements/limitations that force people to use Azure. First, it is only available on Azure. Secondly, do you need Office 365? Guess what, Office 365 will no longer run on multi-user Server OS (RDSH) but wait, it runs on multi-user Desktop OS (WVD). What means, you have to go for Azure.

The bottom line is, they cannot fail one more time with a solution to deliver Windows apps and desktops on Azure. ARA was ugly enough. If they screw it up again, I can bet many people will be invited to work for Amazon or Google.

The beauty here is, no matter what you and I think, you have no option. Cloud will be pushed down your throat and you will have to use WVD, like it or not. At least based on what we know today. If there is enough push back on this, maybe and a HUGE maybe, we may see WVD (multi-user Windows 10) as an option for on-premises deployments. But do not count on that.

Now on the Office topic: Office and Office 365 are different beasts but in many cases these are treated as the exact same thing. Most LOB apps as we know, could not give a bigger shit if I can save crap to OneDrive or not. Or if Microsoft Teams is available. For LOB apps, Office means Excel, Outlook or Word integration. Everything else is irrelevant. This probably means Windows Server 2019 with Office 2019 should still be able to work just fine with the LOB apps, assuming these do not have specific ties/requirements for a particular Office version. Of course for users not using these LOB apps, and simply relying on Microsoft Office as they know on their own devices, Office 365 may be what they want/need. What leads us to the right tool for the job. Two platforms, one delivering the LOB apps, one delivering Office 365, what is just fine with me.

So before you put the nail on the RDSH coffin, please remember ARA. Take a minute of silence remembering how many hours of PMs, developers and marketing that died in vain. And keep in mind that WVD may be the next ARA.

Resuming: be careful about the boat you decide to board. The Titanic was all pretty and shiny and we know what happened with it.


3,145 total views, 7 views today

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 ‘’ 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 ‘’.

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 ( 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 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.


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 This means if you choose rds-gslb, your unique name will be

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. pointing to the FQDN created for your traffic manager profile (i.e. 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, 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)

To get a subscription:

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.



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.



600 total views, no 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.



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.



2,114 total views, no views today