(Reposted for reference)

Ran into this issue recently and wanted to document it in case anyone else ran across the same problem.

Scenario: I have set up a ConfigMgr 2012 Task Sequence to deploy Windows Server 2012 R2 and I want to customize the server with some Roles and Features after the OS comes down.  I have created a PowerShell script (including some basic logging) to add some of the ConfigMgr DP prereqs…

…and I’ve created a legacy Package and Program to run the script during the Task Sequence using the following command:

    powershell.exe -ExecutionPolicy Bypass -File .\ConfigMgrDP.ps1

Issue1: The first issue I run into is that the script doesn’t appear to do anything.  When I check for the log file I see that it is created and has contents, so I know it’s executing:

There’s obviously something wrong because the time stamps for the start, middle and finish of the execution are all the same.  It appears that only the Install-WindowsFeature commands are failing to install.  If we look at the execmgr.log file, it shows that everything is executing without any errors:

However, it’s here that we find our first clue: the Program is executing in a 32-bit environment:

This was a common issue with SCCM 2007 since the client was natively 32-bit, but although the ConfigMgr 2012 client is 64-bit on 64-bit Operating Systems there are still some functions that operate as 32-bit (including legacy Packages/Programs).  We can easily verify this by adding the following line to the script:

$64bit = [Environment]::Is64BitProcess
Add-Content -Path $env:windir\Temp\CoreConfig.log -Value (’64-bit process = ‘ + $64bit);

The log tells the story:

As it turns out, the ServerManager module that contains the Install-WindowsFeature cmdlet is only available in the 64-bit PowerShell environment, so the Install-WindowsFeature commands cannot run because the cmdlet is not recognized.  This is easily verified by running the script in a standard 32-bit PowerShell environment:

Resolution1: Fortunately, there is an easy remedy to this situation: we simply bypass the file system redirector using “sysnative” to call the 64-bit PowerShell and execute our script:

    %WINDIR%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File .\ConfigMgrDP.ps1

Now our logs give us something a little more along the lines of what we would expect:

Issue2: So with a functioning script, I decided to make some additions to install and configure WSUS:

When I re-run the server build though, I suddenly no longer see any of the Roles and Features from the ConfigMgrDP.ps1 script installed.  In fact, this time I don’t even see a log file…and yet execmgr.log still says the Program installed successfully with a return code of 0. Running the updated script manually reveals the issue causing the error:

Resolution2: Simple mistake…I forgot to add the call operator (‘&’) to the line executing the wsusutil.exe command. The more important question becomes why we would see a “successful” execution when the script obviously failed to even execute.

The answer is that syntax errors in PowerShell scripts will not return back is failures, even if they are errors that prevent script execution.

So keep this in mind when calling PowerShell scripts from the command line in ConfigMgr.  Just as calling installations from batch files can mask error conditions, so too can calling PowerShell scripts.