)
document but it is a long read, technical and
assumes that you know some of the concepts already. Therefore here
are the basics.Indeed, this is all
explained in the MSI SDK (click
)
document but it is a long read, technical and
assumes that you know some of the concepts already. Therefore here
are the basics.
This is the file that contains the instructions for MSIEXEC.EXE to install the application. The MSI file is a Database file format and is now the preferred application packaging format for the windows platform. Sometimes the MSI file gets too big and some or all of the files are placed in a .CAB file.
In the MSI world, if you didn't create the MSI file, you want to keep the MSI file from the developer intact. To make changes beyond what the original MSI does you use a transform. The transform is applied at the time that the MSI package is installed. Why is this a big deal? In the old days (that includes today as well!) if you would repackage an application and it would fail, the Original Developer of the application would sometimes refuse to support it since repackaging strips out their installation logic. In the Developer’s mind, you modified their application. With MSI and transforms you avoid that charade.
If you create your own MSI packages you can also use transforms to change some parameters for each department of your company. That way you have only one package to maintain and nobody can accuse you of doing a better package for one department vs. another. It’s the same bloody package.
Transform files are in fact MSI files with a different file
extension. The contents of both files are merged together at install
time. They are not supposed to add files to the package but there are
way. Wise Package Studio does allow adding files using Transforms but
they create a CAB file to bring files in without breaking the MSI
rules.
This is another one of MS’ idea to prevent DLL HELL. Merge Modules are groups of shared DLLs and OCXs that depend on one another. If your SetupCapture picks up one or more shared DLLs for which there is a Merge Module for, then those files are removed from your package and the appropriate Merge Modules are substituted in its place.
When you go to edit a package that contains Merge Modules, you don't see the contents of the Merge Modules that make up your package. If you want to see them: Edit menu ->Preferences-> Installation Expert tab-> check the Show merge modules components.
These files are available for download through WPS, Wise Solutions Technical Support Center (for registered users only) and at http://www.installsite.org/ under Merge Modules. When you buy Wise Package Studio (WPS), they are also on the CD.
This is what MSIEXEC does during an installation if it runs into an error and can undo the changes it did up to the point that the error occurred.
|
OS |
MS' terminology |
|---|---|
|
95,98,ME |
n/a (Security? Everybody is admin in 9x!) |
|
NT 4.0 |
Restricted Users |
|
Windows 2000 |
USERS (2/3 down the page) |
|
Windows XP |
|
|
Windows 2003 |
Limited USERS (???) |
|
Sucessor to Windows XP |
tba |
This
is the User Account type that prevents users from installing
applications (err..almost!).
In the old days, LAN Admin would create the User accounts as administrators, install the all software the user needed into his profile and then make the user account a “Restricted User”. The real fun began when you had to maintain such a thing.
Today, you can use MSI to install applications that require administrator access for Restricted Users. It does this by running the MSI installer as a service on the target workstation.
If you install an application for all users on the computer (or assign software to the computer account via GPOs) the software is fully installed only for user that initiated the install. All other existing and future users of the computer will have their installation completed next time they login and/or launch the application. The process used to complete these installations on the fly is unofficially called “User profile fix-up detection”. This is in fact a special case of self-healing feature of MSI. The catch is that most MSI packages don’t do this well if at all. You can, however, tweak the MSI package using Transforms to perform the changes properly.
Err..Almost:
Even Restricted users can install/run some unwanted applications.
This include self-contained applications that require no installation
per se and applications that install files to the user's own profile
and keys to the User's registry hive. The latter does exist but are
few since most home windows users run with an Administrator account.
Developers are more than happy to trade their users' security for
fewer support calls.
WPS is meant to repackage applications into MSIs whereas WfWI is meant to generate MSI packages from scratch or from a Visual C/C++ code (ie.: for developers). Hence, WfWI has no SetupCapture or Transform creation capability.
WfWI version 3.2 and lower had SetupCapture and Transform creation
capability and was able to repackage applications into MSI, since
then Wise has created 2 separate products lines.
In Wise Package Studio (WPS), after you capture an installation, it creates a WSI file along with the MSI file. You can edit the MSI file directly but it is preferred to recreate the MSI file using the WSI file. Doing so gives you more options when creating MSI packages.
In Wise Package Studio (WPS), this is the default path for the captured packages. It is selected at install time of WPS. It is meant to be used as a central location for all packages, source files, WSI files and many other shared resources. In it you have a projects folder. That is where you create sub-folders for each of your packaging projects.
SetupCapture is the program in Wise Package Studio (WPS) used to repackage an application’s setup.exe package into an MSI package. Usually you tell it to create a WSI file instead of an MSI file directly. The WSI file is the working file from which you later compile it, with the source files, into an MSI file.
Install Tailor is the program in Wise Package Studio (WPS) used to create Transforms (.MST) an application’s setup.exe package into an MSI package. Unlike SetupCapture, you create an MST file directly and edit the MST file directly.(there is no such thing as a WST file in Wise)
Install Tailor is the program in Wise Package Studio (WPS) used to edit MSI packaged and Transforms (.MST). The is also the tool you use to edit WSI working files from which you later compile it, with the source files, into an MSI file. (BTW: Yes this is the same tool in Wise for Windows Installer.)
Wise has 3 classes for their WPS product:
-Standard costs the least and includes WiseScript Express.
-Pro costs 2-3 time more that Standard but add Client/Server setup and the full WiseScript Editor. Pro also add the much touted “Virtual Capture” feature but few people use it and nobody in the newsgroups answers questions about it.
-Enterprise costs more than Pro and is targeted to places that have many packagers and need to track/coordinate their work. It adds more reports and few more features.
All
3 versions can share the same SharePoint provided that the versions
are matched-up. Ie. WPS 4.62 Standard and WPS 4.62 Pro can use the
same SharePoint .
If
you upgrade the SharePoint (by upgrading one Workstation) the other
lower versions of WPS will be locked out. The only thing that really
locks them out is the Workbench database. None of the packages in the
projects folder are changed. If you use the conflict resolution and
package distribution functionality (of Pro and up) then those
features will probably be affected too.
In MSI land this is usually a division in your package to separate major functions. For example in MS Office, Excel and Word are separate features of the Office MSI package. Features are also meant to be able to be complete by themselves. If feature share files and registry settings for some things like spell checking, those are usually spun off as a separate feature that Excel and Word depend on.
In Wise Package Studio when you capture a setup, it usually creates
only one feature called Complete. You can add features
manually or add them using a feature SetupCapture. A feature can
also be sub-divided into Components.
You can even have feature that install automatically depending on conditions. These are called Conditional Features.
A grouping of files and/or registry keys that are usually related to one another. Similar to the idea of a feature but provides a small functionality of a feature. Different features can use the same components.
Note: Some MSI packagers like On Demand’s WinInstaller create one component for each registry entry and file. This makes the package hard to troubleshoot but also eliminates many ICE Errors.
This term is used over and over but is not explained well. It is a specific Registry key or File that a component sees as most critical. When an MSI-based application is launched, it checks these critical registry keys and files or KeyPaths. If one of them does not match with what is in the MSI then the component related to that KeyPath is re-installed. This process is known as self-healing.
The
fun in troubleshooting MSI comes when the KeyPath is set to a moving
target like a temporary file or volatile registry entry like “last
run time” or size/location of a window. This in turns triggers
self-healing. You can change the KeyPath for components in WPS.
Variables in MSI are called properties.
Then can be set in the MSI tables in the package, set using a custom action in the MSI package, as a parameter if launched through the command line or using a transform.
The SDK mentions many "predefined" properties and says that some are initialized at runtime. If their name is ALL_UPPERCASE then they are known as public properties which can be set from the command line.
MSI technology runs on scripting. You can add to this script as you see fit. The catch is that these Custom Actions are not logged and are not undoable during a rollback. They can be used to uninstall the old non-MSI version of an application and other non-trivial things. You can do very fancy things like using a Custom Action to call a DLL which tests unlock codes to your application.
If you want to install unattended and want to use all the defaults in the menus, launch the MSI from the command line with the –QN switch.
If you want to install unattended but need to change something in the menus, then you must use a transform and launch the MSI from the command line with the –QN switch.
If
you will be using GPOs to launch the MSI packages the same rules
apply except the -QN switch is implied.
This is the way that applications are made available to be installed without actually being installed. This is used for Install-on-Demand purposes. This feature is meant to be used when distributing the package via GPOs or SMS or ZENworks. The package is assigned (via GPO) to a user and if the user launches the shortcut or opens a file with an extension associated to that package, then the package is installed for that user. The shortcuts and file associations are also called Entry Points to the package.
If you install an application for all users on the computer (or assign software to the computer account via GPOs) the software is fully installed only for user that initiated the install. All other existing and future users of the computer will have their installation completed next time they login and/or launch the application using these special shortcuts. The process used to complete these installations on the fly is unofficially called “User profile fix-up detection”. This is in fact a special case of self-healing feature of MSI.
What happens when a file in the package already exists on the target PC? In the old days it was whatever the author of the setup.exe felt like and that created what is known as “DLL HELL”.
MSI has rules for this:
Most files (EXE, DLL, etc.) have version numbers inside (Right-click-> Properties -> Version tab to see them). If a file that exists in both the package and on the target PC, the file with the highest version number will be copied (or left) on the machine. This is regardless of the file date.
If one of the files doesn’t have version number then the file with the version number will be copied (or left) on the machine.
If the file already exists on the PC it is NOT overwritten.
In some cases you really need to break these rules. Use the “companion file” feature of MSI to do that which is covered in the FAQ.