DISM Cmdlets fail to run in Win PE with MDT 2013 Update 1 – WORKAROUND

Whilst working with Windows 10 and MDT 2013 Update 1 my colleague Graham Hardie and I ran into an issue which was preventing us from running DISM Cmdlets in Win PE.

The issue became apparent whilst trying to implement Michael Niehaus’s Windows 10 Inbox App Removal script and specifically trying to run the script offline in Win PE.

The MDT boot Image was successfully generated with the MDAC, .NET, PowerShell and DISM Cmdlets features but would fail to run the “Get-AppxProvisionedPackage” Cmdlet with the following error:

Get-AppxProvisionedPackage : The ‘Get-AppxProvisionedPackage’ command was found in the module ‘Dism’, but the module could not be loaded. For more information, run ‘Import-Module Dism’.
At line:1 char:1
+ Get-AppxProvisionedPackage -Path e:\
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Get-AppxProvisionedPackage:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

We found that the Microsoft.Dism.Powershell.dll file was becoming corrupt at boot up…not had the chance to investigate what exactly is causing the corruption yet.

However, to workaround the issue you need to do the following:

  1. Delete the file from:
    x:\Windows\System32\WindowsPowerShell\v1.0\Modules\Dism
  2. Copy the file back down to the X: drive from the Deployment share:
    %DEPLOYROOT%\Servicing\x64\Microsoft.Dism.Powershell.dll 

You can obviously automate this as part of your Task Sequence. I simply added two ‘Run Command Line’ steps to Delete the file and copy the new file.  The steps need to be added before you run any script which has a dependency on DISM Cmdlets…in our case before Michael’s Inbox App Removal script:

The first step:
DISMCmdLetFix1

Command Line:

cmd.exe /c Del “%SystemRoot%\System32\WindowsPowerShell\v1.0\Modules\Dism\Microsoft.Dism.Powershell.dll” /q /s

The Second step:
DISMCmdLetFix2

Command Line:

robocopy Z:\Servicing\x64 X:\Windows\System32\WindowsPowerShell\v1.0\Modules\Dism Microsoft.Dism.Powershell.dll /is

Note: Add Error Code 1 to Success Codes for this step…robocopy can report a success with a non zero return.

A bug has also been opened on Connect.

Let us know if this works for you or better still if you identify the root cause of the issue.

Advertisements

8 thoughts on “DISM Cmdlets fail to run in Win PE with MDT 2013 Update 1 – WORKAROUND

  1. Thanks for this. A little improvement to the second commandline. It assumes that you are using a x64 boot image. I used this to stay agnostic to the architecture:

    robocopy “%deployroot%\Servicing\%architecture%” X:\Windows\System32\WindowsPowerShell\v1.0\Modules\Dism Microsoft.Dism.Powershell.dll /is

  2. Pingback: DISM cmdlets fail to run in WinPE (MDT 2013 Update 1)

  3. Hi, thanks to your blog post we were able to overcome our problem with DISM. I’ve blogged about it over at http://JustAnotherITBlog.co.uk/ and thanked you in the post. Just to let you know we overcame the problem a similar way but used a PowerShell script instead of two Task Sequence steps. Cheers, John.

  4. Hey guys, this issue failing to be fixed by Microsoft has really slowed me down, writing custom functions using dism.exe to apply images in scripts, testing, etc… I finally broke down and figured out a way to fixed this permanently. After trying the solution posted here, I would still get errors saying that the module was still corrupt, etc…and yes, even with the latest PE version and ADK.
    It seemed to be more than just the dll file being corrupted.

    Using MDT and the extras folder, I copied the DISM module from Windows 10 Enterprise 1511
    and placed it like so…

    %DEPLOYROOT%\Extras\amd64\Servicing\X64\Modules\Dism
    %DEPLOYROOT%\Extras\x86\Servicing\X64\Modules\Dism

    I updated my WindowsPE boot images and voila! The nice thing about this is that whether you are online or offline, this fix will still work, which is what I needed. Recovery partition purposes.

    Here is my powershell code…

    # %ForceElevation% = Yes
    #Requires -RunAsAdministrator

    #Clear The Screen
    Clear-Host

    #Define Default Action Preferences
    $DebugPreference = “Continue”
    $ErrorActionPreference = “Continue”
    $WarningPreference = “Continue”
    $Global:ConfirmPreference = “None”

    #Define ASCII Characters
    $Equals = [Char]61
    $Space = [Char]32
    $SingleQuote = [Char]39
    $DoubleQuote = [Char]34
    $NewLine = “`n”

    #Load WMI Classes
    $OperatingSystem = Get-WmiObject -Namespace “root\cimv2” -Class “Win32_OperatingSystem” -Property * | Select *

    #Retrieve property values
    $OSArchitecture = $($OperatingSystem.OSArchitecture).Replace(“-bit”, “”).Replace(“32”, “86”).Insert(0,”x”).ToUpper()

    #Define Functions
    #Repair Powershell Module in WindowsPE
    Function Repair-Module ($Module)
    {
    Remove-Item -Path “$PSHome\Modules\$($Module)” -Recurse -Force -ErrorAction SilentlyContinue
    Copy-Item -Path “$Env:Systemdrive\Servicing\$($OSArchitecture)\Modules\$($Module)” -Destination “$PSHome\Modules\$($Module)” -Recurse -Force -ErrorAction SilentlyContinue
    }

    #Repair Modules
    Repair-Module -Module “Dism”

    #Import Modules
    Import-Module -Name “Dism” -Verbose -ErrorAction Stop

Speak your mind...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s