PowerShell failing in a task sequence

I recently worked on an issue with a customer that might affect more of you out there.  They were trying to run a simple PowerShell (POSH) script in a System Center 2012 R2 Configuration Manager SP1 (SCCM/ConfigMgr) OSD task sequence.  The PS1 script file would run fine outside of the task sequence, but in the task sequence it was failing.  Looking at the logs there was an exit code 4 (The system cannot open the file) being returned.  The task sequence was doing a "run command line" step similar to:

  • CMD.EXE /C %SYSTEMDRIVE%\windows\system32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -file %SYSTEMDRIVE%\windows\temp\collection\MYPOSH.ps1

Looking a littler deeper in the logs we saw things like:

  • gwmi : The term 'Get-WMIObject' is not recognized as the name of a cmdlets, function, script file, or operable program.  Check the spelling of the name, or if a path was included, verify the path is correct and try again.

A little time spent troubleshooting and testing reveled that once the OS is laid down but the task sequence is still running the PowerShell system didn't load up all the normal modules you would expect to be available to you.  One of those basics that wasn't loaded was the PowerShell Management module, which has all the cmdlets for interaction with WMI.  The fix I used was to add a step in the PS1 file to fist import the missing module, in this case the get-WMIObject module (other cmdlets might be in other modules, but the idea is the same).  The added line was:

  • import-module -Name C:\windows\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Management -verbose

Once that runs all the normal WMI modules are present for the rest of the POSH script to load and use.


7/29 update – Typo fixes

Comments (7)

  1. Jason Sandys says:

    Also, why in the world would you use cmd to launch powershell? That makes absolutely no sense.

  2. Sorry… leftover from some troubleshooting.

  3. Torsten says:

    There is no "Configuration Manager 2012 R2 SP2". It's either "Configuration Manager 2012 SP2" or "Configuration Manager 2012 R2 SP1" 🙂

  4. Torsten – Thanks for keeping me honest. Typos will eventually be my downfall. 🙂

  5. Al Ray says:

    I know this is a little old, but to Jason Sandys — You'd use CMD to launch powershell in a TS if you need it to run as a different account. That's at least one reason I can think of.

  6. Dustin Walters says:

    Thank you, Mike, for providing this workaround. I’ve been banging my head against this very same problem in my own OSD task sequences. On Windows 7 with WMF3.0 or WMF4.0 installed, certain basic cmdlets (Get-WMIObject, New-Object, etc.) would fail to be recognized when the .ps1 was called using a RUNAS command (Well, Run Command Line as a specific user, to be more precise). The problem does not occur with my previous custom WIMs that did not have WMF3.0 or 4.0 baked into them. In my case, I needed Microsoft.Powershell.Management for GWMI and Microsoft.Powershell.Utility for New-Object.

    It’s still disconcerting these modules are missing when you use “RUNAS” in an OSD TS with WMF3.0+. These are very basic modules; without them, Powershell is effectively useless and broken. This seems like a bug that ought to be fixed. But nevertheless, thank you sir for your post!

  7. Strafe Sawdoffe says:

    Wow! A whole day of troubleshooting, banging my head, and gathering observers simply because I couldn’t believe the behaviors I was seeing, and then, Google brought me to this post. Life saver. So apparently, if you do a “run as different user” in an OSD sequence and call powershell, it loads with total amnesia of its basic functions… adding the “import module” statements at the start of the script fixed it.

Skip to main content