Understanding Azure File Share

All of us at some point, be in our educational institutes or in professional world have used the file share, i.e. the common storage space maintained by IT team of an organization where users can create their folders, access common software installers or keep project specific documents. Usually we mount this storage space as a network drive for easy and quick access.

This article describes the details of below topics 

• Basics of Azure file storage
• Creation of file storage service using Azure portal
• Mounting file share as drive
• Accessing file share using storage client libraries.
• Setting SAS policies on content in file share using storage client libraries.

Basics of Azure File Storage

Azure file storage is an offering of Microsoft Azure is an equivalent to SMB file share. The legitimate question to be asked here is since I can anyway have SMB file share implementation on premise, why would I go with Azure file storage? And here are your reasons

• You can quickly migrate legacy applications relying on file share.
• Avoid costly re-writes.
• Azure file storage becomes your central share which can be consumed by Virtual machines running in Azure, Cloud services, any on premise clients with SMB protocol.
• Better control and more built in accessibility options available. E.g. System I/O APIs, REST API, Client libraries, PowerShell cmdlets.
• Easy integration with Linux.
• Better scalability and performance targets.
• Simplified hosting for high availability workload data

Note that as of today, file storage doesn’t support active directory based authentication mechanism to validate access requests. Instead it uses access key based mechanism of storage account. If you need to have more control on stored content, then you should use shared access token as an alternative.

What is SMB

The file shares are typically driven by a protocol called as SMB. SMB protocol is Server Message Block, which is nothing but a mechanism to provide shared access to files, printers, and serial ports over the network.

Microsoft’s implementation of this protocol is called as Microsoft SMB. It was introduced with Windows vista operating system as SMB 2.0 and revisions of the same were made later in Windows 7 with subsequent major revisions of 2.1 and 3.0 as of today.

Concept of Azure File Storage

Let’s try to understand the concept of Azure file storage

Storage Account

Basically it is a subset of azure storage services and hence we will need an azure storage account.  

Share

Shares can be considered as logical representations of the drives which you can map. It is a container of directories and you can create unlimited number of shares within a storage account and each share can store maximum of 5 TBs of data.

Directory

These are nothing but the folders you can create within a file share. It is an optional entity in the hierarchy.

File

You can store any number and any type of files in a file share. Each share has its quota limit and can be maxed up to 5 TBs. Maximum file size than can be stored is 1TB.

The hierarchy can be visualized as below

As shown in the image above, storage account contains two file shares. i.e. Share 1 and Share 2. Each share has two directories and each directory is containing some files.

The Url of the file stored within a directory or in a share is formed in a following format

https://<storage account>.file.core.windows.net/<share>/<directory/directories>/<file>

Fail-over and Backup

For any storage solutions, one of the key criteria is to make sure that data is not lost even in disaster. File share being an azure storage offering, it does follow all disaster recovery and failover standards and mechanisms as of storage account however there is slight difference. What is it?

As of writing this article, the file share witness and RA-GRS (Read Access – Geo Redundant Storage) is not supported for file share.

About back up, though there is no official way to back up the azure file share there is always a workaround. You can automate the process of backup with the help of AzCopy and backup your file share content to blob storage or install back up agents like Cobian to set up your full and incremental back up procedures of file share mapped drive.

Creating File Share using Azure Portal

Let’s go ahead and set up and azure file share using azure portal. It is a quite straightforward process and starts with creation of a storage account.

Let’s create a storage account with name demofsstorageaccount within a resource group which I created earlier. You can choose to create new resource group if you don’t have one. Once you are done filling all required information, hit create button and it will submit the creation job to azure.

As this is a demo storage account, I have set its type as locally redundant. To Read more about what all types you can select and what their significances are, it is recommended that you should go through this link at least once.

Once the storage account gets created, browse to it and click on the Files section as selected in image below

Click on the Add file share button at the top of the File service panel. It will open up another panel where you can give name to the file share and declare its quota.

Let’s give file share name as “sharedfiles” and quota limit as 1 GB, it immediately creates the share for you which looks like below

Take a note of the highlighted buttons which are quite self-explanatory. We will take a detailed look at connect button later in this article.

Before we add some files, let’s add a directory in file share and which will act as folder for our files. Name it as “Shared Content”

Click on the upload button and it opens up a panel with typical file upload control with multiple selection enabled. You can browse files that needs go on file share and select start upload button in header of the panel. We can see that directory and files are being shown in the file share now.

Select any file and click on properties button in the header. You will be shown URL of the file which follows the same format as mentioned above in this article

Note that there is ETAG associated with each file meaning that the files will be cached depending on the change in contents of the file. The cached copy of the document will be sent down to client every time when it is requested.

Let’s try to update our excel file by deleting it from share and uploading a new copy with same name. Observe the change in the ETAG

Mapping File Share as Network Drive

As mentioned before, we can map the file share as network drive so that content on it becomes easily accessible and you can browse through different directories quickly.

It is quite straightforward process and I am sure many of you might have done it already but even if you haven’t, here are simple steps to do it.

Before we go ahead and map it as local drive, there are certain things you need to be aware of

• The client device should support SMB 3.0 protocol (Windows 8 and above OS) and port 445 (TCP outbound) is open.
• If you mapping drive on windows virtual machine hosted on azure in a same subscription and same region as of your file share service then the traffic between Azure VM and file share will be free, else you would be charged for the traffic as external bandwidth.
• For Windows 7 devices, though they support SMB 2.1 but access from outside of azure is restricted due to lack of channel encryption in SMB 2.1, however SMB 2.1 is supported if you are accessing the share within Azure.

Mapping can be done in multiple ways, one is using command prompt and other is using UI on windows devices.

Remember the Connect button mentioned above in this article? it shows simple instructions how you can map your file share as network drive using command prompt.

Open “My Computer” (Quickest way to launch it Windows key + “E”) and select the option from the top action links which says Map Network Drive.

Name the drive and enter path of the file share which we just created.

For us the share is \\demofsstorageaccount.file.core.windows.net\sharedfiles

Since Azure file share doesn’t support any other authentication mechanism than typical storage key as of now, select both checkboxes i.e re-connect on logon and connect using different credentials.

Once you are done, you will be asked for credentials. Make sure you enter your storage account credentials in the authentication dialog. You can get the primary or secondary storage key of your account in storage account Settings > Access keys.

After successful authentication, you should be able to see the mapped drive in your explorer.

Accessing File Share using Client Libraries

Before we start this, make sure that you are using 5.x + version of storage client assemblies. Also note that Azure emulator currently do not support File share so make sure that you are pointing to correct file share service on azure.

Let’s create a console application which will access and download the files in a file share which we have recently created. Create new console application project in visual studio and install “WindowsAzure.Storage -Version 6.2.0” nugget on it.

The sample code to access and download the file is as below

Note – The code below is just for the demo purpose and may not be the best performing code.

It connects to the file share and verifies if it exists and then proceeds, same is done for getting connected to directory and file to be downloaded. It downloads the file to the local file system.

Note that it reads the connection string of the storage account from the application configuration file so to run the code below as-is, you will need to add the key with same name to your app.config and set it’s value to connection string of your storage account (which can be easily found on azure portal by going in the Settings > Access Keys)

class Program

{

   static void Main(string[] args)

   {

     try

     {

       CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConfigurationManager.AppSettings["StorageAccountConnectionString"]);

       CloudFileClient fileClient = storageAccount.CreateCloudFileClient();

       CloudFileShare fileShare = fileClient.GetShareReference("sharedfiles");

       if (fileShare.Exists())

       {

         CloudFileDirectory rootDirectory = fileShare.GetRootDirectoryReference();

         if (rootDirectory.Exists())

         {

           CloudFileDirectory customDirectory = rootDirectory.GetDirectoryReference("Shared Content");

           if (customDirectory.Exists())

           {

             CloudFile file = customDirectory.GetFileReference("The Word.docx");

             if (file.Exists())

             {

               Console.WriteLine("Downloading file..");

               DownloadFileFromShare(file, @"D:\Downloaded_The_Word.docx");

             }

           }

          }

        }

      }

      catch (Exception ex)

      {

         Console.WriteLine("Error: " + ex.Message);

      }

      finally

      {

          Console.WriteLine("Enter to exit..");

          Console.ReadLine();

      }

    }

    private static async void DownloadFileFromShare(CloudFile file, string saveToPath)

    {

       await file.DownloadToFileAsync(saveToPath, System.IO.FileMode.OpenOrCreate);

    }

a

Setting SAS policies on content in file share

As mentioned in the article above, we can set up SAS policies using storage client libraries for better control over the content, let’s see how it can be done.

This article assumes that users have basic understanding of SAS and related policies and so will only focus on setting these policies on file share contents. If you do not know about SAS, you can read more information here.

The basic idea is, when you don’t trust your storage clients and still you want to provide access to resources in storage then you can achieve this by providing shared access signature token and let clients access the resource for limited period. You can optionally define the access policy and generate token from the policy which we will do in our example below. The benefit you get out of this is, you don’t have to share the primary or secondary key of your storage account to the end users which ultimately provides them the administrative access to your storage account.

In our sample code below what we will do is, we will define a SAS policy with read only permissions on the file share which we created. We will try to perform the write operation on file share i.e. by creating a new file in file share, it is expected that the code should run with an error as we don’t have any write permissions yet.

If we run code below as-is then we should get error like this

class Program

    {

        static void Main(string[] args)

        {

            try

            {

                CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConfigurationManager.AppSettings["StorageAccountConnectionString"]);

                CloudFileClient fileClient = storageAccount.CreateCloudFileClient();

                CloudFileShare fileShare = fileClient.GetShareReference("sharedfiles");

                if (fileShare.Exists())

                {

                    string policyName = "DemoPolicy" + new Random().Next(50);

                    FileSharePermissions fileSharePermissions = fileShare.GetPermissions();

                   

                    // define policy

                    SharedAccessFilePolicy sharedAccessFilePolicy = new SharedAccessFilePolicy()

                    {

                        SharedAccessExpiryTime = DateTime.UtcNow.AddHours(1),

                        Permissions = SharedAccessFilePermissions.Read

                        //Permissions = SharedAccessFilePermissions.Write

                    };

                    fileSharePermissions.SharedAccessPolicies.Add(policyName, sharedAccessFilePolicy);

                    // set permissions of file share

                    fileShare.SetPermissions(fileSharePermissions);

                    // generate SAS token based on policy and use to create a new file

                    CloudFileDirectory rootDirectory = fileShare.GetRootDirectoryReference();

                    if (rootDirectory.Exists())

                    {

                        CloudFileDirectory customDirectory = rootDirectory.GetDirectoryReference("Shared Content");

                        if (customDirectory.Exists())

                        {

                            CloudFile file = customDirectory.GetFileReference("DemoFile.txt");

                            string sasToken = file.GetSharedAccessSignature(null, policyName);

                            //generate URL of file with SAS token

                            Uri fileSASUrl = new Uri(file.StorageUri.PrimaryUri.ToString() + sasToken);

                            CloudFile newFile = new CloudFile(fileSASUrl);

                            newFile.UploadText("Hello!");

                        }

                    }

                }

            }

            catch (Exception ex)

            {

                Console.WriteLine("Error: " + ex.Message);

            }

            finally

            {

                Console.WriteLine("Enter to exit..");

                Console.ReadLine();

            }

        }

    }

Now we will simply change the permission of the policy and let users give permissions to write and run the code.

Note that the change in is only in a line i.e.

// define policy

  SharedAccessFilePolicy sharedAccessFilePolicy = new SharedAccessFilePolicy()

  {

    SharedAccessExpiryTime = DateTime.UtcNow.AddHours(1),

    Permissions = SharedAccessFilePermissions.Read | SharedAccessFilePermissions.Write

  };

Code runs successfully, let’s verify if file got created in file share.

If you download the file and see the content, you should be able to see Hello! Which we wrote using our console application.

There are lots of other possibilities to configure and play around the file share using the client storage assemblies and PowerShell scripts.

Thanks for reading this and your views, comments will be appreciated.

Guide to Azure Remote Apps

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 –

 class Program

{

   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.

https://www.remoteapp.windowsazure.com/

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.