I want to use the Deployment Workbench to create OS images that will be deployed from multiple WDS servers using the PXE boot process.

It seems like support for this kind of functionality is a glaring omission in the Deployment Workbench.

I’m using MDT for Vista/Server 2008 builds and deployments, with limited XP usage (refresh/upgrade and post deployment configuration). Right now we have one “thick” image that serves 80% of our users needs and customization post-deployment to serve the other 20%.

IMHO, it should almost always make sense to find an automated way to rebuild your images. Automation is the key to productivity. There are different methods/products to do this but I’ve found MDT to be the most compelling, feature/flexibility/support wise. Of course, if you make a very small number of changes, the time it takes to set up the automation may not make sense.

jools86,

I don’t see what a custom app that duplicates MDT’s functionality adds the table besides extra cost and time. MDT already provides you with a framework to do what you will. While it’s not perfect, (we’ve had to add a few custom VBScripts/HTAs to add functionality) it’s pretty close. At this point, writing a custom app to do this kind of stuff is reinventing the wheel.

As for the documentation, I have to agree with you there. There is a lot more that could be done in that area and I find myself gleaning more from the Deployment Guys blog than the official documentation.

Anyone with multiple OUs, Core Applications, extra lock-downs are far better off scripting their own WINPE/HTA and associated UNATTEND.XML file with associated VBScripts with a good old-fashioned Network Share called VistaBuild or something like that.

XML processing is pretty simple in VBS and you would be suprised how easy it is to edit an XML file on the fly.

Another thing is the shoddiness of the documentation and the inability to provide coherent discussion of creating a standard Domain based SYSPREP Deployed Image.

The solution you describe is exactly the kind of thing MDT can help you automate. Lets say you have multiple images for different scenarios in production. Lets also say you need to upgrade an application that is common to some or all of these images.
Here’s what I see as your choices:

A) Deploy all of your affected images to build machines, upgrade the app, re-sysprep and re-package.
B) Rebuild all of your affected images from scratch with the new application, sysprep, package.
C) Change the application in one place in MDT, have it rebuild all your images for you.

A is painful and results in a slightly dirtier image. B is REALLY painful, results in a clean image but there is more of a chance something has been forgotten or left out of the image. C gives you a clean, consistent image with only the changes you want.

Better yet, if you set up your MDT /app repository structure with change control and versioning built in, you can automatically create testing and production images with little more than dragging and dropping application packages in the right place. Maybe I’m not seeing the whole picture, but in the environment I’m in, this is pretty exciting stuff.