hey buddies, Read this lovely conversation of Steve Balmer with MVPs during a Summit.
http://www.microsoft.com/Presspass/exec/steve/2008/04-17MVP.mspx
Its worth reading through Balmer’s answers to the queries raised.
Category: Microsoft
Covers stories and news from the Microsoft world – Product Launch, previews, Developer and IT Pro Tools, Open Source initiatives, Interviews, MVP Program, Microsoft Communities and more!
Step 1: Launch the Patch Creation tool from within your Wise product. The Patch Creation tool’s Welcome dialog appears. This dialog offers an outline of the steps for creating a patch.
Step 2: Read the information on the Welcome dialog, and click Next when finished. The Specify Patch Settings File dialog appears.
Step 3: The radio buttons on the Specify Patch File Settings dialog indicate whether to create a new patch file or Open an existing patch settings file. A patch file (.PCP) stores settings from the Patch Creation tool, such as the names of the previous and new .MSIs and whether to include whole files or file patches when compiling the patch. For this exercise, select the radio button to create a new patch file and click Next. The Specify Previous Versions dialog appears.
Step 4: Use the Specify Previous Versions dialog to add entries for each of the previous versions of an installation that the latest version can patch. Click Add to add a previous version. The Previous Version Details dialog appears.
Step 5: Click Browse to browse to the .MSI for the previous version of your application. Click Open after locating the .MSI.
Step 6: Make any desired changes on the Previous Version Details dialog. The settings in the Validation section of the dialog indicate the requirements of the previous installation on the destination computer in order to install this patch. Please view the online help by pressing F1 on the Previous Version Details dialog for more information about the various fields.
Step 7: Click OK when finished making changes on the Previous Version Details dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI and the Specify Previous Versions dialog shows a target path pointing to a temporary directory where the extracted .MSI resides.
Step 8: Add other previous versions if applicable, then click Next on the Specify Previous Versions dialog. The Specify Upgrade Version dialog appears.
Step 9: The Specify Upgrade Version dialog shows the path to the .MSI that upgrades the previous versions enumerated on the Specified Previous Versions dialog. When launching the Patch Creation tool with an installation project already open, the Upgrade MSI path field contains the path to the .MSI for the current installation project. Click Browse to browse to the upgrade .MSI if the Upgrade MSI path field doesn’t already contain the correct information.
Step 10: Click Advanced to display the Advanced Upgrade Version Details dialog. This dialog shows the Patch GUID and a field for Previous Patch GUIDs to replace. Please view the online help by pressing F1 on the Advanced Upgrade Version Details dialog for more information about the fields on the dialog. Click OK when finished making changes to the Advanced Upgrade Version Details.
Step 11: Click Next on the Specify Upgrade Version dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI to a temporary directory, and then the Compile Patch dialog appears.
Step 12: The Compile Patch dialog shows several options for compiling the patch. The first field is the name of the Output .MSP file. Browse to the location where to store the .MSP file, or type in the full path including the file name.
Step 13: The Advanced Settings on the Compile Patch dialog determine whether to create file patches or to use entire files, whether to allow the Product Code or Version Number to differ between the previous and upgrade, and whether to create a log file. Mark the checkboxes for these options to enable them.
Step 14: The Multi-patch Media settings indicate the starting file sequence and disk ID numbers as well as the volume label for the .MSP and the prompt that displays when the application needs to be repaired. Again, please view the online help by pressing F1 on the Compile Patch dialog for more information. Note that the Volume Label on this dialog must match the volume label on the CD or other write-protected media that distributes the patch. Click Next on the Compile Patch dialog to continue the patch creation process.
Step 15: The Patch Creation tool begins creating the patch. A dialog might appear, saying “ProductCodes between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop. Another dialog might appear, saying “ProductVersions between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop.
Step 16: When the Patch Creation tool has finished creating the patch, the Compile Patch dialog says Patch creation completed and has a View Log button. Click View Log to view the patch creation log, or click Finish to close the Patch Creation tool.
Here’s a great reference if you want/need to learn some Windows Installer concepts and best practices. This document is very useful to individuals who are starting to do application packaging
http://www.microsoft.com/technet/community/en-us/management/msi_faq.mspx
Here’s a fantastic document by Richard on “how to interpret Windows Installer logs”. This is a very essential and a noteworthy bookmark for every packager and administrator. Especially, Don’t miss the Annotated Verbose Installer Log section; it has a pdf file, which contains a log file generated on Vista.
Special Thanks to Richard Mc Donald for this wonderful Document!
When you need to troubleshoot a failing install, it is often useful to use the policy hive rather than the command line to catch things like repairs and multi-package installs. The Windows Installer Log comes in very handy in this case. The log can be generated 2 ways (Other than the usual Msiexec <misname> /l*v c:\testlog.log).
1. Registry Key
Start Registry Editor (Regedt32.exe), and then create the following path and keys in the registry:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Create keys:
Logging : voicewarmupx
Debug”=dword:00000007
The letters in the value field are the options that are available to use with Windows Installer logging. You can use the options in any order. Each option turns on a specific logging mode. The function of each option is as follows:
v – Verbose output
o – Out-of-disk-space messages
i – Status messages
c – Initial UI parameters
e – All error messages
w – Non-fatal warnings
a – Start up of actions
r – Action-specific records
m – Out-of-memory or fatal exit information
u – User requests
p – Terminal properties
x – Extra debugging information.
+ – Append to existing file
! – Flush each line to the log
* – Wildcard, to log all information except for the v option. To include the v option, specify *v.
It is recommended that you use this service only for troubleshooting. Leaving the service turned on creates a new Msi*.log file every time you use the Add/Remove Programs tool in Control Panel. This activity adversely affects system performance and disk space.
2. Modifying Group Policy
You can use Group Policy to enable logging by modifying the appropriate organizational unit (OU) or Active Directory Group Policy:
Click Start, and then click Run.
In the Open box, type gpedit.msc to start the Group Policy Editor.
Expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Installer.
Double-click Logging, and then click Enabled.
In the Logging box, specify the options for what you want to log.
After the installation\UnInstallation of the package check in %temp% for log files starting with MSI (eg.MSI8758d.LOG).
Here are few points which would prove handy while re-packaging an application for Vista / Windows 7.
1. If you must make a change on the system via a custom action, ensure that the custom action is deferred and the msidbCustomActionTypeNoImpersonate bit is set. This will ensure that the custom action inherits elevated privileges from the installed
2. Place all your custom actions in the Execute Sequence to ensure that they are invoked during silent mode and use appropriate conditions on the custom actions to only run when intended
3. Test your application for a locked down user. If necessary, give the user permissions to access folders and registry keys that the application tries to write to via the Locked Permissions table. Do not open higher level folders such as C:\Program Files, C:\Windows or C:\Windows\System32 for locked down users. Instead, set permissions on the exact sub-directory that the application needs access to:
4. AdminUser property commonly used to check for admin rights will not work in UAC. Microsoft has decided to set this to TRUE by default for Application Compatibility reasons. Use MSIUSEREALADMINDETECTION property instead.
5. Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.
6. Turn off Virtualization feature. This will ensure that, duplicate files and registries are not created. This mainly happens to the applications which need a launch. The keys which are virtualized can be removed from the package as well.
7. Add support for Vista-specific features 🙁 This can be found in the “Windows Installer Options” dialog of Installation expert in WPS 7.0)
a. Disable the User Account Control (UAC) prompting for standard user installations.
b. Set options for Restart Manager.
8. Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.
9. Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application’s primary functionality.
10. Remove all WRP components from the MSI package. If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:
a. Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.
b. Isolate the protected file so it is installed to a different location.
11. Fix installation-related errors that you find while performing installation and functionality tests.
12. Make other changes that are not related to Vista but are required as Customers standards.
13. Resolve CA’s which involved Nested Installation. This will throw an error while deployment.
14. Impersonation should not be used when running setups on Windows Vista. Edit the custom action and change its In-Script Options property to Deferred Execution – System Context. Test to verify that the custom action runs in this context.
15. Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions
16. Any property beginning with MSI cannot be used. Hence avoid using the same.
17. Components cannot have a dummy GUID; it’s a best practice to generate one.
The Windows Installer has many built-in actions for the installation of applications. However, when a packager of an installation package finds it necessary to write a custom action. There are some best practices which have to be followed for optimal execution.
- Custom actions that use sensitive information should not write this information into the log.
- Custom Actions must not attempt to set a System Restore entry point from within a custom action.
- Return error messages from custom actions and write them to the log to facilitate troubleshooting custom actions.
- Do not change the system state from an immediate custom action. Custom actions that change the system directly or call another system service must be deferred to the time when the installation script is executed.
- Every deferred execution custom action that changes the system state must be preceded by a rollback custom action to undo the system state change on an installation rollback.
- Custom actions that perform complex installation operations should be an executable file or dynamic-link library. Limit the use of custom actions based on scripts to simple installation operations.
- Make the details of what your custom action does to the system easily discoverable to administrators. Put the details of registry entries and files used by your custom action into a custom table and have the custom action read from this table.
- A custom actions should not display a dialog box. Custom actions requiring a user interface can use the MSIPocessMessage function instead
- Custom actions must not use any of the MSI functions like,
MSIApplyPatch
MsiEnableLog
MSIReinstallfeature
MSIVerifyLog etc… - If the installation must be capable of running on a Terminal Server, test that all your custom actions are capable of running on a Terminal Server.
- To have a custom action run when a particular patch is uninstalled the custom action must either be present in the original application or be in a patch for the product that is always applied.
- Custom actions should not use the UI level as a condition for sending error messages to the installer because this can interfere with logging and external messages.
- Use conditional statements to ensure that your package correctly runs custom actions, does not run custom actions, or runs alternate custom action when the package is uninstalled.
- Test that the package works as expected when uninstalling custom actions.
If the installation must be capable of being run by users that do not have administrator privileges, test to ensure that all the custom actions can be run with non-administrator privileges. - Custom actions require elevated privileges to modify parts of the system that are not user specific. The installer may run custom actions with elevated privileges if a managed application is being installed or if the system policy has been specified for elevated privileges. Any custom actions the require elevated privileges must include the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate Custom Action In-Script Execution Options in the custom action type.
If you repackage an installation with any version of Installshield AdminStudio, and when you try to validate it, you will most certainly see..
ICE33 – This ICE is caused by the fact that repackager adds COM related information into the registry table as supposed to the Microsoft recommended Class ID, Prog ID and Type Lib tables. This Error can be safely ignored as the application should work properly as your com information will be registered via the Registry table.
ICE64 – This ICE warns about directories created under the User Profile folder not being specified in the RemoveFile table. So for example if your msi package contains [AppDataFolder]mydir or [PersonalFolder]mysubfolder, ensure that ‘mydir’ & ‘mysubfolder’ are specified in the RemoveFile table. Doing so will ensure that they get removed at uninstallation time.
ICE57 – If you have a component in your msi package that contains both per-user & per-machine data e.g if the component is installing a file to [AppDataFolder] and also contains a registry key being installed under HKLM. you can expect to see this Error/Warning. The ideal thing to do is separate User data from machine data into separate components. Anytime you have a component that is installing to a User Profile directory, make sure that the component does not contain a key file. This component should instead have a key path. This component should contain a registry key under the HKCU hive, set as the key path. If your msi package does not contain any registry keys under HKCU hive, create a dummy key to ensure that your user profile data is installed properly for subsequent user logging on the machine.
ICE50 – This ICE usually occurs when your installation tool is unable to extract icon from the Icon file specified in the shortcut. Sometimes InstallShield Editor displays this error. The best way to work around it is to specify an Exe or different ico file in the shortcut to extract the icon from.
The basics of this feature is explained in the article Folder Virtualization Concepts in Windows Vista.
Impact in MSI Packaging
Files in a registry key can be found twice in your installation. Especially if the application has to be launched to customize options and settings.
Possible Work-around
During Setup-Capture:
Virtualized resources needs to be merged with the original files and the virtualized resources can be deleted from the installation resources. If file and registry virtualization is enabled on the default user environment, you will need to test the application with two different default user accounts. Check if resources from the application gets virtualized and that those contents will not affect the proper functionality of the application.
The best practice is to disable the file and registry virtualization. Microsoft does not guarantee this feature will be in future releases of Windows. If a file or registry key needs permission changes, use the LockPermission table or use a custom action to modify the related security descriptor of those resources. If the user has the permission to modify the resources, it won’t be virtualized.
It’s recommended to use the latest release of a product that supports Vista. Applications following the Microsoft development guidelines for Vista compliant applications, are modifying resources in the user profile where virtualization will not take place.