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
WiseUser | 13 Sep 2007 | 5 comments

Here's the scenerio: You have a system file that needs to be installed to the System32 folder. And, you have several HKEY_CURRENT_USER registry keys containing configuration information.

This causes problems since the installation writes a file to the System32 folder, which is locked down for non-administrator users. Read on for the solution.

Here are your options:

  • Require an administrator to install the application. While this places the file in the System32 folder, the registry keys install with the administrator's profile rather than the end users.
  • Split the install into a per-machine and per-user installation. This creates two installations to track and requires the administrator to run each per-machine installation and each user to run the per-user installation.
  • Create one installation that...
WiseUser | 13 Sep 2007 | 1 comment

Public properties are differentiated from private properties by being listed in all capital letters. Public properties may be set on the command line (or in a transform file.)

Below are a list of standard public properties you may set. Keep in mind that vendors may also provide additional public properties specific to their applications.

TARGETDIR
Used as the location to copy the Installer installation package during an administrative installation.

ALLUSERS
Determines where configuration information will be stored.

ARPCOMMENTS
Provides Comments for the Add/Remove Control Panel.

ARPCONTACT
Provides Contact for the Add/Remove Control Panel.

ARPNOREPAIR
Disables the Repair button in the Programs...

R-Vijay | 12 Sep 2007 | 29 comments

Existing MSI packages should be deployed as they are. If customization is necessary, a Transform (MST) file should be used to introduce that customization. If you repackage an application and find that it references the MSI.DLL file, it is better not to repackage the application. Microsoft Office 2000 and XP are good examples. These applications are hard coded to use the Windows Installer service, and may make calls back to certain locations within the original MSI package.

Applications containing system files managed by the Windows File Protection features of Windows 2000 and later are also to be avoided, such as Internet Explorer, Windows Service Packs and certain hot fixes. For these, a provided MSI or command line installation is your best bet.

Repackaging certain types of applications is not recommended. These include:

    ...
R-Vijay | 12 Sep 2007 | 5 comments

Here are some rules I picked up through my time spent packaging software.

I live by them. Your mileage may vary.

  • Don't exclude any file from Setup capture Inclusion List.
  • Keep the default directory immediate to the Program Files.
  • In Merge module dialogue, uncheck all the merge modules and proceed.
    Adding Merge module should be done to a particular feature, but modifying or deleting have to done keeping all features into constraint.
    WFP Files will never be replaced.
  • When assigning key Path, avoid keeping it as ODBC, Its preferable to have it as a File Key path.
  • When a key path is missing for a component, it turns to be a broken component.
  • It's preferable to use installation expert to delete the file.
  • Always create a "shared" folder in local directory, to have the...
WiseUser | 12 Sep 2007 | 4 comments

Windows® File Protection (WFP) prevents the replacement of essential system files installed as part of Windows. Applications should not overwrite these files because they are used by the system and other applications. Protecting these files prevents application and operating system failures.

Protected File List

WFP protects files with the following extensions that are installed by Windows: .dll, .exe, .ocx, and .sys. In addition, the TrueType fonts Micross.ttf, Tahoma.ttf, and Tahomabd.ttf are also protected.

At the end of the Windows installation, WFP runs a scan of all protected files to ensure they have not been modified by applications installed through unattended installation. WFP also copies verified versions of these system files to the cache directory. When an application attempts to replace a protected file, WFP...

WiseUser | 11 Sep 2007 | 3 comments

Have you ever had a package that always goes for self heal? If so, here are a few points to check ...

If a key file is found to be missing on launch, Windows Installer will trigger a reinstallation of the parent feature. Having a "clean" package is key.

To find out just what the problem is, look in your Application Event log. Or for more detail, turn on Windows Installer logging and search for the word "error" in the resulting log file (found in %TEMP%).

Some common reasons why this may occur:

Missing Files or Registry Keys

Look closely- some files are deleted by the application itself. If your package contains such a file it will self-heal in order to restore the file each time.

Temporary Files Included In MSI

If any temporary files left on the system are captured in your package, they may cause self repairs to occur in order to restore them.

Correct Path for the components.

Sometimes the component will have a...

WiseUser | 06 Sep 2007 | 0 comments

The UPGRADINGPRODUCTCODE property is set by Windows Installer when an upgrade removes an application. The installer sets this property when it runs the RemoveExistingProducts action.

This property is not set by removing an application using the Add or Remove Programs in Control Panel. An application determines whether it is being removed by an upgrade or the Add or Remove Programs by checking UPGRADINGPRODUCTCODE.

You can condition custom actions that are sequenced after InstallValidate to handle major upgrades by using the UPGRADINGPRODUCTCODE property:

  1. If you want a custom action to run during an uninstallation of the product, but not during the removal of the product by a major upgrade, use this condition.
    REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE
    
    
  2. If you want a custom action to run only during a major upgrade, use this condition.
    UPGRADINGPRODUCTCODE
    
WiseUser | 06 Sep 2007 | 0 comments

Here's some useful information that explains how Windows Installer handles file replacement logic for versioned and unversioned files.

Hope it helps.

  1. In the case when the source and destination files are both versioned files, these rules are straightforward - if the key path file does not exist in the destination location or if it exists in the destination location and it is of a lower version, Windows Installer will install the component (and all of the files in it, including the key path). If the key path file exists in the destination location and it is of an equal or higher version, Windows Installer will not install the component but instead only reference counts the component. It becomes trickier when only one of the files is versioned or neither of them are.
  2. In the case when only one file is versioned, Windows Installer will install the component (and all of the files in it, including the key path file) if the...
WiseUser | 04 Sep 2007 | 0 comments

On Windows Installer 2.0 and later, you can prevent confidential information, for example passwords, from being entered into the log file and made visible. Read on to learn how.

  1. You can prevent the Installer from writing the property that is associated with an Edit Control into the log by setting the Password Control Attribute.
  2. You can prevent the Installer from writing a property into the log by including the property in the MsiHiddenProperties property.
  3. The Installer does not write information entered on a command line into the log unless the Debug system policy is set. To write command lines to the log, set the Debug system policy to a value of 7. This does not display properties included in the MsiHiddenProperties property or associated with an Edit Control that has the Password Control Attribute.
  4. The...
WiseUser | 31 Aug 2007 | 1 comment

Shortcuts not created (or 1909 error)?

Note that if a non-advertised shortcut doesn't get created at all (no message) or you get a runtime error "1909" it is possible that the "Target" parameter of the Shortcut was invalid (ensure you supplied the full path to it).