The Desktop Virtualisation Alphabet soup
I have some colleagues doing their MLSE and have come to the “Virtualisation Licensing” module and the alphabet soup therein: MED-V, APP-V, RDS, VDA, APP-V for RDS, VDI, MDOP. While there seems to be an abundance of technical knowledge for all these, there is very little high end simple explanations for these, and those there are out there make the products seem more similar than they should, and this is what this post will address.
MED-V
In my earlier post on Desktop Virtualisation, I went through a brief explanation on virtual desktop options. Included in this is the XP Mode you get with Windows 7 Professional or higher editions. This allows applications to run in XP mode should they not be compatible with Windows 7. This means each physical machine has it’s own virtual PC controlled and managed by that user allowing them to run legacy applications whilst taking advantages of the new Windows 7 OS.
MED-V also delivers the applications with compatibility issues with the latest OS on previous versions seamless to the end user. So what is they difference? Why spend the money on MED-V when you get XP mode with Windows 7? It is simple, MED-V is designed for IT environments and centrally managed deployments and provides support for the virtual environment and is suitable for large scale deployments. XP mode is suitable for individuals who require legacy applications. They will not be centrally managed or updated.
MED-V is only available through the MDOP Licence which is a subscription licence for users with active SA for their desktop OS.
APP-V, RDS and APP-V for RDS
App-V (or Application Virtualisation) comes in 2 flavours: App-V for Desktops. This is ONLY available as part of the MDOP licence. And App-V for RDS. This is ONLY available included in the RDS CAL
App-V for Desktops: Instead of installing an application on the desktop, the administrator packages the application using App-V and streams the application across the network where it is cached locally on the end users desktop but not installed. So the applications effectively sit in bubbles as to not conflict with one another. An example where you would use this would be if you needed 2 versions of Access working on the same machine. Installed on the same machine, they would conflict with each other, working in their App-V bubbles, they don’t! Also, as the application is cached locally on the machine, the end user can work off line on the application. Any updates are streamed to the machine when it reconnects to the network:
RDS or Remote Desktop Services is the shared usage of a desktop environment that is running on the server. A user will log in via a portal and launch a session of a full desktop environment. The user will then have access to the applications installed on the RDS Server. The application will run from the server and not the desktop but the application would be presented to the end user on their desktop:
Should you have a conflict in applications, again using the above example of the 2 versions of Access, traditionally a new RDS host would need to be built as they would not be able to run on the same Server. App-V for RDS allows the administrator to stream and cache the applications on the RDS Host in their isolated bubble (rather than the desktop), avoiding these conflicts and allowing them to run on the same machine:
The disadvantage for applications run on a Remote Desktop Server, with or without App-V, is that you will need a constant network connection in order to access the applications on the server:
If the customer has App-V via MDOP as well, IT can package the applications and stream to both RDS host and to the desktop as well to be cached locally for offline usage.
In order to run RDS, you need to purchase a Windows Server Licence for your server, then each user or device accessing the application on the server will need an RDS CAL as well as a Windows CAL. App-V for RDS is included in the RDS CAL.
MDOP or the Microsoft Desktop Optimisation Pack is a suite of technologies available to customers with Active Software Assurance for their Windows Desktop. As already discussed App-V for desktops and MED-V are just two of the technologies included in this subscription and help resolve issues by ways of different methods of virtualisation. Other technologies included in the licence, all a different flavour of soup for another day: AGPM, DaRT, MBAM, and AIS, full details and descriptions on the MDOP page. Access to the software through MDOP is only available as long as the subscription for the software remains active.
Full Desktops running from the Server
There are 2 ways in which to licence the desktops from the Server as either session based on a Remote Desktop Server (RDS) –the new name for Terminal Services – or individual virtual desktops in a VDI environment.
Session Host – Remote Desktop Server – RDS
As explained above, RDS is the shared usage of a desktop environment
The devices access different sessions of the same Virtual Desktop environment running from the RDS Host. Licensing for this Scenario is also explained above. This has limitations in that it does not allow users to install their own applications, personalise the desktop environment or have any admin rights.
VDI Environment
Remote Desktop Services (the new name for Terminal Services) allowed users to connect to the RDS server for a session of a full Desktop or individual programs. That sever could host multiple sessions for multiple users sharing the same resource. When Microsoft launched Windows Server 2008 R2, they changed Terminal Services to Remote Desktop Services to reflect the added role to the Hyper-V: Remote Desktop Virtualisation Host. This then allows for users to access a dedicated Virtual desktop running a Windows Client OS on the server.
In order to Licence this Scenario, each DEVICE accessing a VM will need to have an Operating system covered by Active SA, this then licences the Windows OS client running on the datacenter. Should the device not be covered with SA, be a third party device or a thin client, you will need to Licence with these with a VDA or Virtual Desktop Access Licence. The Server will need to be licenced with a Windows Server Licence, and then each Device accessing the VMs on the server would need the appropriate Windows CAL. Each Application would need to have the correct amount of licences for the amount of devices accessing the application. In order to deliver the VDI desktops to the devices, you will need an RDS CAL
VDI Suites
As delivering a VDI environment requires high management, Microsoft have have released a suite of products designed to deliver the VDI environment in a cheaper, simpler way. This takes the place the the need for the RDS CAL (or Citrix XenDesktop, Quest vWorkspace, VMware View should you not wish to use the Microsoft technology). This is known as the VDI suites. You get 2 versions:
In the Standard suite, you get the restricted rights to RDS, this means you get the connectivity of RDS but not access to the RDS Host itself (so the RD Broker, which connects users from their device, to the Virtual Desktop, and the RD Web Portal, which users can use to connect to their desktop securely)
Should you wish connectivity to an RDS host, you would need the Premium suite as this would give you the full RDS CAL and cover the device for connection session based desktops as well as VDI Desktops.
VDI Licences are a device based subscription Licences. The right to use the software on the subscription expires when the SA coverage expires
While this solution is more flexible than the RDS solution, it can be up to 4 times the price of licensing the RDS scenario.
A big Massive THANK YOU to Matt McSpirit and Nick from Microsoft for a very detailed response to all my tangled questions to get some clarification on this issue
