Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog
Showing posts tagged with Wise Packaging
Showing posts in English
R-Vijay | 07 Dec 2007 | 0 comments

The internal version number for Windows Vista is 6.0. The GetVersion function returns this version number. The problem is, some applications will return a higher version number. This means trouble. Learn how to steer clear, here.

Symptoms of OS Version

  • Applications that check for OS version will get higher version number.
  • Application installers may prevent themselves from installing the app and apps may prevent themselves from starting.
  • Applications may warn users and continue to function properly.

Mitigation Techniques for OS Version

  • For apps and installers that check for OS version, a Compatibility mode is provided in Windows Vista
  • Users can right right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the Compatibility tab. This applies multiple shims including "WinXPSP2VersionLie"
  • Better: Apply the shim "WinXPSP2VersionLie"
  • In many cases, applications...
WiseUser | 06 Dec 2007 | 1 comment

In Wise Package Studio there is a file section where the packager should be aware of "Controlling File Versioning Settings" when they place files in the package. There may be a situation where the user wants to overwrite a file or just ignore if the file is present. Here's how to deal with those situations.

Note: Text in "" represent "Variables" which can be used in "System Search" page of Wise Package Studio.
  1. Can be used to determine the OS (NT, XP, 2000...)

    Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
    Value Name: CurrentVersion
    Value: "4.0" for NT,
    "5.0" for Win2k,
    "5.1" for XP,
    "5.2" for Win 2003

  2. Can be used to determine the OS SP (SP2, 3, 4...)

    Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
    Value Name: CSDVersion
    Value: "Service...

WiseUser | 05 Dec 2007 | 0 comments

If you've created a package using Wise package studio, here's a way you can update a custom action using a patch.

You can update a custom action using a patch. If the custom action is included in the binary table, then simply update the custom action in the update installation image.

When you generate the patch between the original and update installation images, the patch will contain a database transform that will transform the old binary data stream to the new binary data stream.

WiseUser | 04 Dec 2007 | 0 comments

It is easy to determine if Windows Installer prompts for a reboot because it installed over a file that is in use. The first step is to generate a verbose log file. In the verbose log file, look for the presence of the ReplacedInUseFiles property in the property dump.

If this property is present with a value of 1, then the Installer will require a reboot because it overwrote an in-use file.

To determine which file was in-use, scan the log file for "Info 1603" and "Info 1903" messages. The 1603 message will be logged by the InstallValidate action. For example:

MSI (s) (DC:DC): Doing action: InstallValidate
Action start 19:55:42: InstallValidate.
Info 1603. The file d:\test\sample.exe is being held in use by the following process: Name: sample.exe, Id: 4068, Window Title: 'Sample'. Close that application and retry.

Normally, this message coincides with the presentation of the FilesInUse dialog box. In silent UI cases, this dialog...

R-Vijay | 04 Dec 2007 | 1 comment

You can detect the system language in a package by using the SystemLanguageID property present in the MSI.

In Wise Package Studio:

  1. Go to the Setup Editor view
  2. Click the Product tab
  3. Go to Launch Conditions
  4. In right panel, right-click New -> Launch Conditions
  5. Click Build button
  6. Enter SystemLanguageID = 1033
    Note: You can look at the WiseLanguage table in a WSI to get the details on the Language codes.
    1033 – English
    1036 – French etc..
  7. Click Paste and Ok
  8. In message text:
    This package was designed to install only on a English lingual system. Contact your administrator.
  9. Click Ok
R-Vijay | 03 Dec 2007 | 2 comments

Error 1720 is a generic Windows Installer error message which you get when there is a problem with a custom action script in the package.

To troubleshoot this error:

  1. Finish the install and look in the application log in the eventviewer. The eventviewer will have a warning with a source of MsiInstaller. This warning will often show you exactly where in the VBscript the error is.
  2. Log the MSI installer. You can activate logging with the following command line misexec /i pathtomsi.msi /L*v "pathtologfile.log". The log file will be created and added to as the install takes place. When the error occurs leave the error dialog on the screen and look at the log file. The end of the log file will contain the exact action that has caused the error. Look at the last MSI action to run without ending. This will be the action that is causing the problem. Often you can find this action in the CustomAction table (use Orca to open it up) and can fix any syntax errors or...
WiseUser | 26 Nov 2007 | 2 comments

Wise Package Studio ships with some very cool functionality that allows you to find differences in msi, mst, msm, wsi, and wsm file types. This spendid feature can be very handy when troubleshooting.

I've done some testing of my own (and snapped screen captures) to illustrate how to take advantage of this feature.

  1. Open Wise Windows Installer Editor and choose Tools -> Visual MSIDIFF
  2. Different file comparisons can be made between msi, mst, msm, wsi, wsm.
R-Vijay | 13 Nov 2007 | 5 comments

This tip will (hopefully) shine some light on the concept of performing a "Gap Capture".

Let's start with a simple equation:

So, basically, a Gap Capture is the difference between a Source Application and Captured MSI.

When do we do This?

You have done the setup capture but your MSI fails in Functionality Testing. One reason could be that some files or registry is missing in your package.

To capture the LEFT OUT entries, we need to do GAP capture.

How to do Perform a Cap Capture

  1. Install Captured MSI of the Application on your system.
  2. RUN Setup Capture and take the SnapShot.
  3. Install Source Application over it.
  4. Now finish the Capture (SnapShot of OS+MSI+Source Application)

What you've captured in the WSI is now a GAP Capture.

How to go About with These Entries

First re-build the machine and install your earlier...

R-Vijay | 12 Nov 2007 | 7 comments

If a file that should have been removed from the user's computer remains installed after running an uninstall, the installer may not be removing the component containing the file for one or more of the following reasons:

  • The msidbComponentAttributesPermanent bit was set for the component in the Attributes column of the Component table.
  • No value was entered for the component in the ComponentId column of the Component table.
  • The component is used by another application or feature that is still installed.
  • The key file for the component has a previous reference count under HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls.
  • The component is installed in the System folder and any file in the component has a previous reference count under HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls.

The installer does not remove any files that are on the Windows File Protection (WFP) list. If a component's key file is on...

R-Vijay | 09 Nov 2007 | 0 comments

Files in Use and Restart manager are two big features of Windows Installer 4. These features provide excellent support to MSI packagers when customizing an application which needs a restart for optimal functionality.

Files in Use:

Files-In-Use functionality is among the countless services that Windows Installer exposes for setup authors to leverage for their application install/maintenance. This functionality lets setup authors display the processes that hold on to files that would be updated by this install. The user would want to shut those processes before continuing with the install to ensure that the install wouldn't require a reboot.

The current Files-In-Use mechanism involves enumeration of the HKEY_PERFORMANCE_DATA key using registry API for information on processes and the PE images that they have held in-use. This works well in scenarios where the process holding the file in use has a visible window that the user can shut down.