Sean Wallbridge
Back in the days when dinosaurs roamed the Earth you needed to use Citrix Presentation Server if you wanted to “publish” applications from a terminal server out to a webpage for easier yet controlled access by users. It sat on top of a Terminal Server install and provided extended functionality that mere Terminal Server users could only dream about. Then along came Server 2008 R2 and Microsoft started to chip away at Citrix dominance by adding in features such as Application Publishing to the growing feature list in Terminal Services (now Remote Desktop Services or RDS). However, even with the “goodness” of RDS services in 2008 R2 and the even more expanded capabilities in 2012, there was still a “disconnect” between RDS and non-Microsoft device users. Everything was just wonderful and many options were available for PC users and RDS; not so much if you had an iPad/iPhone (henceforth referred to as iOS) or an Android device.
We hit this problem in-house with our own RDS server as well as at some customer sites. True, with certain third-party apps you could access the desktop of the RDS server with your iOS/Android device but published apps access was a no go. The solution at that point was still Citrix (XenApp) which worked but which also added more cost and complexity to the equation.
Well, with the release of Server 2012 R2 and the new Microsoft Remote Desktop Client for iOS/Android there are now a whole bunch of options available to the iOS/Android device user of RDS services! And those options no longer rely on having a third-party app installed on either the RDS server or the iOS/Android device. Microsoft is now deadly serious about providing the seamless services experience to all devices that users want to use to access RDS services (or any Microsoft supplied service, for that matter). And with Server 2012 R2, Microsoft has made it a whole lot easier to build out your RDS infrastructure!
Let’s take a look at my home lab RDS configuration as well as how the RDP client works on iOS and Android.
My home lab is modest; I have an older HP desktop machine running Windows 8 with Hyper-V enabled and a whitebox desktop machine currently loaded with an eval copy of Server 2012 R2 with the Hyper-V role enabled. I have a Server 2012 R2 VM running in Hyper-V on my HP and that VM is the DC for my test domain, norex.local (in a nod to the days when I had my own company in case anyone wonders about the name) and a second Server 2012 R2 VM running in Hyper-V on the whitebox. That VM is the RDS server. There is no “horsepower” behind any of this, all the demo VM’s are small. You could try a similar demo/proof-of-concept using the same eval licensing from Microsoft and some spare PC resources, you don’t need a monster lab (although it sure is nice if you have it!).
Building an RDS server that can publish desktops and apps on the internal LAN is essentially as enabling the RDS role and then following the prompts:
On the following screen you get to make a choice of whether you are going to build a “farm” for RDS that spans multiple servers or a single-server install that installs all the components on one box. For this discussion it will be the “single server” solution:
The following screen is also crucial in my choices as it determines whether I am creating RDS services with virtual machine-based deployment (VDI) which assumes I will be publishing virtual desktops driven from special VM’s or if I am creating a “traditional” session-based server (good ol’ Terminal Services) to publish RemoteApp programs and session desktops. Again, for purposes of this discussion I will be going the “Session” route.
Whops! Guess I better restart. I’ll cancel, reboot, then come back here. OK, I’ve rebooted and got back to where I was.
Tick the “Restart …” box then click Deploy!
The system will chug for a bit and will most likely restart. When you get logged back in you should see Remote Desktop Services added into Server Manager and the Add Roles and Feature Wizrad should open back up and display status progress:
At this point the basics are in place. A “Session Host” has been created along with a “Quick Session Collection” which is a group of Published applications that are now “visible” in the RD Web Access.
This collection is published to and, therefore, accessible by “Domain Users” meaning any user with Domain User privileges on the Norex domain can access these apps from the RDWeb. This is a bit different in scope from previous methods of publishing and securing apps. secifically 2008 R2, where you essentially set user access rights (do I get to see and use this app?) on each app itself. Now you create collections of apps that “like” users can access. By default, the QuickStart creates this collection for ALL users but there is nothing stopping me from creating other collections for a more “select” group.
I want to publish out my Office 2013 programs so I will add them to the list of published apps by selecting the appropriate functions from TASKS:
Now I should be able to connect to the published apps using my web browser. Note I have not applied any certificates at this point so I should expect to see a warning about web security.
This is expected. I’ll continue to the website and then add it into my list of Trusted Sites. That done I login:
Yay! I have a list of Published Apps! I should be able to run one …
I know this is the published app because it comes up with the user “Sam Beagle” and that is the user I used to login to the webpage, it is NOT the user I am logged in as on my local PC. So the published apps work!
This is “good enough” to play with and maybe even good enough for a really small install. It certainly is not good enough, from a security perspective, to use in a regular production environment. Various certificates need to be added to secure the website properly to allow you to actually “import” published apps into your Win 7/Win 8/8.1 machines. An RDS Gateway would need to be added if you want to publish access out through your firewall in order that remote users can just hit a web page on the WAN to authenticate and gain access to applications. But that is for another post. This is actually all we need to test out the iOS and Android clients for published app access. That will be in Part 2 of this post.