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.
As users make the transition away from traditional desktop PCs to all manner of mobile devices, application 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 applications 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 considerations 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.
[Click on image for larger view.]
Figure 1. To configure an Azure RemoteApp environment, you begin by clicking on the Create a RemoteApp Service link.
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.
[Click on image for larger view.]
Figure 2. The Quick Create option includes a predefined template for Microsoft Office 2013 Professional Plus.
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 application's path within the template image.
Once the application is published via Azure RemoteApp, you must grant your users access to it. You can do this from the Quick Start page by clicking on Configure Access. After doing so, simply specify the user or group to which you want to grant access.
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.
Recommendations and Considerations
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
Azure RemoteApp Resources
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.