Application virtualization on the desktop is hot. Not only will it deliver a future proof set of application “scripts” but it also promisis a very fast way of deploying up-to-date, non-conflicting software. But of course! You’ve had a lot of work, I mean months and months of testing, in creating MSI packages. Throwing that away is not a very strong business case to move to app virtualization. For that issue I ran into a nice tool that is capable of automating the migration effort. Check out www.softgridguru.com too.
If you have chosen Softgrid as your app virtualization platform you need to create streams or sequences. To migrate an MSI into a stream automatically check out this tool (registration is required). Although it’s “just” a program around the command line sequencer, it makes life a lot easier.
If you have choosen Altiris SVS as your app virtualization platform you can use the Wise Package studio for easy migration. So lets hope you did not just buy Installshield…. Also the Altiris suite includes tooling to assist your migration and packaging efforts.
Finally, if you have a Citix farm you should towards Presentation Server 4.5. This version includes application streaming technology. But I haven’t heard from migration tooling here (yet). Suggestions are welcome.
For now this is all just theory. In the coming months I expect lessons learned to become more widely available as migration efforts get finalized. Pls post your comments if you’ve allready done it!
- Paul
Entries (RSS)
Paul,
Not only application virtualization is hot, all virtualization is hot and although we all know hardware virtualization (Virtual Server R2 and Virtual PC 2007) suddenly Presentation Virtualization appeared at MMS 2007, people use to call it Terminal Services.
Even inside Vista there is virtualization, file system and registry virtualization. If you do not have access to certain parts of the file system or registry, Vista automatically redirect write actions to your personal profile.
Have a look in \AppData\Local\VirtualStore
It is a bit sad that this feature was not introduced in Windows 2000 or Windows XP because many reauthored or repackaged applications to Windows Installer MSI packages failed acceptance and functional testing because lack of permissions in the registry or on the file system.
Although it still seems an attractive rapid migration approach for Vista, be aware that Vista 64bit does not virtualize these actions. So if these actions are not properly documented you have to run Vista 32 bit operating system on 64 bit hardware.
Regarding lessons learned, I believe it is better to start with RTFM, also known as read documentation and not only the dos but also the don’ts
Just as an example from the Windows Installer documentation:
• Using the application’s native Windows Installer package. A native Windows Installer package contains a single product (the dos not important)
• Reauthoring applications. If you have software applications that are not designed for Windows Installer, you can reauthor the setup to a Windows Installer package.
• Repackaging applications. If you have an application that is not designed for Windows Installer, as a last resort, you can repackage it into the .msi format so that you can use the features of Windows Installer to distribute the application. A repackaged application combines the entire feature set of the application into a single feature. Windows Installer can install the repackaged application; however, you lose the flexibility to efficiently customize the application.
Important: Prior to reauthoring or repackaging any applications in your organization, it is important to compare the benefits of each strategy with the costs involved. Reauthoring and repackaging are both advanced operations. There are tools for each operation that can help developers create the final Windows Installer package, but the procedures are still resource-intensive and can be costly.
To be clear about what reauthoring stands for?
When you reauthor an application, you create an application that adheres to the Windows Installer format. You essentially redevelop the setup portion of the software to take full advantage of the advanced capabilities of Windows Installer.
If you plan to reauthor an application that does not contain a Windows Installer package, you need the following:
• All executable files, DLL files, and other resources. For all but the simplest applications, you need the source code to understand the logic and behavior
• An understanding of the application and the registry entries, shortcuts, and other information needed for the application to run correctly.
• An authoring tool that supports creating Windows Installer packages.
I could copy something about repackaging below but probably better to read it yourself, Published: November 1, 2001 http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/winmsi.mspx
Just one more big misunderstanding, transactional rollback
From the document: Windows Installer keeps track of all the changes it makes to a computer. Therefore, if you attempt to add, modify, or remove an application and the action fails, Windows Installer restores the computer to its previous state. The restoration procedure is known as a rollback.
Quite often the rollback is interpreted as installing the Windows Installer package, using it for a month and then removing the Windows Installer package from a system. But the rollback counts only for failed attempts to add, modify or remove an application, and not for custom actions inside the MSI…