So imagine you are the CTO / CIO of a business (any size, it doesn’t matter from 10 people to 10,000) your clever team of developers have just implemented a top-notch line of business application (LOB) using the latest tools, on the Windows platform. The application becomes the de-facto tool for all your employees and the business cannot run without it. You decide the time is right to sit back and relax a little as the world is a good and happy place.
The following week the executive board decide that your previously rigid policy of no access to the network unless by a corporately owned, domain-joined device is out of the window and employees may either bring their own device to work or select from a range of devices that are not limited to the Windows platform such as Mac OSx, iOS and Android. The relaxing is over and you need to come up with a solution fast to prevent the revolt in you development team. They know and love their programming in .NET etc. but have never created apps for the other platforms.
What do you do?
The solution is to dive into Microsoft Azure RemoteApp. The short answer is to publish your LOB application either entirely in the Cloud or as part of a Hybrid solution utilising Windows Server 2012 R2 remote Desktop Services (RemoteApp) (which has been around since Windows Server 2008 R2).
Currently in preview as shown below
Azure RemoteApp allows the user to publish a list of applications to users or groups of users that will not run natively on their systems. The only requirement for their platform is the existence of the Microsoft Remote Desktop Client which is available for Windows, Mac OSx, iOS and Android.
The trial solution includes a whole host of built in applications as well as Office 2013. Before I walk you through the simple setup and deployment, let’s finish off the tech specs and business benefits.
Importantly in the mobile devices era, the concern over data security is eliminated since the application runs on the Azure servers (or your on premises ones) so the loss of the device does not expose and data to exposure or loss.
Scaling up and down is rapid, cost-effective and easy to achieve in the Azure platform. This can cater for rapid expansion or decline in service requirements. Seasonal workers can be accommodated without the capital costs and time involved in procuring and deploying servers. Equally important the scale down doesn’t leave expensive assets switched off being unproductive.
Employees can use either their corporate credentials or a Microsoft Account, whichever you choose.
Sound good, well if you want to follow this walk through simply sign up to an Azure trial (if you aren’t already an Azure customer) by clicking here. Then once you are in use any of the helpful tutorials or product documentation the get up to speed with the portal and navigation. Finally to prepare you for the session, sign-up to the Azure RemoteApp preview here.
Once this has been accepted and you are comfortable with the portal, read-on. (The rest of the post assumes a basic knowledge of Azure services and principles)
Sign in to your portal at https://manage.windowsazure.com where a list of your previously created items will be displayed.
Scroll down the list of services until you find the RemoteApp section, select this tab.
Select + New at the bottom left of the screen and then App Services followed by Remoteapp (you may have to scroll the list down a little, the number of Azure services is growing rapidly). Two choices are available Quick create or Create with VPN. The latter is for Hybrid deployments, for now we will choose Quick Create as below
Enter a name for your service and the location in which you want this hosted. The number of regions is also growing. I always select North Europe or West Europe which relate to our data centres in Dublin and Amsterdam respectively (note Dublin is North Europe!). Currently the only template image available is Office 2013 Pro Plus running on a Windows Server 2012 R2 platform. (Although you will never see or know about the servers, Microsoft patch, update and maintain them in the background as part of the SLA)
Once your service has been created it will appear under RemoteApp services. Select the service by clicking on it and the service setup page will be reached.
The next stage is to configure which applications and which users may take advantage of this service.
Select the ‘publish remote programs’ option and add / remove from the list of available applications shown below.
Having chosen the required built in apps, you can now go ahead and click on ‘configure user access’
Simply enter the email addresses of your users. You can even add groups to segment which users have access – this group would come from the built in Azure Default Active Directory.
The remainder of this tab hosts a published apps list and a session list showing the status of all connected users.
Clicking on the dashboard will show your current and available session usage and other image and template information.
You are now all set. All that is left is to download the client application from https://www.remoteapp.windowsazure.com/ which will default to the windows application page but a link will take you to the all clients download page. These are shown below and include Windows (x86,x64 and 8.1RT), Android, iOS (iPad and iPhone) and Mac (OSx)
Having done that it is simply a matter of running the app, logging in with the registered email address and choosing the Windows application to run.
Let’s have a look at the client experience on a Windows 8.1 device (simply as I am being lazy with the time required to screenshot on an iPad and transfer the files – on a deadline!)
The first thing to remember is that like on-premises RemoteApp, the first time you connect to an application, the Remote Desktop Protocol session is initialised and authenticated. So the app takes a short while to open. All other apps hosted on the same host then open in that session and are much quicker. (Remember, if you close all the RemoteApps the session will be closed so future starts will be slower again).
Here it’s worth pointing out that the RemoteApp client can connect simultaneously to more than one RemoteApp service so an end user can have access using the same email address to many different RemoteApps from many different providers.
So run the Application, in this case from the start screen.
Log in with your registered email address and you find an empty window.
Click on App invitations and you will see any provider invitations to connect to a RemoteApp service. Choose the one you need and the window is then populated with all the published apps. This can be refreshed mid-session to see if any apps have been unpublished.
From there run the applications as you want, whilst remembering that your PC, iPad, Mac or Android device is not doing the processing the remote machine is doing that all you are doing is running a remote connection to it and presenting that on your screen. So data remains on that server. You can connect to your OneDrive which exposes the cloud shared files (currently each user has 1TB of storage). See the screenshot of the Task Manager Processes tab on my home PC when running four Azure RemoteApp programs. A total of 170MB of ram and 0.1% of processor.
I have shown below some screenshots showing PowerShell and CMD windows open having run a whoami and an ipconfig to show the host is the same for each app and the ip scheme and networking information is specific.
I have also shown a shot of the open dialog in RemoteApp Excel and the temporary storage setup for the system with a handily placed warning README.DOC not to store files there.
The files you do not want on OneDrive can be saved locally. Try creating a file closing the session and accessing it again they are all persistent. So your data is stored safely in Azure.
Here we see a RemoteApp Windows PowerShell session (I would run that wouldn’t I?) You can see from the task bar that the icon has a RemoteApp symbol on in (in green)
I have gone well over my normal word count and haven’t even touched on the uploading of your own images to host in the cloud or on creating VPN’s to run RemoteApp programs on-premises through Azure.
These will have to be for another day, but both involve a lot of PowerShell, always PowerShell!