ConfigMgr 2012 and 32-bit Application Installers

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%

%ProgramFiles% from a 32-bit command-prompt

%ProgramFiles% from a 32-bit command-prompt

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.

New key in 32-bit regedit.exe

New key in 32-bit regedit.exe

New key in 64-bit regedit.exe

New key in 64-bit regedit.exe

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:

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.

Programs Tab in Deployment Type for 32-bit application installer

Programs Tab in Deployment Type for 32-bit application installer

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.

Registry Detection Rule in a Deployment Type for 32-bit application installer

Registry Detection Rule in a Deployment Type for 32-bit application installer

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.

ConfigMgr Folder Structure

Next Article

ConfigMgr Folder Structure

11 Comments

Cancel

  1. Thank you so much for this, I was really struggling to get the correct detection method for this – I had tried other reg keys but they wouldn’t work at all!

  2. Thanks for this, Brilliantly explained and helped me loads

  3. Years later this is helping people (like me) understand what to do in these kinds of situations. You have made things easier on me and increased the speed and knowledge of my deployments.

    Thanks!

  4. Thank you fot this article! It is very helpfull fo me!

  5. The only problem that I vae wih this article is that %ProgramFiles% points to
    \Program Files on a 64 bit system and to Program Files (x86) on a 32 bit system – the opposite of what the article says

    • Did you even read the article? The entire first half discusses why your comment is incorrect. The value of %ProgramFiles% is dependant upon the architecture of the executable run or the context that it is run in in addition to the architecture of the OS. Thus, you need to check the option that says run the installer and uninstaller as 32-bit processes to account for the uninstaller running in 32-ibt or 64-bit OSes.

  6. Very, very, very helpful information. The concept was vague and very confusing by Microsoft’s SCCM. You made so clear and understandable. god bless buddy and thank you so much.

    • Glad it helped you. Keep in mind here though that the issue isn’t really caused by ConfigMgr but is the result of how Windows 10 segregates data for 32-bit and 64-bit apps and processes. ConfigMgr does certainly muddle the issue a bit though because packages are run as 32-bit.

  7. Thanks for this! Just what I wanted to know!