And Finally…..

Not my final post but the final part in my Azure RemoteApp series. First, many apologies for the delay, the day job is getting hectic. I have been evangelizing, demonstrating and using Azure RemoteApp for almost a year now and like most Azure services this one has developed and blossomed into a seriously powerful Enterprise Mobility Tool.

The first two posts covered why and how you set up and use an Azure RemoteApp collection. This post will cover some recent enhancements and a description of what I think is its most powerful use case.

To use your organisational credentials to authenticate against your on-premises Active Directory and to then use resources inside your corporate network from a non-domain joined, possible non windows device with complete safety and security.

In a recent IT camp at our London Headquarters, Cardinal Place, Victoria, there was an evacuation alarm just as I was about to demonstrate these features. Luckily I had my handy Lumia 1520 phone with me and found a spot to carry on the demonstration outside, which then seamlessly continued on a different device when we regained our cosy auditorium.

So to recap, I introduced Azure RemoteApp in this post and developed the theme by uploading my own image with an installed application in this post.

Now it’s time to finish off. To help set the scene, below is a diagram of the infrastructure I am using. 

It is fairly self-explanatory but in this instance all these servers are IaaS Virtual Machines running in Microsoft Azure (Cunningly masquerading as my On-premises datacentre). As shown below.

So what is different about this RemoteApp collection?

Well in Post no 2 you learned how to create and upload a new RemoteApp image. The pre requisites are.

Windows Server 2012 R2 Image.

Remote Desktop Session Host Installed

Applications required installed and updated

Update the Operating System fully

VHD not VHDX (use dynamic)

Sysprep the image

Upload it.

 

The difference is in how you create the RemoteApp Collection. This time we are going to add this to the ADDS Domain (in this case corp.ed-baker.co.uk) and use the create with Vnet option.

There are Basic and standard plans available which simply dictate the size and power of the VM that is created. Pricing is available here.

Having created my collection, I have a number of tasks to complete. The collection I am using for this post is one which is joined to the corp.ed-baker.co.uk domain (on premises AD DS) and runs a Line of Business Application and also accesses data stored in an on premises SQL Server (the Adventureworks sample database) by using Microsoft Excel.

Configuring this has become much simpler than it used to be, despite Azure RemoteApp being a new service, it has undergone frequent revisions and improvements. The latest and greatest of these are the release of the PowerShell CmdLets and the ability to use a virtual network in Azure that is already present and in use for other functions. Prior to this you had to create a special RemoteApp network and then join it to other networks. This is not now required.

As shown below

We are now left with a new but empty collection.

Clicking on the right arrow takes you to the quick start page. Where you should start the configuration of your new collection.

 

 

 

 

 

 

 

 

 

 

 

It really is as simple as 1,2,3,4 GO!

In my demonstration setup I use a Virtual Network I created in Azure and use for the virtual datacentre shown above.

I made sure the network was large enough for my local and remote users. You really don’t want to run out of IP addresses if you have a small network and lots of users, this is a possibility. You are also warned about this.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To link the network you simply complete a short wizard.

 

 

 

 

 

 

 

 

The next step is to join a local domain (on premises AD DS) again this is a simple step of clicking the button and adding the necessary credentials. This user MUST have domain join rights (computer accounts), it is best practice to create a new user (service account) specifically for this rather than use a domain admin credentials.

 

 

 

 

 

 

 

 

 

 

 

The organization unit is an optional field allowing you to join the remote desktop session host servers to this OU.

The below is a screenshot of the Computers container in corp.ed-baker.co.uk after a while using this collection.

My on-premises Servers are all present, as are the many instances of RDH Servers, it would be tidier to create an OU for these and state it in the wizard so all future RDH servers are created in that OU.

So we now have an empty collection attached to a network and set to join its instances to my domain. The next step is to link this collection to my uploaded image. For the sake of brevity (this is already a chunky post) I will refer you to post 2 in the series which shows the process for uploading your own image.

Just remember the re requisites for the image. Such as VHD rather than VHDX, dynamic rather than fixed size as well as the details for the operating system and applications above.

Having got this far you are now enabled to start publishing the applications you would like to deploy through this service, to your remote users.

There are two ways of publishing programs, by start menu or by path.

 

 

 

 

The first option lists out all the applications that are available on the start menu (installed) of the image you deployed. The second allows you to choose a program that you have placed in a particular location.

 

The image I uploaded has the followed published programs, a mixture of Path and Start Menu programs.

The final step is to choose the users you want to deploy this service to. Azure RemoteApp requires a default Azure Active Directory to be associated with the service, when using a hybrid collection.

To add users you simply enter them line by line 

Or bulk add them using a .CSV file with a single column containing the UPN of the users you wish to add.

 

 

 

 

 

All the users added MUST be dir synced users from your on-premises Active directory because you have joined this collection to your domain so authentication will take place there. You can see below the failure report when I try to add an Azure AD user not originating or sync’d from the on-premises Domain.

 

 

 

 

Your collection is now complete. A few pointers here though about your environment back on-premises.

The users with Azure RemoteApp access must also have AD DS access to the machines and resources you want them to reach. Also things like port 1433 for SQL Server (thankyou @deepfat) must be open.

The dashboard, sessions and scale tabs are all self-explanatory and allow you to manage your collection from now on.

Users require access to the same client as before on any of the supported platforms. (almost all of them)

When you connect with your on-premises users, the log in screen will authenticate you against the on premises Domain Controller.

You then have access to all the published applications and since you are operating from a server joined to the domain and have domain credentials, you can access the internal resources, just as if you were within the corporate network.

The beauty of this is that you aren’t and you could be on any device and the data never lands on that device it is stored safely on-premises and in the application in Azure.

You can see below a screenshot of the end result.

For a full recorded demonstration of the user experience for this collection, I shall publish a short video demonstration in the next few days.

When Azure Remoteapp was first released in Preview last year I was enthusiastic, now it has become generally available at an affordable price in different flvours of size and licensing options and has been updated and refreshed I am firmly believe this is now a killer App and the take up from customers is proving this point.

Why not set up a 90 trial now. There are also useful resources in Microsoft Virtual Academy to help you. If you haven’t been there for a while, take a look now – it has a new look and feel to it.

Finally as you might imagine, I would like to end this series by introducing you to the new PowerShell CmdLets for Azure RemoteApp as described in this MSDN Blog post from March.

This makes the automation of these processes just a PowerShell session away. Happy Days.