Time is relative. Whatever. I mean, who is the “Einstein” who came up with that one? :^)
Have you ever heard of a New York Minute? I guess time is different in the big apple.
What about “Microsoft Time”, you know where the progress bar says it’s 90% complete with 2 minutes remaining, but the next time you look. Pow! The progress bar now says 91% complete with 5 minutes remaining! How can it take negative 3 minutes to go 1%?
Of course the problem is that in a Modern OS there are thousands of different components that can affect performance. Memory Exhaustion, other background processes and other systems each fighting for limited resources.
Anyways, in the realm of OS deployment performance, things are relative. An OS deployment that took 1 hour might seem fast to you on a Virtual Machine, but it’s slow to me on a new Desktop.
How do we make MDT go faster? Easy, find the bottlenecks! One of the best places to start when using MDT LiteTouch deployments is by looking at the BDD.log file. The BDD.log file will show all the steps taken during a full OS Deployment.
- Booting to WinPE
- Interacting with the user with the Wizard
- Formatting and Reparitioning the disk
- downloading the OS *.wim file
- Full OS Installation
- State Capture and State REstoration
- Installation of Applications
Of course, when reading bdd.log files, I highly recommend using the CMTrace.exe tool found in the
System Center 2012 R2 Configuration Manager Toolkit. The CMTrace.exe reader can parse otherwise complex bdd.log files and display the relevant information in a table (these tables can even be imported/exported into Excel).
We can follow the date/time that each steps was performed, and determine how long operations took. One cool feature is the ability to highlight a set of commands and see what the elapsed time was to perform the command. Note the “Elapsed Time” at the bottom of the CMTrace.exe window?
We can use this information to make educated guesses on where to improve our processes. For example if we can see that it takes 2 hours to apply a 4GB installation image from our MDT server when the server is under load, I would suggest looking into configuring the server for multicast.
Or perhaps we can see that a single application installation is taking too long. Can we can then investigate why that application is taking too long.