In-Depth

First Look: Microsoft Azure RemoteApp

The new Microsoft Remote Desktop Application as a Service is now available and takes traditional RDP to a new level.

• By Brien Posey
• 01/30/2015

As users make the transition away from traditional desktop PCs to all manner of mobile devices, appli­cation delivery and application compatibility become increasingly challenging issues. Organizations still largely depend on a variety of Windows-based line-of-business applications. However, these applications are typically not natively compatible with mobile platforms such as the Windows Runtime, iOS, Android or Windows Phone. Because the adoption of mobile consumer electronics devices in the enterprise has become such a pervasive trend, a number of different application delivery solutions are now available from a variety of players.

Microsoft's latest attempt to address the challenge of delivery of Windows applications to non-Windows devices is the company's new Azure RemoteApp. Introduced last spring, Microsoft released Azure RemoteApp at the end of the year. It's similar to Windows RemoteApp in that it allows organizations to stream applications to devices through a Remote Desktop Protocol (RDP) session, even if the device isn't natively capable of running the application. All the device needs is a native RDP client.

Azure RemoteApp is available on a subscription basis. The $10 per user per month Basic Plan is for employees typically dedicated to a specific task using simple Web apps, while the $15 Standard plan is for knowledge workers who use the likes of Microsoft Office. The company issued a detailed price plan, which is available here.

Planning Your Deployment
As you consider using Azure RemoteApp to deliver applications to devices, you must decide on the type of deployment you want to create. Microsoft gives you two options: You can create a cloud-based deployment or you can create a hybrid implementation.

A cloud-based deployment is the easier of the two options, but it isn't appropriate for every organization. A cloud-based deployment is less complex than a hybrid deployment because the deployment exists solely within the Azure cloud. You don't have to involve back-end infrastructure on your private network. When you create a cloud deployment, Microsoft provides you with Office 2013 apps that you can make available to your users. Of course, most organizations will likely have additional appli­cations they need to publish. For that you have the ability to build a custom template image.

Like cloud deployments, hybrid deployments allow you to make applications available to your users. However, hybrid deployments offer the distinct advantage of allowing the applications to run in a domain-joined environment, which makes it possible for users to access data on your private network through the application.

Considerations for Custom Templates
The custom template lets you make custom applications available as Azure RemoteApps. The template creation process is relatively straightforward, but there are a number of consider­ations you must take into account.

A template is really nothing more than a Windows virtual hard disk (VHD) that contains a sysprepped Windows Server 2012 R2 installation and the application you want to make available to your users. Although this might sound really simple (and it is), there are a number of requirements to which you must adhere. Otherwise, you risk the template being rejected.

By far the most critical of these requirements involves the structure of the VHD itself. The VHD must be a VHD-format disk. Microsoft Azure doesn't support VHDX-based disks. The disk can be dynamically expanding or it can be of a fixed size, but Microsoft recommends using a dynamically expanding VHD. The virtual disk can contain multiple volumes, but it must use MBR partitions (Azure RemoteApp doesn't currently support GUID partitions) and the VHD must contain only a single copy of Windows Server.

There are also some very rigid requirements regarding the size of the VHD. It must be at least 40GB, but can't exceed 127GB. The size you should use depends on your application's requirements, plus the requirements of any data you plan to store alongside the application (such as in a separate partition within the VHD). It's a good idea to overestimate the space requirements because adjusting the size later on is likely to be a disruptive process.

The most important thing you need to know about the VHD is its size must be an exact multiple of megabytes. For example, if you wanted to create a 40GB VHD, it would need to be 42,949,672,960 bytes in size, because that number is exactly 40,960MB. You can't just round the number to 42,000,000,000 because that number is not evenly divisible by 1,048,576 (1MB). If you get the size wrong, the upload process will fail.

There are a few other important considerations around the creation of a custom template. The template will need to contain the Remote Desktop Session Host role and the Encrypting File System will need to be disabled. The image also requires the Desktop Experience feature to be installed (you can't perform a server core deployment). As previously noted, the image will need to be sysprepped. The instructions are available here.

Configuring RemoteApp
Whether you're performing a cloud or a hybrid deployment, the first step in the process is to create a RemoteApp service. This is a really simple process that requires you to go to the Azure Management Portal and then go to the RemoteApp page. From there, you would click on the Create a RemoteApp Service link, shown in Figure 1.

If you plan to perform a cloud-based deployment, you can use the Quick Create option (see Figure 2). It allows you to create a RemoteApp service that's based on the Microsoft Office 2013 Professional Plus template. If you're performing a hybrid deployment then you would use the Create with VPN option. Either method can take up to half an hour to provision the service.

Neither cloud-based nor hybrid deployments use a single-step configuration process. Both types of deployments require you to perform some additional tasks to get Azure RemoteApp up and running. Most of these tasks are the same for both types of deployments, although the order in which you must perform the tasks will vary depending on the type of implementation. Furthermore, a hybrid infrastructure requires you to perform some tasks not required (or in some cases are optional) for cloud deployments.

Linking to a Template Image
It should come as no surprise that one of the tasks you must perform is to link the Azure RemoteApp service to a template image. If you're performing a cloud-based deployment, you perform this step in concert with the creation of the Azure RemoteApp service. The wizard will ask you which template you want to use. You can choose to use the built-in template that contains the Office 2013 applications or you can choose your custom template as an alternative. In the case of a hybrid deployment, you wouldn't provide the template image until a little bit later in the process.Link to a Virtual Network

If you're performing a hybrid deployment then the step that must be performed prior to uploading your template image involves linking Azure to a virtual network. The virtual network's job is to bridge the gap between Azure and your private network. That way, your users will be able to access data that's stored on your private network while accessing an Azure RemoteApp.

In addition to creating a virtual network, you'll need to create a site-to-site VPN that can provide connectivity between Azure and your private network. Your private network will require a Windows Server 2012 (or 2012 R2) server running the Routing and Remote Access Service (RRAS) or a compatible VPN device (a list of compatible devices is available here).

In either case, you must provision your VPN with an externally accessible IPv4 address (you can find instructions for setting up the VPN here).

Active Directory Synchronization
Another task you might need to complete is Active Directory synchronization, which lets you base access permissions to Azure RemoteApps on the same Active Directory user accounts and security groups established on your local network.

In the case of a cloud deployment, Active Directory synchronization is optional. There's nothing stopping you from using Active Directory objects to control access to Azure RemoteApps, but you don't have to use this approach. You can use local users and groups (within the custom template) as an access control mechanism instead.

In the case of a hybrid deployment, Active Directory synchronization is an absolute requirement. Remember, the advantage of performing a hybrid deployment is that you can provide users with access to a RemoteApp that's hosted on Azure, while also allowing them to access application data that's stored locally. The only way to achieve this level of access is to make use of Active Directory synchronization so the user's credentials remain valid for access control on the local network and on Azure.

Establishing directory synchronization between Azure and your private Active Directory forest involves a lot of work, described in Microsoft documentation.

Publish RemoteApp Programs
Whether you're configuring a hybrid or a cloud deployment, the last part of the process involves publishing RemoteApp programs and then granting user access.

The first step in making an Azure RemoteApp available to your users is to publish the app. You can do this by going to the Azure RemoteApp page and clicking Publish. You can choose to publish the RemoteApp through the template image's Start menu or you can specify the appli­cation's path within the template image.

Client Components
One last thing you need to know about Azure RemoteApp is that your users probably won't be able to access the remote application through a standard RDP client. Microsoft publishes a version of the client that's designed for use with Azure RemoteApp. You can download the new client from the Azure RemoteApp Quick Start page.

Some might argue Azure RemoteApp isn't really anything new because Windows Server has included a RemoteApp feature for quite some time. The nice thing about the Azure RemoteApp feature, however, is that it allows applications to be hosted in the cloud so that users can access those apps without having to consume the organization's bandwidth (except for in the case of a hybrid deployment). Furthermore, it's now available as a service and the Azure infrastructure makes it easy to scale application delivery as your organization grows