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.
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.
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).
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.
