Introducing the Microsoft Deployment Toolkit 2008

This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the sessions that I managed to catch at UK customer launch for Microsoft’s 2008 products last week was Julius Davies’ and Jason Stiff‘s presentation on Windows Server 2008 (and Windows Vista) deployment. I recently spent some time brushing up my deployment skills but there have been a few developments since then – not least the rebranding of the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) as Microsoft Deployment.

With Windows Vista and Windows Server 2008 now sharing a common codebase, the same techniques can be applied to both client and server deployment. Conseqently, whilst still consisting of a combination of documentation and tools to provide guidance for deployment best practice, the Microsoft Deployment Toolkit (MDT) 2008 is equally applicable to Windows Vista (including SP1) and Windows Server 2008 (as well as certain downlevel operating system releases) – hence the removal of the emphasis on the business desktop.

As for its previous incarnations (I recently wrote an overview of BDD 2007), Microsoft Deployment 2008 provides for “lite touch” or “zero touch” deployment. Lite touch deployment is primarily about the creation of images for deployment from DVD, using Windows Deployment Services (WDS) or another method. Zero touch deployment relies on Microsoft System Center Configuration Manager (SCCM) to provide a management framework but both use the same core tools (Windows PE, ImageX, etc.).

As with BDD 2007, MDT 2008 includes a deployment workbench with an information center (documentation, news, and components), distribution share (operating system, applications, packages – e.g. language packs, and drivers), task sequences (with major OEMs to provide their own extensions to the XML), and deployment (deployment points and database) – now including multicast support (which even Microsoft note is overdue) using Windows Deployment Services. With the zero touch installation, MDT is used to extend the SCCM site server and provide similar concepts to the deployment workbench, including the ability to import task sequences from MDT and take them further (for example to provide role or feature-based installations).

In terms of roadmap for MDT, an update is expected in June 2008 to support System Center Configuration Manager 2007 service pack 1 as well as enhanced OEM support and further configuration elements. Further out “deployment 5” is expected to include an expanded product knowledge and cater for role based deployments using a “hydration” process for common applications.

Whilst on the subject of deployment, Garry Martin sent me a link to Dan Cunningham’s Workstation Migration Assistant – effectively a wrapper for the Microsoft User State Migration Toolkit (USMT). It looks like it could be a useful tool in the migration engineer’s arsenal – The Deployment Guys have more information on their blog.

Office 2007 Customisation and Deployment using BDD 2007

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Over the years, the various methods available for customising and deploying Microsoft Office have advanced considerably and so here are a few notes on customising and deploying the 2007 Microsoft Office System using the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) 2007:

  • The first step is to create a network distribution point.  This is easily achieved using the BDD 2007 workbench (Distribution Share, Applications, New), with the additional advantage of integrating the Office 2007 files into the BDD distribution folder structure (e.g. D:\Distribution\Applications\Office2007).
  • The BDD workbench will also enable the application (by default) and allow the entry of additional information on the General tab.  The Dependencies tab can be used to control the order of application deployment within the BDD logic.  There is also a tab for Office Products which can be used to configure the deployment of Microsoft Office.
  • To save disk space, additional Office System components may be added to an existing distribution point.  Multiple languages may be integrated in the same manner – i.e. by adding the files to the application within BDD Workbench.
  • Office 2007 is always installed via setup.exe rather than with individual Windows Installer (.MSI) packages.
  • The Office Customization Tool (OCT) is used to create or edit Windows Installed Patch (.MSP) files to customise Office installations:
    • It may be launched from the command line using setup.exe /admin or within the BDD Workbench using the Office Customization Tool button in the application properties.  The OCT replaces the Custom Installation Wizard and Custom Maintenance Wizard tools in previous Office versions.
    • The OCT language interface will match the regional setting for the application (rather than the operating system language).
    • OCT allows the specification of multiple network sources (in case the primary is not available). By default, all necessary files are copied locally first and setup is launched from this cache – the local installation source (LIS).  If the installation is modified later then setup with use the LIS before attempting to locate network sources.
    • By default, .MSP files are saved in the Updates folder on the application distribution point.  Setup scans this location when it runs and will retrieve application settings from .MSP files.  If multiple .MSP files exist then the first one (in alphabetical order) will be used.
    • When editing .MSP files with the OCT, those areas that have changed from the defaults are highlighted in bold.
  • Microsoft Office updates and service packs can be copied to the Updates folder on the application distribution point for automatic application during installation.
  • Settings may be specified within a config.xml file (via the application properties in BDD Workbench) or using a .MSP file:
    • Sensitive values such as product keys should be stored within an .MSP file rather than as clear text in config.xml.
    • The command line to use a config.xml file is setup.exe /config applicationsubfolder\config.xml.
    • Settings in config.xml will take precedence over duplicate settings in a .MSP file.
  • Office setup writes a log file to %temp% on the destination machine.  The filename for this log will be prefixed with setupexe.
  • Microsoft Systems Management Server (SMS) 2003 can also be used to deploy Microsoft Office 2007:
    1. Create a package using the source files from the BDD distribution point.
    2. Create a program for Office 2007:
      • Within the package, create a new program and edit the properties to include the program name (e.g. Office 2007) and the appropriate command line (setup.exe /config applicationsubfolder\config.xml).
      • If the program is hidden (on the General tab) and the installation requires user input then it will never complete.  Similarly if the option to allow users to interact with this program option (on the Requirements tab) is not selected then installation will fail, unless the package has been created for silent installation.
      • If users have local administrator rights on their workstations then he program may be configured to run with user rights; however this is generally not desirable and a run mode of run with administrative rights should normally be selected.
      • The Windows Installer tab can be used to define a .MSI file that is used when clients with the package installed make updates to the Office installation (e.g. install on first use or repair).
    3. Create a distribution point (within SMS – not to be confused with the BDD distribution point) and copy the package to the distribution point.
    4. Check the distribution process using the SMS report for the distribution status of a specific package.
    5. Define a collection to receive the package based on membership rules and specific resource attributes.
    6. Create an advertisement for the package/program and schedule accordingly.
    7. If clients are taking a long time to receive an advertisement, check the schedule and also try initiating both machine and user policy actions within the systems management applet in control panel (installed by the SMS client).

BDD 2007 overview

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

It’s been almost three years since I wrote a post about the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) and since then it’s been updated twice – first with BDD v2.5 and now with BDD 2007 (the latest version of which is now known simply as Microsoft Deployment).

According to Microsoft:

The Solution Accelerator for Business Desktop Deployment (BDD) is best-practice guidance for desktop deployment. BDD is targeted at companies that want to reduce deployment time, effort, and cost by increasing the level of automation. It allows administrators to deploy desktops with Zero Touch and Lite Touch interaction at the target PCs. This solution also helps organizations move to a managed environment with standardized desktop images.

Effectively, BDD is a framework that brings together a variety of deployment tools with business logic in order to implement best practices.  In it’s simplest form, known as Lite Touch Installation (LTI), BDD allows administrators to create/capture operating system images, customise these and deploy them to other workstations.  This requires very little infrastructure and as such is suitable for small and mid-size business; however there is also a Zero Touch Installation (ZTI) option that integrates with Microsoft Systems Management Server (SMS) 2003 or System Center Configuration Manager (SCCM) 2007 for enterprises that have the required infrastructure in place.

Supported on Windows X, Server 2003, Server 2003 R2 and Vista, BDD can be used to deploy Windows clients, together with applications (e.g. Office 2007) and customisations.  Available in both x86 and x64 editions (with both versions supporting installation of clients on either architecture), BDD 2007 is finally looking like a product, rather than a collection of tools glued together with scripts and HTML applications.  There’s still a few strange interfaces, but the hub of BDD 2007 is the BDD Workbench – an MMC 3.0 snap-in.  Other requirements for BDD are Windows Script Host (WSH) 5.6 and it also makes use various other tools that may be downloaded from within the BDD Workbench:

  • Windows Automated Installation Kit (WAIK).
  • Application Compatibility Toolkit (ACT) 5.0.
  • User State Migration Tool (USMT) 3.0.
  • MSXML 6.0.
  • Key Management Server (KMS) (and associated management pack).
  • Volume Activation Management Tool.
  • Office Migration Planning Manager.
  • Windows Vista Hardware Assessment

Screenshot of the BDD 2007 Workbench

After installation of BDD (supplied as Windows Installer .MSI file, together with a quick start guide and deployment tools overview – both of which are worth reading), the primary folders are held in %programfiles%\BDD 2007\ and consist of:

  • \BIN – BDD Workbench console and supporting files.
  • \Documentation – documentation.
  • \Downloads – storage for components downloaded by BDD 2007.
  • \ManagementPack – BDD management pack files.
  • \Samples – sample task sequence scripts.
  • \Scripts – scripts used by the BDD Workbench.
  • \Templates – master template files used for defaults in unattended Windows installations.
  • \Temporary – temporary storage space.

Other tools (e.g. the WAIK and ACT) add their own folders to the BDD file structure.

The installation also creates a \Distribution folder on the drive with the largest amount of free space (or at a custom location supplied during installation).  This contains the following subfolders and except \Scripts and \Tools are empty at installation time:

  • \$OEM$ – files and folders to be copied to the destination computer during Windows Vista setup.
  • \Applications – any application files that are installed as part of deployment.
  • \Captures – images captured using ImageX.
  • \Control – storage of files used by the BDD execution engine.
  • \Operating Systems – any operating system files that are installed as part of deployment.
  • \Out-of-Box Drivers – driver files not delivered by default with Windows Vista.
  • \Packages – Windows Vista-compatible packages for installation with the operating system (security updates, language packs, service packs, etc.) in cabinet file (.CAB) or Windows Update (.MSU) format.
  • \Scripts – scripts used by the Lite Touch deployment engine.
  • \Tools – tools used by the deployment engine and the location of USMT source files.

Configuring BDD to deploy an operating system and applications consists of:

  1. Install BDD.
  2. Update/install additional components (e.g. WAIK, USMT) from within the BDD Workbench.
  3. Add one or more operating systems to the distribution share from within the BDD Workbench.  This could be a full set of source files, a custom image (.WIM) file (i.e. an image captured from a reference computer) or an image from a Windows Deployment Services server.  This operation can either copy the installation or move it from another location.
  4. Add any applications to the master image from within the BDD Workbench – applications can be moved/copied to the distribution share or existing locations may be referenced via a UNC path.  Specify any application settings (e.g. command line switches for a silent installation, or a working directory).
  5. Add any additional device drivers that are required within the master image, using the BDD Workbench.  The BDD tools will look for .INF files in the process of scans all subfolders in the specified directory.
  6. Add any additional packages, such as operating system updates and language packs, using the BDD Workbench.

Once the master image is established, it’s necessary to define one or more builds.  Each build has an identifier (which must not contain spaces) as well as a name and a number of associated comments.  The build defines an operating system, along with key details such as product keys and the Administrator password and, once created, the build properties can be amended to customise settings, optionally launching the Windows System Image Manager to edit the unattend.xml file that controls the Vista installation.

Finally, the deployment point must be configured:

  • Builds may be deployed using the local BDD distribution point (shared as \\%computername%\Distribution$), a separate share on the local or a remote computer, as a .ISO image for use on removable media (DVD, USB flash drive, etc.), or via SMS 2003/SCCM 2007 (which facilitates ZTI installations).  Note that SMS 2003 requires the SMS 2003 Operating System Deployment (OSD) Feature Pack whereas SCCM has OSD functionality built into the product.
  • Various options exist to control the user experience during deployment (e.g. the selection of other applications during installation).
  • It may be necessary to create/update the Windows pre-installation environment (WinPE) images that are used to connect to a deployment point.  The resulting .WIM files (found on the distribution point in a \Boot folder) can be added to a Windows Deployment Services (WDS) server as a bootable PXE image for bare-metal deployment whereas the .ISO file equivalents can be mounted in a virtual machine or booted from removable media.  During the creation of these images, tasks are logged in %temp%\DeployUpdates_x86.log.  Generic images are generic_x86.wim and generic_x86.iso.

At this stage, BDD is ready to deploy builds to workstations; however there are some additional capabilities:

  • It is possible to define a SQL Server database to store details of deployed computers.
  • Images may be captured using BDD deployment points such that there is no requirement to separately run SysPrep or ImageX.  The Windows Deployment Wizard (invoked from the Windows PE images created earlier) automatically runs both of these utilities in order to prepare and capture an image.

Avoiding Windows Server 2003 R2 product activation after using non-VLK media

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last month I wrote about how it’s possible to upgrade a retail copy of Windows Vista to an Enterprise version and it turns out that this is also possible with other versions of Windows.

Last week I needed to build a new server with Windows Server 2003 R2 and my colleague who was supplying the media only brought 32-bit CDs with him (with 8GB of RAM for this server to run multiple virtual machines, it makes sense to use a 64-bit operating system). I spent most of the day downloading 64-bit CD images from various file shares around the company (in theory, because we’d bought the appropriate licenses, it shouldn’t matter what media we used) but when the volume licensing key (VLK) that I’d been given didn’t work we realised that the disc image we were using was an MSDN version. After supplying a product key that did work and going through all the hassle of getting the server added to the corporate domain, Windows notified me that I had 55 days left to activate the product, so I finished installing the applications today and then “upgraded” using the correct volume license media and key, removing the requirement for product activation.

Another point that’s worth noting (thanks to Daniel Petri for this tip) is that the .IMG files that Microsoft provided in the “ISO only” download appear to be just ISO 9660 (.ISO) files with a different file extension. Either way, the cdburn.exe resource kit tool was able to write them on my Windows Vista PC (although it did report an error when trying to eject the CD).

Fixing RIS after installing Windows Server 2003 SP2

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

This may be an isolated incident, as I’ve already written about how my Windows Server 2003 SP2 installation appeared to be broken (but was ultimately successful) but ever since SP2 was installed, I’ve been warned about service startup failures and have been unable to PXE boot to RIS.

I haven’t bothered too much – my RIS server is used for XP builds and I rarely need to build XP machines these days but as there are no fully-featured Windows Vista display drivers for my IBM ThinkPad T40, I wanted to rebuild it on XP today.

It turns out that the problem was trivial. RIS has been replaced in Windows Server 2003 SP2 by Windows Deployment Services (WDS). WDS includes something called Windows Deployment Services Legacy – which looks remarkably like RIS to me (it uses WDS binaries to provide RIS functionality). I fired up the Windows Deployment Services Legacy administrative tool and performed a diagnostic check, after which PXE boots resulted in a successful connection to the OSChooser.

Confirmation that it is possible to upgrade from a retail edition to a volume license edition of Windows Vista

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Just before I went on holiday, I rebuilt my company-supplied notebook PC to run Windows Vista (running Linux doesn’t look too good when you work in the Microsoft Practice of a major IT company). At the time, I didn’t have any volume license media and whilst I knew that all of the retail editions were contained in a single image on the retail DVD, that doesn’t include Windows Vista Enterprise Edition. Nevertheless, I installed Windows Vista Business Edition, choosing not to supply a product key (Vista allows 30 days before activation is required). Since then, a colleague has sent me the correct media and license keys, so tonight I was ready to rebuild on Windows Vista Enterprise Edition.

I say rebuild because I didn’t expect an in-place upgrade to work but it did – “upgrading” my Windows Vista installation to a new edition was as simple as dropping in the CD and running the installer. It seemed to take a lot longer than a fresh install (understandably) but I still have my user accounts, profile and data from prior to the upgrade. So, just to confirm, it is possible to upgrade from a retail to a volume license (enterprise) edition of Windows Vista.

Using RIS as a TFTP server

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier tonight I needed to upgrade the software on an Ethernet switch. Most network administrators will be aware that this generally requires access to a trivial file transfer protocol (TFTP) server and it’s widely believed that to set up TFTP on a Windows server requires third party software. Not so – Microsoft remote installation services (RIS) includes a built-in TFTP daemon and I found that this can be used to serve files to any TFTP client (I’ve written before about using RIS to PXE boot non-Windows images and this was a effectively a variation on the same theme).

All that was required was to copy the binary that I needed to run on my Ethernet switch to the RIS server’s remote installation share (\\servername\RemInst). Once the file had been copied to the RIS server it was simply a case of following the switch upgrade process and supplying the appropriate TFTP server address (i.e. the IP address for the RIS server) and filename.

Windows Vista imaging and deployment

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

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 gave an interesting presentation on Windows Vista imaging and deployment.

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.

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).

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) and enhanced through the creation of Microsoft automated deployment services (ADS) – now renamed Windows deployment services.

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.

.WIM files are structured as follows:

  • Header – with signature, version, GUID and indexes to images.
  • File resources – the actual image files.
  • Metadata – information about the files within the image.
  • Resource table(s) – effectively a directory tree for the files within the image, defining the file system.
  • XML data – information used to customise the image.

Windows imaging uses a system of filters, e.g. the .WIM file system filter (to edit image contents) and the WIM boot filter (not surprisingly to boot from an image). The main tool used for manipulation of .WIM files is imagex.exe (previously known as ximage.exe). imagex.exe allows the mounting and unmounting of .WIM files as a file system, whereby changes can be made before they are committed to the .WIM file. It is also used to create, append to and split image files, as well as for viewing the XML data about an image file. There’s also an API for programmatic manipulation of .WIM files – WIMGAPI. It’s important to note that, whilst there are both 32- and 64-bit versions of the Windows Vista deployment tools, they are compatible, so images created/modified with a 64-bit version of imagex.exe will still work on a 32-bit system, etc. Also worth noting is that the System Preparation Tool (sysprep.exe) still exists – images still need to be sysprepped – but there are new options around what the system should do on its first boot.

Whilst imagex.exe can be used to capture the contents of a running system, it’s not good practice, and Microsoft recommends that the Windows pre-installation environment (WinPE) is used instead. Because WinPE runs entirely in memory there are no issues around locked files and Windows PE 2.0 will be made more widely available than previous versions. James’ presentation also indicated that a file called winscript.ini can be used to specify exclusions (e.g. pagefile.sys, hiberfil.sys, \WINDOWS\CSC, \RECYCLER, System Volume Information, \$ntfs.log, etc.); however he’s since blogged that the .INI file is not required – the key point is that there are files which you will almost certainly want to exclude from an image.

Another important tool is the Windows System Image Manager – setupmgr.exe on steroids! This is used to build a catalog of .WIM file contents and then customise the file – e.g. to add components, or to customise settings, before validating the resulting unattend.xml answer file.

Other deployment tools, available for previous Windows versions but updated for Vista include the application compatibility toolkit and the files and settings transfer wizard (formerly the user state migration toolkit).

Bootable .WIM files are always called boot.wim. The boot process is as follows:

  1. Read boot configuration database (BCD) file. This tells the system what to execute and effectively replaces the boot.ini file found in previous versions of Windows NT/2000/XP/2003; however, unlike boot.ini it is not a text file – it must be edited using bcdedit.exe.
  2. Mount boot.sdi
  3. Attach boot.wim to boot.sdi
  4. Continue boot process.
  5. Install .WIM file system filter

The use of .WIM files is not limited to Windows Vista imaging – although they may be unsupported with other operating systems and there may be complications (e.g. I wrote a post last year about deploying Windows XP using ADS). Indeed, Windows Vista imaging technologies will also be used for the next Windows Server product (codenamed Longhorn), although because this is still a beta product, the details may be subject to change. Importantly, the tools provided for working with Windows Vista .WIM files are not all compatible with legacy operating systems.

It looks as though the new Windows Vista approach to imaging and deployment will be a steep learning curve for us all, but it should result in a more flexible, and manageable, approach to deployment – more information about Windows Vista deployment enhancements is available on the Microsoft website.

Creating a customised Windows XP CD using nLite

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last night, when I was installing Windows on my Mac, I needed a Windows XP CD with service pack 2 included (i.e. a slipstreamed service pack as Apple Boot Camp doesn’t allow the use of a non-SP2 CD). I didn’t have one – only a Windows XP (RTM) CD, an integrated SP1 CD, and an SP2 update CD – but that’s no problem, as you can create your own slipstreamed XP SP2 CD.

The official method linked above works well, but (as highlighted in the August 2006 edition of Personal Computer World magazine) there is an easier way – using the excellent (and free) nLite deployment tool for unattended Windows. After copying the contents of my original Windows XP (RTM) CD to a temporary location on my hard disk, I was able to use nLite to integrate the service pack (from my SP2 CD) and make a bootable .ISO image of the new distribution (ready for burning to CD using the software of my choice) using just a few mouse clicks. I could also have integrated drivers (e.g. the ones from the Macintosh driver CD that Boot Camp creates), included updates/patches, removed components, applied tweaks and generally customised the Windows XP installation to suit – all using one simple wizard.

Thanks to Dino Nuhagic (Nuhi) for creating nLite (and for making it free) – it really is a very useful tool.

How not to image servers

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A couple of weeks back, I wrote about using Microsoft’s system preparation tool (SysPrep) to prepare virtual machine images for duplication. It doesn’t really matter whether the machine is virtual or physical, the principle is still the same (my point was that cloning virtual machines using a file copy is easy but needs to be prepared in a specific way – i.e. using SysPrep).

A few days ago I was completely amazed to hear how one of my clients had duplicated some of their servers – they had simply broken a mirror, placed the second disk in a new server, then added another disk in each server to recreate the mirror (repeat until all servers are successfully duplicated). It may be ingenious, but it’s also extremely bad practice.

The client in question is in the process of preparing for a migration from Windows NT to Windows Server 2003 and Active Directory. Although NT doesn’t get too upset if servers are cloned, including their security identifier (SID), Active Directory does. They now have three choices:

  • Rebuild the problem servers.
  • Remove the servers from the domain.
  • Use a tool like Sysinternals NewSID to change the SIDs (both officially unsupported by Microsoft).

Whatever the decision, it’s all extra (and unnecessary) work – completely avoidable.