Software Installation and Maintenance
Software Installation and Maintenance |
|
The Windows Installer package is an .msi file that contains explicit instructions about installing and removing specific applications. The company or developer who produces the application provides the Windows Installer package .msi file and includes it with the application. If a Windows Installer package does not come with an application, you might need to create a Windows Installer package by using a third-party tool. Windows Installer technology provides the following:
Microsoft provides a redistributable installation program, instmsi.exe, that enables the Windows Installer installation service on Windows NT 4.0, Windows 98, and Windows 95. For more information about this installation program, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
Note
Only Windows 2000 Professional supports Group Policy–based managed applications.
Each package (.msi) file is a relational database that stores all of the instructions and data required to install and remove the program across various installation scenarios. For example, a package file can contain instructions for installing an application when a prior version of the application is already installed. The package file also contains instructions for installing the software on a computer where that application has never been present.
A Windows Installer package consists of multiple interrelated tables that together constitute a relational database of the information that is necessary to install a group of features.
The Windows Installer package database schema provides advantages over a text-based flat file solution as follows:
A Windows Installer .msi package contains standard summary information: Tables that describe the features that make up the application, pointers to the source files to install, and pointers to where to install the application on the client computer. The summary information stream contains some basic data about the package and the application that the package installs. This information includes the application name, the application publisher, and the version of the application as well as other basic information.
Developers can use the Windows Installer installation service and the .msi package schema to divide an application into available features and then further divide these features into the required components that make up the feature. This highly defined relationship between features and components is the architecture that allows applications to install features as they are needed. After the application is installed, a user can modify it by selecting additional features as needed; this is called "just-in-time" feature installation. Windows Installer also maintains the necessary key files and registry settings. If the necessary components for a feature become damaged, an intelligent reinstallation of only those features is possible. And the complete removal of the application is possible because of the known and tracked relationship between features and their base components.
You can store a Windows Installer package anywhere and on any media type that you want. As long as a client can get to the share, the package is available.
You can use the package format to compress all of the product's component files into one or more cabinet (.cab) files for installation from either a floppy disk, network share, or Internet location. The cabinet files can also be included in the package. When products reside in a folder hierarchy, the hierarchy is the same on the CD as it is at a distribution point and on the user's local hard disk drive by default unless the user makes changes. In such cases where the user has made changes, the package does not include product files themselves, but rather a reference to an installation point where the product files reside.
For the best installation experience, use natively authored Windows Installer packages. Natively authored Windows Installer packages support all of the Windows Installer functions including just-in-time feature installation, feature repair, and installation with elevated privileges.
Typically, an organization can natively author a Windows Installer package for their in-house applications when they have access to all the source code, executable files, dynamic-link libraries (DLLs), and other resources. You need to have an understanding of the application, including registry entries, shortcuts, and other information that are needed for the application to run correctly.
For example, an organization has an in-house application that users can use to arrange their business travel. They have all the files for the application, and the developers understand how the application must be installed on user's computers. In this case, the organization can choose to natively author a Windows Installer package for the software. It is important that you fully understand all aspects of an application before modifying features and their relationship to other components.
For best results, create the installation package and the software simultaneously. That is, you should not create the setup as an afterthought at the end of the development cycle; instead, the installation of the software should be a part of the overall architecture of the application.
Windows 2000 can work with existing applications, but there are some distinct advantages to working with "Certified for Microsoft Windows" applications. A "Certified for Microsoft Windows" application requires more than just a Windows Installer based installation. For more information about these types of applications, see the appendix "'Certified for Microsoft Windows' Applications" in this book.
There are a few programs available to assist you with natively authoring a Windows Installer package or modifying and repackaging existing Windows Installer packages. Windows 2000 Server includes the VERITAS WinINSTALL LE (Limited Edition) repackaging tool. Other tools to support creation of packages include authoring tools from InstallShield, Wise Solutions, and Microsoft. For more information about these applications, see the following links on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources:
Use these Windows Installer authoring tools if you are a developer, you have access to the source code for the application, and you understand how to install the application. If you are an administrator, you have software with a non-Windows Installer based setup, and you want to use a program to repackage the application and create a Windows Installer package, you can use the third-party authoring tools.
Note
The VERITAS Software WinINSTALL LE is included on the Windows 2000 Server CD in valueadd\3rdparty\mgmt\winstle.
You can use the VERITAS WinINSTALL LE program to view existing .msi packages and to see and modify many aspects of the package, including the following:
You can use this application to view the property table, the summary information table and which DLLs and program files are required for a specific application.
By using the VERITAS WINInstall LE program, you can make simple modifications to the applications general summary information that users see when working in the application. It is recommended, unless you are the author of the .msi package, that you only modify the general summary information area. Modifications to the required files, registry settings, and services can make the package unstable. If you need to make changes to the package, consider creating a transform.
Caution
An erroneous package can disable the software on the server and client computers. Do not make changes to the existing .msi package if you are unsure of the possible effects.
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
You can use WinINSTALL LE to take a snapshot of the current system state and store the configuration. You are then free to make systemwide changes, such as installing software, updating the registry, and configuring settings. After this is complete, you can then take another snapshot of the system. The changes between the two snapshots are compiled into a package known as an .msi file. (This tool can also assist with troubleshooting because it can compare the files and registry information before and after installation.)
It is best to repackage applications on the version of the operating system on which they are to be installed. For example, if you plan to install a package on Windows 2000 Professional, repackage the software on Windows 2000 Professional. If you plan to install the package on Windows NT 4.0, repackage the software on Windows NT 4.0.
For more information about Windows Installer, including the Windows Installer package schema, the details of the Windows Installer API, and sample packages and code, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
Note
Systems Management Server can distribute and install Windows Installer packages. A
An organization can use repackaged applications for Windows Installer to begin to benefit from the Windows Installer technology and to use the software installation and maintenance feature of Windows 2000. Repackaged applications are not as granular as natively authored applications, that is typically they have one large feature that makes up the Windows Installer product defined by the package, whereas natively authorized packages can contain multiple, customizable features. Repackaged applications can be advertised and repaired and can install with elevated privileges when assigned or published.
Keep in mind that Windows Installer packages can be used for installing applications on computers that are running Microsoft Windows 2000, Windows NT version 4.0, Windows 98, and Windows 98. Systems Management Server can also manage Windows Installer packages.
Repackaging requires clean computers. A clean computer is one that has only the operating system installed and has not had any other software installed or removed. Begin the repackaging process by taking a snapshot of the computer without any applications on it. After you have the snapshot, run the existing installation program for the software you want to repackage, configuring the files and registry entries for any customizations you want. Then, when the computer is configured exactly how you want it, take another snapshot. The repackaging software compares the before and after snapshots and uses the differences to generate a Windows Installer package.
Of all the things that impact the success of repackaging, the most important is to start with a clean reference computer; that is, one that has not had other applications installed on it. If you do not use a clean computer, any files or registry entries needed by the application that are already on the computer are not detected by the repackager. This can potentially leave vital files out of the repackaged .msi file, and thus might break the application when you try to install it.
Consider using Windows 2000 Remote OS Installation to manage the clean computers in a repackaging lab.
Thoroughly test all repackaged Windows Installer packages before deploying them in a production environment. Repackaging is generally a safe process, but some applications that modify system settings can cause problems if installed in a repackaged format.
Delete any shortcuts placed in the Startup folder by the application between snapshots, or manually remove the shortcuts from Windows Installer package after it is created. Otherwise the shortcuts are created by the Windows Installer package rather than by the software installation and maintenance feature, and the application automatically installs itself when the users logs on if the application is assigned to them whether this is called for by the Group Policy object or not.
Delete any shortcuts that point to an uninstall program for the application. It is recommended that a repackaged application be removed by using Add/Remove Programs in Control Panel so that Windows Installer is triggered to perform the removal. The application might not be removed correctly if the user runs the earlier uninstall program.
In general, avoid restarting the computer between repackager snapshots. Even if the application states that the computer must be restarted after the setup is completed, it might be a good idea not to restart the computer. Windows might adjust certain registry settings or files during the restart process that might inadvertently end up in the resulting package. If your resulting package does not work, and restarting the computer is recommended, rebuild the package and restart the computer prior to taking the second snapshot.
If you have applications that do not have a Windows Installer package, and you have decided not to repackage the application for Windows Installer, use software installation and maintenance to publish existing setup programs using .zap files.
Note
Windows Installer packages whether natively authored or repackaged can be installed automatically with elevated privileges if they are either assigned or published. Typically, existing setup programs would require the user to have local administrator privileges to run the existing setup, which is one reason to consider repackaging versus publishing existing setups using .zap files. Also, if the existing setup does not support clean and complete removal of the software, publishing the existing setup does not improve the software removal experience.
Using the .zap file format, you can publish applications using their existing setups. The .zap file is placed in the same folder on the software distribution point as the original setup program that the .zap file references. When an application is deployed by using a .zap file, the contents of the .zap file are parsed and the application and its associated file name extensions are added to Active Directory.
When you publish the existing setup using .zap files, the experience for the user installing the application is the same as using the existing setup. That is, if the person installing the application has to be an administrator to install the software, they also have to be an administrator to install the published version.
The .zap file resembles an .ini file. It must include an Application section [Application] and might optionally contain a file name extensions section [Ext]. Each section is made up of several parameters and their values. You can create or modify a .zap file by using a text editor such as Notepad.
Caution
ZAP files created with Notepad might actually have a name of file name .zap.txt. Make sure that the extension of a zap file is .zap.
The following information is provided as an example for creating a .zap file. Do not copy this information exactly as it is presented. Modify the information to match the application that you are attempting to manage, as well as the location of your software distribution point.
The following three lines are all that is needed in a .zap file to publish Microsoft Excel 97 using the existing Excel 97 setup program:
[Application]
FriendlyName = "Microsoft Excel 97"
SetupCommand=""\\server\share\Excel 97\setup.exe""
The path and name of the .exe file must be quoted within the [Application] section. If there are no command line arguments, it needs to be quoted twice. For example:
Absolute path:
SetupCommand=""\\server\share\long folder\setup.exe""
SetupCommand="\\server\share\long folder\setup.exe" /argument
Relative path:
SetupCommand=""setup.exe""
SetupCommand="setup.exe" /argument
The following example shows a more extensive .zap file for publishing Microsoft Excel 97. This example includes optional information from the application documentation, file name extensions and includes LCID, CLSIDs, and progIDs.
Note
Many entries in this file are optional. The progID, CLSIDs, and LCIDs vary based on your system and the application with which you are working. A .zap file with only the required entries can be much shorter. Do not copy this file exactly as it is.
; ZAP file for Microsoft Excel 97
[Application]
; Only FriendlyName and SetupCommand are required,
; everything else is optional
; FriendlyName is the name of the application that
; appears in the Software Installation Snap-in
; and the add/remove programs control panel.
; REQUIRED
FriendlyName = "Microsoft Excel 97"
; SetupCommand is the command line to
; Run the applications setup. if it is a relative
; path, it is assumed to be relative to the
; location of the ZAP file.
; Long file name paths need to be quoted. For example:
; SetupCommand = "long folder\setup.exe" /unattend
; or
; SetupCommand = "\\server\share\long _folder\setup.exe" /unattend
; REQUIRED
SetupCommand = ""setup.exe""
; Version of the application that appears
; in the Software Installation Snap-in and the
; add/remove programs control panel.
; OPTIONAL
DisplayVersion = 8.0
; Publisher of the application that appears
; in the Software Installation Snap-in and the
; add/remove programs control panel.
; OPTIONAL
Publisher = Microsoft
; URL for application information that appears
; in the Software Installation Snap-in and the
; change/remove page of add/remove programs control panel.
; OPTIONAL
URL = http://www.microsoft.com/office
; Language for the app, in this case US English.
; OPTIONAL
LCID = 1033
; Architecture, in this case, intel.
; OPTIONAL
Architecture = intel
; the [ext] [CLSIDs] and [progIDs] sections are
; all optional
[ext]
; List the file name extensions this application supports
; "auto-install" for. This entire section is optional.
; When listing file name extensions you can place a dot in front of the ; extension or leave it off. For example you can use .XLS= or XLS=
; The text listed after the first = sign is optional and ignored.
; The first = is required (or the entire line will be ignored).
XLS=
XLA=
XLB=
XLC=
XLM=
XLV=
XLW=
[CLSIDs]
; CLSIDs that this application will "auto-install"
; for. This entire section is OPTIONAL.
; Format is CLSID with LocalServer32,
; InprocServer32, and/or InprocHandler32 (in a
; comma separated list) after the =.
{00024500-0000-0000-C000-000000000046}=LocalServer32
{00020821-0000-0000-C000-000000000046}=LocalServer32
{00020811-0000-0000-C000-000000000046}=LocalServer32
{00020810-0000-0000-C000-000000000046}=LocalServer32
{00020820-0000-0000-C000-000000000046}=LocalServer32
{00020820-0000-0000-C000-000000000046}=LocalServer32
[progIDs]
; progIDs that this application will "auto-install"
; for. This entire section is OPTIONAL.
; format is a CLSID, with the corresponding progid
; listed after the = sign
{00024500-0000-0000-C000- _
000000000046}=Excel.Application
{00024500-0000-0000-C000- _
000000000046}=Excel.Application.8
{00020821-0000-0000-C000-000000000046}=Excel.Chart
{00020811-0000-0000-C000-000000000046}=Excel.Chart.5
{00020821-0000-0000-C000-000000000046}=Excel.Chart.8
{00020810-0000-0000-C000-000000000046}=Excel.Sheet.5
{00020820-0000-0000-C000-000000000046}=Excel.Sheet.8
{00020820-0000-0000-C000-000000000046}=Excel.Sheet
{00020820-0000-0000-C000-000000000046}=Excel.Template
{00020820-0000-0000-C000-000000000046}=Excel.Workspace
You can customize Windows Installer applications by using transforms. Authoring and repackaging tools provide mechanisms that permit the creation of transforms, and applications might also provide wizards or templates that permit a user to create transforms.
For example, Office 2000 has the Office 2000 Custom Installation Wizard that builds transforms. By using the Office 2000 Custom Installation Wizard, you can create a transform so that you can manage the configuration of Office 2000 that is deployed to users.
By customizing the Windows Installer package with a transform, you can provide the key features that users need. In the case of Office 2000, Word might be a key feature, so it installs during the first installation. You might customize less popular features, such as revision support or document translators to be installed on first usage. You might decide that it is best that other features, such as clip art, not be installed at all. And again, you might create another transform that provides all of the features of Word and does not install PowerPoint. The exact mix of which features to install and when to install them varies based on the needs of your users.
You can transform or modify a Windows Installer package to handle a variety of customizations. For example, you can control which features are installed and where they are located: on the local computer's hard disk drive or used from a file server. Although they are optional, transforms can be used for a variety of purposes including the following:
Note
It is recommended that transforms are stored at the same software distribution point (in the same shared folders) as the Windows Installer package that they customize.
A Windows Installer package might be associated with one or more transforms that get applied to the package at deployment time. Many of the customizations that you used to perform by repackaging applications are better handled by transforming the Windows Installer package.
Transforms are associated with the Windows Installer package at deployment time rather than when the Windows Installer is actually using the package to install or modify the application. Deployment time is when you are first working with the Windows Installer package in the Software Installation
It is best to create separate packages for each application. For example, if you have four separate applications you want to install, create four separate packages so that the Windows Installer service has the ability to better manage the installation state in the case of an installation failure. For example, if the installation of a package fails, Windows Installer can undo the installation. If four applications are one package, and the first three applications install, and then there is a failure with the fourth application, all four applications would be removed when the single package fails.
Note
In the past, administrators often customized the software by repackaging the software. Do not try to repackage applications that use Windows Installer, instead use transforms for additional customization.
Note
If a transform needs to change, make a new transform, and then remove the existing application and transform and reassign or publish the application with the new or changed transform. If you have to do this, consider making an upgrade relationship between the application and the old transform and the application and the new transform. Of course, it is recommended that this be tested to ensure you get the results that you want.
Important
When you create a transform to customize a Windows Installer package, do not change the product code of the package. If you change the product code, you must verify the assignment and publishing of the package with the new product code works as if it were an upgrade or it might not be available to the users who already have the existing package (with the old product code).
You can customize the summary information screen of a Windows Installer package to fit the needs of your organization and your users. For example, you can include support information for your company to make it easier for your users to access support for the application being installed.
The information that you add is displayed when a user selects additional information in Add/Remove Programs in Control Panel.
To add modifications to an application package, use one of the Windows Installer authoring or repackaging tools. The process that you use to modify information and the information that you can modify varies according to the tool that you select. For example, you can use the VERITAS WinINSTALL LE application that is included with Windows 2000 Server to open the package and customize the summary information data.
The summary information screen contains basic data about the Windows Installer package and the application the package installs. It includes the application name, the application publisher, and the version of the application as well as other basic company support information.
You can safely modify the following items on the screen:
Caution
You can damage the entire package if you modify any information outside the basic summary information listed in the previous paragraph. For example, you might unintentionally make the package unavailable to some users.
Many organizations need to distribute additional files with an application. For example, you might want to distribute a sales quote template with Word and a customized bidding spreadsheet with Excel.
These files can be bundled with the executable file and other source files for the application when you create the package, or you can include them as a transform.
However, these files are often more volatile than the application files. Therefore, you might want to package them in their own Windows Installer package. This package has its own product code, and therefore it can be upgraded on a different schedule than the application. If the files are included as part of the application transform, each time the templates are updated, the entire application transform needs to be deployed again.
When working with your own templates or custom files, it is easy to create new packages using one of the available native authoring tools for Windows Installer packages. You only have to define the files and the location where you want the files to installed, the target location. Build a package to distribute only the updated files, and if necessary, the files are compressed into their own Windows Installer package.