Thick vs. Thin Images. The distinction between these two is somewhat subjective so I will start off with my simplistic and generic definitions. Both are generic descriptions of what should be included in an image.
Thick Image: An image that includes the OS, OS updates and patches, miscellaneous components, drivers and applications.
Thin Image: An image that contains only the OS and a very minimal set of updates and patches.
So why, in theory, is a thin image better? Because it is easier to maintain; it contains a minimal set of components and thus a smaller set of components that must be updated.
I don’t agree with this thin vs. thick theory in whole however. Like many theories, they sound great, but reality gets in their way. Maintenance of images should be automated and should be a minor concern: see part 1 of this series for a further explanation.
There are a few goals for the master deployment image(s) and ease of maintenance is not one of them:
- Hardware agnostic. Few organizations are actually able to standardize on a single hardware system for al of their desktops, so this goal should be obvious. What might not be readily obvious is that it is achievable. The main obstacles to this goal are drivers and the Hardware Abstraction Layer (HAL) in XP. Part 3 will cover this one.
- Universal. Images should be a baseline for all deployments in an organization, they should contain the least common denominator of all the desktop needs in an organization. If not everyone in the organization needs an application or component, it shouldn’t go into the image and instead should be layered on after the image is deployed. Part 4 will cover this one.
- Deployment Speed. This is not as important as one and two, but is still worth including and does become very important if network is not as fast as it should be or a WAN is involved. Applications and components included in an image only slightly increase the time it takes to deploy a system because they are already installed and do not have to be pulled across the network separately. Applications and components layered on after the deployment increase the time significantly because they must be installed and pulled over the network. Typically installations include some files that aren’t even installed on the system, so this can have a greater impact than is first realized.
Ultimately, I honestly feel the thin vs. thick is a moot argument. Every deployment image will probably be somewhere in the middle and what is right for one organization may not be right for another. However, I do feel strongly that having a thin image, just for the sake of having a thin image, should not be a primary goal. Maintenance of images, if automated and done correctly, is a minor concern.
