4.1.8 - PSADT 4.1 launched from Intune executes in 32 Bit, Regression from 4.0

The Toolkit General Discussion
1

I found this issue when I was testing 4.1.8 with Set-ADTRegistryKey.
The logs correctly show that the registry keys are created and set at the expected path.

<![LOG[[Post-Install] :: Setting registry key value: [Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\TestCompany\Applications\Test_E2E-Monitoring_1.0.0.0_EN_x64_09] [Name = E2E-Monitoring].]LOG]!><time="14:35:21.073+60" date="8-12-2026" component="Set-ADTRegistryKey" context="NT-AUTORITÄT\SYSTEM" type="1" thread="7340" file="C:\WINDOWS\IMECache\743c15d5-37fa-4801-954d-e5f1087ff5cc_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">

However, when I open the Registry Editor and browse to the expected path, the key does not exist.

I was eventually able to find the key at:

HKEY_LOCAL_MACHINE\Software\WOW6432Node\TestCompany\Applications\Test_E2E-Monitoring_1.0.0.0_EN_x64_09

The old Application Template using PSAppDeployToolkit 4.0.5 did not behave this way and worked as expected. The new 4.1.8 template is almost identical.

I tested the same application on the same Windows 11 test VM:

Windows 11 10.0.26200 x64

The issue only occurs when the application is installed through Company Portal from Intune.

In Intune, the installation is configured as follows:

Install Behaviour: System

Install Command:
%SystemRoot%\System32\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy Bypass -NoProfile -File Invoke-AppDeployToolkit.ps1 -DeploymentType Install -DeployMode Silent

When I run the exact same install command through PSExec64 on my machine, the registry key is correctly written to the 64 bit registry path.

Registry Branding

We set our application branding through a function in PSAppDeployToolkit.Extensions\PSAppDeployToolkit.Extensions.psm1. This is where Set-ADTRegistryKey is used for all of our applications.

[string]$appScriptVendor = "$($config.Toolkit.CompanyName)"
[string]$appPackageName = "$($adtSession.AppVendor)_$($adtSession.AppName)_$($adtSession.AppVersion)_$($adtSession.AppLang)_$($adtSession.AppArch)_$($adtSession.AppRevision)" -replace '\s', '-'

function Set-RegistryBranding {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $false)]
        [ValidateNotNullOrEmpty()]
        [System.Int32]$ExitCode = 0
    )

    $registryBrandingEntries = Switch ($adtSession.DeploymentType) {
        { $_ -in 'Install', 'Repair' } {
            [ordered]@{
                'Name'      = $adtSession.AppName
                'Publisher' = $adtSession.AppVendor
# [...]
        Default {
            [ordered]@{
                'Status' = 'Unkown'
            }
        }
    }

    $regHive = if ($IsAdmin -or $IsLocalSystemAccount) { 'HKLM' } else { 'HKCU' }

    $registryBrandingEntries.GetEnumerator() | % {
        Set-ADTRegistryKey -Key "$regHive\SOFTWARE\$appScriptVendor\Applications\$appPackageName" -Name $_.Name -Type String -Value $_.Value
    }
}

I am aware that Set-ADTRegistryKey has a -Wow6432Node option. However, this option defaults to false and we do not set it anywhere in our code.

Difference between PSAppDeployToolkit 4.0.5 and 4.1.8

When comparing the logs from the old and new templates, I noticed that the following line is present in the 4.1.8 template but was not present in the 4.0.5 template:

<![LOG[[Initialization] :: PowerShell Process Path is [C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\PowerShell.exe].]LOG]!><time="14:05:46.330+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">

The same log also reports:

<![LOG[[Initialization] :: PowerShell Version is [5.1.26100.8457 X86].]LOG]!><time="14:05:46.326+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">

This appears to indicate that PSAppDeployToolkit is running under the 32 bit version of Windows PowerShell.

For comparison, when I run the same installation locally, the PowerShell process path is the 64 bit version:

<![LOG[[Initialization] :: PowerShell Version is [5.1.26100.8875 X64].]LOG]!><time="15:52:15.299+60" date="8-12-2026" component="Open-ADTSession" context="NT AUTHORITY\SYSTEM" type="1" thread="57104" file="C:\Git\UEM\WindowsClientManagement\PSADT4_SPIRIT21_Template\src\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: PowerShell Process Path is [C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe].]LOG]!><time="15:52:15.302+60" date="8-12-2026" component="Open-ADTSession" context="NT AUTHORITY\SYSTEM" type="1" thread="57104" file="C:\Git\Template\src\PSAppDeployToolkit\PSAppDeployToolkit.psm1">

The local installation correctly writes the registry key to the expected 64 bit path.

The relevant 4.1.8 initialization log is:

<![LOG[[Initialization] :: [Invoke-AppDeployToolkit.ps1] script version is [4.1.8].]LOG]!><time="14:05:46.269+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: The following parameters were passed to [Invoke-AppDeployToolkit.ps1]: [-DeploymentType:'Install' -DeployMode:'Silent'].]LOG]!><time="14:05:46.276+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] module version is [4.1.8].]LOG]!><time="14:05:46.278+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] module imported in [7,6678661] seconds.]LOG]!><time="14:05:46.283+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] module initialized in [8,2788576] seconds.]LOG]!><time="14:05:46.286+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] module path is ['C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit'].]LOG]!><time="14:05:46.290+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] config path is ['C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\Config'].]LOG]!><time="14:05:46.292+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] string path is ['C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\Strings'].]LOG]!><time="14:05:46.296+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: [PSAppDeployToolkit] session mode is [Native].]LOG]!><time="14:05:46.300+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: Computer Name is [TSTWCAP005].]LOG]!><time="14:05:46.302+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: Current User is [NT-AUTORITÄT\SYSTEM].]LOG]!><time="14:05:46.306+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: OS Version is [Microsoft Windows 11 Enterprise X64 10.0.26200.8457].]LOG]!><time="14:05:46.310+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: OS Type is [WorkStation].]LOG]!><time="14:05:46.312+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: Hardware Platform is [Physical].]LOG]!><time="14:05:46.316+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: Current Culture is [de-DE], language is [DE] and UI language is [DE].]LOG]!><time="14:05:46.320+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: PowerShell Host is [ConsoleHost] with version [5.1.26100.8457].]LOG]!><time="14:05:46.324+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: PowerShell Version is [5.1.26100.8457 X86].]LOG]!><time="14:05:46.326+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: PowerShell Process Path is [C:\WINDOWS\SysWOW64\WindowsPowerShell\v1.0\PowerShell.exe].]LOG]!><time="14:05:46.330+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: PowerShell CLR (.NET) version is [4.0.30319.42000].]LOG]!><time="14:05:46.334+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: The following users are logged on to the system: [INTERN\tony.stark].]LOG]!><time="14:05:46.338+60" date="8-12-2026" component="Open-ADTSession" context="NT-AUTORITÄT\SYSTEM" type="1" thread="8944" file="C:\WINDOWS\IMECache\2bf811c4-a139-4d06-96e1-2846c95b4d38_1\PSAppDeployToolkit\PSAppDeployToolkit.psm1">
<![LOG[[Initialization] :: Session information for all logged on users:

Expected behaviour

The application should write the registry values to:

HKEY_LOCAL_MACHINE\Software\TestCompany\Applications\Test_E2E-Monitoring_1.0.0.0_EN_x64_09

The registry values should not be redirected to:

HKEY_LOCAL_MACHINE\Software\WOW6432Node\TestCompany\Applications\Test_E2E-Monitoring_1.0.0.0_EN_x64_09

Questions

Could the SysWOW64 PowerShell process be causing the registry redirection?

Why is the 4.1.8 template being executed using thee x86 version of Windows PowerShell when the Intune install command explicitly calls

%SystemRoot%\System32\WindowsPowerShell\v1.0\PowerShell.exe

Any guidance on why Set-ADTRegistryKey is writing to WOW6432Node in this scenario would be appreciated.

2

That will be your problem, Intune by default (currently) launches PowerShell as 32 bit.

The PSADT developers wrote the executable (wrapper) that fixes this issue.
Simple solution is to only use the full PowerShell command line for 'testing' and use the exe to deploy, therefore try this instead:

Install Behaviour: System

Install Command:
Invoke-AppDeployToolkit.exe -DeploymentType Install -DeployMode Silent
3

Thank you for the Info, I will try it, I just find it odd that the install command was working perfectly for PSADT 4.0.x and 3.x but not with 4.1.x

4

I'll never for the life of me understand why people continually bypass our exe or don't even look into the reason why it's there. We haven't shipped it because we like writing C# applications that serve no purpose...

5

Maybe this helps to understand why.

  • It was the first option in the docs How to Deploy · PSAppDeployToolkit
  • Why would the exe be required, if you don't use the additional parameters?
  • The behaviour from a normal execution from powershell was the same as the exe with PSADT 3.x, 4.0.x but not with 4.1.x
  • The 32 bit behaviour from Intune is not mentioned in the doc. It's not clearly mentioned by Microsoft either.
  • Intune often provides the option Run script as 32-bit process on 64-bit clients which you can find for the requirement and detection rules which is disabled by default. From that someone can think that Intune would execute the command the same way a user could with psexec with 64-bit.
6

So the new 4.2 docs also mention the 32-bit PowerShell Behaviour.
How to upgrade from v4.1 to v4.2 · PSAppDeployToolkit
I think this should also be added to the 4.1 Documentation since that is where it started to fail for us. 4.0 and 3.10 did not behave like that.

7

@abc
Yes the mention of this in 4.2 is not mentioned for version 4.0, 4.1 or earlier, but it has been added with the 4.2 docs to make it clearer, it was relevant earlier, just not mentioned:

To prevent this from happening, either call PowerShell.exe from SysNative instead of System32, or use the Invoke-AppDeployToolkit.exe launcher, which will ensure the correct PowerShell host is used.

TBH "use the Invoke-AppDeployToolkit.exe launcher" is the normal production use * for this and has been since PSADT 4.0 - hence why I suggested it above.

* Based on forum discussions here with the developers.

In your OP you are not instructing PowerShell to launch using SysNative (or using the Invoke-AppDeployToolkit.exe launcher), so this is why it isn't working for you as you expect in 64-bit PowerShell:

Knowing if you are running 64-bit PowerShell is an age old problem, the following is a good (and still relevant) explanation from 13 years ago:

and with that knowledge you 'can' use techniques like this to relaunch PowerShell in 64-bit:

But, this is all unnecessary if you use the Invoke-AppDeployToolkit.exe launcher, as this performs the 32-bit to 64-bit switch (on a 64-bit Windows OS) automatically.
However, if you ever had a need to launch a specific PSADT script in 32-bit you can use the /32 parameter with the launcher to achieve this:

As v4.2 is due for release soon, I doubt any effort will be spent on updating documentation for the older version(s).