Thin Clients

Thinking of a Remote Computing Solution based on Citrix/VDI/BladePC’s? Make sure your Network is up to the task, or you might have curious issues?

Dave Caddick — Thu, 04 Dec 2008 04:11:06 GMT

Recently I found myself at a school down near Melbourne carrying out what should have been a relatively simple PoC (Proof of Concept) of 20 x BC2500 BladePC’s in an Enclosure with some T5730 Thin Clients, and initially all went pretty well and then I found that I had some issues with the SAM Registration service….. from the BladePC’s not communicating very well (or at all) with the SAM Server

BTW – SAM = HP’s Broker, Session Allocation Manager

So then I was thinking through some ideas about what the next steps might be to help isolate it?

Initially I was getting a note in the Application Event Log for all the BladePC’s that they are unable to contact the SAM Server, and yet:

they can ping it successfully
I can connect to the blades using RGS fine
The Windows Firewall is disabled for now
There are exceptions in the firewall any way for the SAM Service

So I then used WireShark to take a trace and isolated one conversation with a blade and the SAM Server and got it to translate the TCP conversation and the resultant HTTP reply from the SAM Server indicated an internal error – so I simply rebooted all the Blades and the SAM server and I finally got the devices registered – hurrah!! I thought I was out of the woods.

Then as the day wore on it appeared that after a period of time the Blades would become “Offline” with a red circle and the diagonal slash indicating they were offline and they would no longer respond – a reboot will get them going again.

Now if I was just troubleshooting this it would not have been too bad – but I was also seeing some other very curious issues like:

When I connected from the T5730 to the BladePC via RGS direct (no SAM) it is verrrrry slow (5 – 10min login)
When I connected from the T5730 via the SAM Client it is verrry slow just to start the Login process (even longer?)
Once connected the experience is not too bad (not real snappy, but just about useable)
Connecting a USB device to the T5730 to test Video causes the RGS session to drop – with no warning – before the Media Player comes up

Now was I right to suspect the network at this point? I’m not a Network/Switch expert, but I know enough to be dangerous? ;-) but it was starting to look like there was more than just a hint of coincidence with what was going on?

Curiously enough I’ve also found that while my laptop is connected to their network and using the proxy to gain access to the ‘net to get email that the connection to exchange keeps bouncing quite a bit and when I send an email it can sometimes hold in my Outbox for hours before finally getting under way….

Outcome – all now sorted – it would appear that even though the SAM/Altiris Server AND the BladePC Enclosure was plugged in to the Core Switches there was a ProCurve 2650 that was throwing out FCS Errors and causing a ruckus – this also happened to be the unit that I was trying to go through with the T5730 Thin Clients……

This morning a Network Guru from their integrator turned up and updated all the firmware on the Cores and 2650 alike, found the issues were related to the 2650 only, this was then swapped out for a temp unit – then it seemed like nothing was working at all with no connectivity to the Enclosure, then it was discovered that Spanning Tree was the cause of this, so that was hit on the head – and now everything has settled down nicely.

Good news is that apparently HP’s ProCurve Switches come with a lifetime warranty – I learn something new every day? – so as it turns out it’s not too bad?

So a day or two late, but finally back on track.

Incidentally, when I was trying to update the Firmware in the Enclosure for the Switch and the IA (Integrated Administrator) via a simple TELNET I was getting timeouts and errors, after this wayward Switch was replaced it all worked a treat.

Lesson:
As with Citrix and VDI, as well as BladePC/BladeWS, it’s always worth remembering that this is typically the first time that a network will have been asked to provide “real time” network performance. Up to this point even things like email are effectively only “store and forward” process’s so do not be surprised when a relatively simple PoC (Proof of Concept) shines a Spotlight on any Network issues?

I hope this helps others?

Reminder regarding time sync in a domain

Dave Caddick — Sun, 12 Oct 2008 03:03:40 GMT

Hi All,

Just a note regarding an issue I had to help resolve a little while back?

Issue:
We had a pre-sealed image of an XPe intended for a customer, who wanted to join it to the domain, come through and during testing at our location and on site for the customer it was found that it simply refused to get it's time in sync

Research:
What we able to narrow down to is that the Registry Entry for:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters was listed as Type = NoSync and what was really needed to be changed to NT5DS.

What we were also able to identify is that while we are quite certain that any *Local* user on an XPe device will always get “access denied” when trying to run NET TIME as they are not a valid domain user – what can be done though is run the w32tm /resync command (if the module/executable is available? AND ONLY if the time is within the default 5 minute max…) *OR* alternatively simply restart the Windows Time Service. Both of these commands can be run without issue using Local credentials.

Looking deeper in to why the W32Time Type was incorrect we managed to come up with this little gem from Microsoft:

Registry entries for the W32Time service and within this we found the following:

Type : REG_SZ
Used to control how a computer synchronizes.
Nt5DS = synchronize to domain hierarchy [default]
NTP = synchronize to manually configured source
NoSync = do not synchronize time
The Nt5DS setting may not use a manual configured source.
Note When you join a Microsoft Windows Server 2003-based computer to a domain, the computer may not synchronize its time setting with the time setting of the domain controller if the Automatically synchronize with an Internet time server check box in the Date and Time Properties dialog box is not selected. The default option (NTP) for Windows Server 2003 workgroup computers is disabled if the Automatically synchronize with an Internet time server check box is not selected. When you join the computer to a domain that has this setting, the default synchronization type (Nt5DS) for computers that are joined to a domain is not set and the time service does not synchronize from the domain hierarchy.

I have highlighted the interesting section in red. After further testing we found that the default image had this check box unchecked, however, once this was checked before joining the domain then the NT5DS setting would be in place immediately after the reboot following the Joining to the Domain and as a consequence the device would time sync correctly as soon as it was booted.

From what we can see this is an issue that is not restricted to purely XPe but XP as well and hopefully thi info might be useful to others?

Renaming a Computer or Thin Client for large scale deployments? Whether you are using Altiris, PXE, RIS, SMS, etc. this is a tool worth checking out

Dave Caddick — Wed, 25 Jun 2008 02:16:59 GMT

While the deployment we were assisting with today was maybe not that large even by local standards the issue was something that comes up on a some what regular basis.

A customer wants to have a number of Thin Clients imaged to their specifications and then drop-shipped to various locations ready to go. Part of this involves creating and applying Asset Tags to the devices – a small thing to be sure – but for the poor folks in charge of keeping track of the devices this was vital.

The issue was that part of the FBReseal (First Boot Reseal) process renames the devices based on a process that combines the MAC address and the serial number and then comes up with a random name, and of course that was not making things that easy for the “Asset Taggers” ;-)

So we were testing the imaging process at the Integrators site using Altiris as the deployment mechanism and trying to figure out how we might be able to achieve something that would leave everybody happy and we discovered “COMPNAME.EXE”

My hats off to Oli at Willowhayes.co.uk as this is a great tool that does exactly what we were after, but it clearly has some great functions that make it really well suited for RIS with references to UUID and the ability to create and reference fake UUID’s when needed.

It is so easy because you can easily see the info it can pull out via the summary switch (examples below) and then reference them via the template function – so in our specific case we simply called a job that ran “COMPNAME.EXE /c HP-?s” and this then appended the serial number after the HP- prefix.

Now it was possible for the customer to receive a spreadsheet of all the devices, including a listing of the specific Computer Names so that Asset Tags can be printed and applied ahead of delivery.

Summary switch provides the following info:
Mainboard manufacturer : Hewlett-Packard
          model        : 30C8
          serial       :
Chassis   manufacturer : Hewlett-Packard
          model        : Notebook
          serial       : 2CEXXXXH29
System    manufacturer : Hewlett-Packard
          model        : HP Compaq 2710p (#ABG)
          serial       : 2CE8060H29
Ethernet address       : 00:1F:3B:09:XX:XX
IP address             : 192.168.0.4
NetBIOS name           : xxxxxxxxxxx
DNS Host name          : xxxxxxxxxxx
System UUID            : 21FFBB999ADCXXXX111XXX8410012529

Switch Examples are:
?u = System UUID                        ?U = Fake UUID (24 zeros plus MAC).
?G = If System UUID is FFFF... or 0000... or null it uses ?U, otherwise ?u.
?i, ?j, ?k, ?l            = 1st, 2nd, 3rd, 4th octets of IP (decimal).
?I, ?J, ?K, ?L            = 1st, 2nd, 3rd, 4th octets of IP (hex).
?d = Hostname found by reverse DNS lookup of IP address.
?m = First MAC address.                 ?e = Existing NetBIOS computer name.
?D = day    ?M = month    ?Y = year
?1, ?2, ?3, ..., ?0       = 1, 2, 3, ..., 10 random alphanumeric characters.

COMPNAME /c acme-?s Changes computer name to "acme-ABCDEF" where ABCDEF is the system serial number.

XPe’s replacement, Windows Embedded ‘Quebec’ due in 2010?

Dave Caddick — Mon, 23 Jun 2008 03:41:46 GMT

Well as far as I am aware, XPe as it stands to day will be available through till sometime in 2010, but it seems more news is getting out about is’s possible Vista based replacement? My personal view is that MS should take a deep hard look at the *LACK* of take up and interest in Vista before heading down this path anytime soon – but that doesn’t mean they won’t try regardless.

Now of particular note from the details below from Mary Jo Foley is the indication of the size of the OS? XPe may have a *core* size of 40Mb but it is typically 350Mb or so when deployed - does that mean that with a core of 300Mb for Quebec that the typical load will be around 2.5Gb and larger? If this is the case then it’s just as well that Flash manufacturers are able to keep making larger and larger memory modules?

But, really…. activation?? for an embedded OS – give me a break!!! That is unless MS are going to repeal the restriction that they have always had with the embedded OS in that they have always insisted that you are NOT able to install any of the Office products locally?

Who know’s? is it that far fetched? Thin Clients are getting more powerful CPU’s, RAM is pretty cheap, Flash sizes are going up and the price is coming down and yet here is an OS that is cut down to what we’d probably want Windows 7 to be? It also has (should have?) either EWF (Enhanced Write Filter) or the File Based Write Filter to maintain it’s integrity?

Interesting times ahead? :-)

Windows Embedded ‘Quebec’ due in 2010

Posted by Mary Jo Foley @ 6:23 am

Although it hasn’t said much about its plans for a Vista-based successor to its Windows XP-based embedded operating system, Microsoft already is working on one.

Microsoft released during the first week of June a new test build of its latest Windows XP-based embedded operating system, known as “Windows Embedded Standard 2009,” the final version of which is slated to ship by the end of 2008.

However, Microsoft also is readying the 2010 successor to this product — another Windows Embedded release codenamed “Quebec.” Unlike the 2009 release of Windows Embedded, the Quebec product will make use of a number of features that are part of Windows Vista.

Microsoft is on tap to share some information about the Vista-based embedded release at its TechEd Developers Conference this week in Orlando. A first widescale Community Technology Preview (CTP) test build of Quebec is due out next year.

Microsoft’s Windows Embedded family of products, which Microsoft sells to device makers, is designed to power thin client terminals, point-of-service terminals, gaming devices, medical-imaging systems, DVRs and industrial-automation systems, among other products. Windows Embedded is not at the core of cell phones or ultra-low-cost PCs (ULPCs), however. Windows Mobile phones currently are built on top of a Windows CE-based core and ULPCs run full-fledged Windows. (Microsoft has OK’d ULPC makers shipping Windows XP on their systems through 2010.)

The forthcoming Quebec embedded release will include BitLocker drive encryption, Windows Firewall, Windows Defender, Address-Space Load Randomization — and on the memory-management front, support for SuperFetch, ReadyBoost and Dynamic System Address Space. On certain devices, the Quebec release will also provide as optional components Aero user-interface, Windows Media Player 11 and various Internet Explorer 7 features. Unlike Microsoft’s XP-based embedded releases, which are 32-bit only, Quebec will support both 32-bit x86 and 64-bit x64 processors.

Not surprisingly, support for all these features comes at a cost — size. According to a slide deck available to TechEd attendees, while Windows XP Embedded core’s minimum image size is around 40MB, according to a slide deck to be presented at TechEd on June 6, Quebec’s core is expected be around 300MB — not counting all the optional add-ons like Media Player, IE 7, etc.

The other cost is Quebec will require product activation; XP Embedded does not. The Quebec release will require basic retail activation or OEM activation. There will be a default evaluation product key that will allow the Quebec image to run for 30 days without activation.

Windows Embedded ‘Quebec’ due in 2010 | All about Microsoft | ZDNet.com

Thinstall to be reborn as ThinApp under VMware's new management?

Dave Caddick — Mon, 12 May 2008 22:45:25 GMT

So along with Alessandro I'm curious as to why the name ThinApp has been chosen as it does have more than a passing resemblance to Citrix's new XenApp?

I wonder if this is any indication of the coming marketing campaigns in the push for customers attention in the Desktop Virtualization market? ;-)

VMware ThinApp is the final name for Thinstall technology

In January 2008 VMware, a hardware virtualization company, acquired an application virtualization startup called Thinstall.
The plan is to use the Thinstall technology to stream virtualized applications on the virtual desktops that VMware spawns through its connection broker: the Virtual Desktop Manager (VDM).

So fare VMware has been pretty fast in rebranding the Thinstall Application Virtualization Suite: the beta program for the new version is open since end of February and the testers can already download the beta 2.
The final version of the product, temporarily called Project North Star, is expected for the H2 2008.

The only information missing so far was the final name that VMware wants to use.
Now Micheal Keen, Director and Senior Solutions Architect in the Enterprise Architecture group at Alliance Technologies, reveals that the final name is ThinApp.

Duncan Epping further validates the news reporting that a former Thinstall employee confirmed.

The choice is interesting considering that Citrix just renamed its Presentation Server product in XenApp.

virtualization.info: VMware ThinApp is the final name for Thinstall technology

Future vision of VDI? What if the Hypervisor was cheaper and flexible enough to run on BladePC's/BladeWS's - could vMotion/XenMotion then switch on demand?

Dave Caddick — Mon, 28 Apr 2008 08:58:13 GMT

I am sure this is not really what VMware had in mind when they were touting VMware OnDemand? I'm guessing they had more of an idea that it would combine some of the benefits of ACE with ESX? ;-)

I have just got back from some training in Houston and while listening to a question from a colleague from the UK where he asked if "VDI was going to be able to use the full suite of Hypervisor functionality like vMotion..." and that got me thinking...

Some of the Conventional Wisdom around the place holds that VDI by itself will likely not be able to cover all of any one customers needs and most will more than likely need to look at quite possibly a number of different approaches to cover ALL employees and ALL Applications.

So with this in mind I'd be interested in your thoughts on the following idea?

Just a few thoughts around VDI??

Let's say that we stock a couple of decent servers with loads of resources and allows us to run quite a few VDI instances? OK? So one of the possible issues with the classic VDI so far is that if a user places a bit too much pressure on the resources then it has the potential to impact on all other users, being as it is a shared resource? (This is still one of the classic gotcha's in Terminal Server and Citrix PS - the session is sticky and it stays with the same server unless a logout/login occurs)

So one idea I'm kicking around is the possibility that if a user started something like a 120Mb Excel spreadsheet that might consume quite a bit of CPU then would it be possible to use the vMotion to transfer him to a BladePC, if they started 3 or 4 of them (or they needed more resources?) then transfer them to a BladeWS.....?

Seamlessly!! with the user completely unaware that this has happened!!

Now the fundamentals of vMotion (or XenMotion for that matter?) requires shared boot storage - BUT I don't think it needs to be NFS or iSCSI, etc. - the Citrix Provisioning Server or OS Streaming method like Neoware IM would probably work just as well in this scenario? As this then leaves the Virtual HardDisk/Storage in a common area accessible by the Vitrual Desktops regardless of whether they are running on VDI's, the BladePC's or the BladeWS's.

The other point is the similarity of CPU would possibly cause an issue, and this probably extends beyond just Intel/AMD? This appears to be a fundamental of vMotion/XenMotion? So this might not fly today, but it is possible that with improvements in the Hypervisors this issue might be overcome at some stage soon?

Anyway, what do you think of the *idea/concept*? As a user requires more CPU and resources they might be able to be transferred from shared resources (VDI on ESX) to individual resources (BladePC) and then high powered resources (BladeWS) - once the high intensity workload has finished then the user would be transferred seamlessly back through the stack to a VDI instance on the ESX server.

Please bear in mind that this is only a concept at the moment and there are clearly problems and issues to be overcome - but the main reason for this post is to ask if you think it has legs? What do you think?

Clearly the ESX/Hypervisor would need to be able to run on hardware outside of it’s current Hardware Compatibility List (HCL) but with Xen this might not be such an issue?

Is wonder if this is where XenDesktop is headed? ;-)

picotux - smallest Linux computer in the World

Dave Caddick — Sat, 15 Mar 2008 03:38:50 GMT

Now I have always been a fan of making the PC as small as possible, but this is verging on the ridiculous surely? I'm wondering how useful this device might actually be?

picotux - the smallest Linux Computer in the World

The picotux 100 is the world's smallest Linux computer, only slightly larger (35mm×19mm×19mm) than an RJ45 connector. More information can be found here.

picotux - smallest Linux computer in the World

Licensing Windows Client Operating System in Multiuser Scenarios - read Microsoft's definition here?

Dave Caddick — Tue, 12 Feb 2008 15:55:22 GMT

Now somewhile back I produced the following post regarding any other alternatives to RDP and ICA and at the time I might have been somewhat flippant about NComputing's model based on Windows XP SP2, and since then there have been a number of other companies like Miniframe jump on the same bandwagon where they are effectively using a desktop based OS to provide concurrent multi-user sessions and I always thought this did somewhat fly in the face of the EULA?

At the time I was sort of suspecting that MS might have actually been turning something of a blind eye to this in some parts of the world, but now it seems that MS has finally decided to get off the fence (or at least the Lawyers have now made a decision? ;-) and produced this document to clarify things.

So I'd like to clarify here that this is not that I don't think NComputing can add value, but in doing any due diligence anyone who seriously wants to consider either NComputing, Miniframe or any other method of using XP SP2 in a multi-user model should seriously check this document from MS before going too far down this path?

If I was contemplating, or indeed already using this scenario I would be asking the Vendor to review this document from MS and provide some sort of legal indemnification?

Licensing Windows Client Operating System in Multiuser Scenarios

This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed within are my own and should not be attributed to any other Individual or Company or the one I work for.

SPICE might be an alternative to ICA and RDP?

Now this is very interesting news because with all the interest around VDI there is still no real alternative to ICA other than RDP (or VNC...?) and in this I'm not even going to consider Ncomputing's WoIP, as from a techies point of view this would appear to simply be a rehash of RDP, although I'm prepared to be convinced otherwise?

But it might be exciting to see that there is a real possible alternative to the ICA/RDP stranglehold and this might have the makings of some interesting changes to how things might be approached in the VDI space?

******UPDATE******
As a consequence of this post I have been contacted by Ncomputing and it would appear that their WoIP is actually what they term a combination of UTMA and UXP and does indeed make the connection/transition/session at a lower level in the stack. However, you will not find much detail on the inner workings of this as it's proprietary, and I'm still trying to understand how this all plays out with regards to the Microsoft Licensing side of things as detailed here in a post on their Forum
http://ncomputing.com/ncomputing/wbb2/thread.php?threadid=963&hilightuser=1087

If/when I find out more I'll update either here, or as a separate post on my new blog at www.techagility.info
******UPDATE******

SPICE might be an alternative to ICA and RDP?

Live Demos of VDM2 from VMware and XenDesktop from Citrix

Dave Caddick — Sat, 09 Feb 2008 20:41:02 GMT

In some cases the regular methods of "Going to Market" with a new product is fraught with pitfalls as it is conceived by Marketing and/or Product managers who then seem to loose sight of what the Customer is actually after - I've always thought it better to get the product and solution in front of the customer as quickly as possible and let them make up their mind and give feedback?

In all fairness, with some of the larger Vendor's there is so much red tape and bureaucracy this makes it nigh on impossible to actually create demo sites like this that Gareth has created - so kudos to him for getting this created.

What Gareth has alluded to but possibly failed to qualify was, if you don't have a Citrix ICA client installed then you might also want to think about downloading that elsewhere than from his hosted servers as that will also be quite quicker at over 17Mb for the web client?

Xendesktop or VDM2? Compare them for yourself

When the beta code for VDM2 was first released I wanted to push them both out over the Internet, however there was a red tape / NDA issue.

Now that VDM2 is released I can put both of them out together. All of the components are running as virtual machines on one ESX host. The XP clients are identical in terms of their configuration and resources.

The two URLs are https://oasxendesktop.oas.co.za for the Citrix XenDesktop and https://VDM2.oas.co.za for the VMware VDM2.

username is demo
password is also demo.

The latency is likely to be pretty awful for those abroad. It is slow but usable in South Africa but I am interested in seeing how the performance is from Europe, I think our under-sea cable terminates in Europe so it will probably be even worse in North America.

We have unfortunately also been having to contend with an inordinate number of power cuts, so please bear with our Third World infrastructure. Crises notwithstanding, I will try to give you some more details on the configuration some comparisons on the two different mechanisms tomorrow.

Stop Press:
Whoa, the reason that the Xendesktop demo worked was that most people already had a Citrix client. The VMware VDI agent is 6MB in size and getting that over our slow link will be hopeless.
Try to download and install it from http://garethcharlotte.googlepages.com/VMware-vdmclient-2.0.0-403.exe , this is hosted by google and should come down fairly quickly worldwide.

VMware and CITRIX for South Africa

Why VDI might have an up-hill battle to win the hearts and minds of CIO's?

Dave Caddick — Mon, 28 Jan 2008 18:57:30 GMT

A very comprehensive rundown (from Massimo) of the potential issues being faced by anyone trying to implement a VDI solution?

I certainly agree with Massimo on a number of points, just as it's quite easy to move from physical to virtual on the Server side this almost sets the customers expectations that it's just as easy to do the same for the Desktop, and this is where things are sometimes getting undone?

Why Desktop Virtualization is not as easy as Server Virtualization

In the last few months I have been struggling to understand what is so different, in terms of mass adoption, between virtualizing server workloads and virtualizing desktop workloads (also known as "VDI" or "Virtual Desktop Infrastructure"). I have been exposed to this phenomenon of x86 virtualization since around 2000 where the idea was as simple as taking a high end server and miniaturizing it into many small virtual servers. Similarly I have been exposed for the last 3 years to the other big use-case for x86 virtualization which is "Desktop Virtualization" and I can tell you that the time it took for the first traditional use-case to take off (through seeding the market with the idea - piloting and proofs of concept - mass adoption) was way shorter than the time it is taking for VDI to take off (going through the same phases above). This doesn't mean that VDI is not taking off but there are no doubts that after 3 years from introduction I have seen so many more production implementation of VMware ESX than I have seen of VDI.

Why is that? Isn't VDI just virtualizing XP rather than Windows Server? Well not quite I would say. Let's dig into some of the details (not in strict order of importance).

- Desktop Virtualization alternatives. While I am focusing this discussion on the VDI concept there are some analysts that, for good reasons, are implying that desktop virtualization is not just VDI (i.e. virtualizing Windows XP and putting it on a server in the back). There are other alternative architectures to "virtualize a desktop" such as Windows Terminal Services, Application Virtualization, OS streaming and many others. To complicate things further these technologies are sometimes complementary to each other and sometimes alternative to each other. So customers are challenged since the beginning of the potential desktop virtualization project with a great deal of input and information that they find hard to understand and digest. In the server space this has never been a great deal since "virtualizing a server" has always had a single meaning that was that of "hardware virtualization" (i.e. getting as many virtual hardware partitions as possible out of a single physical server). So in the server virtualization realm the confusion was far less than the one that is being created nowadays given all the potential architectures at the very different layers of the desktop software stack (and VDI is just one of these different architectures).

- VDI Products complexity. On top of the above complexity there is another one. In fact 8 years ago it was much easier to understand the products you needed to adopt a server virtualization model. If you used to buy 20 physical servers and install 20 Windows instances, now with server virtualization you would buy 2 physical servers, 2 VMware ESX 1.x licenses and install 20 Windows instances. As easy as it is. You couldn't do much differently and it worked great (so why bother?). VMware has since introduced new versions of the software and enriched their value proposition "linearly" with Virtual Center 1.x and eventually with VI3. On the other hand to adopt a desktop virtualization model you have to buy a virtualization platform, a connection broker, and you need to decide which access device you want to use etc etc. For every single layer of the architecture you have multiple implementations which translate into multiple different products that are supposed to do similar things (if you want to know more about the architecture of VDI have a look at this presentation). As a result in the last few years this desktop virtualization market has been very "foaming" with ISV's entering into this space and ISV's buying out other ISV's etc etc. Clearly it is much more difficult right now to understand what do to and which ISV to buy from a VDI solution than it was 8 years ago for a customer interested in entering the server virtualization space.

- Overall cost of the solution. In the desktop space there is a predominant metric that is "cost per seat" that you can hardly find in the server space. Sure customers understand that a server virtualization solution could cost slightly more than a traditional layout of a string of small physical servers but apparently they are more ready to discuss the benefits (in terms of TCO) of a virtualized solution and factor them in into the overall costs. This is especially true when these customers are considering high-availability solutions and disaster recovery that are either very expensive in the standard physical space or not achievable at all. On the other hand the "cost of the desktop" is a very strong metric that most customers are using when discussing the overall costs of a desktop virtualization solution. A couple of days ago I met with a customer that, as part of a very large bid, was buying (branded and good quality) desktops for 233€ (monitor and Windows license included). Needless to say that in a VDI solution which comprises the back end-servers, the virtualization software, the proper Microsoft licenses, the connection broker software, the thin clients and the miscellaneous utilities you might want to use to complement the scenario, the cost per user might be VERY WELL above that 233€. While for a server virtualization scenario the overall acquisition price of the solution can get close to what a customer would pay for a standard physical deployment (or at least within a reasonable range that is off-set by the tremendous advantages), to create a business case for VDI you have to include a detailed TCO analysis to get on pair with a standard desktop deployment. And we all know how difficult it is to "sell" on TCO (especially to desktops buyers).

- Microsoft licensing. Of particular importance is the issue of MS licensing. Historically, customers have always bought Windows PC's and historically these Windows PC's have come with a so called (very cheap) OEM Windows license (that is, when you buy a PC you get a Windows license tied to it). This OEM license CANNOT be used in a VDI scenario so you need to buy brand new licenses. And this is where the "fun" starts. This is a very bad story for customers both from a complexity perspective as well as from a cost perspective. At the time of this writing Windows licensing for virtual desktops is still pretty confusing: "should I buy a retail version of the OS?", "Should I buy the VECD (Vista Enterprise Centrlized Desktop) license under Software Assurance?", "What if I am not a customer with MS Software Assurance?" etc etc. All in all whatever you decide fits best your scenario as a customer, it's going to be more expensive than the cheap OEM Windows license you used to buy tied to your desktops purchase. We all hope MS will make this transition easier for our customers but so far ... not so good.

- End-user Experience. There is a big difference between virtualizing a server and virtualizing a desktop from an end-user perspective. You, as a CIO / Sys Admin, can virtualize a server or even the whole server farm and no one at your company would even notice it. It's just your own decision to do that or not to. In a desktop virtualization scenario, as soon as you start deploying the first thin client you are opening it up to the whole company. Immediately you have exposed your decision to dozens / hundreds / thousands of other individuals that, for good reasons or political reasons, will start to challenge you. Good reasons might be technical limitations that you have to compromise with as of today, limitations for which a thin client can sometimes hardly cope, in terms of local device attachment support / multimedia video performance / flexibility / off-line capabilities etc etc, with a standard desktop deployment. I can assure you that no single "average end-user" would ever realize that their mail system in the back is now running on a vm whereas yesterday it was physical; however even the more "IT-candid end-user" would understand that he / she is using Outlook from a "little box where I cannot even attach my iPOD anymore" as opposed to the PC he / she was used to! And there is when political problems start. On this I have always said that a very happy Sys Admin has a frustrated end-user base and, viceversa, a very frustrated Sys Admin has a happy end-user base. It's a matter of compromising as usual: VDI technology advancements will allow the CIO / Sys Admin to provide the standard business requirements whereas end-users will need to understand that they can't just see their business access device as if it was their home PC.

I think these are some of the major road-blocks for VDI to become really true and start the massive deployment we have seen in the traditional server virtualization use-case. All in all I think that the root of the problems when trying to re-architect the desktop deployments is that, whatever you do, it's basically a "hack". If you think about that for a minute, the WHOLE industry only has one default that is "the end-user will be using a Windows desktop". Whatever you do with any technology that the industry is creating (be it an application, a physical USB device or whatever) to make it work in a different scenario... it is a "hack". We have implemented hacks with Terminal Servers and we are doing the same with VDI and any other technology such as Application Virtualization. As long as there is an industry that creates "stuff" for the PC and there is just a handful of people that try to make the "stuff" work differently in a different scenario ... it will always be an up-hill. I look forward to the day when the industy as a whole will embrace these non-PC deployments in a more structured way than the current "I'll do this assuming the PC and then someone will be able to hack it to make it work for alternative scenarios". I look forward to the day when the average "CIO Joe" that needs to create an IT infrastructure will not only think "I have 1000 users, I have to buy 1000 Windows PC's" but rather ... "I have 1000 users, I need to buy a VDI solution for them".

At that point all these things such as products and architecture complexity, end-user experience, licensing issues etc etc will fall apart... because it has become the "obvious / default" way to give end-users access to IT.

Massimo.

IT 2.0 Main Blog : Why Desktop Virtualization is not as easy as Server Virtualization