Both Infrastructure as a Service (IaaS) and Software as a Service (SaaS) are nothing new and have been around for a few years now. Just short of two months ago Citrix, along with Microsoft, announced the availability of XenDesktop 7 on Windows Azure. Finally, full Remote Desktop Services (RDS) availability in the Cloud, or so it seemed. Although I was instantly interested, my (spare) time was scares during that period so I had to postpone my ‘Cloud’ ambitions. About a week ago I came across a random article discussing RDS on Windows Azure, an interesting read. After that I decided to do some research and perhaps open up a temp Azure account so I could experience its look and feel for myself.
After reading various articles discussing the matter, I soon realized that implementing XenDesktop 7 on Windows Azure might just be a bit more complicated than most of us think. Especially when reading the Citrix XenDesktop 7 on Windows Azure | Design guide an architectural reference document well spread throughout the community, it’s easy to get the wrong idea (I used this document as a reference throughout this Blog post). Let me explain…
The XD7 Design guide
On page three, as part of the introduction, the design guide states, and I quote:
With the introduction of Azure support for Remote Desktop Services Subscriber Access Licenses (RDS SALs) a broad set of opportunities to leverage Azure for hosted Windows desktops and applications begin to unfold. As a platform Microsoft Azure provides a robust, state of the art infrastructure and global presence for enterprises and service providers.
Directly followed by:
Citrix customers wanting to leverage public cloud infrastructure as a service in order to expand their on premise datacenter capabilities, without investing in new capital resources, can now host virtual desktops based on XenDesktop 7 within Azure.
If we continue we come across an example use case to help us setting up the basics:
Let’s assume “World-wide Co, Inc.” (WWCo) plans to leverage Microsoft and Citrix products to deliver a hosted desktop solution for their accounting department. The solution will provide value to the department by enabling access to Windows desktops and applications from any device. The Citrix XenDesktop 7 solution hosted on Azure consisted of a small number of components: Citrix XenDesktop 7 Delivery controllers, Hosted Shared workers (Session Isolation), Server VDI Workers (VM/Server Isolation) and a few more. The remaining components were already in place in the World-wide Co. on premise corporate datacenter.
The rest of the document tells us how WWco completed their assessment by using the Citrix Project Accelerator, assisting them with their Windows Azure environment design. In the sections that follow (in the document) each part of the design is discussed separately. It has been split up into the following sections: User Group, Access layer, Desktop layer, Hardware layer and finally the Control layer. I’m not going to discuss them here since they’re irrelevant in making my point.
There’s just one more thing I’d like to highlight before moving on and that’s the ‘Desktop layer’ as stated above. If we look closely at the visual representation recommended by the Citrix Project Accelerator (unfortunately the image quality isn’t of the highest standards so it’s a bit hard to see, I copied it in anyway), it shows us two different catalogs, the first one is based on the Windows 7 client OS (Content creators, Pooled VDI) and the second one is based on the Hosted Shared Desktop principle, made up out of Windows Server 2008 R2 (Task workers).
What I make of this
Although the above is a relatively short summary, given the circumstances, it does give us a good idea on what’s needed, assessed and finally implemented, or a recommendation at least. It involves Hosted Shared Desktops, a small VDI implementation based on a Windows 7 image, external access and a bunch of other components and technology needed to create our first cloud based XD7 Site.
Some terms and statements from the design guide: Hosted Windows desktops and applications # for enterprises and service providers # host virtual desktops based on XenDesktop 7 within Azure # hosted desktop solution # Windows desktops and applications from any device # Hosted Shared workers (Session Isolation) # Server VDI Workers (VM/Server Isolation) # Windows 7 client OS.
Reading through the above and according to the design guide, or at least the way I interpreted it, it should be possible to create a XD7 Site containing Hosted Shared Desktops made up out of the Windows Server 2008 R2 and 2012 OSs as well as a VDI deployment based on a Windows 7 image (or Windows 8 for that matter) as the visual recommendation shows us. It also shouldn’t matter if you’re an enterprise company or a (Microsoft) service provider providing hosted services. So far you’re still with me right? In the next section I’ll explain why this design isn’t possible.
Facts
There’s a link on page 14 which leads us to the Windows Azure online Documentation section. It explains how to create VM’s within Azure based on a Server OS, there is a reason behind this: it isn’t allowed to run a client operating systems within Azure! But the design guide doesn’t tell us that, in fact, it talks about a environment partly based on Windows client operating systems (five VM’s based on Windows 7) It also states: The following Citrix components are currently supported within Azure: Citrix XenDesktop 7 Delivery controllers, Hosted Shared Workers and Server VDI Workers, which isn’t true.
These ‘Server VDI Workers’ are associated with the creation / provisioning of the five Windows 7 based VDI machines under the section ‘Desktop layer’ as discussed earlier. That just doesn’t make any sense. Even if I’ve missed something (and if I did let me know) it’s clear that this document is confusing to say the least. Let’s continue.
Licensing
It all comes down to licensing. This is what Microsoft has to say with regards to client operating systems on cloud hosting platforms: Multi-tenant hosting is restricted in the Product Use Rights of Windows Clients, such as Windows 7 or Windows 8. Windows Client Desktops are not available on either Windows Azure or on any other Service Provider such as Amazon or Rackspace. You can read more about the Microsoft Product Use Rights here. And there you have it.
Let’s dig a bit deeper
To start, let’s first have a look on what can be deployed, and as such is supported, on Azure. If you want to install or move one of your physical machines into Azure, or any other cloud service provider for that matter, you first need to make sure that the associated operating system (and applications if applicable) license includes something called: license mobility. Next to that you also need to have a valid Software Assurance for all the software you own. All this is well documented in the Microsoft Product Use Rights MPUR) document This document also states: the Windows® client operating system, and desktop application products are not included in License Mobility through Software Assurance. Again highlighting the fact that it isn’t allowed to run client OSs in the cloud. Below you’ll find some of the more popular operating systems and applications available for use on Azure:
- Microsoft Windows Server™ 2008 R2 / 2012 Standard
- Microsoft Windows Server™ 2008 R2 / 2012 Datacenter
- Microsoft Exchange™ Server 2013 Enterprise
- Microsoft Exchange™ Server 2013 Standard
- Microsoft Forefront™ Identity Manager 2010 R2
- Microsoft Forefront™ Unified Access Gateway 2010
- Microsoft Lync™ Server 2013
- Microsoft SharePoint Server 2013
- Microsoft SQL Server™ 2012 Business Intelligence
- Microsoft BizTalk™ Server 2013 Enterprise
- Microsoft BizTalk™ Server 2013 Standard
- Microsoft SQL Server™ 2012 Enterprise
- Microsoft System Center™ Essentials 2010
- Microsoft System Center™ Essentials 2010 with SQL Server 2008 Technology
Be aware that there are more, have a look at the MPUR document mentioned above for more detailed information. But wait… it doesn’t end here.
Server operating systems
So far we’ve learned, or already knew, that Microsoft’s licensing only allows Hosted Shared Desktops based on Windows Server 2008 R2 or Windows Server 2012, no VDI based solutions where client OSs come into play are allowed. So yes, XenDesktop 7 can be implemented within Azure but with limited functionality.
UPDATE 21-08-2013
Since I was focussing on the combination of Citrix XenDesktop 7 and, or on, Windows Azure, with the accompanying Design Guide in the back of my mind, I might have left out an important piece of information. Throughout my article I state, multiple times, that it isn’t possible to host client operating systems on a (multi tenant) cloud platform since Microsoft simply doesn’t allow it, see the Microsoft quote (it’s license related) on this mentioned earlier. Although this is true, I should have emphasized the multi tenant part! On a multi tenant platform (Azure, Amazone, Rackspace etc…) you’ll have to share all available infrastructural resources with other customers (tenants) on the same platform, this is because you have no control over the underlying hardware and / or hypervisor. One of the main reasons why client operating systems are not allowed.
But… if you are a Citrix Service Provider and you can offer a isolated virtual infrastructure including dedicated underlying hardware, per tenant (this is the important part), then you would be allowed to offer client operating systems from the cloud. Citrix calls this the Site isolation model, this, and the above, also applies to VDI-in-a-Box by the way. Again, None of the infrastructure components are shared and in most cases each Site will reside on a dedicated vLAN or physical network. I probably should have mentioned this earlier, I apologize, my bad.
To make use of the RDS functionality (limited to the Hosted Shared Desktop functionality) within Azure we would need the newly introduced RDS Subscriber Access Licenses (SALs) from Microsoft (assuming that license mobility and Software Assurance is covered) This is where it gets interesting, again. The RDS SALs are offered as part of Microsoft’s Services Provider Licensing Agreement (SPLA) licensing. This means, to obtain these licenses you’ll need to be a Microsoft Services Provider!
Uhm… but what about: ‘As a platform Microsoft Azure provides a robust, state of the art infrastructure and global presence for enterprises and service providers’ and… ‘Citrix customers wanting to leverage public cloud infrastructure as a service in order to expand their on premise datacenter capabilities, without investing in new capital resources, can now host virtual desktops based on XenDesktop 7 within Azure‘?
This basically means that if your company wants to make use of Azure’s RDS functionality it needs to be a Microsoft service provider or it needs to contact one so it can do the hosting for them. Something to be aware of since the design guide doesn’t mention the licenses involved, license mobility or any other restrictions you might need to consider for that matter. According to the design guide, enterprises as well as service providers can make use of Azure to expend their existing on-premises data centers. Unfortunately it isn’t that simple.
Here’s a quote from Microsoft: RDS Client Access Licenses (CALs) purchased from Microsoft Volume Licensing programs such as Enterprise Agreements, do not get license mobility to shared cloud platforms, hence they cannot be used on Azure. Microsoft’s explained. So ‘just’ CALs aren’t enough anymore.
There might be a way around this, by obtaining SPLA licensing, your company automatically becomes seen as a service provider, at least by Microsoft. This way you can buy and use RDS SAL’s the way you feel fit. But I’m not an expert on this field so don’t just take my word for it, have a look here Again something to look into before entering the cloud, not making it any easier.
Resume
- The MPUR document lists what is allowed and supported on Azure
- You need license mobility and Software Assurance
- Client operating systems are not supported on Azure
- Server operating systems are supported on Azure, limited to Server 2008 R2 and 2012
- When XD 7 is implemented on Azure only Hosted Shared Desktops are possible
- To make use of the RDS functionality within Azure you’ll need RDS SALs
- RDS CALs are not valid for use in Windows Azure.
- To obtain RDS SALs you need to be a Microsoft service provider
- By default, not every enterprise can make use of RDS on the Azure platform
Provisioning
Another drawback, Citrix Provisioning Services as well as MCS are both not supported within Azure. The provisioning of VM’s is done by hand. Larger scale environments can be provisioned using Azure PowerShell scripting. The appendix of the design guide contains multiple sample PowerShell scripts, you can find the cmdlets here. According to the design guide the primary information source on using these cmdlets come from this Blog.
Mohoro
There is talk of a ‘secret’ project Microsoft is working on called Mohoro which may offer true VDI scenarios enabling the use of client operating systems on cloud based, multi-tenant infrastructures. It’s speculated that we can expect to hear and see more around the second half of 2014. Here’s a nice article on Mohoro, it’s from redmondmag.com Once it’s out I’ll definitely do a review on it.
Conclusion
This might not be new information for some, but you must admit (or not :-) that the way Citrix introduced XD7’s availability on Azure, including the accompanying design document, isn’t their best work up to date. It’s confusing, at least that’s the way I see it. As far as the title goes, of course there’s nothing stopping from implementing XD7 on Azure if you want. But if you do, be aware that you will have to do with limited functionality. Personally I think it’s a waste of money. You buy XenDesktop 7, which we all know isn’t cheap, host it on Azure to find out that you can only use half of what you paid for. If it was me, I’d be patient and wait just a little while longer. Or instead, deploy XenApp for example, it offers some great use cases leveraging Azure. For now deploy your XD7 Sites on premises and make full use of all it has to offer. I’m sure Azure / Microsoft will support some, if not all, of the above in the near future. And if all else fails, we always have Mohoro to look forward to!
Bas van Kaam ©
Reference materials used: Windowsazure.com, Citrix.com, Support.Microsoft.com, Wikipedia.com, Redmondmag.com and Google.com
21 responses to “Why you shouldn’t deploy XD7 on Azure just yet.”
Nice article, have come up against the same questions and am still waiting for replies form Citrix and MS for them to provide clarity on this. And agree the diagrams seem to have had a bit of rushed copy and paste, and the design doc is not clear. I’ll post any replies I get.
Hi Tom, thank you and I’m glad you agree. I wonder if you will get an reply, but let’s give them a chance :-)
Hello Bas,
First of all thank you for the feedback on the document, we already have a call scheduled so we can go to more depth in real-time. I look forward to it.
A couple of key points to clarify:
1. All Citrix XenDesktop workloads that are hosted on Azure are based upon the Windows Server OS, not the Client OS, for the technical and licensing reasons you have stated. As for your interpretation, and your stated (OK “hinted”) opinion that Citrix may have been intentionally misleading with regards to that fact please consider that the Windows Server OS based virtual desktops used in the Azure solution are specifically documented in the guide as follows:
– listed on page 4 of the document and illustrated on page 5 as part of the executive overview of the sample solution.
– We again state the OS workloads on page 11 under the Project Accelerator section
– On Page 15 under the “Project accelerator architecture modifications within Azure” section we again show the graphic that demonstrates Windows Server OS based workloads as part of the actual Azure Design, no client OS workloads appear in the graphic anywhere.
– On page 16 we state “Microsoft Windows Server 2012 Datacenter Instances were used for all Windows Servers in this Guide.”
2. Use of the currently available Project Accelerator is helpful but can add confusion for Azure guidance since it does not yet provide guidance for XenDesktop 7 workloads, including Server VDI. This is really where most of the confusion has come from since, as you state, it shows Windows Client OSes as part of the solution. As one of many inputs to the Azure Design Guide The Project Accelerator is a reference point within this particular guide to establish the use case and the relative VM sizes that will be used in the sample solution rather than the actual OS. We established Project Accelerator was only one of the tools to be used for the overall solution in the beginning of that section. Further, we hoped to address potential confusion on page 11 by detailing specific bulleted line items for Hosted Shared and Server VDI as a direct in-line correction of the Windows 7 Client guidance in the Project Accelerator graphic, which is the native output of the Project Accelerator at this time. This can lead to confusion, but we decided to not doctor the image, let it remain intentionally blurry (maybe a bad idea), to demonstrate real outputs from Project Accelerator, and then explain the workload change/replacement in text. The Project Accelerator is an evolving tool that will include XenDesktop 7 outputs any day now. Again, we all agree that this can be confusing if the rest of the document and it’s reference to other inputs (such as the Microsoft usage rights documents) are not taken into account. This is why, at the beginning, middle, and end of the document, we state the XenDesktop Hosted Shared and Server VDI models are used for this sample solution.
I look forward to our phone call soon in order to get more of your feedback on how we can make the next rev of this guide better.
Kurt Moody
Citrix
It’s my understanding that when they say “Server VDI Workers” it means using a server OS (no RDS role) to deliver what would previously have been a XenDesktop (5.6 say) desktop. This is similar to some XenApp implementations I have heard of that have 1-user-per-server scenarios (usually to provide a VDI experience for an application that won’t run on a client OS). This approach avoids the client OS licensing restriction.
Hi David,
I’m sorry, I can’t agree with you. That’s not the way they describe it in their design guide, in fact they talk about the Windows 7 OS (a whole catalog full of them, well… 5 in total :-) in combination with these ‘Server VDI Workers’ so there use is obvious, it’s for VDI purposes, can’t be done. Though I must admit that in some sections of the document it could interpreted this way and it’s probably what they mean in some cases, but still… it’s all very confusing and I’m pretty sure that’s not what they were aiming for, at all. Also, a 1-user-per-server scenarios would be hard to sell without the use of RDS, but you are right it avoids the client OS licensing restriction. Companies have already been hosting Server desktops through the use of Citrix XenApp for years. We are still waiting for full cloud based VDI (read client operating systems) environments, I guess it’s up to Microsoft to sort out their licenses.
Regards,
Bas.
I tend to agree with Bas, the design guide suggest this is using XD7 to deliver what we previously referred to as XenApp on top of RDS. I believe the reference to the Windows 7 OS catalog is an error in the design guide, as that is definitely not allowed according to the licensing t and c’s from MS
Plus delivering a single Server OS to a user is not cost effective, and thus it would not be promoted for true users in a large organisation, (i.e non admins/developers etc), you wouldn’t be able to publish apps and thus it would reduce the need to have XenDesktop in the mix as you would just RDP to the server. Why would you pay for XD just to broker connections to a few servers that you would give your developers etc.
When Citrix refers to Server VDI we are referring to a model that CSPs have been using since March 2012 and that is now available in XenDesktop 7. Technically the Server VDI model use a Microsoft Windows Server OS that DOES NOT have the Remote Desktops Service Session Host role installed/enabled, but instead uses the Citrix XenDesktop VDA installed using the /ServerVDI command line switch. Configured in this manner many of the use cases for VDI can be addressed that are not addressed by the Session Host based model. Particularly this enables a greater level of application compatibility for those applications that check for RDS or Terminal Services and then refuse to install if the role is present. For some applications this is necessary based on the session context in which they are designed to run, for others it is just something done as part of the installer by practice. Server VDI also enables use cases where a particular set of users need administrative control of their own VM, as documented in the design guide sample.
Good dialog.
Kurt
Thank you again Kurt. And Kuddo’s for David on this one :-)
Tom,
It is possible to host XenApp Hosted Shared Desktops from the cloud, Azure included (although Azure is new to the party as of the first of July 2013 with the introduction of the new SAL licenses as mentioned in my article) The license limitations do not apply to the server operating systems, at least not in the same way. There are multiple companies, hundreds even, offering such a solution, for some years now. Needles to say that you could also use XD7 for this, the question is, why would you? It has so much more to offer! By the way, and that’s my bad, it is possible to host client operating systems from the cloud, just not from Azure. This is because it’s a multi tenant platform, meaning that you’ll have to share all underlying resources with other customers (tenants) since you have no control over the underlying hardware, hypervisor included. If you are a Citrix Service Provider and you can offer a dedicated virtual infrastructure including dedicated underlying hardware per tenant (this is the important part), then you would be allowed to host client OSs from the cloud. I know, it’s a bit weird. I probably should have mentioned this earlier, but since I was focussing on XD7 on Azure it just didn’t came up. But maybe you knew this already?
Yes I was, I was keeping this in the context of Azure and XD7 only and an enterprise not a service provider, as this is where I am coming from.
I thought something like that, thanks for your input Tom!
Hello Kurt,
Thank you for your extensive feedback, it definitely cleared up a point or two, although I still can’t say that I agree on the approach Citrix took regarding the Design guide. I mean, with your explanation alongside it, it does make (more) sense, but it still has a few blanks, the way I see it, which I won’t discuss here :-)
Stating that XenDesktop Hosted Shared and Server VDI models are used for this sample solution throughout the document, together with two or three graphics on which only Server VDI Workers are shown (perhaps it’s in the terminology used throughout different documents as well, it’s not always the same), in my opinion, isn’t clear enough on what can and cannot be done. Especially because, before, in between and after those sections other misconception are easily born.
I also think that by trying to clear up the confusion the way you did, on page 11, only made it more confusing, but that could be just me of course.
I deleted the ‘misleading’ part by the way, I didn’t mean it that way. I’m still a fan :-)
I think that with your remarks, and now (some of) mine and the article itself we have an excellent starting point going into next week. Have a good weekend!
Regards,
Bas.
We all have a way to go in the cloud arena, any progress is a good thing. :) Talk to you soon. Have a good weekend as well.
Kurt
Yes we are definitely not there yet, we seem to be somewhere between the “Peak of Inflated Expectations” and “The trough of Disillusionment” which means things can only get better – hopefully Mohoro might be just that!!. But thanks for the clarity.
Anyway back to the RDS specific part of this question: Luis Panzano puts it succinctly:
http://blogs.msdn.com/b/luispanzano/archive/2013/07/15/remote-desktop-services-are-now-allowed-on-windows-azure.aspx
I came across that one as well. I wonder about the last bullet though… I mean wit regards to the ‘Server VDI Workers’ not making use of the RDS / TS functionality :-) It probably doesn’t apply to Server OS based VDI solutions.
Yes it doesn’t apply to “Server VDI” but it means that you can use XenDesktop 7 to deliver RDS/XenApp if you want but that to do this you need to license XD (thats a given) and also that you need to buy RDS SALS through the SPLA agreement.
Yes, that’s what I figured as well, but again, if you read it word for word, it doesn’t say that it doesn’t apply to Server OSs :-) So then technically Server VDI’s, because RDP isn’t used like Kurt stated, wouldn’t be an option as well. But let’s not make it any more complicated then it already is… Nice discussion though!
[…] Why you shouldn't deploy XD7 on Azure just yet. | Bas van Kaam […]
Just thought you should also be aware, RDS SALs etc are quite cheap, however you will also need to SPLA your Office licenses since those you purchased for your traditional fleet can’t be run on multi-tenanted hardware either.
That’s the real cost and one that often gets ignored and pepole simply do on AWS etc.
Thank you Mark, good point!
[…] IT departments interested in using XexDesktop 7 (XD7) running on Windows Azure should read Why you shouldn’t deploy XD7 on Azure just yet by Bas van Kaam (@BasvanKaam), a Citrix Product Lead & Senior Engineer at Qwise.nl regarding […]