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.

CR

811 total views, 1 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.

CR

2,160 total views, 10 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 ‘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,207 total views, no views today

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

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

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

1,397 total views, 4 views today