Azure's RemoteApp lets desktop software run as a hosted service in the cloud. This is useful in many scenarios. It allows software companies to extend the life of mature desktop systems by offering them as pay-as-you-go services and it removes the installation and maintenance burden from customers. It also lets training companies pre-configure desktop environments with everything the user needs to get started and lets companies configure, secure, and maintain desktops for remote workers without installing apps remotely onto the end user's equipment.

The idea of remote desktops isn't new. The Remote Desktop client has been part of Windows since Windows XP Pro SP2, and Remote Desktop Services has been around since Windows NT, when it was known as Terminal Services. Many companies already host Remote Desktop Services in their server rooms and Data Centers or on virtual machines (VM) in Azure. Users can run Windows and Windows applications from a variety of clients including Macs, iPhones and iPads, Android devices, and Windows phones. That's right, users can even run old VB6 and FoxPro apps from the cloud on their Macs and iPads. Talk about extending the life of an old app!

So what's so cool about RemoteApp? RemoteApp is remote desktop as-a-service. Instead of sharing an entire desktop session, it shares individual applications and the server itself is completely managed and updated automatically. This is somewhat analogous to how Azure Web Sites relieves us of having to create, configure, scale, and maintain Windows Servers and IIS in order to deploy Web sites.

A RemoteApp server starts off as a Windows 2012 R2 Server with Remote Desktop Services installed. This can be a VM you create in Azure or create locally as a Hyper-V image. You'll install and configure the desktop software you want to make available and make sure everything works correctly on the VM. Then you'll prepare the machine image to be loaded into your RemoteApp environment. At that point, Azure takes over your VM and manages it for you. You can no longer connect to the VM via a remote desktop session. Azure applies OS patches, monitors the image and the hardware, and collects dev-ops information. If you need to update the machine image, you'll have to upload a new one.

Creating a RemoteApp Server Image

If you just want to play around with the technology, Microsoft has provided a Server 2012 R2 image with no additional software installed and a second image that includes Office pre-installed. You can create a new RemoteApp Collection from the portal at any time using one of these images with no additional prep. But images without any of your software on them aren't all that interesting for most of us. If you want to customize your server with your software, you'll need to create a custom server image instead. You can choose to start with a copy of the images provided by Microsoft. Create a new VM in Azure and choose the Windows Server Remote Desktop Session Host image (or the version with Office installed) from the Virtual Machine Image Gallery. This image has Remote Desktop Services installed and configured for RemoteApp.

I find it much more convenient to work with a local Hyper-V image than an Azure VM image. To create a Hyper-V image locally, there's a fantastic article (https://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-custom-image/) that takes you through each step. I'll highlight the important steps here. Create a new .vhd (not a .vhdx) drive in Hyper-V Manager. Make the disk a dynamically sizing disk with a maximum size of 127GB and name it RemoteApp.vhd, as shown in Figure 1.

Figure 1: Create a .VHD Virtual Hard Disk.
Figure 1: Create a .VHD Virtual Hard Disk.

Next, create a new VM named RemoteApp, as shown in Figure 2. It doesn't matter how many CPUs or how much RAM you assign to your VM since you'll configure all of that again when you put the image into RemoteApp. In fact, only the .vhd will be uploaded to Azure. I've chosen to give my local VM 2GB of RAM and 2CPU cores as well as a network adapter so I can install Windows Updates. Make sure that your VM is configured as Generation 1, not Generation 2, or it won't work in RemoteApp.

Figure 2:  Create a Generation 1 Hyper-V VM.
Figure 2: Create a Generation 1 Hyper-V VM.

Next, install Windows Server 2012 R2 and start the Windows Update process to make sure that the VM is fully patched. After a couple of re-starts to complete the patching cycle, configure windows and install the Remote Desktop Session Host (RDSH) role and the Desktop Experience feature. These are required for RemoteApp. Once the components are installed, run Windows update AGAIN and install any patches it finds.

Although it's not a required step, I highly recommend that you shut down the VM and make a copy of your .vhd in case you want to create another RemoteApp server image later. That way, you won't have to start this process from scratch every time you want to make a new RemoteApp image. Name this copy RemoteApp.vhd.v00. Once you have a backup, re-start the VM and log in. Install whatever software you want to share and test your applications. Make sure you install the software for all users, not just the current user. There's no need to install printer drivers, as they'll be of no use in Azure and are removed when the image is prepared for upload.

It's important to mention that RemoteApp servers can be re-created in Azure at any time, so anything you install or configure after you upload the image can be wiped out. In order to install software updates, you'll need to prepare and upload a new image. Self-updating ClickOnce applications are a good way to get around this inconvenience, however at the time I'm writing this, full trust ClickOnce applications won't run as RemoteApps because the users who'll be running the apps won't have sufficient permissions. The work-around for this is to install the ClickOnce application on the computer, then later, configure RemoteApp to run Internet Explorer, passing it an argument of the URL of the ClickOnce .application file to start the app. It's not elegant and the user will see IE's icon in place of the application's icon when launching the app, but it works well. Fixing this is a long-requested feature that we hope to see soon.

Even though the image can be re-set, it doesn't mean that everything gets wiped clean. The user's Documents folders are persisted within the RemoteApp Collection, even if the machine is re-imaged and even when you update the machine image. It's only deleted for good if you delete the entire RemoteApp Collection, so you can store user-specific configuration here and you could even copy a .NET app to here and run it from this folder. Although that works, it's not very secure.

Log in as a non-administrative user to make sure that the applications function as expected. This is the last time you'll have a chance to log into your VM. Again, it's not a required step, but I highly, highly, highly recommend that you shut down the VM and make a copy of your .vhd at this point. Name this copy RemoteApp.vhd.v01. Re-start your VM and log in as an administrative user. Open a command prompt As Administrator and run the following commands:

Fsutil behavior set disableencryption 1
C:\Windows\System32\sysprep\sysprep.exe
/generalize /oobe /shutdown

The first command disables the encrypting file system. The second command removes all user accounts and hardware drivers in preparation for moving the VM to new hardware. That's one reason you'll want to make sure you have that backup with a version number in place before you run this command. Once SysPrep has completed its work, the VM shuts itself down. Your image is ready to be uploaded. If you created your VM image in Azure from one of Microsoft's images, you'll still need to run the SYSPREP step. As with a local VM, I highly recommend you back up your VM image before running SYSPREP on a VM in Azure.

Uploading a RemoteApp Server Image to Azure

In order to upload an image, you'll need Azure PowerShell (it should say “Azure PowerShell” in the title bar, not “Windows PowerShell”). If you haven't installed it yet, you can install it with the Web Platform Installer. There's a link in the upload Wizard that starts the installation for you.

Open the Azure Web portal and sign in. If you don't yet have an Azure account, go to portal.azure.com and click on the Free Trial link to create one now. You'll have to enter your credit card information, although Microsoft won't charge your card without your express consent. They'll cut off the account when the trial period expires and/or your trial credit is used up. As I write this, RemoteApp can only be configured in the full portal, not the Preview portal. If you're logged into the preview portal, click on your login name in the upper right corner and click Azure portal. Select REMOTEAPP from the list of Azure services on the left, and choose the “Template Images” tab, as shown in Figure 3.

Figure 3: Upload a customized RemoteApp system image.
Figure 3: Upload a customized RemoteApp system image.

If you created your VM image in Azure, make sure you've run SYSPREP on it and choose Import an image from your Virtual Machine library and skip to Creating a RemoteApp Collection. If you created a local HYPER-V image, choose Upload a new template image as shown in Figure 4 and continue here.

Figure 4: Upload an image created locally in HYPER-V Manager.
Figure 4: Upload an image created locally in HYPER-V Manager.

Name the new upload MyFirstRemoteApp and choose your Region. The portal creates a PowerShell script and downloads it to your computer. Save that .ps1 file to a convenient spot. Then, open the Azure PowerShell command prompt As Administrator. Copy the command line shown in the portal to the clipboard and paste it into the PowerShell window. Use the CD (change directory) command to switch to the folder where you downloaded the .ps1 file and then paste the command into the PowerShell window and execute it to run the script. The script scrolls down your screen for a while, then prompts you to locate your RemoteApp.vhd file. Make sure you've run SYSPREP and shut down the VM, or the upload won't work. After you select the .vhd, the PowerShell window shows it creating an MD5 hash (for security) and then shows the file upload progress. Because you created a dynamically expanding disk, it should only be as big as the space actually taken up on the disk, not the size of the full capacity of the disk. Still, it may take a while to upload 18GB or so, depending on your connection, but once it's done, the image should show up in the portal as shown in Figure 5.

Figure 5: The custom image successfully uploaded to Azure.
Figure 5: The custom image successfully uploaded to Azure.

If your upload fails for any reason, I've found that the best way to re-try is to delete any image that shows up in the portal, and then get a new script for your clipboard and download a new PowerShell file before trying again. Otherwise, I tend to run into new errors caused by the failed upload.

Creating a RemoteApp Collection

Provisioning a RemoteApp Collection from your image takes a very long time; it takes about an hour as I write this. Choose the RemoteApp Collections tab and click the Add a RemoteApp Collection link, as shown in Figure 6. Enter a name for your Collection. Choose your Region and either the Basic or Standard plan. The Standard plan is a bit more expensive, but provides more powerful hardware. Then choose your template image file. Make sure to select the region you uploaded your image to first or it won't show up in the list.

Figure 6: Create a RemoteApp Collection from your image.
Figure 6: Create a RemoteApp Collection from your image.

While you're waiting for your server to spin up, you can spend a few minutes adding some users to Azure Active Directory (AAD) if you wish. Your Microsoft account is already in your AAD, so you'll be able to use RemoteApp, but that's not usually the point of running RemoteApp, is it? If you haven't used AAD before, to the end user, it acts almost exactly like your Microsoft account or an Office365 account (if you have one). If you know of a user with a Microsoft account who can help you test your app, you can enter their Microsoft account's email address into your AAD. Otherwise, click on AAD and add a new user with a name, email address, and password. By default, AAD gives new users who don't have an existing account an @azureonline.net address, but you can configure AAD to use a custom domain name that you own, if you wish. That's all there is to it. Create as many accounts as you like. AAD is free unless you want the premium features.

Your Microsoft account is already in your AAD, so you'll be able to use RemoteApp, but that's not usually the point of running RemoteApp, is it?

Publishing Apps for Users

Now that your server's up and running and you've configured accounts for your users, let's publish some applications so that end users can use them. Select your server from the RemoteApp Collections tab and click on publish remoteapp programs, as shown in Figure 7, and look for your application(s) in the list of programs, as shown in Figure 8. If you didn't install any programs, you can use NotePad.exe or some other app installed on the server. If you're using ClickOnce applications, remember to publish Internet Explorer as the application and provide the URL of the .application file as a parameter. In this example, I've installed an old copy of Microsoft FoxPro on my image, so I'll publish that.

Figure 7: Publish applications for your users.
Figure 7: Publish applications for your users.
Figure 8: Select your applications.
Figure 8: Select your applications.

Test Your Published Applications

Now it's time to see how you've done. Install the RemoteApp Client on your computer or one of your supported devices and log in with an email address that you configured in Azure Active Directory. Remember that the email address from your Azure account was automatically set up for you. You'll see the applications that were published for you, as shown in Figure 9.

Figure 9: RemoteApp Client
Figure 9: RemoteApp Client

Click on an app and it runs on your device as though it were a locally installed application, even though it's actually running in Azure. Figure 10 shows FoxPro appearing to run on my Windows 10 desktop, but I could just as easily run it from a Mac or an Android slate or even my iPhone. Printing works too, if you have a printer installed locally on your device.

Figure 10: The RemoteApp-published application runs on my desktop.
Figure 10: The RemoteApp-published application runs on my desktop.

Costs

The Basic plan costs $10 per month per user for up to 40 hours of use per month and the plan is capped at $17 per month per user for unlimited hours. The Standard plan costs $15 per month and is capped at $23 per month. There's no limit on the number of applications you can publish for this price. The Server 2012 R2 license cost is included in these fees, as is the license fee for Office if you used Microsoft's image as a starting point. It does not, however, cover any Office365 costs for connecting to an Office365 mail server.

Summary

RemoteApp is definitely a niche product and it highlights just how diverse Azure is and how powerful it can be. This article fleshed out some interesting scenarios, such as extending the life of older Windows desktop apps, enabling companies to offer Windows apps as a service, and making them available on multiple platforms. RemoteApp is also commonly used to make infrequently used apps easy to deploy and affordable, as in the example of publishing Office apps. There's no up-front cost or installation hassle for end users. Instead, you pay monthly for RemoteApp, which includes the cost of the server and Office licenses. In future articles, I'll continue to introduce you to both the mainstream and niche offerings available in Azure.