Is Microsoft going to replace Azure RemoteApp with a new platform?

Microsoft endorsed cloud-based Windows applications with Azure RemoteApp, but will that be giving way to something new at Ignite?

In May of 2014, Microsoft revealed Azure RemoteApp to the world. It was a big step for Microsoft because it finally showed the world that they, too, were buying into the concept of delivering Windows applications from the cloud. It came just in the nick of time, too, because we’d already deemed 2014 to be “The Year of DaaS” due to all the other activity going on in the space, even going so far as to write a book about it. Nearly everything in that book is still relevant today–except for the fact that there’s no mention of Azure RemoteApp (ARA).

Microsoft has the ability to slow down industry-wide adoption of a specific technology until they’re good and ready, and though DaaS seemed perfectly happy to keep on trucking along in spite of Microsoft’s lack of an offering, the release of ARA instantly made something that seemed a little risqué into a plausible, supported, even endorsed strategy.

Unfortunately, we haven’t seen widespread adoption due to technical challenges, and that combined with the recent developments between Citrix and Microsoft have me questioning ARA’s future.

Problems with ARA

ARA’s issues don’t stem from the high-level, conceptual stuff. It’s the low level onboarding and day-to-day stuff that makes it a difficult platform to use. There are good things about it, for sure (Benny Tritsch and Freek Berson called the HTML5 client a “hidden gem” in their BriForum 2016 London session about ARA), but not enough to place ARA in the position as the de-facto cloud-based application delivery platform.

Among the more challenging shortcomings of ARA are:

  • No load balancing
  • Slow clone times to spin up new instances
  • Clunky user management
  • No per-app publishing
  • Updating applications requires third party help or user downtime

Let’s quickly look into each one of these, starting with the lack of load balancing. On the surface, you might think that Azure’s “Elastic Runtime” is some sort of load balancing, but in fact it’s merely an average usage calculation that determines when to spin up clones to support your users. It looks at your usage over the week and spins up enough VMs to support your users at any given time. Users are added sequentially until the first VM is full, even while other VMs sit there unused. Microsoft can tweak the scaling algorithms or provision all the machines at one time, but there is still no proper load balancing.

When you reach the capacity of a VM and there are no more templates already running, ARA will spin up a new clone of your template to accommodate more users. This cloning process uses the same kind of cloning technology we had back in 2008 – basically SysPrep – and can take as long as ten minutes to complete! There is no fast provisioning built in to the platform.

User management can be a challenge because adding and removing users has to be done one at a time. There is no ability to add users to applications based on AAD group membership. There are ways around this with CSV file imports and PowerShell scripts, but it appears Microsoft left out functionality that is basically expected these days.

Similarly, applications cannot be published singularly. Rather, when you create a collection (their word for a pool of VMs built upon a single template), any user assigned to that collection sees all the applications. If you want to control which applications a user sees, you need to create multiple collections with different sets of applications in them. That’s a fine approach, and not too dissimilar from some old-time SBC strategies, but it means that you end up with far more template images to manage.

Last, with regards to the template images, if your applications are part of the template and you need to update them, you must deploy a new template and force your users to log out and back in again. This isn’t necessarily the end of the world, but the more templates and collections you have, the more challenging this becomes. This kind of situation all but requires you to have some sort of third-party application management platform, which is why you see companies like Unidesk and CloudHouse coming out with Azure-specific offerings.

Starting over

So now you can see that in spite of the fact that we all love Microsoft’s big endorsement of cloud-based Windows application delivery, there are some issues to overcome. Ordinarily, I’d call this a “v1” product and wait to see what happens, but now that Microsoft has relaxed their multi-tenant licensing jargon for Windows 10 Enterprise, I’m wondering if something else is coming down the road.

Nearly everyone expects Microsoft to do something with a proper Desktops as a Service offering in the near future. Heck, Kirill Tatarinov even said that they would be working with Microsoft to create a Desktops as a Service offering during the Synergy keynote (at 49:30 in the video). That could come as soon as Microsoft Ignite this September, and if it does happen, I can’t imagine they’d base it on the same problematic platform ARA is currently running on. If they have trouble supporting ten users on a VM, imagine trying to scale this out with one user per VM! VMware, AWS, and all the other DaaS providers would laugh at that half-hearted attempt.

With that in mind, I think Microsoft will be announcing a new platform designed to deliver desktops and/or applications. If that happens, ARA will be retired, but there would probably be a migration path for customers. Odds are it wouldn’t be too troublesome given the fact that the VMs and templates would likely be compatible. Whatever happens, I’m excited to see what comes out of Ignite this year. As I mentioned before, Microsoft has a knack for holding down a market until they’re ready, then blowing it up when the time is right. I think that day might be quickly approaching.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I don't think Load Balancing is required because RemoteApp uses OS Isolation, where each user is running a dedicated Windows 2012 R2 Server session behind the scenes. But I see other limitations that I don't think were mentioned above...


1. The OS Isolation approach also means that the first application launch is consistently slow for every user while their VM boots-up (> 1 minute - you can watch the VM start-up by clicking the "Details" radio button). To some people that may be OK because you get greater stability in your own VM versus the 1:Many Process Isolation approach with Citrix
XenApp. Also, subsequent application launches are fast because the user's VM session is already running. But most end-users expect a quick start-up consistently.


2. You have to stack applications onto a single VM template (i.e. Collection) versus the application silos that you would create with Citrix XenApp to optimize performance and availability. You can purchase additional Collections per user, but that gets expensive and only partially addresses the problem.


3. Print traffic uses the display protocol so there is no chance for QOS to prevent a large print job from impacting other users.


4. Patch one application and you have to regression test all other apps installed in the same Collection (i.e. VM template). Operations cost go up.


5. No ability to pass the Windows credentials already entered when using a Windows PC device. My client was surprised when they had to enter multiple credentials while their old Citrix environment brought them right to their application icons.

Thanks for that feedback. Even if Load balancing isn't a problem, it seems like there is a lot of work to do. I'm very curious to see what happens, especially since nothing has been said about licensing or Azure DaaS since Synergy.