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 : Introducing Windows Installer

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
11/8/2011 9:22:08 AM
Most everyone who is involved in software management, be it software distribution or packaging, has heard of the Microsoft Windows Installer service (WIS). This powerful service has been created by Microsoft to help manage the software lifecycle on Windows systems. With the release of Windows Vista, Windows Installer is in its fourth edition. Version 4.0 was been specifically designed to run on Windows Vista and Windows Server 2008. Windows Installer version 3.1 runs on earlier operating systems back to Windows 2000. Therefore, version 3.1 will work with Windows 2000 Service Pack 3 and above, Windows XP Service Pack 2 and Windows Server 2003. If you're running an earlier version of Windows, you can obtain older versions of Windows Installer from Microsoft's Web site. The latest version 4.5 supports Windows Server 2003 and later, so for most environments, this one version will provide a consistent standard that may be applied across all client and server systems.

NOTE

For a full list of Windows Installer versions and its corresponding operating system, go to http://msdn2.microsoft.com/en-us/library/Aa371185.

The Windows Installer redistributable download can be found at http://msdn2.microsoft.com/en-us/library/aa372856(VS.85).aspx.

If you're aware of Windows Installer, you're most likely aware of some of its features. First and foremost, Windows Installer provides a consistent, single point of interaction for commercial software or in-house application installations. This is a major change from the pre–Windows Installer days when system administrators and packagers had to deal with a multitude of installation tools, each with its own particular commands and its own particular idiosyncrasies. Using Windows Installer for installations is one way to reduce administrative overhead for software management because you only have to learn one single installation method. Of course, not all software or all in-house applications are integrated to the Windows Installer service and this despite the fact that it has been around for a few years since it was introduced. This is one reason why you may want to use a packaging tool to prepare and customize your own Windows Installer installations.

Second, Windows Installer provides a set of features that tie in very closely with the software lifecycle. As you know, software has its own lifecycle, and managing this lifecycle after a piece of software has entered into your network is important. This lifecycle and the relationship the Windows Installer service has with it are illustrated in Figure 1.

The third and most important aspect of the Windows Installer service is that it provides a series of features that were heretofore unavailable through conventional installation systems. Much of this functionality is due to the fact that Windows Installer actually stores an installation database on the target computer system each time it installs a piece of software. This database contains information about the installation, the components that were installed by the installation, and the way those components were configured during installation. This gives WIS the ability to provide a comprehensive set of features in support of this installation.

For example, because WIS includes the computer's preinstallation state in its database, it can support complete installation rollbacks in the case of a problem during installation, returning the target system to the same state it was in before the installation began. In addition, because it stores the software configuration in its database, it can automatically repair an installation should a problem occur with the program. This repair mode can be run through a maintenance mode, but it is also automatically run each time a user launches a program through its shortcuts or through opening an associated file type (such as a document generated by the program). For managed environments, it can automatically elevate a user's privileges during installation to ensure that the installation will occur properly in locked-down environments. That's because Windows Installer is a service that runs in the background and, therefore, always is available. Finally, it can completely remove an application from a system when it is time to retire or upgrade a software program from a network.

These are only some of the features that make Windows Installer a powerful installation system. These features are part of the reason why many strive to integrate all of the installations to this service. Most, but not all, new software products on the market are now provided as MSI packages for these reasons.

Figure 1. Understanding the interaction of MSI In the software lifecycle

1. Integrating installations with the Windows Installer service

Taking advantage of WIS does not mean that you need to go out and buy a new version of all of the software products in your network. An average-sized network, say between 500 and 5,000 users, will most likely have between 100 to 300 different software programs and applications in use. Some organizations of this size may have over 1,000 such programs in use. This is before the organization performs a software rationalization — a formal exercise that reviews and justifies the existence of each software product or application within the network. If you haven't done so yet, it is highly recommended that you perform such a rationalization in your network. To do this, you must get rid of any programs that duplicate features or multiple versions of the same program. This greatly reduces your software administration burden and potentially reduces licensing costs. Rationalization is an important aspect of any Vista migration project because it helps significantly reduce the application preparation workload.

It is unrealistic to expect any organization to be able to simply go out and purchase new versions of each software product in their network to have versions that are integrated with the Windows Installer service. That's because of several reasons:

  • The cost would be too prohibitive.

  • New versions of your in-house applications aren't available on the market; you have to build them and doing so may also be cost-prohibitive.

  • Some manufacturers simply don't offer new versions of their products.

  • Though they are becoming fewer and fewer, some manufacturers still haven't integrated their software products to Windows Installer.

For these reasons, you have to consider your options for moving to Windows Installer-integrated installations. The first thing you should do is categorize your software into the following three program types:

  • Native Windows Installer software: This software includes any product that bears the Designed for Windows Vista, Server 2008, Server 2003, Windows XP, or Windows 2000 logos or any software that does not include this logo but has been set up to be installed through Windows Installer. Obviously, software that supports the logo may be more reliable than software that does not include it. That's because the logo specifications include much more than Windows Installer integration.

  • MSI-Integrated Corporate applications: These new versions of your corporate applications should be integrated to the Windows Installer service in all cases.

  • Repackaged Legacy software: This software encompasses all products that are not upgraded and use an installation system other than Windows Installer. They should be repackaged to be integrated to this service. This also includes corporate applications that do not require recoding or cannot be recoded as well as legacy commercial software.

2. Examining the Windows Installer service

Like all system services, Windows Installer is a service listed in the Services section of the Computer Management console. This service is set to a manual startup and is activated only when you launch an installation that is integrated to it. This automatically starts the service and runs Windows Installer to perform the installation. You should not change the settings of this service because they are controlled by the operating system.

In addition, you need to know which version of the Windows Installer service you are running. Obviously, the newest version includes the most comprehensive feature set. To find out which version you are running, search for MSI.DLL in the Windows folder. After you locate it, you can verify its properties to view which version you are running. Figure 2 shows the version number for this file.

Another and even easier way to find out which version you have installed is to simply type one of the following commands at the command prompt:

msiexec /?
msiexec /help

This will display a dialog box that lists all of the switches supported by the command as well as display the installed version of the service (see Figure 3).

Figure 2. Identifying the Windows Installer service version in Windows XP and Vista

Figure 3. Getting help from msiexec

NOTE

A complete list of the switches supported by the msiexec command on Windows can be found at http://support.microsoft.com/kb/314881.

3. Windows security and software installations

Like Windows NT and Windows 2000, Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008 use the NTFS file system. The advantage of this system over its predecessors is that every object stored in the system includes attributes. These attributes can contain security features — security features that are different for users, power users, and administrators. The greatest limitations are applied to users. Because a user's main responsibility is to operate the system, they only need to read and execute permissions for system components. By nature, NTFS protects system and application files by restricting access to these files.

However, in Windows NT, users were given too much leeway. This is because software integration was not controlled effectively. Many software products would install into (and require constant read and write usage of) the system directories. Giving users these rights would open the system to potential damage and therefore higher support costs.

Realizing this, Microsoft released the Zero Administration Kit for Windows NT. This kit provided corporations with the tools to increase system "lock down" to limit user access further. But this system was complex to use, and organizations often had to invest heavily into its management.

With Windows 2000, Microsoft changed the nature of the NTFS system lock down. It added further restrictions to users and changed the way applications work with the operating system. As a comparison, users in Windows NT have the same rights that power users do in Windows 2000. Today, actual users have significant restrictions within the operating system directories and within application directories.

In Windows XP/2003, Microsoft added more complete support for protected software operation within the operating system itself, such as support for side-by-side dynamic link library (DLLs) in memory. Now with Windows Vista, Microsoft has updated the system to provide further protection for registry components along with the file components that belong to applications running on the system.

Software that follows the most recent guidelines for the Designed for Windows Logo program (see above) should not install any component in the system directories. That's because all software components now reside in the application's own directory in Program Files. In addition, every component that is modifiable by a user (including configuration settings and user preferences) is stored within the directories containing the user profile. Here users can read and write to their hearts' content. This is a good strategy because critical system and application files are protected for all users. If users damage something related to an application within their own profile, you can usually repair it by erasing the profile and re-creating it. Of course, care must be taken during this operation because the profile doesn't only store application preferences but also user preferences and sometimes user documents. It is a good idea to make sure that you back up and restore documents and preferences once the profile is recreated.

Windows resource protection

Since Windows 2000, Windows has included Windows File Protection (WFP). This feature stores a backup copy of many critical system files (within the %SystemRoot%\System32\DLLCache folder). A special agent is constantly watching the system directories. If a Windows system file such as a DLL is deleted or replaced, this agent will automatically correct the situation by restoring the original and proper file. Many files are contained within the cache folder and are restored quickly without notification. However, due to space considerations, Windows may attempt to pull an original file from the installation media (for which you may be prompted if it is not available at the time).

Files protected by WFP may be updated only by OS upgrades, service packs, and hot fixes released by Microsoft. To protect the operating system further, WFP allows only operating system operations to update files within the DLLCache folder.

NOTE

Windows Installer cannot update protected files. If a Windows Installer package attempts to update such files, it will return error 1933. For this reason, setups that are tightly integrated with the operating system, such as Windows Media Player and Internet Explorer, are not provided as MSI setups from Microsoft.

In Windows Vista, Microsoft updated Windows File Protection and renamed it Windows Resource Protection (WRP). Along with the protection of system files, WRP now offers protection for key registry entries. If Windows Installer encounters any files or registry keys that attempt to modify protected areas of the system, it will log a warning and simply skip over the offending component. This is different from the behavior of Windows Installer with WFP. With WFP, Windows Installer would request that WFP install the offending file, but with WRP, the component is simply not installed and the installation proceeds without error. This may cause products to work erratically once the installation is complete. This is one more reason why applications should be updated to Windows Installer version 4 before they are deployed to Windows Vista systems.

Managing software in a locked-down environment

The new file structure for application location, application preference location, and the Windows File Protection make it even more difficult to update and install software on Windows systems, especially remotely. Of course, users who have local administration rights can install anything on a system. Standard users, who are on the lowest end of the totem pole in terms of installation rights, cannot install anything on the system because they are granted generic user access only.

Although this makes for more stable PCs, it does present a challenge for administrators: they need a proper vehicle to install software in locked-down environments, or grant all users administrative rights. Running a network where all users have administrative rights is like running a Windows 95 network, because you don't gain any of the advantages of a locked-down environment.

Although many desktop management solutions provide a client agent to address this issue, native support is also provided in Windows by Windows Installer because it can provide elevated rights to install software packages within the security context of the user. This makes it possible to have a locked-down environment and still allow installations in secure contexts. Of course, this does not solve all of the problems related to user installation rights, especially for those related to workstations or servers that are not connected to the network, but it does go a long way toward solving problems related to network-based software installations in a locked-down environment.

Other -----------------
- 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
- File Type Associations (part 1) - Anatomy of a File Type
- Registry Tasks and Tools (part 5) - Back Up the Registry
- Registry Tasks and Tools (part 4) - Export and Import Data with Registry Patches & Prevent Changes to a Registry Key
- Registry Tasks and Tools (part 3) - Create an Interface for a Registry Setting
 
 
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
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server