shawnbass.com - Virtualization blog

Virtual Desktops - Myths and realities...

shawn@shawnbass.com — Sun, 28 Feb 2010 16:32:17 GMT

If you're available on Tuesday March 2, 2010 please join me and five vendors of virtual desktop technology (Citrix, Microsoft, Quest, Symantec, and VMware) for a webinar that's sure to please VDI fans and opponents. The webinar will be held at 1:00 pm EST and will go until 2:30 pm EST. We're planning on having about 60 minutes of panel discussion where I will ask all five vendors questions that I've created based upon real world challenges people are having with VDI. Then we'll be opening the discussion up to audience questions for the remaining 30 minutes. If there's something you want to know about VDI, this is the time to get your questions answered. For more information and to register for this great session please visit Laura Whalen's blog entry that has all the details here.

With well over 1,000 attendees already registered, this is an event you don't want to miss. Also, you have a chance of winning a free pass to Citrix Synergy!

More...

App-V 4.6 is here (64-bit goodness can commence)

shawn@shawnbass.com — Tue, 23 Feb 2010 15:28:34 GMT

Microsoft posted on their MDOP blog that App-V 4.6 RTM'd on Friday. Oh and there was something or other posted about Med-V. So back to App-V ;) 4.6 RTM includes support for 64-bit Windows platforms which means you can get a functional deployment of Windows 7 64-bit and more importantly you can begin your projects to rollout 2008 R2 with a supported 64-bit App-V client. Now all we need is a supported release of Citrix XenApp for 2008 R2 and we're golden. Read more about the App-V 4.6 RTM here.

More...

MS Releases Hotfix Rollup Pack 6 for App-V 4.5 CU1 (fixes the file system race condition I blogged about previously)

shawn@shawnbass.com — Wed, 16 Dec 2009 05:20:09 GMT

More...

App-V 4.5 File System race condition found and fixed

shawn@shawnbass.com — Mon, 05 Oct 2009 12:57:56 GMT

If you follow me via Twitter, you're probably aware that I've been working on a bug in the Microsoft App-V 4.5 Client for the last few weeks. This particular bug has been occurring randomly at a client site of mine. User's that have a particular App-V application will sporadically receive the following error message when trying to start the application:

The text of the error message is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem. Error code: 4505CD-1F702639-000036B1"

At the same time as this launch failure, the following event log entry is logged in the System Event Log

The details of this event log entry are this:

Source: SideBySide

Category: None

Type: Error

EventID: 59

User: N/A

Description: Resolve Partial Assembly failed for Microsoft.VC80.CRT.mui. Reference error message: The system cannot find the path specified"

Background on the error:

This issue would randomly occur with Office 2007 SP1 App-V package, but the issue was very rare. However, we had one sequenced application (BMC Control-M) that it would occur around 1 in 5 launches. At first we suspected some kind of software conflict. When you're in an environment with 2000+ applications across 20k desktops, it's not unheard of that some broken package might be overwriting some key DLLs, etc. This suspicion was raised because the launch failures were not occurring for all users of the application. More on why later. Anyway, we began with the typical things like re-installing the .NET Framework, re-installing the VC++ 2005 SP1 runtime and while we had limited success after doing so then problem was still there. After messing around re-instaling a few applications, we decided to take our desktop build down to the absolute minimums and try to repro the issue. Even with the build at the very basic OS components, we could still reproduce it. I decided to try an OS build straight from media to avoid any kind of customer OS modifications. To my delight, the problem did not recur on my fresh OS build from media. We later discovered that it had more to do with this system being a VM than it did with the system being a fresh OS install.

On to the problem discovery:

One of the guys that I work with at this cilent site (we'll call him Bob) had an ancient laptop that was already lifecycled off the books, but he still had possession of it. When Bob ran the Control-M package on his ancient laptop, he couldn't reproduce the issue once. When Bob informed me of this, we both started thinking "Is it because this machine is slower and therefore the client is taking longer seeking the hard drive and preventing the problem from occurring? Or is it because this system has a single CPU whereas everything else is running at least two CPUs due to Hyperthreading or Dual Core?"

Let's test the multiple CPU theory:

The first test for the multiple CPU condition was an easy one. Simply add a second CPU to my VM that was consistently working and see what happens. I did just that and voila the problem began occuring on my VM (not as frequently as on the physical desktop hardware though so system speed appears to have something to do with it too).

The second test was to take one of our dual processor systems (in this case a hyperthreading machine not a true dual core) and alter the boot.ini to include the /onecpu switch which forces Windows to ignore the 2nd logical processor. To our excitement, this system began working 100% of the time despite having failed regularly before.

Now we've proven it, now what?

Before we give up and call Microsoft, I wanted to ensure this wasn't fixed in CU1 or any post-CU1 hotfix rollups otherwise that would be a wasted premier support incident. I downloaded and installed CU1 and the July hotfix rollup. No difference in error frequency.

On to Microsoft support:

Now that we've confirmed this isn't something that's already fixed, we opened an incident with MS Premier support. We provided all the details on how to reproduce the issue and even sent our problem package off for testing at Microsoft. They were able to repro the issue in their labs. After about a week of back and forth and the issue going up through escalation, Microsoft confirmed the existence of a race condition bug in the App-V File System in three different places and that they would be working on a hotfix.

And the fix....

Microsoft created a fix for the three race condition bugs and they will be including it into the September 2009 Hotfix Rollup Pack which currently has KB974278 This KB is not currently public, but I would expect it to go public in a few weeks. If you desperately need this fix before then, you should contact Microsoft Support to obtain it as I will not hand out any non-public hotfixes.

Finally someone who "gets" cloud computing

shawn@shawnbass.com — Fri, 01 May 2009 16:19:58 GMT

Hoff tipped me off to this great audio recording of Larry Ellison speaking on "What the hell is the cloud?". It's an enlightening bit of audio that reflects some of my thoughts on the hype surrounding cloud computing. Definitely an entertaining listen.

Microsoft announces cumulative update release of App-V Client that works on Windows 7 and that TAP for 64-bit App-V will be 1st Qtr 2009

shawn@shawnbass.com — Sat, 28 Feb 2009 01:36:19 GMT

There are two things that have slowed investigation of Windows 7 and 64-bit Terminal Services for many Enteprrises. Those two things are App-V not supporting Windows 7 (yes, I know Windows 7 isn't released yet) and the lack of support for 64-bit in App-V. Microsoft has released immediately (for MDOP customers) an App-V 4.5 CU1 release that works on Windows 7. In addition, they've announced that they'll be opening up the TAP for App-V 4.6 which will support 64-bit Windows (TS is the big use case here) in Q1 2009. I happen to have a customer that is running App-V 4.5 right now that is definitely looking forward to both of these things, so it's very exciting news.

Read more about these two exciting items at the MDOP blog item here.

VMWare Server 2.0 fails installation with Windows Installer Error 1718 - MSI was rejected by digital signature policy

shawn@shawnbass.com — Wed, 26 Nov 2008 17:06:12 GMT

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.

Why doesn't Microsoft have memory overcommit / transparent page sharing?

shawn@shawnbass.com — Thu, 25 Sep 2008 22:21:04 GMT

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.

Upgrading to MS App-V 4.5 (fka Softgrid) FAQ

shawn@shawnbass.com — Tue, 23 Sep 2008 19:06:27 GMT

Courtesy of the MS App-V blog, I came across a blog post that directed me to an FAQ that Microsoft has posted on their website with frequently asked questions regarding the process for upgrading App-V Clients and Servers to the 4.5 code that was just released. The FAQ has some great items that describes the upgrade order as well as what compatibility there are for 4.1/4.2 packages moving to 4.5 clients/servers as well as what happens to the SGCache and User Preferences (usrvol*.pkg). It's a great read. The only thing I find a little strange is references to the 4.5 Terminal Server client, which seems to not be in the 4.5 code on MVLS. Strange...

More App-V 4.5 (fka Softgrid) news (4.5 binaries available and SPLA license forthcoming)

shawn@shawnbass.com — Mon, 15 Sep 2008 15:57:36 GMT

This is just a quick update on my previous blog entry announcing that Microsoft had reached the Release to Manufacturing (RTM) milestone on App-V 4.5. Two new things that I've learned are:

1) Microsoft has posted the App-V 4.5 bits on the Volume Licensing website per this Softgridguru forum posting. Unfortunately, I still don't see anything up on MSDN :(

2) Microsoft is working on a SPLA (Service Provider Licensing Agreement) for App-V 4.5 per this MDOP blog news. This is great news for those organizations that offer up hosted Citrix / VDI environments.