Once I got past that initial thought I began to think about the details of the changes.  Sumit's post lays it out in a nutshell:

"Citrix XenDesktop™ 4, VDI Edition - Best-in-class VDI-only solution available at $95 per user or device, or $195 per CCU
Citrix XenDesktop™ 4, Enterprise Edition - Enterprise-class desktop virtualization solution available at $225 per user or device
Citrix XenDesktop™ 4, Platinum Edition - Best-value comprehensive desktop virtualization solution available at $350 per user or device"

So they added Per device licensing to Enterprise and Platinum as well as adding a VDI-only edition with all three license models to choose from.  I would love to see a comprehensive licensing matrix of all of these choices to better lay out what you do/do not get with each.  I am sure that will come with time.
In addition they added a Campus wide licensing model.  This should benefit educational institutions as long as they can afford it.  Those numbers are not released at the moment (probably never will be to non-education people).

Cost
Let's assume your company has 2000 people who need XenDesktop/XenApp on a frequent or sporadic basis.  Thus only about 1000 people will be in the system concurrently.
Let's also assume that you have 1500 desktops since 500 of your users share.  We do not know if you can 'mix-n-match' the licenses together but for the sake of putting the numbers down on paper we will assume you can.
2000 XD4 Enterprise Per User licenses (includes XenApp) = $450,000
1500 XD4 Enterprise Per Device licenses (includes XenApp) = $337,500

2000 XD4 Platinum Per User licenses (includes XenApp) = $700,000
1500 XD4 Platinum Device licenses (includes XenApp) = $525,000

1000 VDI Only CCU licenses (does not include XenApp) = 195,000
2000 VDI Only Per User licenses (does not include XenApp) = 190,000
1500 VDI Only Per User licenses (does not include XenApp) = 142,500
Note: I am unable to find retail licensing prices anywhere.  Maybe I am just blind.
1000 CCU XenApp Enterprise licenses = ????
1000 CCU XenApp Platinum licenses = $600,000

So in the end with the above scenario it would appear a per device license scheme is cheaper until your users want to work from home.  Unless each device license includes a 'home use' clause the Per Device license is only good for labs or training purposes.  If you need your XD users to also use XA it pays to not go the VDI-only route (obviously as the name implies)

One thing that does jump out is that the VDI-only option, no matter which model, does not include CAG licenses.  This means that you either use the CSG (Free) and  you lose a ton of features in the way of security, or you must buy a CCU CAG license.  I would love to add in the numbers for retail cost of just an Access Gateway license (No matter which version) but, again, I am unable to find all retail license info.  They could have at least bundled this with the VDI-Only model so you can actually take advantage of  a CCU model.

Another thing from Sumit's blog post was the following:
"Remember, the user-based licenses are available not for per named users but the users as they login to their virtual desktops. You do not have to manage the user lists yourself."
So does this mean you license simply on those who 'have access' to connect to a XD4 device?  Does this mean anyone in an AD group must have a license?  Still unanswered questions around this, such as how often can you reallocate a user license?

I do think this is a positive change and at least customers now have the option to choose how they want to license.  As long as you can pick/mix your licensing models I am OK with the changes! Don't miss read that though, I am just OK with them.  I would be perfectly happy if the CCU option was included in the Enterprise or Platinum XD4 bundle for the simple reason that the VDI-only solution is way too expensive in a world where your users will need XA.  Let's face it a VDI solution without the ability to stream/dynamically run apps is going to become pretty useless as time goes on.

One final note.  Sumit used 'flexible licensing' a lot in his post but never actually called it 'FlexLicensing'.  I guess they did not like my marketing term after all!

'FlexLicensing'

I joked that Citrix should add a new term to their fantastic marketing names, FlexLicensing, to join FlexCast (seriously, who comes up with these names).  In my discussions with someone who was interested in my opinion the 'FlexLicensing' idea turned from jest into a half way serious thought.

I admit that a  tiny part of the problem I have with moving away from the CCU model is likely because I am an Admin who associates Citrix products with a concurrent user licensing scheme.  I guess part of me may be afraid all of their products will turn to this method.  That being said the biggest part of why I don't like the change of XD going to Per Named User (PNU) is because it simply does not fit into every environment.  For that matter, NO licensing scheme does.  Per User, Per Device, Concurrent User, it doesn't really matter as each company and even multiple environments within that company have different user bases with completely different needs and use cases.

In my conversation, with the person I eluded to in the beginning, I began to think, "Why not have a licensing model that is as flexible as what you are trying to do with your technology?"  Currently a retail XenApp CCU Platinum License runs around $600 bucks.  I think we all know that no one really pays that but it gives Citrix, a public company, a starting point to negotiate what they think their product is worth.  XenDesktop 4 licenses are much cheaper than that for a per user mode.

I then proceeded to make the suggestion to offer multiple different licensing schemes to customers.  If a customer feels that their environment is better suited for a CCU model then so be it, you pay a bit more for the flexibility.  Whether this is in annual SA costs per CCU license or the up front cost you still pay a bit more.  You then have the customer who needs to buy a set of licenses for users in which everyone is in the system at the same time and a CCU model does not fit.  This customer pays for each license as they need it but spends a bit less money because of less flexibility in what they can do with their environment.  And hell, while we are at it throw in a Per Device license model too (though I don't see the benefit of a device license over a ccu license) so it can fit the customer who needs it.  The pricing/annual costs for each of these models would need to have careful thought put into it to ensure that you aren't simply penalized for going to a CCU model but I think it could be done.

I know there are going to be a lot of people out there who think I am nuts (or an idiot) for suggesting adding MORE complexity to software licensing but let's face the fact, you are not going to please everyone by one licensing scheme.  I think if done correctly it would add a lot of value to Citrix's products as they can say, "Customer we can support your environment with our technology and we have a licensing model that fits your use case perfectly.  Here is what it would cost you for CCU, PNU and/or Per Device.  You decide what is best for you".  In the end Citrix is always going to get its money.

VDI Maturity

Another topic that came up in the conversation is my feelings on VDI as a solution in general and why I think its infancy is causing such an uproar on the licensing change.  VDI is just not a technology that is ready for wide scale production use.  I know there are some that are doing this today but I just don't see where VDI, at this point, is going to replace the majority of the desktops in a company.  Unless of course most of your company is lab/training devices that don't need a lot of rich experiences from the desktop.  Until VDI can essentially replicate all of the functionality of an existing physical desktop I just don't see it being as useful as companies claim it is now.

In a way I am talking out of my back side as I have not actually deployed a VDI environment.  What I have tested though (XD4 not included) did not impress me enough to think this stuff is ready for 'primetime'.  And to add to that if these companies think that VDI will eventually replace all machines in a company or that I will eventually run my entire OS in a cloud they are absolutely nuts.

As I finish this post I don't think I conveyed my thoughts very well but I am tired...that's my excuse.

I am building these tools for the community and will be releasing them soon.  In the meantime I would truly love to hear any feedback. Would you would find something like this useful.

When released there will also be a Vista/Win7 gadget to accompany this.

LoadData loads the app specific data (according to the app type), not its associations, which are more expensive to read (accounts, servers, etc).
This is why I suggested to compare it to Get-XAApplication. - Felipe Leon

I had always been under the impression that LoadData() pulled backed all information about the application including Servers, Users/Groups.  So I did a few tests and realized that I was completely wrong.  When throwing a few for..next loops in to enumerate servers,users and groups the MFCOM time shot up by at least 10-15 seconds.

Felipe also suggest comparing LoadData() vs the Get-XAApplication cmdlet instead of Get-XAApplicationReport since the former does not make a call to obtain servers,users/groups.

Using this method the cmdlet obtained most properties on 100 applications in about 1-2 seconds..That's FAST.  On the flip side using MFCOM to enumerate the same application set (100) WITHOUT using LoadData() still takes roughly 5-6 seconds.  There are a number of properties that are readable without using LoaData() but I have yet compared those to Get-XAApplication properties.

I plan to do more in depth testing when I have some additional free time but I wanted to post an update to show that my initial results appear to be wrong. As I stated in my previous post the cmdlets easily win for simplicity and ease of use but in my opinion until Powershell V2 is released (not as a CTP) and brings WinRM with it I think MFCOM is still the winner for multi-farm management.  Maybe by the time the XA cmdlets go out of  Tech Preview phase, Powershell V2 will as well?!

At first thought this is a great idea and kind of the next step in the future of gaming. Or is it?  There are a lot of factors that go into making this thing work well and the obvious two are is bandwidth and latency.  Playing today's online multiplayer games you can stand to work with around 200ms of latency because there is usually netcode that helps to account for it.  With this system they are proposing I would assume any latency would be catastrophic (not in a world ending way of course) to the playability of the game itself.  Unless the system in the cloud is accounting for a delay of say 200ms then you are always going to be a step behind the real time action.

I am curious as to what protocol they will be using (guessing in house developed since they have been working on it for over 5 years) and how it will compare to some of the things from Citrix (HDX), Teradici (PCoverIP), etc.  I know they are obviously playing in different spaces but in the end it all comes down to SBC (in most cases).  Based on some things I've read the requirements are moderately steep to play smoothly.  What I'm wondering is if this new technology applied to the business/enterprise world would actually translate into better performance for multimedia?  Games are going to be, for the most part, more demanding in the screen refreshes and the dependancy on latency greater.  If they can get HD quality running over the internet smoothly I wonder what their technology would do to get basic windows apps and/or multimedia to the end user.

I'm not one to buy into most of the current 'cloud is the answer' hype that has been going around since last year but this implementation may be one to watch.

"What can't the cloud do?"  Right now it can't make me a sandwich...I'm hungry.

You can get the updated files here: Note: There is a file embedded within this post, please visit this post to download the file.

I am working to add features to the gadget and would love to hear any suggestions.  I am planning to recode the MFCOM pieces into C# and expose it via  a COM object.  This should give a bit more power for any multi farm processing that needs to be done.

If you have any thoughts/comments please post them here or shoot me an email at "nick  (at) nickholmquist.com"

The goal was to create a site that would contain code examples for each individual object/property that is accessible via MFCOM.  I have always liked the simplicity of DevGuru.com and how they give clear and precicise examples and thought that would translate to making MFCOM easy to use.  I had hoped to include the most popular languages in the examples and obviously accept user submissions for example code.  I also had ideas for a code repository for community donated code, a wiki for 'super scripts' (when I was more VBScript focused) and a few other little ideas.

Of course as I was working on this as Citrix released their community page and my site seemed unoriginal and pointless.  Therefore it has been sitting dormant.

I only bring this up since I happened to be looking at the list of my domains and realized how easy it is to forget things in the midst of how busy most of us in the IT field are.

I am almost finished with the script to pull back session information while cross-referencing this list but due to my wife and I expecting twins it's been pretty busy around here.

At any rate you can find the updated version in the downloads section.

I created a script to pull the information and match a build to a client.  The script went through a number of changes (this is a modified version of my original script) from the first where I stuck all of the builds/versions in a Select..Case statement but that go too unruly.  The next is what is currently sitting in a thread (the new forums have destroyed the old formatting though) where I stuck the builds/versions into arrays to try and make it a bit cleaner.

What is the point of all this you ask?  Well I have placed all of the client info into an XML file and am currently working on a much more up to date script to dynamically load this file and pull back the information.  Resource Manager does report the full version (for versions above 8.0 I think) but not everyone has Resource Manager or they may have older clients hanging out there that they can't identify.

The XML file can be found here: Note: There is a file embedded within this post, please visit this post to download the file.

I should have the updated script completed very soon but the XML file may be beneficial to someone now.

Please let me know if any of the info in the file is incorrect or if you know of a build I missed.

It's a quick and dirty video and next time I will spend more time getting a better quality audio, first time is always practice, right?

Uploaded at utipu.com: http://citrix.utipu.com/app/tip/id/3346