Category Archives: Uncategorized

(this is an english rewrite of the popular german article “Zusätzliche Special Folders”. However it includes some new findings regarding this topic)

The windows installer technology provides the most frequent needed special folder directory properties out of the box.

However sometimes you need to reference a directory which isnt directly supported (yet).

The following VBScript uses the “Shell.Application” object to get the actual path of the requested special folder. (in our example for “CSIDL_COMMON_DOCUMENTS”)

Insert this action as ““Call VBScript From Embedded Code” Action directly after “CostInitialize” in both “User Interface” and “Execute Immediate”.

Const CSIDL_COMMON_DOCUMENTS = &h2e

Set objShell = CreateObject(“Shell.Application”)

Session.Property(“ONTX_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path

Set objShell = nothing

Afterwards, insert the following line into the directory table:

Bear in mind to add all those properties into the “SecureCustomProperties” Property.

You may use then this property as any other known directory property (eg. SystemFolder, ProgramFilesFolder)

By following the link at the end of the article you will get all known CSIDL’s which can be used for this script.

Continue Reading

Symantec has entered a partnership with Flexera Software, introducing a new solution, “AdminStudio for Symantec”, based on Flexera’s industry leading technology.

Flexera AdminStudio for Symantec includes integration with Symantec technologies and full support for all of the latest Windows operating systems and installation-related technologies, including the ability to capture both 32-bit and 64-bit applications. In addition, AdminStudio Virtualization Pack, an optional add-on pack, offers advanced packaging support for the application virtualization technologies from Microsoft (App-V), VMware (ThinApp) and Citrix (Xen App).

A Wise Package Studio 8.0 maintenance release is planned for late 2011 or early 2012. The release is expected to include critical bug fixes, and 64-bit support for the WiseScript Editor and SetupCapture tools. Flexera plans to add the enhanced WiseScript Editor to AdminStudio for Symantec and will continue to develop and support the tool going forward.

Therefore as of November 7, 2011, all versions of Wise Package Studio and the Wise Connector, including any Maintenance Packs and/or patches for each version, in all released languages will reach their End of Life (EOL).

Please visit www.wise-migration.com for more details!

Regards,

SPA Team

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.

During packaging a very common software we ran against the problem that SetupCapture did not capture all files in the installation.

After some investigation we found out that WPS exludes *.swp and other file extensions per default. This however may lead to incomplete snapshot results.

We therefore recommend to remove any file extensions entry from your SetupCapture Configuration which apply to ‘all directories’ :

However if you dont want to exclude those entries permanently you may include them on a per snapshot basis on the “SetupCapture Exclusions” screen.

Mit dem Release des Service Packs 1 für Microsoft Application Virtualization 4.6 sind auch einige neue technische Artikel im Web erschienen.

In diesem Artikel fassen wir die wichtigsten zusammen:

• Login Consultants releases App-V Client ADMX 1.0
  
• Get your App-V Package Accelerators here
• Known issues with Microsoft App-V 4.6 SP1
• New KB: Guide to sequencing .NET 4.0 with App-V 4.6 SP1
• Diagnostics in the App-V 4.6 SP1 Sequencer

Das offizielle “Changelog” von Microsoft kann sich unter folgendem Link ansehen:

• About Microsoft Application Virtualization 4.6 SP1