Be default the capture process in MDT 2013 uses ImageX to capture the image, there is nothing wrong with that, well, it takes time since Imagex takes about 15 minutes or more just to scan the file system before it starts to capture the image and maybe you would like to get rid of that time. That is possible by doing some modification to one of the scripts in MDT so that it starts to use DISM.exe instead
The script that needs to be modified is ZTIBackup.wsf and you can download the updated version here. (Please make sure you have a copy of the previous version so that you can go back for any reason.)
(Important note: I have updated the script since I missed to include settings that will honor the wimscript.ini file, without that the image will not be cleanup from junk and therefore larger. So, if you did download the script and used it, download it once more, since it is now updated)
As a bonus this also fixes the problem to append the wim file to an existing wim file.
How-to?
- Download the file from here: http://1drv.ms/1gZICln
- Rename the Scripts\ZTIBackup.wsf to ZTIBackup.old
- Clear the Internet download flag from the new ZTIBackup.wsf.
- Copy the new ZTIBackup.wsf to the Scripts folder.
Done.
/mike
Share this:
Categories: Deployment, Lite Touch, MDT
The Deployment Bunny 
And if you ever need the original file from any version of MDT, have a look at http://mdtcustomizations.codeplex.com/SourceControl/latest#Original scripts/Versions/ ;-)
Yes Sir! Thank you!
Great site. I have no idea why but my feel after using the script is that it took longer to create the WIM file. Not sure if network traffic can be blamed for it. None the less, thanks for all the great info you provide on the site. Kudos.
No, it was me, I missed to include the wimscript.ini file in the command, the script has been updated to do that now, sorry…
That’s a great idea, DISM is the imaging tool of today. I definitely had to try it, but I noticed that my captured images are about 500mb bigger after making this change.
Yes, my fault. The script has been updated to honor the wimscript.ini file to exclude junk when performing the capture. Please download the new script and re-create the ref image, sorry about that
Fast reply, I’m trying the new script right now. Great work!
Thanks, there will an other post up real soon and just maybe you would like that even more, stay tuned :-)
Mikael, I was having a problem when using this script to capture my reference image. When I would deploy them with ConfigMgr, the TS would fail when trying to apply the WIM file. The SMSTSLog file would show “Permission for the requested failed”. After switching back to the default ZTIBackup.wsf script, the TS completed fine. Any idea of what may have caused that?
Yes, the first version of the script was “bad”, I published the script that did not use the wimscript.ini file while doing the capture and therefore it left junk in the image that was from the ref image creation process, that is now fixed.
ok
good.
Can this be used in MDT 2012 Update 1?
if I remember the DISM command is in the previous version of WinPE and if that is correct, yes, it will work. I just cant remember if DISM is in that WinPE version.
It worked for me.
Perfect, yes, it should, but I did not tested, thanks for that report :-)
Thanks for putting this together. After doing this, though, the progress indicator doesn’t show. It looks like DISM doesn’t output its progress to stdout like ImageX did, so guessing it’s just a limitation of DISM?
Yes, that is correct.
When I try to use this script in SCCM, I receive an error from DISM: User profile failed to load.
Any ideas?
Thanks!
Not really, since I never,ever capture an image using ConfigMgr. I use MDT and LTI for that and deploy using ConfigMgr. That is the recommended way even if you ask Microsoft
Recommended by Microsoft. Meh. ;) Well, if someone else comes across the issue and a fix, I would love to hear about it!
Or start creating the ref images using MDT since that is the only working solution today. :-)
Just ask around, it is a pretty common method
We’re actually using this to create a WIM backup of a user’s machine coming out of lifecycle in lieu of Symantec Ghost. We build our reference images using VMware or Hyper-V or VHD.
ok, well, it should work without any issues, I just never tested it. As long as your WinPE version have DISM in the path it should work
Yeah, it’s PE for 8.1 and below so it has DISM in it. The error’s just very odd and does not occur if I run DISM manually via cmd in PE. Not sure why the script would want to try and load a user profile…
Just to let you know : I jhave the very same issue with MDT 2013, Windows 8.1 and Hyper-V … DISM i hate you !!!!
Hi Diagg,
Realize that it has been a while but I decided it was best to ditch VB and this WSF file in my backup routine. Instead, I am using PowerShell and the DISM cmdlet functions. Particularly the new-windowsimage command works wonderfully.
In my scenario, I built a script to identify the OS partition and assign a variable to it. Then I applied that variable in the new-windowsimage command. Pretty easy and tons faster than using imagex or DISM. It did a 55GB backup in no time compared to over an hour or longer with imagex and the WSF script.
Good luck!
Hi,
as this is my first post here i’d like to thank Mikael for his great work that he’s sharing here at deploymentbunny.com.
In the past, some of your postings litterally safed my day!
Today i ran over this threat as i was trying to find a way to optimize the WIM image creation process since i am missing the “description” flag at images captures using MDT LightTouch deployment.
to claryfy:
running “dism /Get-WIMInfo /WimFile:d:\sources\install.wim” at the orginal Microsoft DVD you’ll getting something like:
Index: “1”
Name: “Windows 8.1 Pro”
Description: “Windows 8.1 Pro”
Running the same command at my fresh reference image WIM file i get something like:
Index: “1”
Name: “REFW8X64-001CDrive”
Description: “”
Integrating such a WIM into my original media is causing problems during installation without editing the “Description” field to it’s supposed value using imagex like:
imagex.exe” /info “mywimfile.wim” 1 “Windows 8.1 Pro” “Windows 8.1 Pro”
All this wouldn’t be necessary if we’d use MDT also for OS rollout but my department is using ACK from Aagon instead. This solution unfortunately can´t handle wim files directly and therefore always needs the full set of files according to the original windows dvd.
Do you have any idea on how set the “Name” and “Description” value while running ZTIBackup.wsf ?
I just tried your ZTIBackup.wsf version but it doesn’t set the values eather. Besides, it is unfortunately also not setting the “FLAGS” value.
Best,
Phil
Is there any benefit to switch imagex when applying image to new machine? I think MDT uses images to write image.
You save around 15 minutes of the capture process when capturing Windows 8/Server 2012 and above. Imagex spends 15 minutes trying to figure out the new file system before it starts the capture
No edit button :) Any benefits switching imagex to dism when applying image to new machine? I think MDT is using imagex when applying image file to new machine.
This worked without any problems what so ever. Yhank you verry much indeed!
A question thoe.
Woud there be any gains to use this aproach to deploy the captured image?
Or to clearify futher. Can one substitute ImageX with DISM when deploying and is there any gain in that? And lastly is there parhaps a script to download ready made for this scenario?
/Rab.
HI, no, there is no benefit today to change when you apply an image.
Looks like this is no longer need in MDT 2013 Update 2, the ZTIBackup script is calling DISM.exe instead of ImageX
Correct, someone at Microsoft thought my idea was great :-)