Last Updated on October 12, 2022 by rudyooms

An old one, but still necessary when you are deploying a Win32 app and you have to make sure some 64 bits registry keys are configured before you could install the application.

I was inspired to write this blog after a question on the Technet community website about this topic.

In this blog, I will first show you the differences where data is stored on a 64 bits device and secondly I will show you why deploying a 64 bits registry change in a *Win32 app could give you some issues.

(*Win32app –> Say it out Loud!… Windows 32 App)

I will divide this blog into multiple parts

1. Differences
2. Win32App registry Change
3. Solving the Sysnative Issue

1. Differences

Before I will show you the differences between 64 and 32 bits, we need to know what WoW64 means. If we don’t know what the WoW64 means, you could get confused about the name itself! As an example, 32 bits apps are accessing their files from the SysWoW64 folder…Is this folder, the 64 bits folder? Let me explain.

WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem of the Windows operating system capable of running 32-bit applications on 64-bit Windows. It is included in all 64-bit versions of Windows

Program files:

On a 64-bit computer, 64-bit programs store their files in C:\Program Files, 32-bit programs store their files in C:\Program Files (x86).

Windows Folder:

On a 64-bit computer, if a 64 bits program wants to access the system-wide folder it opens the c:\windows\system32 folder, if a 32 bits program wants to access the system-wide folder it will be redirected to C:\Windows\SysWOW64.

Registry:

On a 64-bit computer, if we write a registry key from a 64 bits process it will be stored in the HKEY_LOCAL_MACHINE\SOFTWARE, if we write a registry key from a 32-bits process  it will be  redirected to the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node

Now we know some differences, I will give you an example:

If you install a 32-bit application on a 64-bit version of Windows and it tries to write to the C:\Program Files folder, WoW64 points it at C:\Program Files (x86). If it wants to access the C:\Windows\System32 folder, WoW64 points it at C:\Windows\SysWOW64.  This process is automatic and is done by a build-in file system redirect

Sysnative:

Sysnative is a virtual folder/alias, that can be used to access the 64-bit System32 folder from a 32-bit application or script.

For example: You could access this 64 bits folder from a 32 bits program like CMD (c:\windows\syswow64\cmd.exe)

2. Win32 App Registry Change

Like I told you at the beginning of this blog, I was inspired to write this blog after a question on Technet. If you want to deploy an application that requires a license server, you will need to define a license server before you could proceed to install the client app itself. 

Creating a custom-made Win32 app would be the best solution. Create a new folder and place your client MSI installation file in it and a PowerShell script to deploy the register setting and start the MSI client installation:

$flexreg = (Get-ItemProperty "HKLM:\Software\FLEXlm License Manager").SW_D_LICENSE_FILE
#Start-Process -Wait -NoNewWindow "msiexec" -ArgumentList "/i","$pwd\DraftSight.msi","/qb","LICENSETYPE=3"
if (!$flexreg) {
    New-Item -Path "HKLM:\Software" -Name "FLEXlm License Manager" -Force
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value 'portnr@servername' -PropertyType STRING -Force
} elseif ($flexreg -like '*portnr@servername*') {
Exit
} else  {
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value $flexreg';portnr@servername' -PropertyType STRING -Force

But now comes the trouble, when deploying this register setting, the registry key is going to be created inside the wow6432node when you use a Win32App.

The Microsoft Intune Management Extension is responsible for the deployment of the Win32 app but keeping in mind the differences between 64 and 32 bits, take a look where the Microsoft Intune Management extension is installed.  

As shown above, it is installed in the c:\program files (x86) folder and what did we learn about this folder? So by default behavior (when you did not change anything), Intune will trigger the Win32 app installation in a 32-bit process context and as I told you earlier, the key will be created in the wow6432node.

3. Solving the Sysnative problem

So what options do we have to change this default behavior? I have got 4 options for you all!

Option 1:

Instead of specifying the install command as you would normally do:

You could specify the “sysnative cmd version”

Like I told you before the 32 bits Intune Management Extension can access the sysnative folder because it is a 32 bits app!!

Option 2:

We got 3 options left, the second option is a little different. I could not find any documentation if this a proper solution, but it works…

You need to create a Powershell script, in this script you will need to define an additional PowerShell script, which needs to be transferred to the disk and you will need to configure a system task to run the additional PowerShell script. The scheduled task would run the script in the 64-bit context.

Another option would be to create the additional PowerShell script itself and make sure you attach it to the intunewin file.

$content = @'
$flexreg = (Get-ItemProperty "HKLM:\Software\FLEXlm License Manager").SW_D_LICENSE_FILE
#Start-Process -Wait -NoNewWindow "msiexec" -ArgumentList "/i","$pwd\DraftSight.msi","/qb","LICENSETYPE=3"
if (!$flexreg) {
    New-Item -Path "HKLM:\Software" -Name "FLEXlm License Manager" -Force
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value 'portnr@servername' -PropertyType STRING -Force
} elseif ($flexreg -like '*portnr@servername*') {
Exit
} else  {
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value $flexreg';portnr@servername' -PropertyType STRING -Force
}'@

Out-File -FilePath $(Join-Path $env:ProgramData CustomScripts\test.ps1) -Encoding unicode -Force -InputObject $content -Confirm:$false

# register script as scheduled task
$Time = New-ScheduledTaskTrigger -AtLogOn
$User = "SYSTEM"
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\ProgramData\CustomScripts\test.ps1`" -Verb RunAs"
Register-ScheduledTask -TaskName "test" -Trigger $Time -User $User -Action $Action -Force
Start-ScheduledTask -TaskName "test"

Option 3:

This option is the most commonly used one.  When you add this script to the top of your own PowerShell script, the script host will rerun the PowerShell script but this time in the 64 bits context

If ($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
    Try {
        &"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
    }
    Catch {
        Throw "Failed to start $PSCOMMANDPATH"
    }
    Exit
}

Option 4:

Another option would be, to configure and run the PowerShell script before you are going to deploy the app. Configuring this setting to yes, will make sure your PowerShell script is run in the 64 bits context

Conclusion:

Knowing the differences between 64 and 32 bits and how they can work together is very important. In my opinion, the first option is the easiest one but I really like the idea of the second option.