Video Screencast Help
Search Video Help Close Back
to help

Endpoint Management Community Blog

Showing posts tagged with Wise Packaging
Showing posts in English
Transitive Components in Wise Package Studio
WiseUser | 24 Sep 2007 | 1 comment

Transitive components are those which evaluate their conditions during repair/modify mode. The creator of the installation package specifies those components that need to be swapped out during a system upgrade as having the transitive attribute.

Learn more aobut these components (and how they can change your life, or not) here.

Let's take an example:

Component name: MYCOMPONENT
Condition on component: VARFLAG="TRUE"
Description: Installs a text file (mytest.txt for example) in Program Files\Test

Non transitive:

If this component was non transitive, it would evaluate the condition VARFLAG="TRUE" only at install time to determine if the file mytest.txt should be installed or not. Now, if you were to repair this package, the condition on the component is not evaluated and the...

Read more
Windows Installer's Rollback Script
WiseUser | 19 Sep 2007 | 4 comments

Windows Installer accomplishes rollback by creating a rollback script. A rollback script is a file that contains a linear sequence of operations to perform, such as file and registry updates, configuration information updates, user interface notifications, and state information for other operations.

Each operation recorded in the rollback script is a direct response to an operation in the installation script. Rollback scripts are stored in binary format.

This improves efficiency, avoids the need for parsing the file, and discourages manual editing of the file.

Rollback script files (.RBS and .RBF) are backups of existing files. Files with an .RBS file extension are rollback script files, and files with an .RBF file extension are backups of existing files. Both are stored in hidden folders called Config....

Read more
Custom Actions: Rules and Best Practices
R-Vijay | 17 Sep 2007 | 2 comments

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...
Read more
Running a Process as a Different User in WiseScript (RUNAS & Sanur)
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...
Read more
Windows Installer Public Properties used in Wise Package Studio Installations
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...

Read more
Applications that Shouldn't be Repackaged
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....

Read more
Points to Remember While Packaging
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 "...
Read more
Windows File Protection and the DLL Cache
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...

Read more
Why Does the Package Keep Reinstalling?
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...

Read more
Understanding the UPGRADINGPRODUCTCODE Property
WiseUser | 11 Mar 2009 | 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
Read more