In some rare cases a vendor setup checks for a pending restart.

During setup capture this will bring a lot of junk into a snap-shot, so the question will be, how can I clear a pending restart in order to install the vendor setup without doing a reboot.

The following registry will is the root of the problem. Renaming the key or clear out the value will solve this issue.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetContro lSession ManagerPendingFileRenameOperations

Ever wondered with which version of Wise Package Studio a msi has been built?

For this reason we have setup a comprehensive list of all known Wise Package Studio builds since 6.0:

The Version used to compile the MSI will usually be saved in the “WiseEditorVersion” property:

Symptom

A software package which is non virtual may perform very slow.

Solution / Workaround

Even non-virtual application are being redirected through the SVS/SWV Filesystem Minidriver while at least 1 virtual layer is active on the system.

This may significantly slow down applications with many registry/file system I/O operations. (e.g bad performance at startup)

To work around this issue you can add those application to the SVS Program Ignore list which you may find at the following location:

HKLMSystemAltirisProgramIgnoreList (REG_MULTI_SZ)

However bear in mind that those applications will no longer see any virtualized resources.

Our Ontrex Best Practices series continues with a very underestimated topic.

We are talking about the ProductVersion Property today.  As many of you already may know the property has to be formatted as follows:

major / minor / build 255.255.65535 (Source: http://goo.gl/Dj3l2)

Usually when we are repackaging we try to adapt the original Product Version as good as possible. But Unfortunately sometimes the vendor’s intended product version does not really fit in this schema which causes several problems like

• Not possible to take over the version at all (eg. 2010.10.10) because it simply doesnt fit into the maxium values of 255.255.65535
• They only increment the fourth field which is simply non-existent in Windows Installer
• They add some strange leading zeros into some fields (Why?)

We have now enforced some general guidelines regarding this to encounter any problems which may be caused by those strange vendor habits:

1. We only keep the first three  fields of any original product version (e.g 10.3.181.14 becomes 10.3.181), Major Upgrade is still possible (however limited) but causes an ICE error. Joining 2 fields together is strictly forbidden.
2. Leading zero’s have to be eliminated from any field (e.g 1.09.10 becomes 1.9.10)
3. Any non fitting Product version will be resetted to 1.0.0 (eg. 2010.23.1)

To conclude my blog article i really want to appeal to all developers out there:

Please try to adapt the windows installer product version schema. And avoid, at all costs, having only incremented the fourth field for any reasons. The fourth field should, if present, be used as build number only.

Therefore my recommendation for a versioning schema is as follows:

Major Release(255) . Feature Enhancements (255) .  Bugfixes / Patches (65535) . Build Number (Unrelevant and ignored by Windows Installer anyway)

And, of course, do not use any kind of date for the versioning schema! 🙂

At first most customers insist of keeping the cabinet files inside the Windows Installer Database.

It may sound reasonable for the time being because you have to deal with lesser file count, but if you have a deeper look into the windows installer mechanics you will soon see some big disadvantages.

Its faster!

When deploying/installing/repairing a msi file/installation with multiple cab files it will be much faster than with only one file. Why? Its simple: Only the required cabinet files will be accessed and this results in less file i/o & less traffic (network share)

It will be cached from Windows 7 onwards

As many of you already may know microsoft introduced a new caching behaviour with Windows Installer 5.0.

Due to signing/certification issues cabinet files will no longer be stripped out before being placed into the Windows Installer Cache directory (C:WindowsInstaller).

This results in much more useless occupied disk space by Windows Installer Packages which are mostly cached anyway by the Deployment System.