Michael Niehaus' Windows and Office deployment ramblings
One of the slow operations in the MDT Deployment Workbench is the initial “Update deployment share” process that has to completely generate new Lite Touch boot images. I always assumed that this was slow due to the amount of I/O being generated by the update process.
Recently, ATI and Dataram released a trial version of their RAMdisk software at http://www.radeonramdisk.com (not that I am endorsing the product – it just happened to come through my Twitter feed and it works on Windows 8), so I had a chance to test the assumption: What would happen if the temporary storage used by MDT to generate the boot images would be on a RAMdisk?
So I installed the software on my laptop, created a 2GB RAMdisk, and formatted it as an NTFS disk. First, I “completely regenerated” the MDT boot images without using the RAMdisk. That process finished in six minutes and 15 seconds (6:15). Then, to get it to use the RAMdisk, I did the following:
That looks sort of like this:
So what difference did it make? Well, instead of 6:15, the whole process finished in 4:55. Not too shabby, about 20% faster, but I expected more. So why wasn’t it any faster? Well, it turns out it’s just a case of shifting the bottleneck. Watching the process using ProcMon and the Windows 8 task manager, I could see that the process was CPU-bound; the RAMdisk utilization was negligible. Hmm, I guess it’s time for a faster CPU…
The trial software doesn’t support server OSes or more than 4GB of RAM; you have to purchase the full version for that. Maybe I’ll try that sometime: Imagine a VM where the entire VHD is in a RAMdisk. I wonder how long that would take…
Stumbled upon a free ramdisk tool the other day: www.starwindsoftware.com/high-performance-ram-disk-emulator
Should be supported on server OS as well...
Is it feasible to modify the source for "update-MDTDeploymentShare" to take advantage of multi-thread CPUs or the GPU (CUDA)??
Not really, as the CPU bottlenecks appear to be in two areas: mounting the Windows PE WIM file, and servicing that WIM file using DISM.EXE. So the improvements would need to come from those operations.
There are some improvements to those operations already in the ADK versions of the tools. I can see that both of my laptop's CPUs are being utilized by the operations (although the second one doesn't quite get to 100%).
"Imagine a VM where the entire VHD is in a RAMdisk" . You may try the Qsoft Ramdisk for this , see
I did that already with another RAMDisk, see blogs.technet.com/.../more-experimenting-with-ramdisks-using-a-vm-completely-in-ram.aspx.