Guide To Azure Remote Apps

AzureRemote Apps

Being a popular cloud services provider, Microsoft Azure keeps adding a variety of new services to its existing offerings making sure the cloud becomes your platform of choice for your existing business scenarios and applications.

What is Azure Remote App Service?

AzureRemote App is nothing but an Azure service which lets you run your existing on-premise applications in Microsoft cloud. In a nutshell, it empowers and gives peace of mind to application administrators to host their enterprise on-premise applications on Azure and leverage existing capabilities of the Azure infrastructure e.g. agility and scalability. In a layman’s terms – your application is hosted on some other machine running in the cloud and you access it using remote desktop services (RDP); this sounds simpler. We will see more details of Azure remote apps in the sections below.

Why Should I opt for Remote Apps?

Of course a genuine question and one you have to ask before making up mind to use this service. Consider a scenario wherein an organization has a chain of their retail shops across the country and all their employees need to use an application for billing process at the checkout counter. If you a give a quick thought to relate this in our city Pune – you can easily figure out one such retail chain, such as D-Mart outlets across the city.

Typically, how this can be done is, first develop the billing application, take pilot runs and then deploy it locally to every outlet at every machine running on a billing counter. Imagine the cost of infrastructure and efforts in setting up all these machines and making sure each one of the workstations is able to run the developed application even in peak hours.

Now the next part, suppose during a busy day – a machine in one of the outlets  goes down, then what would happen? Well typically that billing counter is made offline, redirecting customer queues to other working billing counters until a IT guy in the outlet fixes the machine. But wait, what would happen to the data which was stored locally on the machine? Will that be ever recovered if the machine is formatted? Can I access the installed application from any other device than that machine itself? Would existing working machines be able to run multiple instances of the application in peak hours? Will their infrastructure support the load? All the above scenarios are covered and supported in Azure remote apps.

When you decide to go for Azure Remote App services – you get:

• Instant access to your applications running on cloud.
• No application compatibility worries.
• Access your apps on the go, easy access from any mobile device.(Any win app from any device)
• Consistent look and feel across devices.
• Reduced amount of time in installing and configuring servers.
• Reduced hardware investments and cost of infrastructure.

Getting Started with Remote Apps Concepts

There are some typical terms you will hear or read while working with Azure remote apps and we will see what exactly those mean in layman’s terms so that next parts of this article will become easy for you to understand (assuming that the readers are familiar with basic concepts of Azure):

• Remote App Collection – It is the machine or set of virtual machines running in the cloud hosting your application.
  
  
• Bring your own Image – The pre-configured image of a machine or a virtual machine hosting your windows applications, this image will be used as remote app collection. The image has to undergo multiple checks in order to become compatible to host your WIN applications.
  
  
• RDSH – Remote Desktop Session Host (RDSH) is a role in Remote Desktop Services (RDS), or Terminal Services, as it was known prior to Windows Server 2008 R2. RDSH servers host Windows applications or desktops that are accessed from remote users via a network connection.

RemoteApp collection options

There are two types of remote app collections available

1. Cloud
   
   These collections reside completely in Azure and don’t communicate within the resources in your existing on-premise network. These are quick to create and provision. These can OPTIONALLY use VNET to use un-authenticated resources in existing on premise networks.
   
   
2. Hybrid
   
   These require a connection to your on-premise network using Azure virtual network or Express routes. These also need Active Directory connected accounts and also need to join to your existing domain hence sometimes they're also referred as domain joined collections.

This article focuses mostly on the creation of cloud collection and deploying a simple console application on it, so we will go step by step.

As I mentioned before, the collection term in remote app is nothing but a virtual machine / image which hosts your windows applications which you want to make available to all users of remote app. So by this, you might have guessed it – yup, it all starts with a creation of a virtual machine.

Creating a resource group and VM pre-requisites

Well, assuming that most of us are already familiar with Azure portal basics and how we can create and deploy a virtual machine in few minutes,  the process remains almost similar here except of the fact that the machine which you will be creating now  has to satisfy certain set of conditions e.g. Installing and configuring Remote Desktop services in order to qualify as “Remote App collection”. You can of course go ahead and create the VM by following the standard procedure or create it from your available disks, this is known as bring your own image scenario but it becomes the user’s responsibility to configure those ‘set of conditions’ on your virtual machine in order to qualify to be a remote app collection.

And as usual to make your life easy, Microsoft has already done those configurations for you and created an image out of it. The image can be found in virtual machine template gallery of Azure. The image template is known as “Windows Server Remote Desktop Session Host”, and so we will create our VM using this image.

Whenever we create a virtual machine using Azure portal, you might have observed that it asks for DNS name which typically is cloud service name and storage account, one might ask why Azure does this? Well it’s because of the way it is designed, cloud service can be thought of just a container having public endpoint within which your virtual machine will be hosted and storage account can be thought as a container of your virtual machine’s disk. In a nutshell, Azure hosted virtual machine comprises of three entities.

(Please note that all the screens posted in this article are taken from old and new Azure portal, all remote apps related screens are taken from older Azure portal because as of writing this article remote apps related actions are not available on new Azure portal.).

We will be creating a separate resource group for our needed services so management of those becomes easy. As this article focuses on Azure RemoteApps, I won’t be diving deep in Azure resources manager and concepts. I will cover those up in separate article later but for now you can read basics about Azure resource manager here.

Let’s go ahead and create a resource group using new Azure portal for our RemoteApp. We will name it as RemoteAppDemoRG.



Creating Storage Account

Now, we will create a storage account within this resource group using Azure portal.
We will name our storage account as remoteappdemostorage (yes, all small caps is pre-requisite.)



Observe the highlighted part in the image above, it shows that the resource group which we created in previous step should be selected as resource group of this storage account. As a result, this storage account will be placed under the selected resource group.
Also please note that while creating this storage account, select classic as the deployment model. Why? Because of writing this article, cloud services are deployed using classic deployment model of Azure and the cloud service which are going to create in next step should be able to discover the available storage accounts created through classic mode deployment so that we can associate it with our cloud service.

Creating Virtual Machine

We are all set up to create our virtual machine now, let’s go ahead in Azure portal and select create virtual machine option, select from template gallery. As mentioned above, we will select the template for our VM asWindows Server Remote Desktop Session Host. Make sure to select correct cloud service, resource group and correct storage account before hitting next.

In older Azure portal, browse to the resource group you have created where you will be now seeing two entities created i.e. a storage account and a cloud service. Click on Add button in the header and search with RemoteApp in the search box. Select the image with name – Windows Server Remote Desktop Session Host on Windows Server 2012.



Note that the deployment model chosen in classic deployment mode, click create and fill in the required parameters on the screen.

We will name our virtual machine as RemoteAppDemoVM and set user name as RemoteAppAdmin.

Please take a note of user name and password you mention here. You will need these to connect and log on to the virtual machines later.

In the optional configuration panel, select Network. Once network panel opens up, select domain name. The domain name here is nothing but the public endpoint name of the cloud service. We will create new domain name i.e. create new cloud service and name our cloud service as RemoteAppDemoCS.

Make sure that the correct storage account name is selected.



Make sure to associate correct storage account and cloud service before hitting create.

Once the virtual machine is hosted, go ahead and connect to it. Easiest way to connect is by using portal. Browser to the virtual machine you created and click on connect from dashboard page. It will download RDP client on your machine. Double click on it and enter credentials you have added while creating the virtual machine.

Setting up the virtual Machine

This is a vanilla machine created by using the image you selected from gallery. Once you are logged on to the machine, you will see a PowerShell file on a desktop with name ValidateAzureRemoteAppImage.ps1.

The file is basically nothing but set of pre-written PowerShell scripts which helps you to check the compatibility of the machine to be a RemoteApp collection. All you need to do is run that file to see the result.

Just out of curiosity, we will go ahead and run this file and see what it says:



Message shown is quite self-explanatory so I won’t go into much details of it, however DO NOT PRESS Y for now. We will see that in upcoming section.

Let’s go ahead and create a user on this virtual machine and assign administrative rights. Why we are doing this, I will explain it in later part of this article.

Right click on the Windows start button icon from left bottom coroner of the desktop, and select Computer Management. Under local users and group from left navigation, create a new user. We will call it as RemoteAddAdmin2 and set password that never expires.



We will add this user in the Administrator group of this virtual machine.



Now the next part, we want to host our own custom application on this machine so that it can run on Azure and will be presented as RemoteApp to all the users of our RemoteApp collection.

I have created a sample program which is nothing but a console application reading and writing to the textile on the file system. It runs fine on my local development box and I want to deploy this application as a remote app for all users.

Here is its sample code:

classProgram
{
    private static string filePath = string.Format("{0}\\Test.txt", Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments));
    static void Main(string[] args)
    {
        try
        {
            if (!File.Exists(filePath))
            {
                FileStream stream = File.Create(filePath);
                stream.Flush();
                stream.Close();
                stream.Dispose();
            }
            stringfileContents = File.ReadAllText(filePath);
            if (!string.IsNullOrEmpty(fileContents))
            {
                Console.WriteLine("Here is what you have written previously..\n");
                Console.WriteLine(fileContents);
            }
            Console.WriteLine("Enter contents to write..");
            stringcontentsToWrite = Console.ReadLine();
            if (!string.IsNullOrEmpty(contentsToWrite))
            {
                StreamWriter writer = newStreamWriter(filePath, true);
                writer.WriteLine(contentsToWrite);
                writer.Close();
                Console.WriteLine("Saved!..");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("Error: " + ex.Message);
        }
        finally
        {
            Console.WriteLine("Press enter to exit..");
            Console.ReadLine();
        }
    }
}

First step is to copy the executable and supporting files e.g. application configuration files to the virtual machine which we just created. Note that since we have opted for cloud collection approach of hosting our apps so if apps to be migrated are communicating to any external resource such as web service, local database then you need to make sure that you port all such existing pre-requisites to VM as well. And that is exactly where the hybrid / domain joined remote app collection approach helps. This article will not go in details of that approach.

As my application does not contain any specific configuration settings so let me straight away copy only the exe of my console application and paste it to path “C:\DemoApp\MyApp.exe” on a virtual machine. Take a note of the path to which you host your application, you will need this path later. We will also install some other browser on the virtual machine so that I can serve it as remote app to end users.

Capturing VM Image

Once I validate the output by taking a local run of my app, we are good to go and do next step.

Let’s run that ps file on desktop and make sure if our image is still compatible to become a remote app collection.

It still says image is compatible so hit Y this time. Hitting Y is nothing but your approval to start the sysprep of the virtual machine. Sysprep is the process through which you generalize your server i.e. processes of removing unique information from the machine so that you can use replicate the same machine to multiple places. You can read more about sysprep here.

Once the process is completed, the machine will be shut down.

Once you see the machine in stopped mode in Azure portal, go select the capture option. It captures the image of the machine which we just configured and ‘sysprepped’.



We will capture the image with name RemoteAppDemoImage, make sure that you check that checkbox at the bottom which says I have run sysprep on the virtual machine and click ok.

Once you capture the image, the virtual machine will be deleted and the image of it can be browsed in the virtual machine’s images gallery of your subscription.



Importing VM Image and Creating RemoteApp

Let’s go ahead and create a new remote app which uses our customized virtual machine image.

In new Azure portal, browse to the resource group which we created and click add. Filter results by typing ‘RemoteApp’ in the filter box. Select Remote App Template and hit create. It will redirect you to the old Azure portal.

Once you land in old Azure portal, browse to RemoteApp section and click on Template images tab. We will need to import our image to this gallery so that we can create RemoteApp using that image. Click add button in the bottom bar and it opens up a nice wizard.



Select the option as shown in the image above and hit next. It will show the list of available virtual machine images. Select the one which created in last method and check the confirmation checkbox.



Click next and set name to the image. We will name it as “RemoteAppDemoImport”.

Select the location where you want to store this imported image and click next. It starts the import job immediately. You can track the import progress by clicking on the ‘Template Images’ tab in remote app section in Azure portal. Once the image import is successful, we will create RemoteApp.



Click on the new button in previous portal and select App services then remote app and quick create option. The opened panel asks for certain parameters.



We will name our RemoteApp as RemoteAppDemo, keep region and other settings as shown in the image above. Make sure that you select the correct image which we imported in last step. Note that, if you change the region, it filters out the content of template image dropdown control and lists only images which are available in the selected region. So don’t be surprise if you don’t see your imported image in the dropdown.

Once you create the remote app, it takes you to the dashboard page of it where you can control settings related to the remote app. We will see each one of it one by one.

User Access

This is the section where you can control the accessibility of your remote apps for your end users. You can add / remove users and grant / prevent access to your remote app collection. Note that user has to be present in the active directory in your subscription. You can change the Azure active directory tenant used by your remote app and more information can be found here.



Once you add any user to the list, that user gets access to all apps which you published. You have the option available in portal to do bulk upload of users.

Publishing

Publishing is nothing but a process to make something available for everyone or to make something public. E.g. publishing article in a newspaper or publishing your blog content. Application publishing follows the similar concept i.e. it lets you decide which applications you want to make available to end users of remote app. Now which applications we are talking about? As many of you might have guessed right, the applications which we install or deployed on the virtual machine image which we created few steps back. E.g. our custom console application or Mozilla Firefox.

In the Azure portal, browse to the publishing tab in created remote app. You will see few buttons on the bottom bar e.g. Publish, Edit and Unpublish. Click on publish button. You will see two options



Publish start menu programs

You can choose this option if you wish to publish the applications which are installed on the virtual machine image and available to access from the start menu. We can also add our custom applications to appear in the list as shown below if we place those in the start menu apps path on the image. To make sure your app is in the Start menu, place a shortcut file - .lnk - inside the %systemdrive%\ProgramData\Microsoft\Windows\Start Menu\Programs folder.

Click on this option and you will be presented with the list of available start menu programs installed on the image. Note that Mozilla Firefox which we installed in listed as one of the available app to be published. We will select it and other applications like command prompt and remote desktop and click publish.



Publish program using path

What if we deploy the custom app on virtual machine which we created but forgot to add that app path in the start menu? Here is the option that can be used as alternative. As the name suggests, you can publish the programs if you know the path on which it is installed on the virtual machine. Remember we did take a note of the path where we deployed our custom application?



Here is the list of apps which we have published using mentioned both options.



Sessions

You can track the number of connected user sessions in this section. If user session is idle for more than 4 hours, then user gets disconnected from the session.

There is an interesting feature which I liked the most. You being an administrator of your remote app collection can send message to any user or all users at a time. E.g. if you want to announce about the maintenance schedule of any app hosted in your remote app collection, this feature becomes handy.

Scale

You can decide to scale up or scale down the remote app collection based on user traffic. You get following service plans to choose from.

Basic, Standard, Premium and Premium Plus. You can read more about plan features and costing details here.

End User Experience

Let’s see the side how it looks from end user’s point of view. To access the apps which we just published in previous steps, end user experience is quite consistent. All users need to do is visit the link below and download the appropriate client. 

• AzureRemoteApp

E.g. if user intention is to access the apps through windows OS, Windows remote app client needs to be installed, similarly to access apps from the android device, android client of remote app needs to be downloaded.

Let’s go ahead and download the windows client since I am using windows OS. Once you are finished with installing the client, the welcome screen shows the get started button clicking on which you need to enter your active directory credentials. (Credential of the users who was added through user access section in the Azure portal.).

On successful validation of credentials, you will be shown the exact same list of the applications which we published few steps back. In short, these are the applications we made available as public for all logged in users similar to you.



You can start using any of these app at any time. Experience would be no different than running any normal application which you run on your host machine.

Let’s launch our console application and see if it works! Voila, it worked!



It did save my contents in a text file on local drive of remote app collection. If I run the app again, it will show the saved contents from the disk.

Concept of UPD (User profile disk)

As we saw in our console application, it does save and read the data in local file system, some of you might have already started to churn their wheels about where exactly this data gets saved and how? What if user 2 runs the similar app then what happens? How user sessions and data is being managed? That is where user profiledisk comes in to the picture.

Remote App saves the user’s identity and customizations across devices and sessions in per user per collection disk which is known as user profile disk. Users can save their data in the documents folder which appears to be a local drive. User’s personal settings are also persisted when connecting to RemoteApp. Total available size of UPD is 50GB, to store user and application data. If for any reason you being Remote App administrator need data of any particular user, the best way is to raise a ticket with Azure team and it will provide the link to vhd(accessible for 10 hours) which you can download.

On server users see their UPD mapped to directory c:\Users\UserName.

Note that, UPD and its data is only accessible when user is connected to Remote App session, once it is disconnected then users won’t have any access to the saved data. Shared data storages like one drive and dropbox can be used as solution to this, RemoteApps does support OneDrive for business (not personal) and dropbox.

Redirection concept

Redirection i.e. commonly known as device redirection is a feature which lets users interact with remote apps with devices attached to their local computer, phones etc.

E.g. users might want to play a song in a remote app using speakers of their base computer, run skype on remote app but use camera of phone etc.

Most of the device redirections are enabled by default when you connect to remote app except drive and USBc ports. You will need to enable these redirections explicitly with few PowerShell scripts. You can read more about it here.

Connecting to Remote App Image

Since we have set up Azure remote app and we are able to run apps which we published, but can I connect to the image hosting our apps? Well no because our VM was deleted when we captured its image so what needs to be done?

There is always a workaround available, remember the RemoteAppAdmin2 which we created? We can use that to connect to our collection. Note that you will not be able to access the collection with RemoteAppAdmin which was the administrator of our virtual machine and that is why we created the second user with same permissions.

Let’s run command prompt in our remote app and will try to see the host name. Once we know the host name, we will connect to the host by running remote desktop connection (mstsc.exe) app which we published.



Since now we know the host name, let’s try and log on to the host with credentials of RemoteAppAdmin2.

On successful connection, you can take a look at the file system and also check the mapped UPDs in C:\Users\. Note that you won’t be able to browse the contents of these user directories even though you have logged on with user having administrative permissions. You can also check the path to your custom apps i.e. your executables which you deployed on the VM image.

Why do we need to log on to the hosting server?

This approach can help app developers to update, test and redeploy their applications quickly.

E.g. we can update our custom on-premise app with certain changes and replace the executable on the image with new one. Changes will be immediately available to all the users of remote app collection which saves lot of time during development cycles.

Note that this is not a  recommended approach for production systems because if host changes, the changes you will deploy using this approach will not persist. New host will always refer the original image which you created using  the RemoteApp and will deploy only those changes to RemoteApp collection.

Read more articles on Azure:

• Top Interview Questions And Answers Of Cloud Computing And MicrosoftAzure
• Developing Modern Applications onAzure