This article describes the disadvantages and technical
difficulties of repackaging applications for use with the Windows Installer
Capture or "discover" utilities are designed to convert
legacy installations into the new Windows Installer format; an MSI
These capture utilities, such as Veritas WinInstall LE which
ships on the Windows 2000 Server CD-ROM, take a picture of a system before and
after installation. Any registry changes, files changes, or systems settings
that occur during the capture process will be included in the installation.
Windows Installer is designed to be more integrated in the
application development cycle so that system administrators can have greater
flexibility when they roll out applications in their corporate environment. To
accomplish this, the application's developers considered redistribution during
early development phases, as opposed to the final development cycle.
By waiting until the final development phase to create a setup package, the
application had no support for its own installation; it relied on a completely
unrelated technology to be installed. As a result, total cost of ownership
(TCO) was greatly increased because system administrators had come up with
their own unique method for redistribution. Sometimes these solutions were a
large contributor to the "DLL Hell" problem. Repackaging does not solve all
these problems. It can sometimes compound the problems of legacy installation
technologies and increases the complexity because of the added extra layer of
Windows Installer is the current and future method
of installing applications in the Windows environment. It is a database-driven
installation technology as opposed to being script-driven, and it offers
several advantages, such as changes made to a system by the application setup
can be rolled back during installation. To take full advantage of the Windows
Installer features, the application developer should involve MSI in the
development phase. For more information, see the white paper about Windows
Installer on the following Microsoft Web site at:
Common Problems and Issues
Resiliency Resiliency can be inconsistent with repackaged applications
because the repackager utility may not fully understand the component
dependencies or what the key paths of the application should be. Therefore, an
application may be packaged into one large feature that gets entirely
reinstalled if a component keypath is missing. If it were broken up into
multiple smaller features it would enable a more manageable resiliency.
COM/ActiveX Registration Component Object Model (COM) and ActiveX controls may not be
properly registered. Prior to Windows Installer, COM and ActiveX registration
was a black box. Except for the exported functions DLLRegisterServer and DLLUnregister server, COM and ActiveX controls offered very few hints of their
registration process. RegSvr32.exe was responsible for calling the previously
mentioned functions and then the DLL was responsible for registering itself.
There is no utility that can view a DLL, an OCX, or an EXE and figure out what
goes on inside DllRegisterServer and DllUnregisterServer for that file. There are standard registry entries that most COM
and ActiveX controls register, such as HKCR\CLSID, HKCR\ProgID, and
HKCR\TypeLib. Information on COM registration may or may not get entered into
the appropriate MSI tables by the repackager.
Shortcuts Shortcuts may not be created as Windows Installer descriptor
shortcuts, which enable resiliency. Legacy setup shortcuts were .lnk files that
pointed to an executable in most cases. Sometimes when the repackager runs, all
it knows is that an .lnk file was copied to a directory. For example, a legacy
Setup.exe installed a shortcut to C:\Windows\Profiles\User1\Desktop. The
repackager would copy the .lnk file directly to the directory listed
previously. Therefore, the repackager is not actually copying a Windows
Installer shortcut, but rather it is copying a file without any resiliency
Isolated Components The only way to take advantage of isolated components is to
author a new MSI package. Repackagers currently do not support this feature.
Application Removal When uninstalling a repackaged application, it is possible that
the AllUsers profile may be removed. This is dependent on how the legacy setup
was captured and definitely needs to be tested.
Group Policy and Advertisement Receiving the following error message is a common problem when
assigning to GPO:
This is especially true when trying
to repackage an application as large as Microsoft Visual Studio 6. The error
message is misleading in the sense that it conveys to the user that there is
some ADSI setting that can be made to alleviate the situation. There is
currently no workaround for this error message. This is a repackaging issue
because of the superfluous information this process sometimes places in the MSI
For additional information, click the
article number below to view the article in the Microsoft Knowledge Base:
The size of the object exceeds the
limit set by the administrator.
Publishing Applications in Active Directory May Cause Error
Directory Structure Directory structure chaos is a common problem when repackaging
because of all the differences in the directories of the Win32 operating
systems. Consider the operating system directory locations for each of the
following environment variables:
Therefore, if you capture Microsoft Windows NT and then try
to install the MSI package on a Win9x OS, any files that should have gone to
the Windows\System could go to the WinNT\System32. Therefore, the application
files do not get installed to the proper directory. A "best practice" for this
scenario is to capture or repackage for each Windows platform so that the
directory structure and operating system-dependent files are captured properly.
- System Directory
Windows 95, 98, 98SE, and Millennium Edition =
Windows NT and Windows 2000 = WinNT\System32.
- Profile directory
Windows 9x/ME = Windows\Profiles
Windows NT =
Windows 2000 = Documents and Settings
ANSI vs. UNICODE Applications sometimes need ANSI- or UNICODE-specific libraries.
ANSI libraries are typically found in Microsoft Windows 95 and Microsoft
Windows 98. UNICODE was designed for Windows NT 4.0 and Microsoft Windows 2000.
If you create an MSI package designed specifically for UNICODE or ANSI, you
have problems when you start redistributing your packages across Windows 95,
Windows 98, Windows NT, and Windows 2000. This is another good reason to
repackage for each OS version.
Customization (Repackaging vs. Transforms) If your application was originally built in the MSI format and
you want to customize your package, you do not have to use repackaging. Windows
Installer is designed with system administrators in mind and has anticipated
the need to customize packages. The Windows Installer supports a feature called
Transforms (.MST) that is designed for customizing installs.
more information, see the Transforms topic in the Windows Installer SDK on the
following MSDN Web site at:
User Account Configurations When you repackage an application, any changes that are made
under a user account may be what is installed. For example, the legacy
application, MyProgram.exe, has been converted to an MSI package under the
local machine account Administrator. MyProgram.exe has a shortcut on the
desktop (C:\Documents and Settings\Administrator\Desktop\MyProgram.LNK) and
stores user settings in the USERPROFILE (C:\Documents and
Settings\Administrator) subdirectories. User1 logs in and runs the MSI. User1
receives an error message because he or she does not have permissions to write
to the Administrator folder. Even if User1 has admin privileges or runs the MSI
with elevated privileges, the MSI is going to write the desktop shortcut into
the Administrator profile. The same thing applies to user settings and user
specific data; it is all going to run from the C:\Documents and
Settings\Administrator directory. Therefore, when you repackage an application,
an exact copy of the differences may be written to the profile of the user who
installs the MSI package.
If you decide to use the repackaging tools, you need to remember
a few things:
- Always use the tool on a totally clean computer; make sure
the computer has no other applications installed.
- Close any non-essential services.
- Create a package for each hardware configuration you have.
For example, if you have 50 Dell XYZ computers and 50 Gateway ABC computers,
you need to make packages for each type of system because of all the different
hardware and drivers loaded on each computer. You want to keep each package
limited to your specific hardware and software configuration.
For additional information about
getting through this process, click the article number below to view the
article in the Microsoft Knowledge Base:
How to Create Third-Party Microsoft Installer Package (MSI)
additional information about publishing legacy applications on a Windows 2000
domain, click the article number below to view the article in the Microsoft
How to Publish Non-MSI Programs with .Zap Files