I'll be giving a session a Pubforum 2009 in Dublin, Ireland on June 5-7 (yes Friday through Sunday, this is a geek conference after all).  I'll be presenting on VDI and where the industry in general is at now that XenDesktop 3.0 has been released.  Stop by and say hello!

Just stumbled upon this today.  Initially I though this was an extension of the April Fools day joke about Chrome automatically rendering web pages in 3D, but it seems legit.  Checkout the full blog entry here.

There's a pretty sick video demo shown in the blog entry.  Check it out.

A client of mine recently rolled out their upgrade from McAfee 8.0 Enterprise to 8.7 Enterprise.  On the Citrix server environment we had two major application failures that were the result of the McAfee upgrade uninstalling the MS XML 4.0 Parser on the servers.  There were two applications on the production Citrix environment that required the MS XML 4.0 Parser and they both stopped working following the upgrade.  Unfortunately, the issue was not caught in Lab/UAT testing and was only found after McAfee went out to production.  To make matters worse, something went wrong with the deployment mechanism and the McAfee upgrade went to all servers in one blast whereas the server team usually pushes in 2-3 separate sets of server groups.  All of that combined = FAIL

So McAfee is responsible for the outage, right?  WRONG!

What the Mcafee installer was doing was proper behavior.  It had incremented the shared component registry entry for MSXML4.dll when it was installed on the servers.  The shared DLL component dependency counters are stored in HKLM\Software\Microsoft\Windows\Current Version\SharedDLLS.  Here's an example listing 5 installed apps that depend on MSXML4.dll on my workstation PC (see the DWORD 5 next to MSXML4.DLL). 

Every time a program installs that depends on MSXML4.dll (or any other shared windows DLL), it's supposed to read the existing counter value, increment it, and then write it back out.  Upon uninstalling that program, the installer engine is supposed to read the counter, decrement it, and write it back out.  However, if the value of the counter is 1 and a program is uninstalling that has a shared dependency on that DLL, it's supposed to uninstall that component and remove the shared component counter from the registry.  See, everyone is supposed to tidy up after themselves.

Windows Shared DLLs + Dumb Developers = FAIL

So in my client's situation, they had two applications that apparently required MSXML 4.0 Parser, but those apps never bothered to increment the shared DLL counter in the registry when they were installed.  This is usually due to a dumb developer that doesn't realize that the component has to be registered with the installer engine in order to properly install and register the shared DLL component.  So when McAfee Enterprise 8.0i went to uninstall, the installer engine noticed that the value of the shared component registry entry was 1and subsequently ran a removal process for the MSXML 4.0 Parser.  This equals failure for the two apps that need MSXML.

So how do you know you've been affected?

1) If you're lucky, the application will complain about not being able to find the MSXML4.dll, or not being able to instantiate a object for the MSXML4 DOM.  If you're not that lucky, then...

2) FileMon / ProcessMonitor from SysInternals will pinpoint the issue.  Simply run it before launching your application and when you reach the place in code where the app is crashing or throwing an unexpected error, you'll see messages in the log where it was attempting to locate MSXML4.DLL in the search path and failing.

How do you fix it?

Download MSXML 4.0 SP2 Parser from Microsoft and install it.  You can do the install manually or push it with whatever ESD system you're using.  The MSI installs quite nicely with Citrix Installation Manager if you only have that.

Stay tuned for another entry from me regarding this issue with respect to application virtualization since it has some unique properties that make this particularly challenging...

I was recently installing VMWare Server 2.0 (the freely available VMware virtualization platform) and I found that after the installation initialized it threw this error message:

In doing a quick bit of research, I discovered that this is some type of an issue with Windows Installer engine with large MSIs.  Essentially Windows Installer is unable to allocate the necessary virtual memory to verify the integrity of the MSI.  The strange part about this issue for me is that this server has 6 GB of RAM and there's absolutely nothing else running on it....Strange eh?

Anyway, MS has a hotfix for this issue.  Download and install KB925336 and you'll be good to go.

Helge Klein from sepago put up a blog entry today discussing the memory overcommit feature of VMware's flagship ESX product and how it has a very favorable impact in the VDI space since you're running lots of copies of MS Windows with the same (or similar) applications on them, etc. (this is likely the result of large amounts of transparent page sharing)  Helge also mentioned that Microsoft and Citrix both do not have this feature at this time and are downplaying the significance of it.  Helge believes it's this way because Microsoft simply doesn't have this feature now.  While I tend to agree that there probably is some level of wordplay to de-emphasize the competitors product that has a feature that your product doesn't have, but I also wonder if there isn't another reason why Microsoft wasn't so quick to implement this feature.  Keep in mind that both Vista and Server 2008 have implemented Address Space Layout Randomization (or ASLR) as a tactic to reduce the likeihood that OS exploits can compromise a host system.  I have not seen anyone comment on whether or not transparent page sharing works with ASLR or not.  I would assume that even if it did work, it probably wouldn't be as effective as it would otherwise normally be.  Assuming that's the case, perhaps Microsoft has pushed off this feature since it's not something that would greatly benefit Vista/2008.  Everyone knows that Microsoft always has higher level of focus on their newer operating systems than they do on the legacy stuff.  Perhaps because of this (and my theory on ASLR's impact to transparent page sharing) they haven't pushed this higher in their priority list for Hyper-V development.  Can anyone out there comment on the effectiveness of transparent page sharing with ASLR? Perhaps since's MS's ASLR implementation is rather limited you wouldn't get quite as penalized as a full blown ASLR implementation.  However, without having tested any of this I can only speculate.