5 Reasons Why I Like Microsoft Azure RemoteApp

In June 2014, Petri IT Knowledgebase Contributing Author Simon Bisson wrote an article about Microsoft Azure RemoteApp. His article was pretty complete, but times have changed and so has RemoteApp since it became generally available. In fact, RemoteApp is very different, and it’s become one of the more interesting features in Microsoft Azure. In this article, I’ll give five reasons why I’m smitten with Microsoft’s Remote Desktop Services (RDS) in the cloud solution.

1. Remote Desktop-as-a-Service (DaaS)

The concept of RDS is not new. Most medium-to-large companies have some form of server-based computing (SBC) solution, such as RDS (or based on it. Instead of deploying software onto each and every widely-distributed client device, RDS lets us distribute or locate software in a centralized fashion.

2. Streamlined software distribution

Imagine a company that has 200 computers. How will the IT guy install Office, a PDF reader, and line-of-business client apps on those machines? Is that person going to wander from machine to machine installing software from a shared folder? Hopefully not! They might use some sort of software distribution system, such as System Center Configuration Manager (SCCM), that returns the investment by being able to deploy and maintain software on those 200 computers with a zero-touch approach.
Times have changed and those devices have changed, too. And these devices are simply not PCs anymore, as there could be devices with different form factors running Windows, iOS, and Android. SCCM is great at handling corporate machines in mid-to-large locations, but it’s not Microsoft’s best solution for this scenario. Instead, you should look at Microsoft Intune, available as a standalone product and as a part of the Enterprise Mobility Suite (EMS) that was recently made available to small-to-medium enterprises via open licensing.
That’s one way to approach software distribution. Another approach that some departments like goes back to the latter half of the 1990s. One of the first solutions I was trained on as a newbie consultant was Citrix WinFrame, a solution type that we now know as XenApp or Microsoft’s native RDS. This form of SBC lets us install software on a few servers in a central location to make that software available to any authorized person around the world with pretty good performance. As a result, IT only has to manage software on a small number of machines and can make the software available to all kinds of clients.
With RemoteApp, we get RDS-as-a-Service, and it takes advantage of the scalability that Azure can offer. Do you need 25 users most of the time, but need to rapidly increase the user size by 200 for a two-month project? If so, you don’t need to buy and install hardware. Simply assign more user accounts, and you’re done.
In the case of widely-distributed workers, you have two advantages with RemoteApp:

• You don’t need to increase your on-premises bandwidth.
• You can locate RemoteApp footprints closer to your users by taking advantage of the global locations of the Azure regions.

3. Easy solutions to network issues

A number of the conversations I’ve had about Azure lately start with, “My customer wants to move their servers to the cloud.” At this point, I typically ask what kinds of clients do these services have? The lack of a positive response to my question is shocking. Let’s go back a step to some networking theory.
We have two basic measurements of network performance:

• Bandwidth: That American politician wasn’t so dump; a network is like a pipe. The bigger the pipe, the more water can flow. The more bandwidth you have, the more data can travel at once.
• Latency: This is the one everyone forgets, and we have little control over latency because it’s primarily dictated by the laws of physics. How fast can a packet get from the source to the destination? A ping test will show you the latency, which is measured in milliseconds. Latency is what controls interactive performance.

Let me make this real for you. Once upon a time, I ran the Microsoft infrastructure for an international bank that was based in Ireland. We had an awful backend finance system based on lots legacy stuff. This system needed to be made available to branch offices from New York to Tokyo with points in between. A user would open the client application and run a query off the back-end database. The application would run a subset of that query and pull back data to the client. This process would be repeated until all the sub-queries were executed and the data was merged locally and presented to the user. There are several problems with this approach:

• Security: We had lots of data travelling about the WAN that probably didn’t need to.
• Bandwidth: Lots of data was going across a WAN that was not budgeted for by the networking team.
• Latency: Each flow of data was broken into tiny packets of “send data” and “acknowledged receipt.” So a client in Dublin might operate at less than one millisecond of latency and have a great experience, whereas a client in Tokyo might have 200 milliseconds of latency and have an awful experience.

We could add bandwidth, but that only allows more users in each branch office to have the same bad performance. Instead, we needed lower latency. The solution we came up with was to move the client application closer to the server by using Citrix MetaFrame, which is now XenApp. The application was published to the desktops of users where it would run in a seamless window. But the application would actually run on a series of servers in the same computer room as the backend system. Even our most-distant colleagues in Japan noticed a huge leap in performance after this change.
So if we lift-and-shift services with legacy clients into Azure, such as a file server, then maybe we should do the same with the client too?
You can deploy RDS and Citrix XenApp into Azure virtual machines. Beware of licensing complications and remember that Azure scales out better than it scales up.

4. Removing complexity

Why make RDS a service in Azure? Azure gives us easier infrastructure deployment. RDS requires quite a bit of stuff to make it scale out and be fault tolerant. This stuff is quite complicated, which is why Microsoft gives us a wizard in Server Manager to hide all of that complexity.
RemoteApp is a much simpler system to work with once you understand it and its inadequate documentation. You can deploy applications using two models in RemoteApp:

• Cloud: This lets you publish client applications with no private networking connectivity. This is suitable for clients that are working with Software-as-a-Service, for example, quickly deploying Office Pro Plus to users of Office 365. In fact, there is even an Office 365 Pro Plus template that just requires users to activate one of their five Office installation rights.
• Hybrid: This is the more interesting model!

If you deploy a cloud RemoteApp collection you will be:

• Creating an uploading a custom Windows Server RDS session host with your own set of client applications
• Creating an Azure virtual network that can be connected to other on-premises or Azure virtual networks via a dynamic gateway VPN connection.

5. Robust client support

Microsoft supports a variety of client operating systems with Azure RemoteApp:

• Windows
• Android
• iOS
• Mac OS
• Windows RT
• Windows Phone

An administrator will assign a user to a RemoteApp collection, which lets the user see and use any application that’s published by IT in that collection. On Windows, shortcuts to the applications are presented via a client that the user logs into. Opening an app logs the user into an Azure virtual machine that is managed by Azure (created from your template in the cloud model) and the application opens in a regular window on the desktop. The experience is pretty good, where I can work at my PC in the office, start my commute home, and then log in via my tablet to pick up the same session with my applications still open.
Certain elements of Azure IaaS, such as virtual machines and ASR, are getting all of the press. But, in my opinion, RemoteApp is a critical feature for connecting users to the solution. Although it takes time and effort to learn how to implement some of the more interesting solutions, you’ll want to visit the Petri It Knowledgebase in the coming weeks for additional tips and solutions that I think you’ll find helpful.