Windows 8 – Rumors and more from around the web

the official release of the developer build version of Windows 8 led to many concerns regarding the future of the “software deployment” as we know it.

This article should help you to address these concerns in a Q&A style:

Whats new in Windows Installer for Windows 8?

Regarding to Bob Arnson ( nothing signifant has changed in the Windows 8 Window Installer Header Files. The only major change seems to be the support of “ARM” as an Architecture Flag.

What is Metro?

Metro is the new ” typography-based design language” (Wikipedia) which will be featured on top of our well known windows desktop. It is basically an UI style & Application Framework which is optimized for Tablet PC’s.

Together with Metro Microsoft is introducing the new “Windows Runtime” which will be used together with those new Metro Style Apps.


Whats is AppX?

AppX is the new deployment/packaging format for Windows 8 Metro Style Apps. AppX Packages can only be deployed by using the Windows Store which will be introduced with Windows 8.

Enterprise Customers however will be able to sideload AppX apps (

Will AppX supersede Windows Installer?

No. AppX can only be used for deploying Metro Style Apps. Windows Installer will stay the primary solution for “classic desktop applications.”

Will there be any packaging software for AppX?

Probably not. Visual Studio 2012 already includes all required tools to produce an AppX Container/Package. Microsoft is trying to simplify the deployment process for metro style apps and did therefore e.g not include any sort of “custom actions” in it. The package creation is part of the development process in Visual Studio.


How to clear a pending restart

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

Wise Package Studio Versions

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:

Version Official Name Remarks Wise Package Studio 4.62 RTM Wise Package Studio 5.6 RTM Wise Package Studio 5.6 Hotfix 1 RTM Wise Package Studio 6.0 RTM Wise Package Studio 6.01 RTM Wise Package Studio 6.1 SP1 RTM Wise for Windows Installer 6.1 RTM Wise for Windows Installer 6.20 RTM Wise Package Studio 7.00 RTM Wise Package Studio 7.00 SP1 RTM Wise Package Studio 7.00 SP2 RTM Unknown Internal Build Unknown Internal Build Wise Package Studio 7.00 SP3 RTM Wise Package Studio 8.00 RTM

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


SVS/SWV: Non Virtual Application may perform very slow while at least 1 virtual layer is active


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.

Whats new in Java Runtime 7

What’s new in Java Runtime 7 – from a Software Packaging or Administrator point of view?

This can be answered quite short: Nothing as been changed, the new version is based on the previous installation technology with the same limitations as know.

Here are the most important details about Java Runtime Environment 7

1. A silent repair is still not supported (uninstall and install has to be done) see our bolg for more details.

2. The previous JRE 6 version will not be uninstalled when installing the new JRE 7 version, but version 7 will be the default runtime

3. The new features of Java 7 or read the change log that can be found in the internet

4. Use ‘java -version’ on a command prompt to display the default JRE version and build

5. At last but not least, this package is available as Direct Package Download, a service from Ontrex SPA. DPDs are fully automated software packages that can be deployed with any software deployment systems.



How to repackage a NDIS driver

Several months ago I met a new challenge in shape of a device driver I’ve never seen before called…

NDIS – Network Driver Interface Specification.

I dont want to loose much time with talking about the “driver type” itself, because you can get all information from a well written wikipedia article.

Such a driver usually consists of the very typical driver files:

Inf File, Cat File & Sys File. Everything signed as you might expect of course.

My first attempt was to install the driver the “Ontrex Best Practices” way which usually means either to use the difxapp merge module or the dpinst.exe executable (custom action).

Unfortunately, none of them led to to same result as the original package had behave.

After googling around a bit I finally came to the tipping point: netcfg.exe

This executable is present on every windows at least since windows 2000 and basically helps you to automate any “Network Card” related installation tasks like

– Installing/servicing/uninstalling Network Protocols (e.g. Internet Protocol Version 4 (TCP/IPv4)

– Installing/servicing/uninstalling Network services (e.g. QoS Packet Scheduler)

– Installing/servicing/uninstalling Network Clients (e.g. Client for Microsoft Networks)

Kindly asked the program offers me the following command line parameters:

So the last missing information in the puzzle is how do I know the component id for my driver?

Solution was simple: I had installed the original package and searched through the registry  using the INF Filename and this offered me the following result:


Now I had all required information to schedule a custom action in my package to install the driver.

Because netcfg.exe is already on every windows installation I used the type “Execute Program From Destination” (MSI SDK: Custom Action Type 34)

[System64Folder]netcfg.exe -l “[#netlwf.inf]” -c s -i BNNS_NdisLwf

In our case the target operating system  was a x64 OS and therefore we needed to specify the [System64Folder].

Because the action changes the system state it logicaly belongs to the “deferred” installation sequence.



Ontrex Best Practices Part II – ProductVersion

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:

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 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! 🙂






SPA Blog goes international

The Ontrex SPA Team is proud to announce that our future Blogs will be authored in English as the growing amount of visitors are from international destinations.

This is our first step to provide our technical know how to a wider audience.

We also would like to introduce our offical Ontrex SPA Twitter Account:

Feel free to follow us. we are looking forward to interesting discussions about packaging, software virtualization and other related subjects in the twittersphere.

Yours Sincerely,

Ontrex SPA Team





Why you should keep your Cabinets outside the MSI

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.






The module failed to load

Neulich bei einem Regsvr32.exe /silent Aufruf einer DLL Datei wurde folgende Fehlermeldung (obwohl der Silent-Paramenter verwendet wurde) ausgegeben:

The module xyz.dll failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line systrace.exe tool for more detail.

Eigentlich dürfte dieses Fenster nicht erscheinen, da der /silent parameter verwendet wurde.

Man sollte sich auch nicht durch die side-by-side configuration in die Irre führen lassen und einfach den guten alten Dependency Walker verwenden.

Der Depency Walker zeigt die fehlenden Komponenten an, welche vor der Registration auf dem Rechner vorhanden sein müssen.

Es geht auch Stück für Stück mit dem Event-Log, der in einem Error Eintrag die benötigte DLL anzeigt.

Kurz gesagt, neue Meldung, altes Problem