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.
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.
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:
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:
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:
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.
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:
If you deploy a cloud RemoteApp collection you will be:
Microsoft supports a variety of client operating systems with Azure RemoteApp:
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.