locked
MDT 2013 Update 1 Issues with WIM files after creating USB media RRS feed

  • Question

  • HI Folks,

    I have been tinkering with the latest MDT Deployment software and latest ADK see versions below:

    MDT: 

    Microsoft Deployment Workbench 2013 Update 1

    Microsoft

    Version: 6.3.8216.1000

    ADK: [Version 6.3.9600]

    My issue is as follows, I have imported an existing deployment share to test and updated files as requested by the application. I have then created a selection profile and created new media to allow me to test and create USB media. This all seems to work, however when I made some changes to the share and regenerated the media, It cannot find the operating system wim files. Looking in to the folders, it seems that the wim files have been split and changed to swm files. I was aware that this behavior is correct for the files that will be used for the USB media, but I was surprised that the original wim files from the deployment share were also changed.

    To me it looks as if there is step missing somewhere and instead of maybe using a shadow copy of the original files the process is using the original files and forgetting to copy them back to the deployment share as full wims. This is the second time that I have seen this issue but not having much time I had ignored it. At some point I would like to update a production system but I am worried that this issue may break my custom imported wim files.

    I have had a search on the web and not really been able to word my search to get any relevant results back. I would be surprised if I am the only person to have seen this issue and was wondering if anyone had any ideas why this is happening.

    Thanks in advance,

    Ewen.

    Saturday, July 18, 2015 5:46 PM

Answers

  • Hi there,

    Thanks for the answer.

    Yes the original WIM files in the Deployment share are being replaced by, in my case 2 swm files. The original wim file is being copied out to a folder in %TEMP%. The process seems to complete correctly with the 64 bit images I am using in my task sequence.

    I have copied from Johans blog the process that mdt uses when creating USB media, see below:

    Findings: The really interesting part, which I consider kind of a design flaw, is that the media update action first of all splits the big WIM every single time you run the update, no matter if the big image changed or not. Second, it’s using ImageX.exe to do the split which is supposed to be deprecated (DISM does support split too). Third, it’s using a quite resource intensive workflow for splitting the WIM and update the media. MDT does the following when having the deployment share on a data disk:

    1. Splits the big WIM using ImageX and stores the SWM chunk files in the original big WIM folder in the MDT deployment share.
    2. Moves the big WIM from the MDT deployment share to %temp%. However it’s  really a copy and delete since %temp% is on a different volume by default.
    3. Copies the SWM files from the deployment share to the media folder. Yes, copies, even if they are on the same volume, not moving.
    4. Moves the big image from %temp% to the MDT deployment share. Again really a copy and delete since %temp% is on a different volume by default.
    5. Deletes the SWM files in the MDT deployment share
    6. Done.

    As I have said the final copy back on my x86 image is not happening. I am not getting any errors apart from the obvious when I try to reupdate the media and the wim file for the x86 task sequence is not found.

    I would post a log file but I am not sure where to find the relevant log. Is it the audit.log file in the Deploy folder in the USB media? If so I cannot see any reference to imagex\Dism or copy errors.

    I have also raised a bug in the connect portal.

    Thanks in advance

    Ewen

    • Marked as answer by Ty Glander Thursday, January 12, 2017 1:04 AM
    Thursday, July 23, 2015 9:46 PM

All replies

  • Just thought I would update some details:

    ADK is version: 10.0.26624 not 6.xxxx as I said above.

    I also noticed something today, I had the folder open containing one of my custom wim files that is is in the deployment share that I am ultimately using to generate the USB media. The folder\wim file was a x64 bit wim file. What I noticed was, this wim file gets split during the process, then when complete it is returned as full wim file. I then opened up the other custom wim folder which has a x86 wim contained within. I regenerated the USB media and watched the main wim file get split to 2 swm files, all good, however once complete the original wim file is not returned as per the x64 bit wim.

    This is a pain as I need to keep copying a backup wim file into the x86 folder to retest. 

    Ewen.

    Sunday, July 19, 2015 2:35 PM
  • Are you talking about the WIMs in your deployment share?  They shouldn't be deleted.  Can you post your logs?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, July 20, 2015 4:15 PM
  • Hi there,

    Thanks for the answer.

    Yes the original WIM files in the Deployment share are being replaced by, in my case 2 swm files. The original wim file is being copied out to a folder in %TEMP%. The process seems to complete correctly with the 64 bit images I am using in my task sequence.

    I have copied from Johans blog the process that mdt uses when creating USB media, see below:

    Findings: The really interesting part, which I consider kind of a design flaw, is that the media update action first of all splits the big WIM every single time you run the update, no matter if the big image changed or not. Second, it’s using ImageX.exe to do the split which is supposed to be deprecated (DISM does support split too). Third, it’s using a quite resource intensive workflow for splitting the WIM and update the media. MDT does the following when having the deployment share on a data disk:

    1. Splits the big WIM using ImageX and stores the SWM chunk files in the original big WIM folder in the MDT deployment share.
    2. Moves the big WIM from the MDT deployment share to %temp%. However it’s  really a copy and delete since %temp% is on a different volume by default.
    3. Copies the SWM files from the deployment share to the media folder. Yes, copies, even if they are on the same volume, not moving.
    4. Moves the big image from %temp% to the MDT deployment share. Again really a copy and delete since %temp% is on a different volume by default.
    5. Deletes the SWM files in the MDT deployment share
    6. Done.

    As I have said the final copy back on my x86 image is not happening. I am not getting any errors apart from the obvious when I try to reupdate the media and the wim file for the x86 task sequence is not found.

    I would post a log file but I am not sure where to find the relevant log. Is it the audit.log file in the Deploy folder in the USB media? If so I cannot see any reference to imagex\Dism or copy errors.

    I have also raised a bug in the connect portal.

    Thanks in advance

    Ewen

    • Marked as answer by Ty Glander Thursday, January 12, 2017 1:04 AM
    Thursday, July 23, 2015 9:46 PM
  • Yeah connect bug is probably the right way to go.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, July 24, 2015 12:31 AM