PowerShell commands returning exit code 1 despite working natively.
In an attempt to increase transparency I was attempting to move one line PowerShell commands from scripts into the console and run them natively.
However I came across the commands failing regardless of Execution Policy, application path or command line.
The environment is Windows Server 2012 R2 with a PowerShell execution policy set to Remote Signed.
In this particular instance i was attempting to install .NET 3.5, since the source files are missing I created a package containing the sxs directory from the Windows Server 2012 install media and was attempting to execute the following command:
Powershell.exe -ExecutionPolicy ByPass Install-WindowsFeature -Name NET-Framework-Core -Source:".\sxs"
Nothing unusual to report, however to confirm the command works we can copy and paste it into the current directory for that package.
But wait a second, the command executed successfully! (Success = True)
So we now know the command is correct, its been correctly passed by SCCM to the end-point and the package has been delivered successfully.
So lets take a look at what is happening under the hood, re-running the program installation but this time with ProcMon running to monitor the installation.
When analysing the processes we see that PowerShell is not being run from the location passed to it:
But instead from
So it turns out this is by design.
|The %windir%\System32 directory is reserved for 64-bit applications. Most DLL file names were not changed when 64-bit versions of the DLLs were created, so 32-bit versions of the DLLs are stored in a different directory. WOW64 hides this difference by using a file system redirector.
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. Access to %windir%\lastgoodsystem32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
What this translates to is that the SCCM agent is trying to access %windir%\System32 but being redirected to %windirsys\Wow64
The resolution is pretty simple, to by-pass the windows 32-bit emulator simply point the PowerShell.exe to
So our new command line looks as follows:
%winDir%\Sysnative\windowsPowershell\v1.0\Powershell.exe Install-WindowsFeature -Name NET-Framework-Core -Source:".\sxs"
We changed the path to point to the native PowerShell.exe and deployed the program and we have success!
And there we have it, not a particularly pretty work-around but one nonetheless.