Got a great question from a reader today: “I hear you often explain you have two deployment shares. Have you discussed this before on how you set this up? I’m just starting into MDT and am curious of best practices.”
This is actually a very good question, basically we can use MDT to build images for us as well. I use one share to build images and another roll them out to users. This makes building images faster, more consistent and reliable. Since you need to do it about every six months at the very least, it also removes human error from the tedious checklists that I am sure you are used to. The build share uses the same standard client task sequence you use to deploy the OS, it just starts with the vanilla .wim from the .iso. We add a few additional steps like installing office, dotnet4.5, VC++ and pausing to let you manually tweak a few things here and there before resuming the build. The pause is done by adding a call to the LTISuspend.wsf script hidden inside MDT.
The reason you use two shares simply comes down to the fact that settings that would be appropriate in your build share wouldn’t be appropriate in your production share and vice versa. For instance, there are settings in the .ini file that automate the image capture. The setting DoCapture=YES is configured in my buildshare for example. The production share also has drivers that you want to keep far away from the build process as I am sure you know when it comes to images, driver free is the way to be.
As far as best practices are concerned, I cannot stress the following point enough because at least once a month I have to explain to somebody one very key point: ALWAYS build your images in a Virtual Machine. By building a “driverless image” in a VM, you effectively ensure that the image will run on anything; a laptop, a desktop, an HP, a Dell, or a Lenovo. Don’t worry about drivers in your image. MDT can be configured to inject the drivers “automagically” in the productionshare using the glorious “total control” model taught by Mr. Johan Arwidmark