New DPD Package: Putty Suite

We are proud to announce the newest software package in our “Direct Package Download” portfolio.



Putty is a free and open source lightweight SSH and Telnet Client and currently our customers favorite choice for terminal emulation.

You should be able to order your DPD package from your personal SPA Portal Account as from now!

If you have any further queries please do not hesitate to contact us.


SPA Team

The future of Public User Folder

Since Microsoft did bring the Public User folder to its operating system a Software Developer has officially two locations available to install
files for all users for editing pruposes. But there is one big difference that will make one of them obsolete for the future.

First Location – Old school location %ALLUSERSPROFILE%

Default Location: C:ProgramData<Vendor><Product>

Second Location – The youngest %PUBLIC% location

Default Location: C:UsresPublic<Vendor><Product>

The Big Difference since Windows Vista

An application is usualy executed with standard user rights, therefore the Program Files folder is not a location to creating or modifying files.
In fact the Public and All Users folders are used when a central location for create/modify files aktion for an application is needed. 

But did you know that files created in All Users folder can not be modified by a second user? That’s right you can test it easily by creating a file in All Users folder and then try it to modify it with another user account with standard user rights – it will not be possible to overwrite it because only the creator/owner of the file has change/full rights. In fact this is not  well known, as all users will be able to create new files, but modifying a file with another user account is not possible.

How ever this behaviour is valid for Windows Vista and newer Windows Operating systems but not for Windows XP. In Windows XP there is no location available that would make it possible to modify a file for all users. In Windows XP you have to use a tool like SetACL.exe or using Flexera InstallShield – Application Data – Files and folders View

In Files and Folders view you can edit the permissions for Files and Folder. The following setting will make it possible that all ‘Users’ will be able to modify the files in All Users location.


When using InstallShield Editor make sure that Locked-Down Permissions are set to Custom InstallShield handling:


The Public folder instead will also allow you to modify the files created by other users, and this fact will make the All Users folder obsolete for the future. If you are a software developer, the public folder will be your preferred location for files that needs to be modified by all users without modifying the operating systems standard security settings.


SPA Team

App-V 5.0 Service Pack 1 is available

Microsoft has released, somehow very quietly, the first service pack for App-V 5.0.

The newest version can be obtained from the recently released “Microsoft Desktop Optimization 2013” DVD which is now available from different sources (PartnerNet, MSDN, Technet)


Change & Release notes:



SPA Team


How to disable auto updates for Google products

Google Updater (Omaha) is a background program/service which keeps all installed Google products up to date. 

The Google Updater can be disabled for all Google Products by adding 2 Registry Keys:

Name Values Description
InstallDefault Disallow
Specifies whether Google software can be installed using Google Update/Google Installer.
UpdateDefault Disabled
Automatic silent updates
Manual updates only
Specifies how Google Update handles available updates.

If you want to deactivate the Google Updater for a specific Google product, use the following Registry Key:


The GUIDs can be found in the following table:

Product GUID
Chrome {4DC8B4CA-1BDA-483E-B5FA-D3C12E15B62D}
Earth {74AF07D8-FB8F-4D51-8AC7-927721D56EBB}
Earth Pro {65E60E95-0DE9-43FF-9F3F-4F7D2DFF04B5}
Earth Plugin {2BF2CA35-CCAF-4E58-BAB7-4163BFA03B88}

The GUIDs may change in the future. Keep yourself up to date by downloading the current ADM File which contains the corresponding GUIDs: Download.


SPA Team

ICE27 Error Unknown Action: MsiConfigureServices on AdminStudio 2012 SP2

The newest .CUB File from Admin Studio 2012 SP2 contains an error. As you can see if you validate a MSI Package:


 This error message is not really an error from the validated MSI and can be ignored but it’s not very beautiful to get this error on every validation.

There is only one new line needed inside the CUB File (which contains the validation rules) and it can be fixed very fast:

You need the actual darice.cub file to modify the validation rules, this file can be found here:

“C:Program Files (x86)InstallShield2012SpringSupportValidationdarice.cub”

Open this file with a standard Windows Installer Editor (Insted or Orca) and go to the table _Action. Add a new row into this table with the following options:


Action: MsiConfigureServices
SectionFlag: 8
Prohibited: 31
Required: 0

Save and close the darice.cub file.



You should no longer receive  this validation error.


Windows 8 SDK (contains newest Windows Installer SDK 5.0)

The newest darice.cub, where this changes are already applied, is also available on the following page:

Download the SDK and install the newest Version of Orca. You will find the darie.cub inside the main installation folder. Replace this one with the old validation file inside the InstallShield Directory.


SPA Team


Lets talk about Ghost Repair

A side effect of Windows Installer Entry-Points can cause the Windows Installer to repair an application that was not even target to be run from the launched process.


If the event log shows a warning about an application that has not been launched then this article could bring some light into the dark.

A ghost repair will be started by a process that in general uses a com object like an activex object.
The binary file of this object has been installed by a windows installer based setup (MSI).
In this article I did decide to show a ghost repair based on the following windows scripting host file:


The following diagram explains in short the ghost repair in a simple way:



1. A process will call a com object in this case it’s a windows scripting host file
2.  cscript.exe is executing an activex object
3. The Dll-Loader will now handle the registry read request to inizialize the ocx or dll file
4. In the registry the HotInstaller.HotCom Programmatic Identifier will be read in order to get it’s CLASS ID
5. In the registry the InprocServer32 will be read from the related CLASS ID
6. The Dll-Loader process is detecting an InprocServer32 value in InprocServer32 Key that holds a DarwinDescriptor
7. The DarwinDescriptor holds Windows Installer Details: ProductID, Feature that Installed this file, ComponentCode
8. Enumerates all related Windows Installer Features (Feature in DarwinDescriptor and all it’s parent Features) and checks all compontents key-pahts of the enumerated features for it’s existance
9. If a key path is missing, the ghost repair will repair the product that was hold in the DarwinDescriptor.
10. If everything is fine, the Key-Path of the component found in the DarwinDescriptor will be loaded into the memory
11 and 12. cscript.exe is using the activex object that is now available in the memory

Some technical details

Point 6. where the DLL-Loader detects the darwin descriptor – this value will be genereated by using the Class table:

After running the setup, the class entry will show an additional key with the name InprocServer32 and it’s value will hold ProductCode, Feature and ComponentCode from the Windows Installer based setup.

Point 8 – checks component key paths for it existence – this is the point where the Setup Design of the installed product will cause the ghost repair. In most cases it’s the combination of Current User Registry Keys and a shared component based on COM technology. Installations where ressources in a flat feature structure are installed will cause a ghost repair because all key paths of the target feature and parent features will be checked for its existance. If one key path is missing, the windows installer will start a self repair process.

This is a simple flat feature setup desing that is able to cause a ghost repair.


How to fix the ghost repair issue:

There are muliple ways to fix this issue.

The most common way to fix this issue is to enhance the setup design with shared component awareness. Separate the shared components into a new root feature.


Another way would be to delete the darwin descriptor from each operating system that is target of the issue.

1. Deleting the InprocServer32 key with the darwin descriptor value will 2. fallback the DLL-Loader to the standard initialisation way without windows installer technology


This may only be a workaround, as a repair or reinstallation of the product will recreate the darwin descriptor.

Hotfix Package 1 for Microsoft App-V 5.0


Microsoft has released its first hotfix for their Application Virtualization Technology.

The hotfix package addresses several issues and can be obtained directly from microsoft here:

The patch must be applied to the client installation or can be slipstreamed into the original installation.

we will be happy to assist you in any matters if you need technical advises or any support regarding this information.


SPA Team

Ontrex User Group Meeting – Software Packaging für Windows 8 Presentation


for those who have missed the Ontrex user group meeting we are able to provide you with the slides of our presentation about windows 8 (however only available in german slides):

Continue Reading

Microsoft App-V 5.0


We are glad to hear about the general availability of APP-V 5.0 RTM.

The Ontrex SPA is already prepared for this major upgrade and is happy to be able to offer you various services regarding APP-V 5.0 which includes but is not limited to:

Migration Services (from earlier APP-V Versions), Consulting Services, Trainings and of course our matchless software packaging services.

Source: App-V 5.0 RTM now released!

Frequent x64/x86 traps

Today i want to take care of some very frequent traps regarding x86/x64.


The question is usually very simple: Which runtime architecture do i have to preinstall for my X86 Application on a Windows x64 Operating System?

For those who dont know what runtimes are ill give some examples:

  • Microsoft Visual C++ 2008 Redistributable
  • Microsoft SQL Server 2008 Native Client
  • Microsoft Core XML Service 6

Short answer: Usually you must match the applications architecture not the operating system ones!

But the exception proves the rule. Lets examine: “Microsoft SQL Server 2008 Native Client”:

When you actually try to install the x86 runtime on a windows x64 it will simply block the installation.

But why? i think microsoft wants to stop those confusing situation by creating packages which simply match the OS Architecture. So people dont have to care about the applications architecture.

Because if you look inside the x64 MSI you will see the following:

As you can see the x64 Installer also contains the x86 version of the SQL Native Client.

ODBC Data Sources  / Drivers

Another nightmare which leads to many inquires from our customers.

ODBC Data Sources & Drivers are seperate for each Architecture due to the Registry Redirection mechanism of “Windows on Windows64” (WOW64).

X86 Applications need x86 Data Sources / Drivers and x64 Applications need x64 Data Sources / Drivers.

In our opinion the biggest mistake microsoft has done is just to link to the x64 ODBC Administrator in the Control Panel despite the fact that the application landscape is still mostly x86.

To open you the x86 ODBC Administrator you must manually run:


Those entries will be used for native x86 application. Bear that in mind.