It is a common practice to have a corporate software registry key for tagging software installations that were performed by an official company prepared package.  Many times these keys are stored under HKLM\Software.  On 64-bit Windows this registry key is different for 32-bit and 64-bit applications - but it doesn't have to be!

When a 32-bit application reads or writes to HKLM\Software\InstalledPackages, the registry data will actually be retrieved from HKLM\Software\Wow6432Node\InstalledPackages.  64-bit applications working with the same registry key would read or write this data to HKLM\Software\InstallPackages.  

By default all MSI packages will be processed as 32-bit (see this previous article) and all scripting engines (.CMD/.BAT, .VBS, .PS1) default to 64-bit execution (even if started by 64-bit processes).  Most software distribution and inventory systems will run 32-bit services for quite some time - so they sould find this key as written by 32-bit proceses.  However, some managements system, though 32-bit, can be told to access the 64-bit registry (e.g. SCCM Task Sequences).

It would be ill advised to change all MSI packages to 64-bit simply to write one 64-bit registry key.  Updating and accounting for this difference throughout all scripts, packages and infrastructure is a tedious and trial and error process.  If we could fix it so that they registry kept the same data for both of these key locations, we wouldn't have to change a bit of the infrastructure.  It would also allow existing scripts to work on 32-bit XP, 32-bit Windows 7 and 64-bit Windows 7.  If you're looking at long period of co-existence between 32 and 64-bit Windows, having one set of scripts is extremely helpful.  The best practice of supporting all possible platforms with the lowest impact and maintenance is a defining approach in our new course day CSI-330 Provisioning and Supporting Applications on 64-bit Windows.

The registry supports creating the equivalent of symbolic links.  Two completely different registry keys can point to the same registry data.  Updates in one are seen in the other.   This is NOT the registry reflection technology that was in 64-bit XP (and removed in 64-bit Windows 7) which COPIED data between keys.  This is simply two registry keys both pointing to the exact same data - so changes are instant.  This ability has been used in the core OS for years - for instance the "CurrentControlSet" registry "key" is really a link to the CurrentControlSet1.  In 64-bit Windows, many keys are linked (Microsoft calls them "Shared") in order to enable WOW64 for present the same registry keys to 32-bit and 64-bit applications.

Let's summarize the benefits of this approach:

• Allows the same scripts and infrastructure to be used for 32-bit XP, 32-bit Windows 7 and 64-bit Windows 7.
• Does not require changes to any existing scripts.
• Does not require changes to the existing registry key location for storing Installed Packages.
• Can be implemented after you have already had 32-bit applications write to HKLM\SOFTWAREWow6432Node\InstalledPackages.
• Can be implemented as part of initial workstation build.

A free utility called regln-x64.exe is required to create registry links - download infomration is at the end of this article.

Let's review the following shell script to learn how to do this:

REG ADD "HKLM\Software\Wow6432Node\InstalledPackages"
REG FLAGS "HKLM\Software\Wow6432Node\InstalledPackages" SET DONT_VIRTUALIZE DONT_SILENT_FAIL
regln-x64.exe "HKLM\Software\InstalledPackages" "HKLM\Software\Wow6432Node\InstalledPackages"

The first line uses the built-in reg.exe utility (built-in as of Vista) to create the registry key.  If it already exists, the command generates a warning and continues - so there is not need to test if the key exists before attempting to create it.

The second line is good housekeeping that prevents the key from ever being UAC Virtualizated.  Although the likelyhood of UAC virtualization is low, this step completely eliminates it.

The third line uses regln-x64.exe to link HKLM\Software\InstalledPackages to the real key under Wow6432Node.

A couple words of caution:

• If you need to test the script a couple times, the old link wil have to be removed using "regln-x64.exe -d "HKLM\Software\InstalledPackages" - it cannot be deleted with regedit or REG DELETE and it will cause an error if left in place for the next test run.
• You cannot link multiple new levels with regln.  So if your software key is under HKLM\Software\CompanyName\InstalledSoftware", you may want to create the link at the "CompanyName" level - which would shard all subkeys (potentially an entire subtree).  If you explicitly wanted to prevent sharing other keys that are peers to "InstalledSoftare" then you would create a real key "CompanyName" at the HKLM\Software level with REG ADD HKLM\Software\CompanyName right before regln.  Of course, the regln command would be updated to reflect the new subkey as well.
• The quotes around reg key names are there incase your choosen key has a space in the name.

This solution, as well as a lot more cool stuff, is included in our new course day CSI-330 Provisioning and Supporting Applications on 64-bit Windows.

Get regln-64.exe