Azure Remote Apps
Being a
popular cloud services provider, Microsoft Azure keeps adding variety of new
services to its existing offerings making sure cloud becomes your platform of
choice for your existing business scenarios and applications.
This article
mainly focuses on introduction to one of such offering of Microsoft Azure I.e.
Azure Remote Apps.
What is Azure Remote App Service
Azure Remote 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 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 simplerJ. 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 have to ask before making up mind to use this service.
Consider a scenario wherein an organization having 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
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 workstation 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 outlet 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 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 hour? Will their infrastructure support the load? All
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 means in layman’s terms so that next parts of this
article becomes 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
- Cloud
- These collections reside completely in Azure and don’t communicate with in of 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 network.
- Hybrid
- These require connection to yours 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 also referred as domain joined collections.
This article
focuses mostly on creation of cloud collection and deploying a simple console
application on it, so we will go step by step.
As I mentioned
before, 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 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, so 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
ofcourse 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 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 it? 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-requisitesJ)
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 as Windows 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 –
{
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();
}
string fileContents = 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..");
string contentsToWrite = Console.ReadLine();
if
(!string.IsNullOrEmpty(contentsToWrite))
{
StreamWriter writer = new StreamWriter(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 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 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.
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 profile
disk 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 USBs
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 real quick.
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 recommended approach for production systems because if host changes, the
changes you will deploy using this approach will not be persisted. New host
will always refer the original image using which you created the RemoteApp and
will deploy only those changes to RemoteApp collection.
