I’m at a client side right now working on a large SoftGrid implementation project. I’m going through the motions sequencing applications when I came across one application from Reuters named StockVal. While I initially figured that this would be a slam dunk sequencing process, I discovered that it was anything but that. You see it’s become apparent to me that application virtualization doesn’t actually save you from your own stupidity. What do I mean by this? I mean that one of the biggest challenges with traditional software packaging is that packagers do stupid things. What kind of stupid things? Well here’s some that I’ve personally solved over the last year:
1) Packager snapshots MDAC 2.5 RTM version registry key (the Data Access version key) and distributes said package to over 3,000 desktops. Those desktops that attempt to install anything that requires MDAC 2.7+ fail as they are stating that the machine needs MDAC 2.7. Well XP doesn’t come with MDAC 2.5, so you begin to realize that the packager just made a mistake by not properly auditing their package for a mistake like this.
2) Packager creates an application package for some line of business app that requires Oracle. When they created the package, they neglected to audit the contents of the package and found that it included the System Path environment variable. Upon deploying that to workstations and Citrix servers, every single Oracle app ceased to function since Ora bin directory was no longer in the path.
3) Packager creates an application package for a line of business app. Packager neglects to utilize merge module and instead captures oleaut32.dll into the package. When desktops with this application were upgraded to XP SP2, Internet Explorer randomly crashes while using other applications.
Now all three examples I listed above are situations where someone used snapshot-like technology for package authoring and is largely not a problem when following MSI best practices. However, the whole point of application virtualization is that you do not have to be as careful when creating your packages because this situation isn’t going to break other applications on the machine. While this is generally true, the question is can you be competely carefree about what you’re doing while creating a virtualized application. The answer, of course, is no.
Here’s the scenario. While sequencing this StockVal application I launched the application during the monitoring phase. I typically do not do this, though other SoftGrid experts do advocate executing the application during the monitoring phase. Why don’t I like to execute during the monitoring phase? Because I’ve seen way too many applications that create user preferences on first launch that I often to not want to get captured in the sequence. If you’re good about auditing your packages, you’ll usually find these things and correct them before they become an issue. However, back to this application. I DID execute it during the monitoring phase. This particular application runs mostly remote node off a UNC share and contains some DAT/IDX files on that share that it accesses when it starts up. During the monitoring phase all was well and the application ran as expected. I completed the sequence and copied it up to the SoftGrid VAS server and imported it for publishing. Now on to app owner testing…
The app fell flat on it’s face with some bizarre error message about the database files being corrupt or some such nonsense. I followed the traditional troubleshooting steps of creating a debug OSD and invoking it under the user credentials and verified that I could in fact get to the UNC path where the application was run from and that I could read the database files (the DAT/IDX) files off the UNC path. Hmmmmm….what’s wrong here? I fired up FileMon/RegMon to look for anything suspicious. Everything in the FileMon/RegMon looked the exact same as it would for a regular execution of the app in a non-virtual form. Finally I jumped back into the sequencer to take a peek at the project file. In looking at the Virtual File System tab, it became immediately clear what went wrong. If you remember what I said earlier, I ran the application once during the monitoring phase to make sure it was working. The SoftGrid sequencer captured the access to the database files on the App Server’s UNC and decided to virtualize that file I/O. When I then in turn tried to run this in a virtual form I was getting a “virtual” copy of the real database file instead of the real database file on the app server. Now, there are people out there that think that the SoftGrid sequencer shouldn’t be capturing these types of items as the possibilities for damage are high. Since the sequencer does capture file I/O from network shares, my only advice is don’t assume that virtualization safeguards you against your own stupidity. You still need to check your work… 🙂