{"id":424,"date":"2006-11-13T06:56:00","date_gmt":"2006-11-13T06:56:00","guid":{"rendered":"http:\/\/markwilson.me.uk\/blog\/2006\/11\/windows-vista-imaging-and-deployment.htm"},"modified":"2007-11-22T12:28:30","modified_gmt":"2007-11-22T12:28:30","slug":"windows-vista-imaging-and-deployment","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2006\/11\/windows-vista-imaging-and-deployment.htm","title":{"rendered":"Windows Vista imaging and deployment"},"content":{"rendered":"

However much I try to avoid it, as an IT infrastructure consultant, I always seem to get involved in operating system deployment. With that in mind, a couple of days back, I went along to an event at which Microsoft UK’s James O’Neill<\/a> gave an interesting presentation on Windows Vista imaging and deployment.<\/p>\n

Deployment of a PC operating system ought to be simple. It isn’t. Well, it can be, but only after a lot of hard work and planning. You see, unlike a closed system such as Apple Mac OS X, a Windows deployment typically has to support a plethora of different PCs – each with their own hardware variants (very few organisations have the luxury of a 100% standardised infrastructure – IT hardware simply changes too quickly for that). For many years now, the approach to deploying a PC operating system has been to use imaging software, e.g. Symantec Ghost, but there are complications around which images can be applied on what hardware, as well as licencing implications for any software included in the image – often images are created based on a combination of target hardware and end-user roles. Then there’s the data to consider – how are applications to be deployed, what will happen to user data (e.g. in an upgrade scenario), and what about system settings (Outlook profile, etc.). A managed deployment has many advantages around consistency (between images), manageability and reliability; however there is a huge cost attached to maintaining each image.<\/p>\n

Since the creation of Windows NT, administrators have been able to automate Windows deployment using a system of answer files and either a product CD or a distribution share. This can be customised to roll out additional applications as well as to alter the Windows configuration and add OEM-specific items and it works well, but is slow to deploy and costly to maintain (often scripted installations are used to deploy to reference PCs from which images are taken).<\/p>\n

Windows 2000 introduced the concept of booting a PC across the network using the pre-boot execution environment (PXE) to connect to a remote installation services (RIS) server and download an image. Later, this was extended to create the solution accelerator for business desktop deployment (BDD)<\/a> and enhanced through the creation of Microsoft automated deployment services (ADS) – now renamed Windows deployment services.<\/p>\n

Windows Vista employs a totally new deployment approach – using Windows Image (.WIM) files – look on a Vista DVD and there is no i386 folder (the main setup file on my Vista RC2 DVD is called install.wim). Those who have worked with BDD and ADS may already be familiar with an older version of the .WIM file format and the new version supports deployment to a new system, side-by-side installation, or in-place upgrades (actually, an in-place upgrade is a side-by-side installation which then transfers the settings from the old copy of Windows, which can safely be destroyed later). The Windows imaging approach supports modularisation of components, single instance storage, compression and file-based imaging – allowing many images and many image variants to be installed in a single .WIM file for deployment from optical media, or using deployment solutions such as BDD or Microsoft SMS. Importantly, deployment is non-destructive. Furthermore, Windows Vista does not have any of the restrictions around hardware abstraction layers (HALs) and so there is no requirement for hardware-specific images; and because the image is file-based (cf. disk block-based images), it can be mounted as a file system and manipulated offline.<\/p>\n

.WIM files are structured as follows:<\/p>\n