Windows 2012 Remote Desktop Services – A rant from a service provider’s perspective

Windows 2012 Remote Desktop Services has been with us for a few months now and prior to its release I had high hopes an evolution of what was started in Windows 2008 and 2008 R2 with the issues addressed and features improved. To understand the upcoming rant you first need to understand how our use of Remote Desktop services differs from your typical corporate environment.

What we do is web enable our customer’s applications and this is done using the various components of Windows 2008 R2 Remote Desktop Services. Typically customers either connect directly to desktop to run their hosted applications or we generate remote desktop files and distribute these to the customers so they can place them on the desktop of their computers.  We also provide access using Windows 2008 R2 Web Access and we can publish applications directly to the end users’ desktop. Due to the diverse nature of our customers’ requirements we allocate each customer their own Windows 2008 R2 desktop this ensures there are no issues with application compatibility that you can often find in other shared desktop environments.

 Prior to Windows 2008 one of the biggest challenges was presenting the customers desktop to the internet. This often involved publishing the servers remote desktop port directly to the internet which wasn’t the most secure way of doing things but customers often had to deal with firewalls not allowing access to ports other than common web protocols.  In a lot of cases it was too many hoops to jump through for some customers. When Windows 2008 was released this problem disappeared because along came the Remote Desktop Gateway.  What this does is allow customers to access their applications using HTTP web protocol through a single secure namespace.  From our perspective this made web enabling applications such as Microsoft Office, Sage Accounts or any bespoke application a much simpler process.   The key component of Windows 2008 Remote Desktop services are the options you have to distribute the application to the customer.

  • Remote App RDP File
  • Remote App MSI File
  • Desktop RDP File
  • Remote Desktop Web Access
  • Remote App Start Menu (Windows 7)

This allows us to support a diverse array of client operating systems from Windows XP through to Windows 8 also including MAC OS and numerous flavours of Linux. This for the most part works really well and we have developed a process that allows us to deliver a bespoke solution to the customer within 72 hours of them placing the order.

Windows 2012 Remote Desktop Services brings a host of new features but those are of little consequence compared to what has been removed. Gone is the ability to create Remote App RDP/MSI files along with the ability to customise remote app configuration on a server by server basis. What Microsoft have tried to do is simplify the deployment of Remote Desktop services using “Scenario-Focused Deployment”. This is the equivalent of “Remote Desktop for Dummies” and allows you to deploy an end-to-end solution without having to really understand what each individual component does.  This works really well as long as your environment meets the following requirements:

  • End users connect to multiple session host servers to access their applications.
  • End users are running Windows 7 or Windows 8.
  • You are not a service provider.

Take the following utopian solution.  What we have here is a very simple three server solution. The core RD services are hosted on a single server these consists of:

  • RD Connection Broker – This is used to manage session state between RD session host servers. In layman terms this means if you get disconnected from a remote desktop server the session broker will try to reconnect you back to the same server so you don’t lose your desktop. This works perfectly and we use it extensively with our larger customers who have more than one remote desktop server. However it’s of little use to customer who only ever connect to one server.
  • RD Gateway – This is used to connect the customer’s device to their Remote Desktop server. This is done by converting the HTTPS protocol to the RDP protocol. This is one of the key components in our infrastructure.
  • RD Licensing – This is used to manage the remote desktop licenses for the customers who connect to our environment.
  • RD Web Access – The RD Web server provides a browser based method to access hosted applications.

 

 

The customer applications are hosted on separate Remote Desktop Session Host servers. One server provides Office 2013 and the other is running Sage Accounts. In our utopian scenario the customer logs into the RD Web Access and is presented with their applications. They don’t care where the applications are hosted they simply select the application they want to run and everyone is happy.

As I said earlier in the rant we don’t provide a utopian solution what we provide is a bespoke fully managed solution where each customer is isolated from every other customer. The only shared components are the RD Gateway servers and the active directory where the accounts are hosted. This turns the “Scenario-Focused Deployment” on its head as we are the square peg to its round hole.  Any attempt to configure Remote Desktop services in a way outside the “Scenario-Focused Deployment” process is met with errors like “A Remote Desktop Services Deployment does not exist in the server pool. To create a deployment, run the Add Roles and Features Wizard”  Grrrrr. I don’t want to create a server pool or collection of applications I just want to install the application, create some RDP files and then distribute them to the customer.  Why do I need to use a connection broker when a customer is only ever going to connect to one server? It’s pointless but if we want to use Windows 2012 then we will be forced to implement it. However due to the number of users we have on our system we won’t get away with implementing one server, no we will have to have multiple servers that are load balanced which is just something else to manage.

That said one of the biggest issues I have with Windows 2012 RD services is the inability to create Remote App files. This is one of the primary access methods for our customers, we install the software, create the RDP file and send it to the customer. They can then copy the RDP file to their desktop and run their hosted application as they would a normal application. With Windows 2012 customers will be forced to use the Windows Start Menu to launch their applications and whilst this doesn’t seem like a bad idea I can tell you of the several hundred customers we have using our system just a handful use the option to have the applications delivered to the Start Menu.  That leaves one other option which is a direct desktop connection to the Remote Desktop session host server. In my opinion this is a backwards step and is only of any benefit to customers whose requirements/client dictates this as the only option. That said we have a lot of customers who access their Hosted Applications this way and to ensure we have a tight control over the desktop environment we use Group Policy Shortcut Preferences to deliver application shortcuts to the desktop and start menu these are controlled by Windows group membership which is in turn used by our billing system to determine who gets billed for what.

One of the defining new features of Windows 2012/Windows 8 is the Metro start screen. What this attempts to do is create a desktop experience that is unified with other Microsoft Platforms and sat at home with my PC, Xbox, Nokia Lumia 920 it kind of works.

Unfortunately that is the only time I get that feeling. In a managed desktop environment where the service provide requires some control over what is installed on the desktop and what icons appear on the screen it just doesn’t work at all. There are no group policy settings to control how the metro screen appears so if there is no control then it’s not something we can allow.  Not to worry we can just give the customer a non metro desktop. Wait where’s the Start Menu? Its Metro or nothing, Microsoft in their infinite wisdom have decided to remove the Start button altogether so the intuitive way that every person on the planet knows how to use to find applications has been removed and replaced with gestures that require the mouse to be moved to a specific part of the screen to activate.  The first two weeks when a customer comes to YourOfficeAnyWhere are usually the most support intensive and then after that it usually tails off once they get used to accessing their application in a different way. The introduction of Windows 2012 is going to make the transition even harder for the customer and that in turn is going to lead to a busier support dept.

As a business the biggest challenge we are going to face is if Microsoft decide to stick to their guns and keep Windows 2012 Remote Desktop Services as it is. There is no news on Service Pack 1 and what improvements it may or may not bring. If Microsoft don’t change the way Remote Desktop services works in Windows 2012 then the way in which our customers access their application will have to change and with it our process for delivering those applications. Customer adoption of Windows 8 at the client would certainly make this transition easier but we are still seeing lots and lots of customers running Windows XP/Windows Vista and it’s these customers we risk isolating if we are forced to deploy Windows 2012.

This was a rant by Paul Monaghan

Director at YourOfficeAnyWhere

Categories: Cloud, Hosted Applications, Remote Application, Remote Desktop

Comments: (0) comments

<

Comments are closed.