All About the Four Types of MSI Transforms
The MSI format lets you easily modify or customize the software install by creating a transform. An MSI transform is a file (.mst) that describes how WIS (Windows Installer Service) should install an MSI package. The four types of Windows Installer transforms are embedded, unembedded, secured, and unsecured.
Embedded transforms:
Embedded transforms are stored inside the .msi file of the package. This guarantees to users that the transform is always available when the installation package is available.
If the installation source is read-only, such as a CD or a network share to which the person creating the transform has read-only access, this is not an option because you must be able to write to the source to embed the transform in the *.msi file.
To add an embedded transform to the transforms list, add a colon (:) prefix to the file name. Embedded transforms are not cached separately on the client computer, because Windows Installer can always obtain the transform from the .msi file. .Embedded transforms might be used in combination with secured or unsecured transforms.
Unembedded transforms:
Unembedded transforms are stored separate from the .msi file of the original package. Unembedded transforms are cached separately on the client computer. You can use unembedded transforms in combination with secured or unsecured transforms.
Secured transforms:
Secured transforms are recommended for security reasons. If an application is installed at an elevated level, either per-user or per-computer, a user with low rights can modify an unsecured transform and use it to make changes to the computers that have elevated privileges.
Secured transforms are stored locally on the client computer in a location where, on a secure file system such as NTFS, the user does not have write access. Such transforms are cached in this location during the installation or advertisement of the package. During subsequent installation-on-demand or maintenance installations of the package, Windows Installer uses the cached transforms.
To specify secured transform storage, set the TransformsSecure policy, or set the TRANSFORMSSECURE property, or pass the @ or | symbol in the transforms list.
If a user removes the product, Windows Installer removes all secured transforms for that product from that user's computer. If Windows Installer finds that a secured transform is not locally available, it then attempts to restore the transform cache from a source. Secure transforms can be secure-at-source or secure-full-path:
- Secure-At-Source transforms that are missing from the local transform cache are restored from the root of the source of the .msi file.
- Secure-Full-Path transforms that are missing from the local transform cache are restored from the original full path specified by the transform list.
Unsecured transforms:
Unsecured transforms have not been secured as described in Secured Transforms in the preceding list. When a package is installed or advertised as a per-user installation, and the package has unsecured transforms, Windows Installer saves the unsecured transforms in the Application Data folder in the user's profile. This enables a user to maintain a customization of a product while roaming from computer to computer.
When the package is installed or advertised as a per-computer installation, and the package uses unsecured transforms, Windows Installer saves the unsecured transforms in the %windir%\Installer folder.
If the cached copy of the transform becomes unavailable, Windows Installer can restore the transform cache using a source listed in the SOURCELIST property. Windows Installer uses the same method to search for a transform source as it uses to search for an .msi file.
To apply unsecured transforms when installing a package, pass the transform file names in the TRANSFORMS property or in the command-line string, and do not begin the string with the @ or | characters. Do not set the TransformsSecure policy or the TRANSFORMSSECURE property.
Source: MSDN page on Installer Technology
The Endpoint Management Community Blog is the perfect place to share short, timely insights including product tips, news and other information relevant to the Endpoint Management community. Any authenticated Connect member can contribute to this blog.
Comments
MSTs...error message
Great write up! Very useful!
So I wrapped an application which already had MSI. I created an MST from it and I included the CAB files in the EXE. I pointed the destination in the exe to %TEMP%\test.mst. So on some PCs the application installs without issues. On other PCs the application shoots an error message stating that it cannot get the MST from %TEMP% location.
So for giggles, I changed the MST's destination to %WIN% and then compiled an EXE and this works like a charm on all PCs.
Any comments???
Ropree
My comment to Ropree
The most logical solution is that you use %temp%, and that is not alway's declared. And when it is declared, it depends on the user if it is on the local machine or on the network, because it mostly goes to the temp in the users homedrive.
If you wish to use something like temp, make sure the variable alway's exist.
Regards
Erik
www.svs4u.nl
Regards Erik www.DinamiQs.com Dinamiqs is the home of VirtualStorm (www.virtualstorm.org)
*************************************************************
If your issue has been solved, Please mark it as solved
***********
%Temp% is tricky
[quote=erikw]If you wish to use something like temp, make sure the variable alway's exist.[/quote]
How true this is. If you work with certain CAD applications, you learn that the TEMP directory has to be defined, the problem is the TEMP location is not always defined the same.
However, if all your computers are configured the same (Windows install directory) then using the Windows directory variable is going to work 99% of the time.
MST in %Temp%
Hi Panna,
Thanks for your comments.. :)
Well, I guess this is with reference to the Adobe application which you had done sometime back.
Many a times, there will be a startup script written in a machine to clean up all the temporary data and cookies when it goes for a reboot.
The temporary or junk data are usually present in %temp%, Applicationdata\cookies, Profiles folder etc..
As adobe restarts during the isntallation process, there may be a case where the base MSI is not able to locate the MST in the temp. and that's why it worked when you had copied your MST to windir.
Hope it's useful.
Cheers'
Viju
Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com
MST in %TEMP%
Thanks Viju and Erik,
This was helpful and yes, it makes sense now. Just so you know what I did and it works all the time...
I placed it in the %WIN% directory and at the end of the installation, I told it to delete the mst so there is no clutter.
Thanks again...
Ropree
Optimal Solution : SourceDir
I reckon the best solution for this is to write a custom action which calls the MSI property "SOURCEDIR".
This will be very useful during deployment too.
Any thoughts on this?
Cheers'
Viju
Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com
Would you like to reply?
Login or Register to post your comment.