Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Vista

Working with Windows Installer : The MSI Package Lifecycle

- Windows 10 Product Activation Keys Free 2019 (All Versions)
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
12/2/2011 3:59:08 PM
In a way, this lifecycle is very similar to the software lifecycle, or the history of the software products you choose to use in your network. That's because they both begin with a request; someone somewhere decides they need to have or use a specific product, a product that will provide the particular features they need. In the packaging lifecycle (see Figure 1), this request can stem from a variety of sources, but most often it stems from the user community.

In many cases, these requests are informal — a manager decides a product is required to better the productivity of their team; some user tells a manager they can't do without a given product; IT decides it is time to upgrade or change one of the core products in the network. Ideally, you should be using a tracking system that automatically ferries this request through the proper channels, locating the budget required for the acquisition or the development project if no commercial product responds to your needs, providing approval for the purchase or project launch, and delivering the product to be packaged to your doorstep. At the same time, this tracking system can let users, or rather requesters, know of the status of their request and the expected delivery date for the product on their desktop.

Figure 1. Understanding the MSI package lifecycle

Next, you begin the actual packaging process by examining the product to be packaged. How does it behave when installed? Are there prerequisites for its operation? Will it run properly on your operating system of choice? Does it conform to given Windows standards? These are the types of questions you need to answer and document before you can move on to further stages. One of the most important questions at this stage will be, is the product designed to work with the Windows Installer service or not? The answer to this question will greatly influence how you proceed in the next stages of your packaging lifecycle.

A key step in the discovery process is research and review of existing documentation sources for the application installation. Help may be found in locations, such as a README.TXT file, included documentation, or the vendor's Web site (FAQs or knowledge bases). Unfortunately, this information can often be difficult to uncover. One place where such information can be found for most applications is the AppDeploy Package Knowledge Base. This knowledge base is a community-contributed resource of information on the automated installation of applications on a product-by-product basis with a separate living document available for each version of a product installation. Details include:

  • Command Lines: Command line syntax for installation and removal of the software, which may include available command line arguments and/or public properties.

  • Notes: Shared information on how to handle the automated installation of the software.

  • Virtualization: Shared information regarding how to work with the software in sequencing or creating a virtual deployment package for products like Altiris Software Virtualization Solution (SVS), Microsoft's SoftGrid Application Virtualization, VMware's Thinstall, and Citrix XenApp.

  • Terminal Services: Details on how to address problems working with this software in a Terminal Services session as with Citrix shared environments.

  • Related Links: Links to official and unofficial information regarding the deployment of the software.

  • Security Lockdown: Information regarding which files, directories, and/or registry entries must be opened to standard users for operation in a locked-down environment.

It should be noted that AppDeploy.com offers forums for questions and discussions on this subject, but its Package Knowledge Base is designed for the sharing of facts. The most commonly reported method of package development (repackaged, transformed, and scripted) as well as a simple difficulty rating is voted on by members, which can provide you with a quick starting point to judge how difficult packaging will be for the application with which you are working.

NOTE

The Package Knowledge Base may be found at www.appdeploy.com/packages.

The next step is what most people consider the packaging process itself. This is where you prepare the automation of the installation and configuration of the product you intend to deploy. If the product is compatible with Windows Installer, you can customize it by creating a transform manually or by capturing the installation and configuration settings in a file that may be applied to the original product installation to modify its behavior according to your needs and requirements. If the package is not compatible with Windows Installer, you'll want to convert its legacy installation into one that will work with this service. In this case, you can capture the installation and configuration settings into a special file that will serve as a new installation executable.

After you've created the initial package, you need to test it to ensure that it behaves exactly as you expect it to. There are a number of different tests you can perform at this stage for example: automated or silent installation test, pull installation (manually launched on the workstation or server from a network location), push installation (automatically deployed with your systems management software), uninstallation, and so on. But system tests are not the only tests you require. More often than not, software packagers find themselves preparing a product for deployment that they've never heard of nor have very little experience with. Therefore, it is difficult for you to understand if the configuration you devised for this product is properly designed or if the eventual user will approve of this configuration. To validate the configuration, you need to involve an experienced user in the testing process. His role will be to ensure that the product behaves as it should after it is deployed. This is normally referred to as acceptance or integration testing and is often formalized to identify the expert users who perform it as software owners, people who will be responsible for more than just testing, but also for recommendations on product evolution after it is in formal use in the network.

Another form of testing is conflict detection. It was only a few years ago that we began to realize the impact of "DLL Hell" or the impact of trying to make a multitude of products from different vendors, developed at different times behave properly on a single system. In fact, DLL Hell became so prevalent that Microsoft finally decided to implement a single installation standard for software products in Windows: the Windows Installer service.

Although this service has been rightly hailed as a savior by many systems administrators because of its many features for the support of the coexistence of misbehaved products on a single system, it is not the be all and end all of conflict resolution. Take, for example, the integration of two products on a system: product A and product B. Product B includes components that are not compatible with product A, yet both must be installed on the same system.

The solution is to convert both to an MSI installation to integrate them to the Windows Installer service if they don't already support it. Thanks to this service, incompatible programs can coexist and operate on the same system. Should product B's components damage product A's, Windows Installer's self-healing capabilities will automatically repair the damaged product the next time it is launched, so long as Windows Installer has access to the source installation files. However, you could find yourself in a DLL Hell Loop: When product B is launched, it breaks product A, but fixes itself; when product A is launched, it breaks product B, but fixes itself, and so on. This may be because each program uses a different version of the same DLL or requires the same registry keys with different settings. Nevertheless, you certainly don't want your users to see Windows Installer launch each time they start a program on their system.

That's why conflict detection and resolution are still required. Despite the fact that Windows Installer can handle conflicting situations on the fly, you want to control the behavior of packages in your network. This means ensuring that products are well behaved when delivered. Detection is handled by comparing the package you are working on with the others you have deployed (or a subset of those deployed) and conflict detection can even handle a snapshot of your baseline system image to ensure conflicts with Windows itself are accounted for.

After all testing and conflict detection is done, you need to perform a final quality assurance on the package. Ideally, the person performing this final QA activity will be different from the person who originally packaged the product. This will provide you with a better and more thorough verification. Don't forget to complete all documentation about this package at this stage. Too many organizations try to save time by leaving documentation until after the product is deployed only to find out some critical component was missed and they have no means to find out how to repair it.

So now, your package is ready for release. At this stage, users begin to hearten because your package tracking system has announced to them that they will soon see the package on their own desktop. All they have to wait for now is deployment. Your release process should fit smoothly with your deployment system, automatically integrating the package into the source package store that your software deployment team will use as the source for deployment.

Now that the package is out, you feel that your job is done. Unfortunately that is not so. The packaging lifecycle does not end with deployment. That's because today, it seems that released software must constantly be patched to maintain its operational consistency and protect those who have chosen to use it. Patches, hotfixes, and service packs are a fact and will have varying impacts on your packaging process depending on when in its own lifecycle you decide to deploy a product. If you deploy the product after it has been out for some time, you will need to integrate its patches and possibly service packs to the package before you deploy it. If you have decided to use a new product in its infancy, you will have to deploy patches for the product once it is in use in your network. In both cases, you must continue deploying hotfixes and other patch types throughout the lifetime of the package in your network.

To package or not to package?

Although Windows Installer offers strength and resiliency for product installations, unfortunately, there are some key products, which should not and cannot be packaged through the Windows Installer service. They include these:

  • Service packs, hotfixes, and some system extensions cannot be repackaged with WIS. Good examples of this are core Windows system component updates, such as Windows Media Player or even the Direct X system. Along with the service packs, these components make low-level changes to the Windows system and therefore cannot be supported by Windows Installer.

  • Windows File Protection (WFP) components excluded from WIS. As you know, components that are included in the SFP are automatically protected by the operating system; only the system can update files under this protection. Currently, only Microsoft has the ability to modify files at this level.

  • Special packages that are already included in deployment kits. For example, Internet Explorer comes with its own Administration Kit (IEAK) that lets you package and deploy IE within your network. This type of product is best left to its original state because packaging it in WIS might break something that is automatically taken care of in the IEAK.

  • Device drivers and network protocols. These special components must verify a system's configuration extensively before installation. It's not that WIS can't do that, it is mostly that the changes brought about by these installations are at such a low level that it is very difficult to package them into a WIS package. A good example is Adobe Acrobat. Because this product installed actual printer drivers, it took Adobe several years to modify its installation to the MSI format. Before this, many organizations invested heavily into the repackaging of Acrobat sometimes with little or no success. Now that it is an MSI, it is much simpler to work with.

  • Commercial MSI products. Vendor provided MSI packages should never be repackaged. Remember that to modify these packages, you need to use a transform (MST) and apply it at the time of installation.

If, however, your only mode of deployment is through Active Directory and Group Policy, you can still use Windows Installer to help deploy these types of components. Windows Installer may be used as a wrapper that may use custom actions to turn the installation into an MSI. Windows Installer doesn't actually perform the installation, but it does perform the delivery of the package and launches the setup.exe that is required to perform the installation.


In addition, you must be constantly deploying new applications and updates on target systems that already include installed programs. Therefore, you always need to consider the installed applications whenever you test either the new program or the new update.

Then, after the package has reached the end of its usefulness to users or once the package has become obsolete, you need to retire it from the network. Retirement may also mean replacement if the business function the package fulfills is still required. If you plan to replace the package with a newer version of the same product, then you face an upgrade, which is a native feature of Windows Installer.

NOTE

To be fair, it is important to mention that using existing command line arguments to install a product that is not in MSI format preserves the vendors' provided installation logic and is supported by the vendor. Repackaging has many benefits, but it also adds complexity. If a problem with a repackaged installation cannot be reproduced in an interactive installation, the vendor is very unlikely to provide support.

Other -----------------
- Managing Windows Vista : Backing Up Your Files & Restoring Backed-Up Files
- Understanding the Capabilities of Windows Installer (part 2) - Managing the Windows Installer service
- Understanding the Capabilities of Windows Installer (part 1) - Understanding the Windows Installer architecture
- Working with Windows Installer : Introducing Windows Installer
- Managing Windows Vista : Managing Settings for a Presentation
- Managing Windows Vista : Controlling the Power Options
- Add an Xbox 360 : Configure the Windows Vista–Based PC
- File Type Associations (part 4)
- File Type Associations (part 3) - Customize Context Menus for Files
- File Type Associations (part 2) - Change the Icon for All Files of a Type
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server