Azure RemoteApp Part 2 – More RemoteAppyness from Azure

cloudos1

 

 

Having published a post on Azure RemoteApp recently, I have been absolutely inundated with requests (well three people have asked me) for information on how to use Azure RemoteApp with an application that is not published by default and that I DON’T want to run on my own premises.

 

So here is part 2 of 3 in the Azure RemoteApp story of goodness. Publishing my own apps to Azure RemoteApp.

As a keen photographer I rely heavily on Adobe Lightroom, so i decided I would deploy a 30 day trial of this to Azure RemoteApp

To be honest I had thought this post would be difficult to describe and deliver but at least 60% of the tasks are identical to those in the first post. The ONLY difference is that you must create and upload your own image in the form of a Virtual Hard Disk (VHD) to Azure Blob storage (no I’m not being insulting to Azure storage – BLOB is a Binary Large Object).

The tricky part is that there are a bunch of pre-requisites for this image, its internal setup and the applications on it. So some patience is required.

To follow these steps, you must already have an Azure subscription (a trial will do) and you must have an Azure RemoteApp preview service enabled. Both of these steps are described and links included in my previous post, here.

Step 1 – Create your Image.

There are a number of ways to do this, of course PowerShell is the best way if you want to repeat the process and I will publish a handy script to do the basics, another time. For now just use either Hyper V or Disk Management to create a dynamically expanding, VHD with a Master Boot Record type (MBR). All three of those factors are mandatory.

Azure is not yet able to handle the newer VHDX format so make sure it’s a VHD. A dynamically expanding disk is much more efficient for the uploading and blob storage process. The Azure system only handles the MBR format rather than GUID type.

Once you have this created, then you can go ahead and create a VM based on that disk. The next pre requisite is that you MUST install Windows Server 2012 R2 on the disk. The machine can have several volumes BUT only one instance of Windows Server can be installed. This caters for the scenario where the Application you wish to use as a RemoteApp cannot co-exist on a system partition.

Having found a Windows Server 2012 R2 ISO or DVD and installed it to the VM (you will need to enter a valid licence key, which will be stripped out later on), there are several more tasks to complete before you can upload your VHD as a ‘gold’ image to the Azure storage platform in your subscription.

First you should use either Server Manager or PowerShell to add the Desktop Experience Feature which is hidden under the User Interfaces and Infrastructure section.

experience

 

 

 

 

 

 

This will almost certainly require a reboot.

Having rebooted the VM, again use Server Manager or PowerShell to add the remote Desktop Services Role and during the setup stage of the wizard for this, add only the RDS Session Host option. The normal process for installing RDS is to choose the RDS Installation option as most of the work for setting up your systems and servers is carried out for you.

This will not work for a number of reasons, not least as it requires a domain structure. So for this install you will need to choose Role-based or feature-based installation.

rds install

There are now a few settings to make to ensure that the Azure upload works ok.

First disable the Encrypting File System (EFS), this requires the following command entered in an elevated command prompt.

Fsutil behavior set disableencryption 1

If you know what you are doing and are used to hacking around in your registry, you can add the following DWORD here.

HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisableEncryption = 1

(usual caveats  around backing up the registry and not doing this unless you know what you are doing)

So far I have assumed that you are creating this image on-premises which in this ‘Cloud-First, Mobile-First’ world is an error on my part. There is an additional step to take if you are creating your image within an Azure VM.

There is an XML file stored in \Windows\Panther\unattend.xml

This needs to be renamed or deleted. If this step is not carried out, the upload script (which also assumes an on-premises image source) will fail.

The final three steps to make are

to fully update the operating system using Windows Update

to install your applications which you intend to be used as RemoteApps (my demonstration uses Adobe Lightroom v3 9a digital image importing, cataloguing and editing application).

The last step is to generalize your system so that when Azure starts the image during the process of uploading and provisioning, the system does not find keys, users or passwords that would block the process.

The command required for generalization is

  C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown

This will place the VHD in the same state as immediately after installation before entering the product key and administrator password (oobe). Do remember that even though Sysprep (one of my favourite tools) has a switch designed to use with VM’s, you should not use the /mode:VM switch as this would cause Azure to reject the image.

Even though this is a very simple set of instructions make sure that all of them are completed AND in the order stated. If you do not, expect a lot of red in your PowerShell results! (Hint – RED is bad) (I saw a lot of red in creating this post)

Step 2 – upload your image.

Provided that you have completed step 1 correctly this is the easiest but longest part of the process.

First in Azure go to the RemoteApp section select template Images and upload, answer the wizard options of name and Location (BIG NOTE – remember the location and make sure it is the same as the location when you create your remote app service, if not, you will not see this image)

upload1

Having created the template image name the wizard will automatically start downloading the

Upload-AzureRemoteApptemplateImage.ps1 script (remember where you save this)

The wizard will also contain a link to download the Azure PowerShell module and the details of the command to run, in this instance the command is below

commanupload

Here is the command in a  more readable form, simply copy and paste this into a notepad document so you can reuse it (if your first few tries do fail)

.\Upload-AzureRemoteAppTemplateImage.ps1 -SAS “?sv=2012-02-12&sr=b&si=428348c2-81f9-4ce6-9021-635289465915&sig=DMAia%2F0qa%2B4pXoDad5mRyJEjx%2BTyWVNEJW1Ah%2BDXjnY%3D” -URI https://cdvwu110638459rdcm.blob.core.windows.net/goldimages/428348c2-81f9-4ce6-9021-635289465915.vhd

Ensure that your VHD image is stored on directly attached storage as the wizard does not pick up network shares.

Having downloaded the Azure PowerShell, go ahead and run this from the start screen as an administrator.

azpshell

 

 

 

 

 

 

 

 

 

 

Change drives to the drive and directory where you downloaded the script and paste the command and run it.  The script asks for a location to the VHD, select the correct image and off you go.

upload3

My upload took about 1.75 hours and was around 10GB in size.

uploadfinal

From this point ALL the steps are identical to those in my first post. If the applications you want to use are not on the start menu, they will not show up in the publish applications window and you will need to add it manually by path. (Hence I suggested you write down the path).

path

Once the app is published, you can simply look for more app invitations if the Microsoft RemoteApp is already installed and configured to a different Azure RemoteApp service. The new apps will then show up and you can run them at your leisure.

updating apps

Note here that the first time you run an app within a session from EACH Azure RemoteApp service, it will take longer than usual as it has to set up the connection to the new session host. Also note that despite there being different session hosts, there is only one connection to Azure RemoteApp – all connections go through this one connection, as shown by the Screenshots of the task manager (processes). See also that where I have many RemoteApps open, almost no processing power is used and not that much RAM either. I can also run duplicate copies of the same Application on the same machine (1 RemoteApp and 1 local) also shown in the Task manager screenshot.

taskman

In preview I am limited in the number of concurrent sessions I can run to ten.

nosessions

 

 

 

 

 

The sessions listing in the Azure console allows you to keep track of this. I can even log off remote sessions, disconnect them (for later re connection) or send a message to the console of the user.

disconnect

 

 

 

Of course simply because it is easier for me to do quickly i have shown all this on a Windows 8.1 client. It is available on any platform where a RemoteApp client is available (OSx, iOS, Android, Windows)

Again I have gone well over my self-imposed 1000 word limit so will keep the hybrid implementation of Azure for another day. Happy Apping.

 

 

The post Azure RemoteApp Part 2 – More RemoteAppyness from Azure appeared first on Blogg(Ed).