Is UPD now FSLogix? Taking a look at the FSLogix acquisition by Microsoft.

Perfect timing I guess. A couple weeks after I released the whitepaper I wrote showing how UPD compared to FSLogix, Microsoft decides to open its wallet and acquires FSLogix. I am sure someone at Microsoft did read the whitepaper and understood that UPD needed a revamp and that it would probably take them a long time to fix it than opening their wallet. Very happy to see this happening. With that in mind, let’s take a look at what this potentially means to everyone in the industry.

I am not going to discuss the existing UPD limitations and how FSLogix can be used to complement it or to fully replace it. You can read all about that on this blog post.

The question now that many are asking themselves is simple: will this be part of a cloud-only offering, like Windows Virtual Desktops is as of today? The answer, no one really knows for sure. Probably, not even Microsoft.

The main thing is, UPD, even though it is a much better solution than traditional roaming profiles, still suffers from many issues, no matter if you are hosting your solution in the cloud or not. At the end of the day, you are still accessing a Windows OS and given how it works, a profile is always required (even if it is a local one).

If UPD 2.0 (that is how I will call the FSLogix offering, now under the Microsoft umbrella) does become what FSLogix is and more, it makes no sense to tie it to a cloud-only offering. The reason for that is simple. First of all, having to deal with two different solutions for on-premises and cloud based deployments. Considering many are still fully on-premises and some are in a transition mode (one that may take years), forcing customers to have to deal with two completely different solutions, especially when in a hybrid deployment, could lead to a terrible end-user experience, where things do not work smoothly regardless of its location.

And that is something that Microsoft is trying to avoid at all costs at this stage. If the plan is to turn Microsoft into an utility company, where you pay your monthly bill exactly the same way you do with your cable, natural gas and hydro, it has to behave exactly the same way as everyone is used today. To the point that no one can tell the difference where it runs or how it behaves. Once that is the case, almost certainly a transition to the cloud will be just a natural evolution of an on-premises environment. Simple, effortless and more than that, painless.

Making such solution a cloud-0nly offering creates this gap between what is there right now and what will be there in the future, simply creating push back from customers, instead of promoting adoption. Reason why I do believe that Microsoft will do something regarding WVD, making it available on-premises. To simply make the transition to a cloud-hosted WVD simple for anyone using WVD on-premises.

Yes, luring customers, instead of forcing them.

Now it is worth mentioning that Office 365 is far from being a Windows only offering. Many use it from mobile devices running iOS and Android and of course from non-Windows desktops. With that in mind, to make the Office 365 experience the same no matter where/how you use it, Microsoft has to fix more than profiles. As per my twitter, the main one that comes to mind is printing. I do remember a session I attended during the first ever BriForum, in 2005. Yes, thirteen years ago. And guess what? The printing landscape is as bad as it was back in that day.

So Microsoft, please keep your wallet open and get Tricerat as well. That will give us, Office 365 users, a true world class experience, no matter where we are and what we use.

You know, like a true utility company, that does not care if I have a Vizio or a Samsung TV.

It just works.

CR

541 total views, 2 views today

RDS – The Complete Guide book. Present and Future.

Ladies and Gentlemen,

As you realized, the book I wrote with Freek Berson (awesome guy, great Microsoft MVP for RDS) is now out on Amazon, in both e-book and paperback versions. It is available here. Before you ask us or mention anything about the book, there are a few things I do want to explain the reason behind. So let’s take a look at some of these:

  • Book sucks as it is about Windows Server 2012 RDS. Well if you noticed, RDS on 2016 is pretty much identical to RDS 2012 R2. Very few differences. Same for Windows Server 2019, now in technical preview. Add to that there is way more production RDS environments based on 2012 R2 than 2016. Finally, the book provides a solid foundation that applies to RDS in general, not tied to a particular release. Learn all that is in there and you will certainly be able to deliver a solid RDS solution regardless of the version in question.
  • Certain chapters were sponsored what means you are biased. Well if you know me well from all the conferences I participated over the years, or as an MVP, you are probably aware of the fact when something sucks, I will be the first one to let you know. Over the years I told Microsoft everything I thought was horrible with RDS. Same with Citrix and its products. Did not matter the fact I was a Microsoft MVP for 17 years or a Citrix CTP for 9. For the book, after trying many products to address the RDS shortcomings (and there are indeed several), we truly believe the ones in the book are some of the best out there. And more than that, these are products we use on a daily basis. That is the only reason we reached out to these sponsors in the first place. It was not just about money to allow us to focus in the book but more like bringing to the public what we think are the top tools out there to make your RDS deployment much better.

With that in mind, so what about RDS 2016 and 2019? We are covering these indeed but as companion books. The idea is all the foundation you need is in the RDS 2012 book. The first one. Then, based on what your target platform is, 2016 or 2019, you just get the companion book to complement all that you learned from the main book. Simple. Also this allows us to release these smaller companion books at a much faster pace than what took us to get the RDS 2012 one done. The companion books to be released are:

  • RDS 2016.
  • RDS 2019.
  • VDI using Microsoft RDS.
  • Deploying GPU-based solutions with RDS.

These four should then cover RDS end-to-end, no matter the version and the scenario you have in mind.

I hope this clarifies a bit about the book and the plans we have for it down the road.

Cheers.

CR

899 total views, no views today

The rise of VHD-Based Profiles. And the marketeers.

I decided to write this post due to the fact I am getting tired of marketing people in general, always attempting to sell you something you may not need and worse than that, trying to spread fear all over the industry about other solutions. Before going ahead, let me make one thing clear: I truly believe every product out there in the EUC does have a reason to exist, beyond making money. They do address a particular need and certainly have their value and merit.

Now, leaving the marketing bullshit behind, that does not mean any of these products are the silver bullet, the one solution that will solve all your problems, with zero side effects. If you ask any vendor what the drawbacks are with their product and they have no answer to that, please, do yourself a favor and run away. Every single product has drawbacks and issues. Period. The key thing is understand these and how you can minimize or eliminate them (with potentially another product to complement the first one).

With that in mind, let’s have a quick chat about VHD-Based profiles, what seems to be the hotcake these days. If you are not aware of, Microsoft introduced User Profile Disks (UPDs) back in 2012 with Windows Server 2012. Yes, not even R2. That means whatever this is, it is SIX DAMN YEARS OLD. Got that? Six years in computer years is like 120 human years. Just to put in perspective (I do know you talk about dog years at home, so let me help you making things simpler) how damn old this is.

The idea behind UPD is very simple. The C:\Users\%USERNAME% folder gets pointed to a Virtual Hard Disk (VHD), a single file, sitting somewhere. How big can it be? No idea on the limits but I have used them set at 20, 40 GB without issues. That means every user will get a file that can grow up to whatever it was set to (i.e. 20GB) and that file will get mounted and linked to the user’s own C:\Users\%USERNAME% folder.

Right off the bat you can see that if you have let’s say 40 users connected to your RDS Session Host (XenApp for Citrix people), each user will have a profile folder with 20GB. That means 800GB for user data. Note the C: drive on the server is usually 60-100GB in size. This is possible as it is just a mount point. You are not using disk space off the C: drive but you are still able to have users with profiles that could be potentially bigger than the server drive itself. Nothing magical here and more than that and one more time, SIX years old. But marketing people want to make you believe they are now selling magical software that can magically make your local drive grow like Godzilla. Nope.

As it is a single file, when the user logs in, there is no need to download anything to the server drive. The mount point is established and you are done. Does not matter if the UPD has 2GB or 200GB. Logon time will be the same and as it is just a mount, it will be much quicker than using traditional solutions (i.e. roaming profiles). Here we have the marketing geniuses again, trying to make you believe you are buying an amazing technology that makes your logons much faster now that you are riding on Unicorns. I can make logons faster too and I do not even work at marketing, or have unicorns, just for the record.

Back in December I presented at the Citrix User Group in Israel, exactly about this topic. I showed it live on stage, two completely different solutions (Citrix XenApp and Parallels RAS) up and running, where the same user had UPD enabled. When he logged in to Citrix and did whatever he wanted and logged off, once he logged back in but now through Parallels, all the stuff he had done on XenApp was there on RAS. To add a nice twist to the whole thing, I had the Parallels environment on Azure. That means I was replicating UPDs ON THE FLY, LIVE, between an on-premises solution running Citrix and a cloud-based one running Parallels, for all my users. As you guessed, yes, a completely agnostic solution that does NOT care which product you have and where it is running. And the best part of all this, FREE. Yes, this is part of the Windows Server feature set. No matter if using VMware Horizon, Citrix XenApp or XenDesktop, Microsoft RDS or Parallels RAS, this works out-of-the-box and with all of them.

That said, is UPD perfect? Not at all. It has its limitations (i.e. cannot be mounted twice) like anything else. But it is certainly a powerful solution that is worth investigating and testing. Thing is, many companies realized that a long time ago and now sell their own solutions that in a nutshell use the EXACT same principle. Mount the user profile to a VHD and name it profile container, profile disk or whatever they want to call it. Are they better than UPD? For certain use cases, of course they are! FSLogix for example allows you to mount the VHD multiple times and does use its own filter drive that allows apps like OneDrive for Business to work under RDS. If you do need something like that, sure, take a look at FSLogix (as far as I know, Liquidware Labs does have a similar product, that addresses similar issues – may not address the SAME issues).

The lesson here is simple. UPD, profile containers, VHD-based profiles or whatever you want to call this, is not a new thing. It has been around for a long time. It is not something new or magical as many of these vendors try to make you believe. And what pisses me off the most is the simple fact they try to make you and the industry believe that UPD should never be used, that it sucks and so on, what goes completely against what I think that is always to use the RIGHT TOOL for the RIGHT JOB. Some vendors like FSLogix even got pissed at me with the whole UPD story. Seriously.

For the companies out there, stick to honest marketing and sales and educate your customers and the industry properly, clearly showing what can be achieved with the out-of-the-box solutions and what you bring on top of that.

For you, readers, at the end of the day, it is up to you to decide which tool you need and if you feel like using a screwdriver to put down some nails, go for it. After all, as my wife says, “Why do you have a Lamborghini to do your groceries?” and to that, I have no answer. But do not make the same mistake as I made and make sure you get a hammer to handle some nails.

Cheers.

CR

693 total views, 1 views today

RDS Modern Infrastructure. Modern?

As tons of people spend the week at sunny Orlando for Microsoft Ignite, here I am sitting at home, reading all these tweets and posts about what is next for Microsoft’s Remote Desktop Services stack, RDS for short.

If you read any of these, you are probably aware that Microsoft is changing RDS for the better (hopefully) and the new platform is being called as of today, RDSMi, a pretty term for ‘RDS Modern Infrastructure’.

The more I read about it, the more I think Microsoft has very little clue on what they have been doing with RDS since its early days, dating back all the way to 1997’s Hydra beta availability. And after seeing this ‘RDSMi’ acronym, I can also say with a pretty good degree of accuracy that marketing and its army of marketeers, are deeply infiltrated on anything RDS. As usual, I can certainly and clearly explain the reasoning behind my assumptions.

First of all, if you are not aware of that by now, I have been in the RDS business for quite some time. By that I mean I was probably deploying RDS for customers way before you got a degree and left school. ‘You’ does include many people in the RDS team in Redmond. And being an RDS MVP since 2001, I have seen it all at Microsoft for a very long time (16 years straight, yes, that long). Not only me but others like Benny Tritsch and even Alex ‘Bozo’ Cooper have experienced the same.

So what is the issue and why I am writing about this? Simple.

One of the biggest things the marketeers out there are now promoting and saying about this incredible ‘RDSMi’ thing is the fact many components now do not need to be domain joined. On top of that, if I am not mistaken, there is also an agent of sorts that is now on your RDS Session Hosts.

In other words, RDSMi is basically what we have been telling Microsoft that RDS should be in the past 16 years. Yes, that long. After getting tired of seeing nothing being done, back in 2003 we actually wrote AND released to the market an RDS Gateway that, guess what, was NOT domain joined! Probably sorcery and witchcraft but somehow I managed not to be burnt alive as a witch or warlock. If Microsoft is naming this new thing RDSMi, what was WTSGateway back in 2003? RDSFVi (RDS Futuristic and Visionary Infrastructure)? So please, there is nothing new or modern here.

What is even worse is the simple fact all this shows how Microsoft (and several other vendors in this industry, Citrix included) ask for feedback from MVPs, CTPs and so on and refuse to take it. Taking it 16 years later, at least for me, does not mean you took my feedback. They simply ignore the fact that people like you and me not only have been in this industry for probably way longer than most of the people in these teams but also that we are the ones architecting AND deploying such solutions in the real world. The hands-on people. Very different than saying ‘we listen to our customers and partners’ when what that really means is ‘we pay third party companies to do some research for us and this is what we got from them’. WITHOUT EVER DEPLOYING YOUR SOLUTION IN PRODUCTION, AT SCALE. Funny.

Resuming, and not to ruin your week at Ignite, Microsoft, especially in the RDS space, is just doing what many people told them over a decade ago. Nothing new here. I have to say I am not that easy to impress. But this, seriously? Good try. Maybe on the next Ignite.

For that reason, I am renaming ‘RDSMi’ to ‘RDS Meh Infrastructure’.

And marketeers out there, I am available in case you need some better marketing work.

CR

2,092 total views, no views today

How-to: RD Gateway behind a NetScaler

Before jumping in on how to get this done, let’s take a step back and review what the problem is and why this makes sense.

The Issue

If you are cheap and like to run your labs (or parts of it) at home, that probably means you have a single IP address available and exposed to the outside world and either no way to get a second one or no money for it. Basically you are like me.

That poses a problem when you want to have in your lab everything you can throw at it and still make sure it is all accessible from the outside, over that single IP address. That may include things like a fully functional RDS environment (with RD Web Access, RD Gateway, etc), a XenApp/XenDesktop one and even VMware Horizon. Problem is as soon as one is up, you will have to point your firewall to the internal resource that is doing whatever role (i.e. RD Gateway) and now port 443 is gone. Sure you could then start doing other services on different ports but that creates a mess. Not only not everything allows you to use different ports but having to open several ports to the outside creates a problem. This is the problem in a nutshell.

The Solution

Well the solution is relatively simple and if I could do it (sure thing, with the help of Master of All NetScaler things and Citrix Technology Advocate, Dave Brett, http://bretty.me.uk), even a blind turtle can do it.

So what do you need? Here is your list:

  • NetScaler VPX. You can get the free version. It is limited bandwidth wise but hey, remember you are cheap and cheap people do not have more than 5Mbits down at home for sure. Also you will need a MyCitrix account.
  • One external IP address available (if you only have one, that is ok. After all this is the reason for this post).
  • Ports 443 and 3391 available (TCP 443, UDP 3391).
  • One Content Switch created on the NetScaler.
  • Policies and Actions that will tell the NetScaler where to send requests once it sees things like RD Web Access and RD Gateway traffic.
  • Couple internal IP addresses available.
  • The real FQDNs that people will use from the outside to reach whatever environment. For example, for the RD Web Access I normally use wa.company.com and for the RD Gateway, gw.company.com. Also it does not matter if both roles are on the same server or not. I tested both cases and both work just fine and it is done the exact same way.
  • A wildcard certificate. Unless you want to spend more time managing certificates, I highly recommend you get a wildcard one. If you are really cheap, you can even issue your own certificates by setting up a CA on Windows Server (not part of this article). No matter what you decide to do, remember you need the certificate, Root CAs (if issuing your own certs), etc all on the NetScaler.

Doing it

Ok this is not a step-by-step post in any way. But will give you a very good idea/understanding on how to do it. If you have no idea what a NetScaler is, I highly recommend you take a look at my BriForum session ‘NetScaler for Dummies’. That will get you up and running and ready to create what you will need.

First thing you need, two Content Switch virtual servers (same IP is ok but on different ports). Mine are shown below:

CS VIPs

This is where you will send your firewall to. Port 443 TCP and 3391 UDP will go to the internal IP address you used.

Next is to get three Load Balancing VIPs. One that will be the VIP to your backend RD Web Access servers (SSL) and the other two (same IP but two different ports) that will be the VIP to the RD Gateway servers. So basically in this example I am assuming you have two or more RD Web Access and two or more RD Gateways (for redundancy). You will end up  with something like this:

Load Balancing VIPs

Next you will need some Content Switch actions. This basically tells the NetScaler what to do when someone hits the Content Switch IP. Note that these are not the policies. The policies are the actual rules like ‘if anyone tries to reach wa.company.com, take action ACTION-WA.COMPANY.COM’. It seems odd to create actions first but once you understand the flow, you will see it makes a lot of sense.

So your actions will look like this (I have three, one to deal with the actual NetScaler Gateway – ICA Proxy, to my XenApp/XenDesktop environment and the other two, to deal with the RDS environment):

Content Switch Actions

If you open them you will see all they do is to send the connection to a VIP. The one for the XenApp/XenDesktop sends the connection to the NetScaler Gateway VIP. The other two, to the RD Gateway VIP you created above.

CS Action - ICA Proxy
CS Action – ICA Proxy
CS Action - RDWA
CS Action – RDWA
CS Action - RDGW
CS Action – RDGW

Next step is the policies. As I said, this is where the magic happens. Simple stuff as well. What you need is this:

Content Switch Policies
Content Switch Policies

Let’s take a look at the details of what is going on here:

CS_POL_ns.iqbridge.ca: this policy checks if someone is trying to hit ns.iqbridge.ca and if that is the case, it uses the CS_ACT_ns.iqbridge.ca that is tied (as seen above) to the NetScaler Gateway VIP. Basically it will send people to that VIP.

CS_POL_wa.iqbridge.ca: this policy checks if someone is trying to hit the RD Web Access at wa.iqbridge.ca and if that is the case, it uses the CS_ACT_wa.iqbridge.ca that is tied (as seen above) to the Load Balancing VIP for all your RD Web Access servers.

For the RD Gateway, things are a bit more complicated, due to what the RDP Client tries to do. That is why you need three policies. The idea is still the same. If the client attempts to reach anything that matches these three policies, they are sent to the Load Balancing VIP for all your RD Gateway servers.

The final step is to bind these policies to the Content Switch VIPs you created at the beginning. For the SSL traffic, as we need to check where the connection is going, we do need to bind these policies:

CS VIP SSL - Bindings
CS VIP SSL – Bindings

For the UDP one, there is no policy as all you want to do is to send all traffic to the Load Balancing VIP of the RD Gateway (UDP 3391):

CS VIP UDP - Bindings
CS VIP UDP – Bindings

That is it! Once you do this, you will be able to access your RDS environment from the outside through your RD Gateways, all load balanced. Not bad at all. And all this without losing the capability to reach your XenApp/XenDesktop through the same external IP address and port.

If you have any questions, just shout. As I said, this does work and works great.

CR

9,456 total views, 2 views today

RDS-O-Matic for Windows. It is ready!

It is show time people. Just want to show you the native RDS-O-Matic Win32 app. I had time to port if from the Excel spreadsheet idea and it is not only small but works like a champ.

I know Alex (Twitter @E2EVC) will be complaining about its GUI but hey, for a tool that is this simple there is no need for a fancy GUI. People want apps that work and are simple to use. That is the bottom line and this is what you get with RDS-O-Matic.

So here you have it, on all its glory.

Just want to remind you guys one more time that RDS-O-Matic will be officially released at PubForum (E2EVC) Dublin, in June 2016.

Cheers.

CR

 

14,329 total views, 2 views today

RDS-O-Matic live in the wild.

Ladies/Gentlemen,

Just a quick post to show you RDS-O-Matic in action. I just updated it to match what we have on the book I am releasing with Freek Berson. As I mentioned before this little handy Excel spreadsheet (Windows app will be ready and released at E2EVC Dublin) right now does the following:

  • Creates a complete RDS deployment with:
    • 2 RD Connection Brokers
    • 2 RD Web Access servers, load balanced using NLB on port TCP 443.
    • 2 RD Gateway servers, load balanced using NLB on ports TCP 443 and UDP 3391.
    • 2 RD Session Host servers with the desktop experience loaded.
    • 2 RD Licensing Servers, activated and set to whatever you choose (Per User/Device).
  • Creates a collection with the 2 RD Session Hosts on it.
  • Creates a test published application, WordPad, so you can try the environment immediately.
  • Enables HA on the RD Connection Brokers. For that you need to have SQL ready to go, the folder where the database will be stored has to be created and permissions for the RD Connection Brokers set. This is all detailed and explained in the book. We even cover the actual SQL install.
  • Retrieves the certificate (you enter the location for the certificate in PFX format) and deploys it to all roles. Here I assume you will be using a single, wildcard certificate for all the roles. If not the case, you can easily change the script you get to use different certificates.
  • Final warning, you must have the output folder created before you hit the ‘RDS-O-Matic’ button (i.e. C:\RDSOMatic).

Now that I am back at developing for iOS, is there any value in creating an iOS app that you can enter all this info and it will email you the script ready to be deployed?

Let me know.

Cheers.

CR

9,346 total views, 1 views today