Wednesday, 15 June 2011

What works in Windows 7 imaging and what doesn’t

With all of the experience I have amassed in Windows 7 imaging this year and with our experiences of different technologies it is becoming abundantly clear what works and what doesn’t, for the number of computers that we have.

  • What doesn’t:
    • MDT. Although this has a great deal of promise it is too complex for an organisation of our size. In order to get the best out of MDT it is necessary to spend a lot of effort setting and maintaining MDT itself, as well as scripting the installations for different platforms. This includes scripting the automatic installation of third party applications that don’t always work or aren’t as well documented or supported.
    • Deploying images that have been sysprepped from installation on one particular hardware platform. Our experience has been that it only takes small changes in a target hardware configuration for Windows to refuse to complete installation from an image that has been sysprepped, regardless of which drivers are involved.

The second point is a particularly troubling one. Our experience with Windows 7 is that it can refuse to complete installation from an image if the hardware is slightly different even where the drivers are not boot critical. This appears to be a fatal flaw in Windows 7 that should not even be an issue. If a device is not boot critical then it should be disabled and the installation continued allowing the affected device to be set up at a later time.

The second point also has an impact on MDT since it is sysprepping an image before it is captured. It may be that MDT’s driver injection process can work around this limitation but not having been aware of it at the time and not being a user of MDT now I can’t say if that is the case.

Along with the built in sysprep limit, this has caused me to review our imaging strategy as below.

  • What does:
    • Native VHD imaging. A great technology that makes it easy to deploy and back up images on target platforms simply by file copying procedures.
    • Deploying pre-sysprepped images to a target and sysprepping only that target as the final setup step. DISM is used only if there is a problem with a boot critical driver.

We have basically proved with our imaging experience to date that a pre-sysprepped image can be deployed to a relatively wide range of hardware. If there is a boot critical problem with such an image it is a relatively easy process to service the image with DISM and inject the necessary driver to the image to get it to boot on the target. Pre sysprepped images do not have the same problem with missing or incorrect drivers that sysprepped images do unless the driver is boot critical, such as for a hard disk or disk interface.

Because all images are only sysprepped as the final deployment on that computer, there is not going to be a problem of drivers providing that the pre sysprep image contains all the correct drivers for the target.

There will be fewer generations of images to store and thus a saving in disk storage space.

There will also not need to be as many different images for different hardware platforms especially those that are not used very often.