none
DISM.EXE error while applying unattend.xml during LTI deployment with MDT 2013 - Reproducible bug RRS feed

  • Question

  • The problem I am about to describe doesn't exist with MDT 2010 update 1, MDT 2012, or MDT 2012 update 1 when using the either WAIK or ADK.  I have not attempted to reproduce this problem with older versions of MDT or pre-release versions of MDT 2013.  The problem definitely exists with MDT 2013 RTM.

    This is the same problem as Inconsistent DISM.EXE error when applying unattend.xml during LTI deployment - Possible bug!, but this is more concise and provides details on how to reproduce the problem. 

    Status as of 2014-03-30 (Previous workaround deemed unusable - core bug still present)

    Keith Garner determined that DISM.EXE was failing while processing the <offlineServicing> section in the unattend.xml file.  Removing this section resolves the issue, but this section is needed to inject drivers into the image during WinPE and is needed  The presence of this section didn't cause any problems with previous releases of MDT/ADK - it is likely an interoperability bug within the DISM.EXE tool.  See replies below for details.

    Confirmed the problem applies to deploying Windows 8.1 as well.

    Problem:

    When deploying Windows 7 Pro x64 w/SP1 and enabling/disabling features using unattend.xml, deployment often (almost 100% of the time) fails with this dialog:

    Steps to reproduce ("bare-metal"):

    1. Create a new, clean virtual machine (I used VMware Workstation)
    2. Boot the VM with the Windows 7 x64 Pro w/SP1 Volume Licensing DVD
    3. Install Windows with default options, OOBE choices:
      • User name = Tony
      • Computer name = Tony-PC
      • Password = tony
      • Windows Update = recommend settings
      • Time zone = Eastern
      • Location  = Work network
    4. Install VMware Tools and reboot
    5. Configure Internet Explorer using express settings
    6. Configure Windows Update to get updates for other Microsoft products
    7. Apply all available Windows Updates*
    8. Install ADK for Windows 8.1 (http://www.microsoft.com/en-us/download/details.aspx?id=39982)
      • Installs .NET Framework 4.5 automatically
      • Accept all default installation choices
    9. Install MDT 2013 x64 (http://www.microsoft.com/en-us/download/details.aspx?id=40796)
      • Accept all default installation choices
    10. Apply all available Windows Updates again*

    *When installing Windows Updates:

    • Select all important updates, except Internet Explorer 11
    • Select all optional updates, except Bing Bar, Bing Desktop, Security Essentials, and Silverlight.

    Launch MDT Workbench:

    1. Create a new deployment share
      • Accept all defaults:  C:\DeploymentShare, DeploymentShare$, etc.
    2. Import Operating System:
      • Full set of source files
      • Source Directory = CD drive containing the Windows 7 x64 Pro w/SP1 Volume Licensing DVD.
      • Accept remaining defaults
    3. Create a new task sequence:
      • ID = Test
      • Name = Test
      • Template = Standard Client Task Sequence
      • OS = Windows 7 Professional
      • Key = Do not specify at this time
      • Settings:
        • Full name = Tony
        • Organization = Tony
        • IE Home Page = about:blank
      • Admin password = tony
    4. Update Deployment Share, and completely regenerate the boot images.

    From another new, clean virtual machine:

    1. Boot from the "C:\DeploymentShare\Boot\LiteTouchPE_x64.iso" file from MDT computer.
    2. Run the Deployment Wizard, and enter credentials (tony, tony, . )
    3. Launch the created Task Sequence (accept defaults, click keep clicking ‘next’):
      • Computer name = autogenerated
      • Join a workgroup = WORKGROUP
      • Do not move user data and settings
      • Do not restore user data  and settings
      • Locale and time = accept defaults
      • Do not capture an image

    At this point, the deployment will succeed every time.

    Now, edit the task sequence and edit the unattend.xml:

    1. Add the Foundation Package to the answer file
    2. Edit the foundation Package:
      • Disable MediaPlayback > MediaCenter
    3. Save file and close task sequence.

    Deploy the task sequence again using the directions above (for each attempt, I used a new, unused VM), and it will fail nearly every time!

    Notes:

    • Enabling/Disabling features via unattended.xml is a supported and documented process.
    • I suspect a bug with DISM.EXE v6.3 while operating on Windows 6.1 images.
    • I realize that adding "Install Roles and Features" and/or "Uninstall Roles and Features" task sequence items may be a workaround for this problem (I haven't tried it), but it is not a solution to the problem.

    • Edited by Tony MCP Monday, March 31, 2014 3:31 AM
    Friday, November 15, 2013 3:40 AM

All replies

  • Can you post the full dism.log file to a public share like SkyDrive and share the link?

    Keith Garner - keithga.wordpress.com

    Friday, November 15, 2013 4:52 AM
    Moderator
  • Full dism.log file from failed install available here:

    https://skydrive.live.com/redir?resid=AF5DA59B1008F449!9947&authkey=!AJCg3YBq0-KmOmw

    Errors begin on line 926 and stop on line 936.


    -Tony


    • Edited by Tony MCP Friday, November 15, 2013 6:10 AM
    Friday, November 15, 2013 6:08 AM
  • You know I don't think DISM.exe is failing trying to process the <servicing> section of your unattend.xml, I think it's failing trying to processing this section:

        <settings pass="offlineServicing">
            <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <DriverPaths>
                    <PathAndCredentials wcm:keyValue="1" wcm:action="add">
                        <Path>\Drivers</Path>
                    </PathAndCredentials>
                </DriverPaths>
            </component>
        </settings>
    

    From the logs:

    2013-11-14 21:56:37, Info DISM DISM Smi Provider: PID=1280 SMI provider selected "offlineServicing" servicing pass. - CSmiWrapper::ApplySettings [...] 2013-11-14 21:56:37, Error CSI 00000001 (F) 80220013 [Error,Facility=FACILITY_STATE_MANAGEMENT,Code=19 (0x0013)] #5# from CWcmEngineCore::GetNamespaceWithOptions(nsid = { name: Microsoft-Windows-PnpCustomizationsNonWinPE ver: lang: neutral arch: amd64 pkt: 31bf3856ad364e35 verSc: nonSxS }, iMode = 1, iAccess = 2, iOption = 1, target = @0x401d390, context = NULL, namespace = { name: Microsoft-Windows-PnpCustomizationsNonWinPE ver: lang: neutral arch: amd64 pkt: 31bf3856ad364e35 verSc: nonSxS }) [gle=0x80004005]

    Perhaps it's just some kind of interop issue


    Keith Garner - keithga.wordpress.com

    • Marked as answer by Tony MCP Monday, November 18, 2013 11:40 PM
    • Unmarked as answer by Tony MCP Thursday, January 9, 2014 4:54 AM
    • Proposed as answer by George Simos Thursday, March 8, 2018 3:55 PM
    Sunday, November 17, 2013 10:43 PM
    Moderator
  • You know I don't think DISM.exe is failing trying to process the <servicing> section of your unattend.xml, I think it's failing trying to processing this section

    Thank makes sense when looking at the logs.  Except...

    If I remove the <servicing> section, the deployment is successful every time.  The remainder of the unattend.xml file is identical, including the section you mentioned.

    However (as doubtful as I am), I will test it again with the questionable section removed.  I will post my results later today.

    I appreciate your continued investigation.  Hopefully, we'll figure it out.


    -Tony

    Monday, November 18, 2013 6:52 AM
  • You know I don't think DISM.exe is failing trying to process the <servicing> section of your unattend.xml, I think it's failing trying to processing this section:

        <settings pass="offlineServicing">
            <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" ...>
                 ...
            </component>
        </settings>

    Perhaps it's just some kind of interop issue

    I've tested this, and it seems to be the source of the problem (good find!).  Funny how this doesn't cause a problem until the <servicing> section is present.  It must be an interoperability issue as you speculated.

    For my solution:  I've removed the entire "offlineServicing" section from the unattend.xml file.  The only component within it was "PnpCustomizationsNonWinPE", and that's supposedly only used during the auditsystem configuration pass which doesn't occur when deploying a "new computer".  It also references a non-existent "\Drivers" path.

    I don't believe removing this section is a problem, do you?

    I still think this is a bug in MDT.  The tool shouldn't populate the XML with bad sections.  Maybe it could be fixed by creating Unattend_Core_x86.xml.6.1 and Unattend_Core_x64.xml.6.1 files in the C:\Program Files\Microsoft Deployment Toolkit\Templates folder that don't contain the bad section?  But, this is just a workaround for a likely problem within the DISM.EXE tool.

    Thank you for your help.


    -Tony

    • Proposed as answer by George Simos Thursday, March 8, 2018 3:55 PM
    Monday, November 18, 2013 11:27 PM
  • To add to Tony's above post, I can confirm, i have also seen same issue. Though for me it's intermittent issue. I have tried to build my test server multiple times as 2k8 R2 Enterprise & 2k8 R2 Standard.

    Before Removing "<settingspass="offlineServicing">" section: Every time i reboot MDT server & try build, i see different behavior.

    i) I have seen both Standard & Enterprise succeeding,

    ii) one of these failing

    iii) and both of these failing as well.

    After Removing "<settingspass="offlineServicing">"section: All builds have succeeded & rebooting MDT server is not causing any differences.

    Thursday, November 21, 2013 7:51 AM
  • To add to Tony's above post, I can confirm, i have also seen same issue. Though for me it's intermittent issue. 

    i had the exact symptoms you described. Only when I rebuilt a test system, as described above, did the problem become consistent.

    Just FYI


    -Tony

    Thursday, November 21, 2013 3:35 PM
  • I've got the same problem - but only with 8.1. We can deploy 7 Enterprise with the Foundation packages enabled with no problems, but if we do the same with 8.1 Enterprise it bombs (both x64).

    Removing the Offline Servicing options do not make any difference - I'm going to build a completely new deployment server to rule out anything else locally, but it looks like a bug....

    Monday, November 25, 2013 12:09 PM
  • For my solution:  I've removed the entire "offlineServicing" section from the unattend.xml file.  The only component within it was "PnpCustomizationsNonWinPE", and that's supposedly only used during the auditsystem configuration pass which doesn't occur when deploying a "new computer".  It also references a non-existent "\Drivers" path.

    I don't believe removing this section is a problem, do you?

    Yes, problems!

    My testing revealed the following:

    It seems that the "PnpCustomizationsNonWinPE" DriversPath is what determines what drivers will be inserted into the image.  The "inject drivers" action in the preinstall folder of the task sequence basically copies the drivers into the C:\Drivers folder.  DISM.exe does the work of actually inserting the drivers into the image.  This section tells DISM where to get the drivers to add.  Removing it is not an option.

    So, I put it back in.

    Interesting Test

    After reinstating the section, I began getting the same random failures that started this thread.  So, I took a snapshot of the VM when it was almost done applying the OS image (before DISM runs).  The VM continued to run.  The task sequence continued and rebooted without error.  So, I reverted to the snapshot.  This time it failed!  Revert again = failure;  Revert again = success!  Revert again = failure;  Revert again = failure;  Revert again = failure;  Revert again = success;  Revert again = failure;  Revert again = success;  Revert again = success.  It seems truly random.

    The dism.log file is that same for all failures, and the same for all successes

    I don't even know how to troubleshoot this anymore!

    I guess I'm going to remove the Foundation Package from the answer file and use Roles/Features TS action to perform the same result.


    -Tony

    Thursday, January 9, 2014 4:54 AM
  • Interesting Test

    After reinstating the section, I began getting the same random failures that started this thread.  So, I took a snapshot of the VM when it was almost done applying the OS image (before DISM runs).  The VM continued to run.  The task sequence continued and rebooted without error.  So, I reverted to the snapshot.  This time it failed!  Revert again = failure;  Revert again = success!  Revert again = failure;  Revert again = failure;  Revert again = failure;  Revert again = success;  Revert again = failure;  Revert again = success;  Revert again = success.  It seems truly random.

    The dism.log file is that same for all failures, and the same for all successes

    Exactly, I am seeing same random behavior as I mentioned in my previous post. Every time i reboot MDT server & try build, i see different behavior.

    i) I have seen both Standard & Enterprise succeeding,

    ii) one of these failing

    iii) and both of these failing as well.


    Thursday, January 9, 2014 6:34 AM
  • I submitted this as a bug to Connect.  Hopefully it will get some attention.

    https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/813346/dism-exe-error-while-applying-unattend-xml-during-lti-deployment-with-mdt-2013-reproducible-bug


    -Tony

    I did raised this as bug earlier in connect but Micheal doesn't think same. See reply below Michael Niehaus:

    This notification was generated for feedback item: MDT 2013 with ADK for 8.1 Bug: DISM Failure Win2K8 R2 Build which you submitted at the Microsoft Connect site.

    It appears to be having issues with the unattend.xml file reading the offlineServicing phase to inject drivers: 2013-11-19 06:05:02, Error CSI 00000001 (F) 80220013 [Error,Facility=FACILITY_STATE_MANAGEMENT,Code=19 (0x0013)] #5# from CWcmEngineCore::GetNamespaceWithOptions(nsid = { name: Microsoft-Windows-PnpCustomizationsNonWinPE ver: lang: neutral arch: amd64 pkt: 31bf3856ad364e35 verSc: nonSxS }, iMode = 1, iAccess = 2, iOption = 1, target = @0x2ecaa38, context = NULL, namespace = { name: Microsoft-Windows-PnpCustomizationsNonWinPE ver: lang: neutral arch: amd64 pkt: 31bf3856ad364e35 verSc: nonSxS }) [gle=0x80004005]

    Probably a good one to call Microsoft Support about.

    Thursday, January 9, 2014 6:36 AM
  • Kelvinf, did you solve the problem, because i have the same than you right now. I'm able to deploy all OS, but not the 8.1

    Thank You

    Thursday, January 9, 2014 1:59 PM
  • No - in the end I removed the Foundation package from the build (not really revisited it for a while). I'd like it working as I've got a couple of clients wanting new 8.1 builds.....
    Thursday, January 9, 2014 2:07 PM
  • I've got the same problem - but only with 8.1. We can deploy 7 Enterprise with the Foundation packages enabled with no problems, but if we do the same with 8.1 Enterprise it bombs (both x64).

    Removing the Offline Servicing options do not make any difference - I'm going to build a completely new deployment server to rule out anything else locally, but it looks like a bug....


    I tested and confirmed this problem exists when adding the foundation package to Windows 8.1.  I updated the bug report to include this information and the logs necessary to troubleshoot the problem.  Hopefully, it will get some attention.

    -Tony

    Wednesday, January 22, 2014 6:05 AM
  • I'm having the same issue once I upgraded to MDT 2013 with the new ADK for Windows 8.1 that has the DISM.exe file version of 6.3 .  As a stab in the dark I am going to rename the DISM.exe file to DISM.exe.6.3 and copy the older DISM.exe version 6.2 in the directory.  Then Rebuild my media and try to run my task sequence again.  I'll keep you posted if this works.  It would really be a workaround for people with building Windows 7 images or deployments.  But if it works it does speak to this being a bug with either MDT or ADK.
    Thursday, January 30, 2014 10:09 PM
  • I'm having the same issue once I upgraded to MDT 2013 with the new ADK for Windows 8.1 that has the DISM.exe file version of 6.3 .  As a stab in the dark I am going to rename the DISM.exe file to DISM.exe.6.3 and copy the older DISM.exe version 6.2 in the directory.  Then Rebuild my media and try to run my task sequence again.  I'll keep you posted if this works.  It would really be a workaround for people with building Windows 7 images or deployments.  But if it works it does speak to this being a bug with either MDT or ADK.

    Excellent idea.  Keep us informed.

    Thanks!


    -Tony

    Friday, January 31, 2014 5:08 AM
  • Ok so the idea of changing the DISM.exe file was a fail.  back to the drawing board.  I guess the key would be to determine if DISM.exe is the problem or how DISM.exe performs it's functions with this version and if there is any difference in what it does verses the older version.  i'm going to look at my unattend.xml file now and see if that helps.
    Friday, January 31, 2014 9:15 PM
  • Following workaround works for me:

    1. Remove Foundation Package from Unattend.xml
    2. Install features via 'Install Roles and Features' step in task sequence.

    I also escalated this to MS permier support. They have confirmed they can simulate this issue and they are working with product group.

    Tuesday, February 25, 2014 11:03 AM
  • Hi Kathuria,

    I still have the same issue after removing <settingspass=OfflineServicing>. below is my step and environment:

    Environment:
    Win2012 server

    MDT 2013

    ADK8.1

    Step:

    i) remove "<settingspass="offlineServicing">"section in the Unattend.xml (locate: deployment share\control\task sequence)

    ii) Edit Unattend.xml via task sequence->OS info

    iii) Update depolyment share

    Check the monitor and always failed at step 44. Does anyone knows whats going on of my MDT 2013?

    Thanks,

    BRs,

    Ares

    • Proposed as answer by Dark81 Sunday, March 30, 2014 8:16 PM
    • Unproposed as answer by Dark81 Sunday, March 30, 2014 8:16 PM
    Wednesday, March 19, 2014 8:52 AM
  • Fixed...

    Although I had updated the AIK and MDT to the latest versions, I had not updated the Lite Touch WIM that WDS uses to discover the MDT. Uploaded that and the issue has vanished and I can finally spend next week finalising my 8.1 Deployment.

    • Proposed as answer by Ares Wu Monday, March 31, 2014 1:43 AM
    • Unproposed as answer by Tony MCP Monday, March 31, 2014 3:21 AM
    Sunday, March 30, 2014 8:19 PM
  • Hi Dark,

    Yes. This is a fix that LiteTouch PE also need to be updated via MDT and replaced in WDS.

    step1: Update Deplyment Share -> Completely regenerate the boot images.

    step2: Open WDS -> Boot Images and replace LiteTouch PE.


    Ares Wu

    Monday, March 31, 2014 2:07 AM
  • Hi Dark,

    Yes. This is a fix that LiteTouch PE also need to be updated via MDT and replaced in WDS.

    step1: Update Deplyment Share -> Completely regenerate the boot images.

    step2: Open WDS -> Boot Images and replace LiteTouch PE.


    Ares Wu

    Great!  I'm glad you discovered a solution for your WDS problem, but the core problem described in my original post still exists :(

    My original reproduction steps do not utilize WDS.


    -Tony

    Monday, March 31, 2014 3:28 AM
  • Hey Everybody,

    I'm getting exactly the same error after updating ADK to 8.1. Everything went very well but after I did a DISM on install.wim to integrate IE9 MDT breaks with the same error.

    At this point i'm rebuilding the LitetouchPE wim files.

    I'll keep you up te date if this is also the solution for me.

    Very frustrating !!!!


    Tuesday, April 15, 2014 8:02 AM
  • In the seemingly extensive amount of research I've done in this particular matter, it seems as if it's an issue with IE 11 and how it interacts with the Unattend.xml file.
    Saturday, April 26, 2014 5:22 AM
  • In the seemingly extensive amount of research I've done in this particular matter, it seems as if it's an issue with IE 11 and how it interacts with the Unattend.xml file.

    What makes you think it's IE 11 issue? I am seeing issue with W2K8 R2 deployment and IE11 is not part of my W2k8 R2 build.
    Monday, April 28, 2014 8:00 AM
  • Hi Tony,

    (I have been sidetracked to other projects lately and I finally came back to MDT business ;))

    I faced the same issue last week and as soon as I remove all Packages such as RSAT, everything seems to be working.

    For example:

    When I have RSAT package (x86 and x64) for both Win7 and Win8.1 under "Packages" branch, both Win7 vanilla and Win8.1 vanilla task sequence had the same error.

    When I removed Win7's RSAT and run both Task Sequences, both Win7 TS and Win8.1 TS failed.

    When I put Win7 RSAT back and removed Win8.1's RSAT and run both Task Sequences, both Win7 TS and Win8.1 TS failed.

    When I remove BOTH Win7 RSAT and Win8.1 RSAT, both Win7 TS and Win8.1 TS worked!

    DISM.log was complaining about out of space and when I have both Win7 and Win8.1 RSAT on the MDT Packages, DISM seems to bluntly apply ANY x64 .MSUs and make it skip if it is not applicable.

    Maybe as RSAT is relatively too big and applying both Win7 and Win81 RSAT via DISM causing out of space error and make it fail???

    Anyway, this is my workaround:

    1. Remove everything from Packages section

    2. Create an Application Package to selectively deliver .MSU depending on the versions during the Post Install Task Sequence.

    Please try it and let me know if this is workable solution or not...

    Thanks,

    Young-


    YPae

    Saturday, May 24, 2014 4:26 AM
  • Hi Tony,

    I faced the same issue last week and as soon as I remove all Packages such as RSAT, everything seems to be working.

    DISM.log was complaining about out of space and when I have both Win7 and Win8.1 RSAT on the MDT Packages, DISM seems to bluntly apply ANY x64 .MSUs and make it skip if it is not applicable.

    Young-


    YPae

    Awesome, thank you for your assistance.

    However, I'm not using any MDT packages.  Please review my "steps to reproduce" section to confirm.

    You may have found a different, unrelated problem. I'm glad you posted your results in case it helps some else with your configuration.  But, unfortunately, it's not a solution/workaround for the original problem documented in this thread.

    Thanks anyway!


    -Tony

    Monday, May 26, 2014 8:06 AM
  • I'm facing the same issue, again it seems to be only impacting Windows 8.1 x64. It only started when I added in the various language packs, even if none of them are selected, aside from the default US English it still seems to hang on applying the unattend. Weirdly there is still network activity in the background but nothing on the machine to indicate progress.

    Anyone have an update on a fix? I can obviously leave the langpacks out and add them post deployment but they take a while to add in and there are 7 that I need to add so I'd rather they went in as part of the deployment.

    Friday, July 11, 2014 10:37 AM
  • So are you just trying to remove Media Center?

    Why not just use the uninstall roles and features in your task sequence? You can do that when you build your reference image so you don't have to worry about it during deployment.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, July 11, 2014 4:42 PM
  • So are you just trying to remove Media Center?

    Why not just use the uninstall roles and features in your task sequence? You can do that when you build your reference image so you don't have to worry about it during deployment.

    Actually no, I'm adding/removing several features.  But, for posting purposes, I created a super-simple set of "how-to reproduce" instructions to illustrate the bug.

    I know that I can use the "install/Uninstall Roles..." sequence item, but that doesn't correct the problem (see the last sentence of the original post).  However, it's exactly how I am working around the problem for now.  It is slower though.

    I was hoping someone at Microsoft would read my detailed problem description, follow my exacting & precise "how-to reproduce" instructions, and issue a fix.  I should have known better.

    Anyway, thank you for the suggestion.  Although I knew about it, I didn't document that workaround well, and your post maybe helpful to others.


    -Tony

    • Proposed as answer by George Simos Thursday, March 8, 2018 3:54 PM
    Tuesday, August 5, 2014 7:28 AM
  • Hi everybody!

    Although this is an old thread, I would like to provide my experience on the matter.

    I have an MDT 2013 U2 infrastructure with ADK 10 for 1607 version of Windows 10.

    The MDT infrastructure has been upgraded throughout the years and has been working without issues, apart from the common shenaningans of MDT :-)

    After the upgrade to ADK 10 and MDT 2013 U2, we have been using only the Windows 10 deployment Task sequences without issues.

    I needed to install a Windows Server 2012 R2 and tried to install one via our tested and trusted Task Sequence but it was failing miserably during the application of unattended.xml file.

    To be more precise I duplicated correctly the original Task Sequence because I didn't want to install any roles and features it had except the MPIO one.

    Searching for the error I got here, and to be honest the removal of the offline servicing from the unattend.xml file was a saviour but I didn't want to remove that section because if I wanted to apply drivers it wouldn't be feasible.

    Reading through the dism.log I have encountered entries created during the application of patches - "Apply Patches" step- which happens offline in the WinPE phase and yes it is an offline servicing job , you may take a look below:

    2018-03-07 07:08:46, Info                  CBS    Failed to parse the manifest from the buffer. [HRESULT = 0x800f080d - CBS_E_MANIFEST_INVALID_ITEM]
    2018-03-07 07:08:46, Error                 CBS    Failed to parse package manifest: \\?\G:\Windows\CbsTemp\780_403765\update.mum [HRESULT = 0x800f080d - CBS_E_MANIFEST_INVALID_ITEM]
    2018-03-07 07:08:46, Info                  CBS    Failed to copy manifest: \\?\G:\MININT\Scratch\F04C98D1-C3F8-4844-B695-89B623BD4A50\update.mum to private store and verify the content. [HRESULT = 0x800f080d - CBS_E_MANIFEST_INVALID_ITEM]
    2018-03-07 07:08:46, Info                  CBS    Failed to initialize internal package [HRESULT = 0x800f080d - CBS_E_MANIFEST_INVALID_ITEM]
    2018-03-07 07:08:46, Error                 CBS    Failed to create internal package [HRESULT = 0x800f080d - CBS_E_MANIFEST_INVALID_ITEM]
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed opening package. - CDISMPackageManager::Internal_CreatePackageByPath(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed to get the underlying CBS package. - CDISMPackageManager::OpenPackageByPath(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed to open package at location [\\MDTServerName\MDTProduction$\Packages\SecurityUpdate\amd64_Package_for_RollupFix_14393.1358.1.9_neutral_31bf3856ad364e35_\Windows10.0-KB4022715-x64.cab]. - CPackageManagerUnattendHandler::Internal_InstallPackageFromSource(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed to install package from source [0] - trying next source location. hr = [0x800F080D] - CPackageManagerUnattendHandler::Internal_UnattendInstallPackage
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed to Install the package [Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1358.1.9]. - CPackageManagerUnattendHandler::Internal_UnattendInstallPackage(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Package failed to install [Package_for_RollupFix~31bf3856ad364e35~amd64~~14393.1358.1.9]. - CPackageManagerUnattendHandler::Internal_UnattendProcessPackage(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed to process package at node <package[1]>. - CPackageManagerUnattendHandler::Apply(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Package Manager: PID=780 TID=8 Failed to Apply the unattend. - CDISMPackageManager::Apply(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Unattend Manager: PID=780 TID=8 Error applying unattend for provider: DISM Package Manager - CUnattendManager::Apply(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Unattend Manager: PID=780 TID=8 base\ntsetup\opktools\dism\providers\unattendprovider\dll\unattendmanager.cpp:728 - CUnattendManager::InternalExecuteCmdLine(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM Unattend Manager: PID=780 TID=8 base\ntsetup\opktools\dism\providers\unattendprovider\dll\unattendmanager.cpp:677 - CUnattendManager::ExecuteCmdLine(hr:0x800f080d)
    2018-03-07 07:08:46, Error                 DISM   DISM.EXE: DISM Unattend Manager processed the command line but failed. HRESULT=800F080D
    
    

    This has happened three (3) times in the log, exactly as many the offline patches are in my packages section.

    So I did the obvious, I went in the Task Sequence and disabled the "Apply Patches" section, then I restored the offline servicing entry in the unattend.xml and went to try the deployment.

    The result was succesfull! What I haven't yet tried is the drivers injection during the WinPE phase, if they generate the same error then it seems that DISM or another component used is not handling correctly the offline servicing tasks for Operating Systems prior the current ADK supports.

    And I support Tony's suggestion that this is a bug and it is a serious one.

    Last but not least kudos to Tony and Keith you are my savers, you helped me find the issue !


    George Simos former MVP in Configuration Manager, MCT, MCSA, MCITP Enterprise Admin, MCTS Virtualization & ConfigMgr

    Thursday, March 8, 2018 3:54 PM