When we look at utilizing the WIM format and MDT, there are essentially three schools of thought in building what is commonly termed a golden image in deployment. These are the thick, thin, and hybrid images. They each have their merits and rather than adhere to a single one, I tend to view each as a tool in the deployment toolbox. So depending on the situation and customer needs, I would recommend one over another:
Thick Image: A thick image is an image that contains a patched operating system plus all applications used in the environment. It is large, sometimes problematic to deploy, and has some interesting licensing implications as well in that every deployed system has every piece of software installed.
Sometimes a thick image is the best option due to logistics. Imagine you need to deploy Windows to systems on a submarine or a cruise ship. Sending media containing a thick image by freight/helicopter might be an answer versus deployment from a share.
Thin Image: A thin image is (as one might assume) an image that contains nothing except a patched operating system. It is quick to deploy, but customization post-deployment can take quite some time, even by automated scripts. This is a minimalist approach but has merit when you need an image of the smallest size or only a few diverging applications from a golden base image.
Hybrid Image: A hybrid image is an image that contains a patched operating system and core business applications, typically applications for which the business has a site license. Typically, some limited customizations occur post deployment with these images as part of a task sequence.
Applications, drivers and packages are three components that can be included in the image, depending on type of image. These are defined clearly in the MDT documentation and UI, but need introduction here:
Applications: Applications are usually software installation packages one wants to place into the image or deploy as part of the task sequence itself. Sometimes driver packages can fall into this category as well. The Hewlett-Packard ProLiant Support Pack is a great example of a bundled offering of driver and firmware updates for systems that work best when run as an installation (application in MDT) rather than as a Plug and Play (PnP) operation. Further, many Bluetooth driver stacks, network teaming software, and video graphics driver packs fall into this grouping. They may install in PnP, but do not behave properly unless run as a packaged installation. Generally, this is a result of the installer checking/updating firmware as part of the installation, and PnP just adds the driver and moves on.
Drivers: Drivers are components usually provided by the hardware manufacturer (hopefully in concentrated CAB files for ease of deployment, we will discuss it later). These drivers can (and usually should) be provisioned using mandatory driver profiles, but for small scale or single model deployments, the natural PnP feature of Windows can be used to select and install drivers from MDT.
Packages: Packages are updates from Microsoft to address a problem or defect in the operating system. Typically, these are pulled from the Microsoft Update Catalog and then imported into the MDT console for application to Windows PE or the image itself.