ConfigMgr 2012 and 32-bit Application Installers

Why are 32-bit application installers special and why do they need special handling? First, a caveat: If you don’t have any 64-bit OSes in your environment (or never will), then there is nothing special about them. I think I can safely say that no one using ConfigMgr 2012 falls into this category though.

On 64-bit Windows OSes, 32-bit applications are given their own directory to store application file, specifically Program Files (x86), and their own place in the registry to store data, Wow6432Node. 32-bit applications are transparently redirected to these locations by the OS – the application doesn’t even know that this happening. The end result is that a 32-bit application running on a 64-bit OS resolves things like the %ProgramFiles% environment variable as C:\Program Files (x86) and has all registry read and write requests for HKLM\SOFTWARE actually sent to HKLM\SOFTWARE\Wow6432Node. You can easily see this by opening the 32-bit command prompt from %windir%\syswow64\cmd.exe and typing echo %ProgramFiles%

or by opening the 32-bit regedit from the same location, adding a key to HKLM\Software (notice the lack of HKLM\Software\Wow6432Node), opening the 64-bit regedit, and verifying that key was in fact created in HKLM\Software\Wow6432Node.

The whys and hows of this along with more details can be found in MSDN and basically stems from the fact that 32-bit applications run in a Windows sub-system called WOW64 on 64-bit OSes. Here are some links to MSDN:

• 
  
  Running 32-bit Applications
  
  
• 
  
  Registry Redirector
  
  
• 
  
  File System Redirector
  
  

The above described redirection was a cause for some grief for ConfigMgr 2007 admins because the ConfigMgr 2007 agent (along with all of ConfigMgr 2007 itself), is a 32-bit applications and thus is subject to this redirection. Being redirected means that the ConfigMgr agent by default launches 32-bit versions of the command-prompt, cscript, regedit, and PowerShell (to name a few) which in-turn are also subject to redirection. There are various work-arounds including launching these from Sysnative or using a task sequence with a Run Command-line task which includes the option to disable this redirection for the specific command-line being run.

In ConfigMgr 2012, the agent is now natively 64-bit (on 64-bit OSes at least) and so this exact problem goes away; however, we still have to account for the redirection when defining application uninstallation command-lines and detections – the install command-line itself isn’t really affected by this though although depending upon exactly what the installer does, it could be affected.

As an example, lets create an application for Notepad++, a 32-bit application with an exe installer. As discussed in my previous post, ConfigMgr 2012 Application Deployment By Example: User EXE Deployment, you should always install an application on a test system first to verify its behavior, gather its uninstall string, and determine a method to detect installation. Note that for MSI based installations, this is optional because the Windows Installer engine actually provides uniform and consistent uninstall strings and detection methods that are derived from the MSI’s product code and can be directly extracted from the MSI without installing it – verifying good behavior of MSIs on a test system is still a good idea though. Also, in general, MSIs are unaffected by 32-bit vs. 64-bit differences so should not have to have anything special done for them – only testing will verify this though so once again, make sure you test everything you do before rolling it out into production or deploying it to the All Systems collection.

So, for Notepad++, here’s what I initially came up with:

• 
  
  Uninstall string: C:\Program Files (x86)\Notepad++\uninstall.exe /S
  
  
• 
  
  Detection: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Notepad++\DisplayVersion = 6.1.5
  
  

The first thing to note about the uninstall string is that the installer installed the programs to Program Files (x86) which tells us two things:

1. 
   
   The OS I installed Notepad++ on is 64-bit
   
   
2. 
   
   The installer is a 32-bit application and was redirected (this is also reflected by the registry value noted for the detection method)
   
   

Using this uninstall string will actually work fine as long as I test it and use it on 64-bit systems, but what if this runs on a 32-bit system? It will fail with a file not found error because Program Files (x86) doesn’t exist in 32-bit OSes.

There is a nice little option on the Programs tab of a Deployment Type that seems to indicate it should be used: Run installation and uninstall program as 32-bit process on 64-bit clients. And indeed, this option should be used here; however, it doesn’t completely solve our problem. Why? Because File System redirection isn’t really an automatic thing so the literal path including Program Files (x86) is used but it doesn’t exist on 32-bit OSes.

The answer is simple here though, replace Program Files (x86) with %ProgramFiles% in the uninstall command-line so that when the command is run on 64-bit OSes, it gets interpreted as Program Files (x86) and when run on 32-bit OSes, it gets interpreted as Program Files. Note that both things just mentioned are required, the option and the command-line substitution.

For the detection method, the only thing that is actually needed is to select the This registry key is associated with a 32-bit application on 64-bit systems option because registry redirection is automatic.

If you choose to use a File System detection rule, keep in mind that file system redirection is not automatic and so you may/will have to substitute %ProgramFiles% or Sysnative in the path for folders and/or files referenced in your detection rules as appropriate.

One last note: If you are cursed with managing OSes three versions and 10 years old; e.g., Windows XP or Windows Server 2003, Sysnative does not exist natively and must be added through the use of the method described in KB942589.