|Supporting 64-bit: Using Registry Links On Your Corporate Software Tracking Registry Key|
|Written by Darwin Sanoy|
|Monday, May 23, 2011 12:45pm|
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:
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:
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:
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.