Deploying Vista

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Understanding-Windows-AIK.html

Mitch Tulloch
Part 1: Understanding the Windows AIK


The IT lifecycle for a typical enterprise involves the following phases: plan, test, deploy, configure, maintain and troubleshoot. These phases are the same regardless of whether you’re implementing applications, suites of applications, operating systems, or whole solutions. An important part of this lifecycle is the deployment phase, which can involve anything from popping a DVD into a single box to install something, to automating the deployment of an application or operating system to thousands of desktops at multiple sites.

In the past, deploying Microsoft Windows to large numbers of computers has usually meant one of three things: cobbling together an automated deployment solution using MS-DOS network boot floppies, unattend.txt files, cmdlines.txt files, and various .ini and .inf files; using Remote Installation Services (RIS), a server-based deployment solution first introduced in Windows 2000 Server; or buying a third-party disk imaging or “cloning” tool like Norton Ghost and using this instead. Of course, if you were a Microsoft Software Assurance (SA) volume license customer, or an OEM, then starting with Windows XP you also had access to another tool, the Windows Preinstallation Environment (Windows PE), which basically meant you could throw out your MS-DOS boot disks. Anyway, most time- and budget-conscious admins chose the third approach (cloning) especially if they had more than a few dozen machines to install, and while some very large enterprises deployed RIS, most small and medium-sized businesses (SMBs) preferred third-party disk-imaging solutions like Ghost. In fact, the word “ghosting” became synonymous with “deploying” for many Windows administrators.
With the arrival of Windows Vista however, the landscape has changed as Vista now has a number of tools for preparing, capturing and servicing disk images and then deploying them in unattended fashion to bare-metal systems. Some of these deployment tools (like Sysprep.exe) are included in the operating system itself; others are available from the Microsoft Download Center as a free download; still others like Windows Deployment Services (Windows DS), the successor to RIS, are provided as a role you can add to Windows Server 2008. In addition to such tools, Microsoft has also developed a Solution Accelerator (SA)—a collection of tools, scripts and documentation—for taking some of the complexity out of deploying Windows. The first version of this was called the Solution Accelerator for Business Desktop Deployment 2007, or BDD 2007 for short.
A new version of BDD 2007 called Microsoft Deployment has also just been released, and while it’s tempting to jump right into using Microsoft Deployment and learn how to use it, a wiser approach is to first become familiar with the Windows AIK and Windows DS. The reason for this is simple—Microsoft Deployment is built on top of the Windows AIK and other important tools like the User State Migration Tool and Application Compatibility Toolkit. Knowing how these underlying tools work in detail will help you get significantly more out of using Microsoft Deployment—especially when you have to troubleshoot some deployment issue. Hence this series of articles, which will take you through a detailed walkthrough of using the various tools included in the Windows AIK and also various ways of performing image-based deployment of Windows. Then once a good foundation of understanding the Windows AIK has been laid, I’ll move on and examine how Microsoft Deployment can simplify and streamline your deployment tasks.
Note:
While the focus of these articles will be on deploying Vista, much of the content will be helpful for deploying Windows Server 2008 as well, and to facilitate this the articles will focus on version 1.1 of the Windows AIK, which will be released with Windows Vista Service Pack 1 and Windows Server 2008. Note also that deploying pre-Vista versions of Windows will not be covered in these articles.
What’s In the Windows AIK

The Windows AIK consists of tools, documentation and samples to enable administrators to perform automated deployment of the Windows Vista and Windows Server 2008 family of operating system platforms. Windows AIK 1.1 can be used to deploy Windows Vista RTM, Windows Vista with SP1, and Windows Server 2008. To use the Windows AIK, you first have to obtain it. Version 1.0 is available from the Microsoft Download Center; at the time of writing, version 1.1 is still under development and can be obtained from Microsoft Connect if you’re on the Windows Server 2008 beta program.
To use Windows AIK, you first install it on a technician computer, which is simply the computer you will use to create answer files, build configuration sets, build custom Windows PE images, and so on. Your technician computer doesn’t have to be running Windows Vista or Windows Server 2008—you can use a Windows XP or Windows Server 2003 machine instead if you want. Your technician computer does need to have the .NET Framework 2.0 and MSXML 6.0 installed on it however, but you can install these directly from the Windows AIK splash screen before you install the Windows AIK itself (Figure 1):

Figure 1: Splash screen for installing the Windows AIK
Tip:
If you plan on building custom Windows PE images, then your technician computer should also have a DVD burner and third-party image-burning software on it.
After you install the Windows AIK on your technician computer, you’ll have access to the following tools:

• Windows System Image Manager (Windows SIM), which can be used to create XML answer files and distribution shares.
• ImageX, a command-line tool for capturing, servicing, and applying Windows Imaging Format (WIM) files, which are file-based Windows disk images used by Windows Vista and later.
• PEimg.exe, a command-line tool for creating and modifying Windows PE 2.1 images offline.
• Package Manager (Pkgmgr.exe), a command-line tool for offline servicing of Windows images.
• Other command-line tools including BCDEdit, Bootsect, DiskPart, Drvload, and others that can be used to automate various aspects of deployment.

In addition, Windows Vista and Windows Server 2008 also includes Sysprep.exe, the System Preparation Tool, which is used to prepare a computer for disk imaging by removing machine-specific information such as SIDs, and also for other purposes such as adding device drivers to an existing Windows installation using Audit mode.
When the Windows AIK is installed on a technician computer, it creates a folder structure similar to the one shown in Figure 2 below. After you’ve installed the Windows AIK it’s worthwhile exploring the contents of these folders as there is much helpful documentation and also sample files of various kinds that illustrate how these different tools can be used to deploy Windows.

Figure 2: Folder structure found under %PROGRAMFILES%\Windows AIK
Quick Guide To Changes in Deployment Tools and Technologies in Vista

In future articles of this series, we’re going to dive deep into how to use each of these tools, but before we start doing this let me leave you with something that will kick start your learning concerning how deployment tools and technologies have changed in Vista. I’m assuming you’re familiar with the standard Microsoft tools and technologies used to deploy Windows XP, right? Well, if so, here’s a quick guide to how these things have changed in Windows Vista and beyond:
Tool or Technology
Old (pre-Vista)
New (Vista and Beyond)
Sysprep.exe
Found in Deploy.cab on your product CD
Found in %WINDIR%\System32\Sysprep folder
Disk imaging tool
None (use Ghost or some other third-party product)
ImageX (included in Windows AIK)
Tool for creating answer files
Setup Manager (found in Deploy.cab)
Windows SIM (included in Windows AIK)
Answer file format
Text file with sections and key=value parameters
XML file
Number of different answer files
Lots e.g. unattend.txt, winnt.sif, sysprep.inf, winborn.ini, oobeinfo.ini and so on.
Only two: unattend.xml and (optionally) oobe.xml.
How to run additional commands during installation
List them in cmdlines.txt and use $OEM$ folder on your distribution share
Use RunAsynchronous or RunSynchronous in unattend.xml
How to run additional commands after first logon
Use [GuiRunOnce] section of unattend.txt.
Use FirstLogonCommands in unattend.xml
How to provide supplementary files for an installation
Use $OEM$ folders and various subfolders under this
Use ImageX to create a data image
Table 1
There’s lots more of course, but that should be enough get you started, or at least to whet your appetite

---

موضوعات مشابه:

• Deploying Windows 7
• Configuration Steps - How to Resolve the Vista Backup Error 0x8007045D in Vista Ultimate

---

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part2.html

In order to understand how to deploy Windows Vista, you need to first become familiar with the deployment concepts, technologies and tools found in the Windows Automated Installation Kit (Windows AIK). In the first article of this series, I gave you a quick bird’s-eye view of what the Windows AIK is and what it contains. Starting with this article, you’ll build your understanding of important technologies such as Windows Setup and the Windows Imaging File Format (the topics of this article) and the different configuration passes of Windows Setup (the topic of my next article). Then we’ll examine how to use tools like Windows System Image Manager (Windows SIM), the Windows Preinstallation Environment (Windows PE), the System Preparation Tool (Sysprep), ImageX, and Windows Deployment Services (Windows DS) to successfully perform deployments—plus we’ll also eventually cover how to use the Microsoft Deployment Toolkit 2008 (MDT 2008). But I’m getting way ahead of myself as we need to lay some groundwork first.

Let’s begin then with Windows Setup (Setup.exe), which is simply the program used to install Windows onto a computer. Using Windows Setup you can perform clean installations where there was no previous operating system; upgrades to previous versions of Microsoft Windows; and unattended (hands-off) installations. You can run Windows Setup directly from your Vista product DVD, from a custom-made Vista DVD together with an answer file, over the network from a distribution share, and so on.
What’s significant and new starting with Vista is that Windows Setup now uses Image-Based Setup (IBS), a new file-based disk imaging technology that uses Windows Image (.wim) files based on the Windows Imaging (WIM) file format. A .wim file contains one or more volume images of the Windows Vista or Windows Server 2008 operating system (a volume image is what you get when you capture a disk volume onto which Vista or W2k8 has already been installed) and you can perform various actions on these .wim files using tools like ImageX, Package Manager, and so on which we’ll discuss in due course.
If you open your Vista DVD in Windows Explorer, you’ll find two of these .wim files present in the \Sources directory (see Figure 1):

Figure 1: Boot.wim and Install.wim files in the \Sources folder on your Vista DVD
Here the boot.wim file is a default boot image while the install.wim file is (you guessed it) the default install image. Time for some terminology:

• A boot image is an image you can use to boot a bare-metal system in order to begin the process of installing Windows onto the system.
• An install image is a captured image of the installed Windows Vista or Windows Server 2008 operating system that can be applied onto your system.

Let’s make it clearer: you use the boot image to start the installation process, and once it’s running the installation process then applies the install image to the system you are installing Windows on. This explains why in Figure 1 above the install.wim file is so much bigger than the boot.wim file. Of course, both of these two images can also be customized in various ways, for example by adding drivers needed to support your system’s hardware. But I’ll get to that topic later on my series.
This new WIM file format technology provides a several advantages over previous Windows Setup technologies, namely:

• You can install Vista on any hardware (as long as it’s the right architecture i.e. x86 or x64) since .wim files are hardware-agnostic.
• You can service a .wim file offline, which means you can easily add drivers or updates to an image before using it to deploy Windows.
• You can have multiple operating system images within a single .wim file. For example, a retail Vista DVD can have Vista Basic, Vista Home Premium, Vista Business and Vista Ultimate all stored in a single install.wim file on the DVD (your product key determines which edition of Vista you get to install). This is possible because WIM uses file compression and single-instance storage to reduce the space needs for doing this.

We’ll see later in another article how to make use of these two images for deploying Vista, but let’s get back to Windows Setup and look next at the Windows Setup process and how it works. I’ll focus on clean installs instead of upgrades as most enterprises use the former when they deploy Windows onto their client computers.
Three Phases of Windows Setup

Windows Setup in Vista takes place in three phases as follows:
Phase 1: Windows PE phase. In this phase you configure how Windows will be installed on your system, either by manually specifying information when prompted or by automatically providing this information using one or more answer files. The information you need to specify includes things like your Language, Time and Currency format, Keyboard or Input Method, Product Key (not needed when using volume licensed media), your acceptance of the EULA, which partition you want to install Vista on, and so on. Once this information has been supplied (manually or with answer files) the Windows PE phase of Windows Setup continues by configuring your disk, copying the install.wim file to your disk, creating the files needed to make Windows boot, and processing any answer file settings in the offlineServicing configuration pass (if there are any such settings). That may seem mysterious for now, but be patient as I’ll explain how configuration passes in my next article. Anyways, once all this is done the Windows PE phase is finished and the next phase of Setup can be begin.
Phase 2: Online Configuration phase. During this next phase Setup performs various configuration actions that make this new installation of Windows unique, such as creating unique Security Identifiers (SIDs) for machine and user accounts and so on.
Phase 3: Windows Welcome phase. The third and final phase of Windows Setup performs actions that prepare the operating system for use by the user. These actions include (in the following order) processing any answer file settings in the oobeSystem configuration pass (if there are any such settings), processing the Oobe.xml answer file (if there is such a file—more about this file in another article), and launching Windows Welcome on the computer. Windows Welcome is sometimes known as the Machine Out-Of-Box-Experience (Machine OOBE) as it’s what users see when Windows first boots on their computer. As the user walks through Windows Welcome he can perform final customizations such as creating additional accounts for his computer. You can bypass Windows Welcome if you like by booting Windows into audit mode, which lets you perform additional customizations such as adding drivers and installing applications. I’ll talk more about audit mode later on when we look at the preinstallation phases for successfully deploying Windows in enterprise environments.
Now that we have gained and understanding of what happens when Windows Setup runs, we’ll continue in the next article by examining the different configuration passes used by Setup

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part3.html

In the previous article of this series we examined the three phases of Windows Setup in Windows Vista and Windows Server 2008. To recap briefly, these phases look like this:

1. Windows PE phase – Once you see the screen that says “Installing Windows—that’s all the information we need right now” this first phase of Setup has completed and the next phase has begun.
2. Online Configuration phase – There is no user input during this phase, and when your system performs its last reboot, this phase is finished and the final phase of Setup will begin.
3. Windows Welcome phase – During a manual install, this is the phase where you get prompted to choose a user name and picture, type a computer name, choose a desktop background, and so on.

From a user’s perspective, the above describes what the Setup process looks like. Under the hood however, things are a bit more complicated because of something called configuration passes. A configuration pass is an aspect of the Setup process that can be controlled by configuring settings in an answer file. In other words, whatever happens during a configuration pass can be automated. And while there are only three phases of Setup from the user’s perspective, there are seven different configuration passes that can occur, depending on what type of installation you’re trying to perform.
To see why it’s important to understand these different configuration passes, take a look at the following screenshot which shows me about to add the x86_Microsoft-Windows-Shell-Setup component to my answer file:

Figure 1: Adding the x86_Microsoft-Windows-Shell-Setup component to an answer file
Note that of the seven different configuration passes available within an answer file for deploying Vista, the x86_Microsoft-Windows-Shell-Setup component can be added to six of them. This means you could add this component to the offlineServicing pass (selected in the figure above) for your answer file, to the generalize pass for your answer file, to the specialize pass, and so on.
So the question immediately presents itself like this: Which configuration pass of my answer file should I add this component to? The answer depends on two things: understanding what these different configuration passes do and understanding the different scenarios you can follow for deploying Vista. The rest of this article deals with the first topic, while my next article will describe some possible deployment scenarios.
Let’s now examine each of these seven configuration passes, and afterward I’ll show you how they relate to the three Setup phases described previously. And by the way, if terminology like “the x86_Microsoft-Windows-Shell-Setup component of an answer file” still sounds mysterious to you, don’t worry—working with Vista answer files will soon become clear to you over the next few articles in this series.
Note:
The “x86” prefix to x86_Microsoft-Windows-Shell-Setup simply means we’re dealing with deploying 32-bit Vista, which will be the focus of most of these articles, although I will describe later on the differences for deploying 64-bit Vista.
Pass 1 windowsPE

Answer file settings for the windowsPE configuration pass are used to configure how the Windows Preinstallation Environment (Windows PE) behaves. Windows PE is a minimal version of Windows that is designed to prep a system for installing Windows on it, and you can use Windows PE to boot a system that has no operating system, partition and format its drives, copy disk images to the system’s drives, and launch Setup from a network share.
This really means two things: the windowsPE pass is equivalent to the first phase of Windows Setup, but it’s also something standalone by itself. So by configuring answer file settings for this pass you can either control how the Windows Setup process initiates or you can control how Windows PE works in and of itself.
Most of the answer file settings for the windowsPE pass are found under the x86_Microsoft-Windows-Setup component (Figure 2) of which we’ll have more to talk about in a future article:

Figure 2: Adding the x86_Microsoft-Windows-Setup component to the windowsPE configuration pass
Pass 2 offlineServicing

Settings for this configuration pass can be used to do things like add additional drivers, security updates, hotfixes, language packs, and other packages to your Windows Image (WIM) file. Note that you can’t add boot-critical drivers during this pass—these must be added during the windowsPE pass described above, otherwise Windows PE won’t be able to boot your system. Note also that you can’t add service packs using this pass—or at least, you can’t use this pass to add SP1 to a Vista RTM image, the reason being that Microsoft made some architectural changes to the servicing stack in VistaSP1 and the servicing stack can’t update itself.
From the perspective of running Windows Setup, the offlineServicing pass happens during the second phase of Setup after the .wim file has been copied to the system’s hard disk. This is because the image has to be applied to the hard drive before it can be serviced by Package Manager, the built-in tool in Vista that is used for applying updates, fixes and packages to the image (more on Package Manager in a later article in this series). It’s a bit more complicated that that however, since you can also use the offlineServicing pass to apply packages to an offline Windows image, a process that is known as servicing the image.
Many of the settings for the offlineServicing pass are found under x86_Microsoft-Windows-Shell-Setup, but there are lots of others as well (such as those under the Packages node in Windows SIM) which we’ll examine in due course.
Pass 3 specialize

This pass is used to configure system-specific settings such as network settings, internationalization, domain membership, and so on. There are numerous answer file components that can be added for this pass which we’ll examine later.
From the perspective of running Windows Setup, the specialize pass corresponds to the second part of the second phase of Setup (i.e. between the first and second reboots of your system) but there’s more this pass can do depending on the deployment scenario you’re working with. That’s because the specialize pass can also be used together with the generalize pass as described next.
Pass 4 generalize

This pass is closely tied to using the sysprep /generalize command. Sysprep , the System Preparation Tool, is used mainly to prepare an image for deployment onto multiple destination computers. We’ll look at Sysprep later on when we examine the various scenarios for deploying Vista, but here’s a quick bird’s-eye view from 10,000 meters: the generalize pass is used to create your reference image of Windows, while the specialize pass can then be used to apply different customizations to this reference image for different uses.
Pass 5 auditSystem

This pass happens only when Setup is running in audit mode using the sysprep /audit command. Audit mode is used in certain deployment scenarios for adding various customizations to a Windows image and bypasses the final Windows Welcome phase of Setup. Whatever takes place during the auditSystem pass happens in the context of the Local System account and occurs before the user logs onto the computer.
Pass 6 auditUser

This pass is similar to auditSystem (i.e. it only happens when Setup is running in audit mode) except that whatever happens during this pass occurs in the context of the user’s account and takes place after the user has logged on to his computer.
Pass 7 oobeSystem

This final configuration pass corresponds to the beginning of the third and final phase of Setup and is used to configure happens during the Windows Welcome phase of Setup.
Putting It All Together

If we focus solely on an unattended, clean install of Windows Vista onto a bare-metal system, the comparison between the three phases of Windows Setup and the seven configuration passes looks something like this:

Figure 3: Comparing Windows Setup phases with configuration passes for an unattended, clean install of Vista (click to enlarge)
For a very basic unattended install of Vista, you may only need to configure settings for the windowsPE and oobeSystem passes. For more complex install scenarios, you could also configure settings for the specialize pass, and if you need to add updates, fixes or other components during your unattended install you can configure offlineServicing pass settings as well

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part4.html

In the previous article of this series we learned about the seven configuration passes of Vista’s Setup process. Understanding these configuration passes is crucial because many answer file components can be added to more than one configuration pass. For example, we saw in the previous article that the x86_Microsoft-Windows-Shell-Setup component can be added to six of the seven configuration passes. So the question arises: Which configuration pass should I add this component to in my answer file if I want the settings I configure for this component to be applied?

The answer to this question is that it depends on what type of deployment scenario you are planning on using for deploying Vista, and that’s what this present article is all about. We’re going to briefly examine three possible deployment scenarios, and while you might be able to come up with other deployment scenarios, these three are commonly used in enterprise environments. The scenarios we will examine are called:

• Build-to-Plan (BTP)
• Build-to-Order (BTO)

As we look at each of these scenarios, we’ll relate them to the seven configuration passes of Vista’s Setup process. Then in future articles we’ll actually walk you through the steps of these scenarios.
Understanding the Build-to-Plan (BTP) Scenario

A reference image is an installed copy of Windows that you can later deploy using disk-imaging (also called “cloning”) onto multiple destination computers that have the same hardware configuration as your source computer. In a typical enterprise environment, the process for building a Vista reference image could look something like this:

1. Create an answer file to automate the installation process and save it as autounattend.xml onto removable media such as a floppy disk or USB flash drive.
2. Insert the DVD and answer file media into your source computer (a bare-metal system that has no operating system installed) and boot the system.
3. Windows Setup starts by running the windowsPE and offlineServicing passes, which means that any components in your answer file that have been added to these passes will be used to apply customizations to how Windows Setup runs on the source computer.
4. Once the .wim file has been copied to the reference computer’s hard drive, the specialize pass runs, so this means any components in your answer file that have been added to this pass will be used to apply customizations to how Setup runs.
5. Once Setup finishes, the oobeSystem pass runs, which means this means any components in your answer file that have been added to this pass will be used to apply customizations to how Setup runs.
6. Once Windows Welcome is finished and you’ve logged on, you then install service packs, add device derivers, install applications, and perform other customizations of your source computer.
7. Once you’re source computer is ready, you then run the sysprep /generalize /oobe /shutdown command, which strips the system of all machine-specific data such as SIDs, event logs, and so on. If desired, you can also specify an answer file in your sysprep command so that any components in this answer file that have been added to the generalize pass of this answer file can be used to apply customizations to what sysprep does.
8. Now you boot your sysprepped system using a Windows PE DVD and run ImageX to capture an image of your source computer. You then save this reference image on a network share or DVD so you can use it later on to deploy Vista to destination computers having the same hardware configuration as your source computer.

Examining the above scenario, we can see that the configuration passes you would use to add components to your answer file could be any or all of the following:

• windowsPE pass
• offlineServicing pass
• specialize pass
• oobeSystem pass
• generalize pass (requires a separate answer file used by sysprep)

Understanding the Build-to-Order (BTO) Scenario

The built-to-order (BTO) scenario is similar to the built-to-plan (BTP) one above, except once you’ve created a single reference image for all destination computers having the same hardware configuration as your source computer, you can then customize this image further if needed for different users or departments (in an enterprise environment) or for different customers (if you’re a system builder or OEM). The initital steps of the BTO scenario are identical to those of the BTP scenario above. The BTO process then continues as follows:

1. Use Windows PE and ImageX to apply the reference image you created earlier to one of the computers you are going to deliver to a particular group of users, customers, or a particular department.
2. Once the installation is finished, run the sysprep /audit /generalize /shutdown command so that the next time you boot the system it will start in audit mode.

This calls for a brief aside on what audit mode means. When you boot a computer on which Vista has been installed, it can do one of two things:

• Run the oobeSystem configuration pass and then launch Windows Welcome (also called “Machine OOBE Experience”) which lets the user customize his system before logging on by accepting the EULA, creating accounts, selecting her Time Zone, and so on.
• Run the auditSystem and auditUser configuration passes and then start the computer in audit mode, a stage of Windows Setup that lets you perform additional customizations and test these customizations prior to deploying Windows. These customizations could include adding device drivers, installing applications, install software updates, and so on.

Booting into Windows Welcome is the default; to force a computer to boot into audit mode, you have to run the sysprep /audit command on it. When you run this command, you can specify an answer file that can be used to apply customizations specified by components for the auditSystem and auditUser configuration passes. Booting to audit mode brings up the desktop faster since you can skip Windows Welcome, so this mode is useful when you might need to perform further customizations on a computer before delivering it to the users or customers for which it is intended. Audit mode also allows you to start with a single organizational-wide reference image for a particular hardware configuration and then customize this image with additional drivers and applications when needed for the needs of particular users, customers, or departments. In effect, this means you can have a smaller number of images you’ll need to maintain.
Now back to the remaining steps of our BTO scenario.

1. Use Windows PE and ImageX again to capture a new reference image for your particular group of users, customers, or a particular department. Note that your original reference image was for all computers in your organization that have the same hardware configuration, while this new reference image is for all computers that are needed for a particular group of users or customers or a particular department.
2. Then use Windows PE and ImageX to install your new reference on the computers destined for your particular group of users or customers or your particular department.
3. Boot these destination computers into audit mode and perform any further customizations needed for them (you can use an answer file with components added for the auditSystem and auditUser configuration passes to automate such customizations if needed).
4. Run the sysprep /oobe /shutdown command on the destination computers. The /oobe switch means that Windows Welcome will launch the next time these computers boot.
5. Put the computers on a pallet and deliver them to the users, customers or department they are destined for.

In future articles of this series we’ll walk through the steps of these deployment scenarios and make different kinds of customizations, but for now we still need to build up our basic understanding of Vista deployment concepts and tools. And since I’ve mentioned sysprep a few times in this article, I better talk about that in my next article of this series

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part5.html

In the previous article in this series, we examined several common deployment scenarios enterprises can use to deploy Windows Vista. During the discussion of these scenarios, use of the Sysprep tool was brought up, so let’s use this present article to examine what this tool is for, what it does, and how you should use it.

Sysprep, which stands for System Preparation, is a tool that you use together with other deployment tools for several purposes. These purposes can include:

• Generalizing a Windows installation by removing machine-specific information from it such as security identifiers (SIDs), the contents of event logs, any system restore points, installed Plug and Play drivers, and so on, so that you can then deploy the installation to other machines by using disk imaging (disk duplication) tools like ImageX in order to capture an image of your generalized machine and then apply this image to other machines.
• Boot a Windows installation into audit mode so you can customize your installation by adding additional device drivers and installing additional applications on it and then testing your installation to make sure it is customized properly for its intended users.
• Preparing a Windows installation for delivery to a user or customer by making sure Windows Welcome (the machine out-of-box-experience or OOBE) will run when the user or customer boots the machine for the first time.
• Transfer an existing Windows installation from your old computer to a new one if your old computer is on its last legs and before it bites the dust.

Running Sysprep

Sysprep can be run using three different methods:

• From the command line
• From the UI
• From an answer file

To run Sysprep from the command line, open an admin-level command prompt by pressing Windows Key+R, type cmd, and click OK. Then type cd sysprep to change to the %SYSTEMROOT%\system32\sysprep folder and then type sysprep followed by one or more of the command-line parameters listed in Table 1 below.

Parameter
Description
/audit
Forces the computer to start in audit mode the next time you boot it. In addition, if an answer file is being used with Sysprep then any settings configured for the auditSystem and auditUser passes will be processed.
/oobe
Forces the computer to launch Windows Welcome the next time you boot it. In addition, if an answer file is being used with Sysprep then any settings configured for the oobeSystem pass will be processed before Windows Welcome starts.
/generalize
Removes all machine-specific information from your system in order to prepare the Windows installation for deployment onto other machines using disk imaging tools like ImageX.
/shutdown
Forces the computer to shut down once Sysprep is finished running.
/reboot
Forces the computer to reboot once Sysprep is finished running.
/unattend:answerfile
Applies the configured settings in the specified answer file when Sysprep runs. Only settings specified in the oobeSystem, auditSystem and/or auditUser passes can be applied during Sysprep.
/quiet
Suppresses the display of on-screen confirmation messages. Use this parameter when automating the operation of Sysprep using the /unattend parameter.
/quit
Simply quit after Sysprep runs i.e. don’t shutdown or reboot.
Table 1: Command-line parameters for running Sysprep
To run Sysprep from the UI, open an admin-level command prompt as described above, change to the %SYSTEMROOT%\system32\sysprep folder and then type sysprep without any command-line parameters. This will open the System Preparation Tool window as shown in Figure 1:

Figure 1: Sysprep UI
The combination of options you can select from the UI correspond to the command-line options as follows:
(oobe OR audit) [REQUIRED] AND generalize [OPTIONAL] AND (shutdown OR reboot OR quit) [REQUIRED]
The best way of learning how Sysprep works is to try using it. The next sections show a couple of examples.
Example 1: Generalizing a system and then rebooting into Windows Welcome

Figure 2 shows the UI choices for this scenario:

Figure 2: Configuring Sysprep to generalize a system and then reboot into Windows Welcome
The corresponding command-line version for this would be:
sysprep /generalize /oobe /reboot
Here’s what happens when you run the above Sysprep command on a Windows Vista installation. First, a status box appears indicating that Sysprep has begun doing its work (Figure 3):

Figure 3: Sysprep beginning its work
The system then reboots several times while Sysprep continues its work (see Figures 4 and 5):

Figure 4: Sysprep doing its job

Figure 5: Sysprep continues to do its job
Once Sysprep is finished, the Windows Welcome (Machine OOBE) begins (Figure 6):

Figure 6: Windows Welcome starts
At this point the various screens of Windows Welcome are displayed in the following order (assuming you’re using volume-licensed media like Windows Vista Enterprise:

1. Specify regional settings i.e. country/region, time/currency, and keyboard layout
2. Accept the EULA
3. Type a user name, password, and select a picture to associate with the user
4. Type a computer name and select a desktop background
5. Specify automatic update settings
6. Specify date and time settings
7. Specify location (home, work or public)
8. Click Start to complete the Windows Welcome process

Example 2: Generalizing a system and then rebooting into Audit mode

Figure 7 shows the UI choices for this scenario:

Figure 7: Configuring Sysprep to generalize a system and then reboot into Audit mode
The corresponding command-line version for this would be:
sysprep /audit /generalize /reboot
Here’s what happens when you run the above Sysprep command on a Windows Vista installation. First, Sysprep does its magic (see Figure 3, 4 and 5 previously). Then Windows starts to create the desktop for the built-in Administrator account (Figure 8):

Figure 8: Desktop for Administrator is being created
Then you are automatically logged on as Administrator (even though the built-in Administrator account is still disabled—remember, this is Audit mode not normal Windows) and the Sysprep UI is displayed again (Figure 9):

Figure 9: Sysprep UI is displayed again.
The Sysprep UI is displayed again as a reminder that you must run Sysprep one more time once you’ve completed any customizations you want to perform during Audit mode. You can either run Sysprep this last time from the UI or by running sysprep /oobe /shutdown from the command line. This last running of Sysprep is essential so that when the user receives her computer and runs it for the first time, the Windows Welcome (Machine OOBE) experience runs so that the user can set up her computer properly. Of course, that’s the kind of scenario you would have if you were an OEM delivering a Vista computer to a customer; in enterprise environments, you’re more likely to want to automate the Windows Welcome process using answer files, and that’s what we’ll look at in the next article of this series: using Windows SIM to create answer files for deploying Vista

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part6.html

Windows System Image Manager (Windows SIM) is one of the key tools included in the Windows Automated Installation Kit (Windows AIK). Windows SIM can be used to:

• Create new XML answer files and edit existing ones by adding components and packages and configuring them.
• Create and work with distribution shares and configuration sets.

The focus of this article is on using Windows SIM to create answer files for unattended installation of Windows Vista onto bare-metal hardware. In later articles of this series, we’ll examine what configuration sets and distribution shares are used for and how to create them using Windows SIM.

Examining Windows SIM

As Figure 1 shows, the Windows SIM user interface has five separate panes:

Figure 1: The Windows SIM user interface
The five panes of Windows SIM server the following purposes:

• Distribution Share – This pane displays the currently opened distribution share. You also use this pane to create new distribution shares, add items to the share, and close an open share.
• Windows Image – This pane displays the currently opened Windows Image (.wim) file. As we’ll see soon, you must open a .wim file before you can create an answer file.
• Answer File – This pane is where you create a new answer file and add components (groups of operating system settings) and packages (includes software updates, language packs, and so on) to your answer file.
• Properties – This pane lets you assign values to the component or package that is currently selected in your Answer File pane.
• Messages – This pane displays errors, warnings and information messages concerning the syntax and structure of your answer file when you try and validate your answer file.

The simplest way to see how to use Windows SIM is to create a small answer file using this tool, so let’s do this now. The steps we’ll follow are these:

1. Open a Windows Image file
2. Create a new answer file
3. Add a component to your answer file
4. Configure the component you just added
5. Validate your answer file

Opening a Windows Image file

Begin by copying the Install.wim file (the default install image) from your Windows Vista with Service Pack 1 Enterprise Edition product DVD to a folder such as W:\Sources\Vista Enterprise on a hard drive of your technician computer. Then open Windows SIM by clicking Start, All Programs (or Programs), Microsoft Windows AIK, Windows System Image Manager.
Now, in the Window Image pane, right-click on “Select a Windows image or catalog file” and choose Select Windows Image from the shortcut menu to open the Select A Windows Image dialog box. Browse to your W:\Sources\Vista Enterprise SP1 folder and double-click on the Install.wim file to open the Windows image file in Windows SIM. If a catalog file can’t be found for the image file, a dialog box will prompt you to create a new catalog file:

Figure 2: Creating a new catalog file for a Windows image (Install.wim) file
A catalog file is a binary file containing a description of all the various components and packages in a Windows image. By working directly with catalog files instead of the image files themselves, Windows SIM can display components and packages more quickly. Clicking Yes in the above dialog box will cause Windows SIM to mount the image, process its contents (this takes a few minutes) and then display configurable settings for components and packages contained within the image.
Once the catalog file has been generated, Windows SIM now looks like this:

Figure 3: Opening a Windows image (Install.wim) file in Windows SIM
Creating a new answer file

Next we’ll create a new answer file for deploying Windows Vista SP1. To do this, in the Answer File pane, right-click on “Create or open an answer file” and choose New Answer File from the shortcut menu. A new answer file is created with no components in it:

Figure 4: Creating a new answer file
Notice what you see in the Answer File pane under Components? The seven configuration passes used by Windows Setup! (Refer back to Part 3 of this series if you need to refresh your memory concerning what configuration passes are.)
It’s instructive to examine the XML syntax of this new, unconfigured answer file. To do this, let’s first save the answer file using the filename autounattend.xml. To do this, make sure the root node (“Untitled”) of your answer file is selected, and then choose Save Answer File from the File menu. Browse to somewhere on your hard drive where you want to store your answer file and save the file. Then open the autounattend.xml file you just created using Notepad, and here’s what it should look like:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<cpifflineImage cpi:source="wim:w:/sources/vista%20enterprise/install.wim#Windows Vista ENTERPRISE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
We’ll compare this later with our configured answer file.
Adding a component to your answer file

Now let’s add a component to our answer file. We’ll add a component that is required when performing automated installs of Windows, namely, the component that indicates that the end-user licensing agreement (EULA) has been accepted. Here’s how you do this:
First, in the Windows Image pane, expand Components to display the Microsoft-Windows-Setup component, and then expand that to display the UserData component underneath Microsoft-Windows-Setup:

Figure 5: Displaying the Microsoft-Windows-Setup\UserData component
Note that the actual name of the component will have a prefix and suffix attached, for example x86_Microsoft-Windows-Setup_6.0.6000.16386_neutral was the actual name of this component when my Install.wim file was copied from a MSDN 32-bit Windows Vista Enterprise with SP1 DVD, but for simplicity I’ll leave off the prefix and suffix from components.
To add the Microsoft-Windows-Setup\UserData component (which lets you accept the EULA—see the Properties pane in the above figure) to your answer file, right-click on this component to display the shortcut menu:

Figure 6: Configuration passes you can add the Microsoft-Windows-Setup\UserData to for your answer file
You can see from the above figure that the only configuration pass this component can be added to is the windowsPE configuration pass. This makes sense since in Vista, you always accept the EULA at the beginning of the install process. What makes things interesting however, as we’ll see in the next article, is that some components can be added to more than one configuration pass, and that’s why it was important for us to talk about configuration passes before we looked at Windows SIM, so that you can have some idea of which configuration pass to add a particular component to for your answer file.
Anyways, in the above figure, select Add Settings to Pass 1 windowsPE in your shortcut menu, and the Microsoft-Windows-Setup\UserData component will be added to your answer file—see the Answer File pane in the next figure:

Figure 7: The Microsoft-Windows-Setup\UserData component has been added to the windowsPE configuration pass of the answer file
Configuring the component you just added

Now let’s configure the Microsoft-Windows-Setup\UserData component of our answer file so that the EULA will automatically be accepted during unattended installation of Vista. To do this, in the Properties pane, click in the box to the right of the AcceptEula setting. This displays a drop-down arrow. Click the arrow and select True:

Figure 8: Configuring an answer file setting that accepts the EULA
Validating your answer file

Before we save and examine our answer file, we should validate it to make sure its syntax is correct. To do this, select Validate Answer File from the Tools menu. When you do this, an informational message is displayed in the Messages pane. Double-click on this message to determine which component the message is associated with:

Figure 9: Results of validating the answer file
We can see that the Microsoft-Windows-Setup\UserData\ProductKey component is now selected in the Answer File pane. This particular component will not be saved in your answer file because you haven’t configured any settings for this component.
Now save your configured answer file and then open autounattend.xml using Notepad again and compare the XML to what was there before:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<UserData>
<AcceptEula>true</AcceptEula>
</UserData>
</component>
</settings>
<cpi:offlineImage cpi:source="wim:w:/sources/vista%20enterprise%20sp1/install.wim#Windows Vista ENTERPRISE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

And that’s basically all there is to using Windows SIM to create answer files for deploying Vista. In the next article, I’ll describe which components must be added to an answer file and configured in order to completely automate an unattended installation of Vista

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part7.html

In the previous article of this series, we looked at Windows System Image Manager (Windows SIM), a key tool of the Windows Automated Installation Kit (Windows AIK) that you use to create and configure answer files for automated deployment of Windows Vista. In that article, we learned how to use Windows SIM to create, configure, validate and save answer files. This present article and the next two articles in this series will walk you through the steps of creating a simple answer file you can use to perform a completely unattended installation of Windows Vista onto bare-metal systems using the Unattended Install From DVD deployment method. The answer file we will create will be a bare-bones one, that is, the minimal answer file you need to completely automate Vista deployments. In future articles we’ll examine additional answer file settings you can configure to automate other aspects of Vista deployment.

Specifying Regional and Language Options

Start by selecting and opening the Install.wim file of the version of Vista you want to deploy by following the procedure outlined in the previous article of this series. In this walkthrough, I’ll be using the 32-bit US English version of Windows Vista SP1 Enterprise Edition. Once the image file is open, create a new answer file by selecting New Answer File from the File menu.
Now we’re ready to begin adding components to our answer file. In the Windows Image pane, expand the Components node and select the Microsoft-Windows-International-Core-WinPE node beneath it. Then right-click on the Microsoft-Windows-International-Core-WinPE node and select Add Setting to Pass 1 windowsPE to add this component to the windowPE pass for your answer file. Now in the Properties pane, type values for the various settings of this component as indicated by the following table:

Setting
Value
InputLocale
en-us
Layered Driver

SystemLocale
en-us
UILanguage
en-us
UILanguageFallback
en-us
UserLocale
en-us
The result should look like this (Figure 1):

Figure 1: Configuring regional and language settings.
What we’ve done up to this point is to specify answer file settings for the default language and locale for Windows Setup. The following table describes the settings we’ve just configured in more detail:

Setting
Description
InputLocale
Keyboard layout and system input locale
Layered Driver
Optional—used only for Japanese and Korean keyboards
SystemLocale
Default language for Windows Setup
UILanguage
Default system user interface language
UILanguageFallback
Fallback language if UILanguage is not fully localized
UserLocale
Locale to use for dates, times, currency and numbers
We’re not quite through however as there’s another answer file component we need to specify to finish configuring user locale and language settings. Here’s what to do next: in the Answer File pane, expand the Microsoft-Windows-International-Core-WinPE node and select the SetupUILanguage node beneath it. Then in the Properties pane, click in the box to the right of the UILanguage setting and type en-us as the value for this setting (see Figure 2):

Figure 2: Configuring regional and language settings (continued)
I’m not sure why you need to specify UILanguage in two places like this, but you need to.
Accepting the EULA

Next we’re going to specify the answer file setting that will automatically accept the EULA. In the Windows Image pane, under Components, find the Microsoft-Windows-Setup node and expand it to display the UserData node beneath it. Then right-click on the UserData node and select Add Setting to Pass 1 windowsPE to add this component to the windowPE pass for your answer file. Click the box to the right of the AcceptEula setting to display a drop-down arrow, then click the arrow and select True. The result should look like this (Figure 3):

Figure 3:Configuring the setting to accept the EULA
Tip: If you’re deploying a retail version of Windows Vista (such as Windows Vista Business edition) instead of the volume-licensed Enterprise edition, you’ll also need to specify your product key at this point. To do that, expand the Microsoft-Windows-Setup\UserData node in the Answer File pane to display the ProductKey node beneath it, and they type your 29 character product key (you must include the dashes) in the box beside the Key setting in the Properties pane.
Creating a New Primary Partition

Next, we need to prepare the hard disk on our computer so it will be ready to install Vista onto it. We’re assuming in this article that we’re deploying Vista onto bare-metal, that is, onto a hard drive that is unpartitioned and therefore has no existing volumes on it. We’re also assuming that our target system has only one hard drive in it. This means we have to configure our answer file to create a new primary partition, set it as the active partition, and format it using NTFS. Here’s how we do this:
First, add the Microsoft-Windows-Setup\DiskConfiguration\Disk component to the windowsPE configuration pass of your answer file, and in the Properties pane, set the value of DiskID to the number 0 (see Figure 4):

Figure 4: Selecting disk 0 in order to create a new partition on it
Next, add the Microsoft-Windows-Setup\DiskConfiguration\Disk\CreatePartitions\Crea tePartition node to the windowsPE configuration pass of your answer file, and in the Properties pane, configure the settings shown in the figure below to create a new primary partition of size 50 GB (see Figure 5):

Figure 5: Creating a new primary partition on the selected disk
Tip: If you want your new partition to fill up your entire hard drive, set the Extend setting to True and don’t specify a value for the Size setting.
Now we have to mark our new partition (partition 1) as active and format it using NTFS. To do this, add the Microsoft-Windows-Setup\DiskConfiguration\Disk\ModifyPartitions\Modi fyPartition node to the windowsPE configuration pass of your answer file, and in the Properties pane, configure the settings shown in Figure 6 below:

Figure 6: Setting the new partition as active and formatting it using NTFS
Note that we also had to specify the Order setting in the above figure—this is required.
Specifying the Target Partition

Now we’re ready to tell Windows Setup which disk partition we want to install Vista onto. To specify where you want to install the image, add the Microsoft-Windows-Setup\DiskConfiguration\ImageInstall\OSImage\Insta llTo node to the windowsPE configuration pass of your answer file, and in the Properties pane, configure the settings shown in Figure 7 below:

Figure 7: Specifying that Windows Setup will install Vista onto partition 1 of disk 0
Validating and Saving the Answer File

At this point let’s select Validate Answer File from the Tools menu and check for any error or warning events that are displayed in the Messages pane (only informational events should be displayed, and those you can safely ignore). Now save your answer file using the filename autounattend.xml in the root folder of a USB flash drive. Why name it autounattend.xml? And why save it onto a flash drive? You’ll find out in the next article of this series!
Examining and Commenting the Answer File

Let’s conclude by taking a quick look at the answer file we just created. If you open autounattend.xml using Notepad it should look something like this:

<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
 <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SetupUILanguage>
<UILanguage>en-us</UILanguage>
</SetupUILanguage>
<InputLocale>en-us</InputLocale>
<SystemLocale>en-us</SystemLocale>
<UILanguage>en-us</UILanguage>
<UILanguageFallback>en-us</UILanguageFallback>
<UserLocale>en-us</UserLocale>
</component>
<component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<UserData>
<AcceptEula>true</AcceptEula>
</UserData>
<DiskConfiguration>
<Disk wcm:action="add">
 <CreatePartitions>
<CreatePartition wcm:action="add">
<Order>1</Order>
<Size>50000</Size>
<Type>Primary</Type>
</CreatePartition>
</CreatePartitions>
<ModifyPartitions>
<ModifyPartition wcm:action="add">
<Active>true</Active>
<Format>NTFS</Format>
<Order>1</Order>
<PartitionID>1</PartitionID>
</ModifyPartition>
</ModifyPartitions>
<DiskID>0</DiskID>
<WillWipeDisk>true</WillWipeDisk>
</Disk>
</DiskConfiguration>
<ImageInstall>
<OSImage>
<InstallTo>
<DiskID>0</DiskID>
<PartitionID>1</PartitionID>
</InstallTo>
</OSImage>
</ImageInstall>
</component>
</settings>
<cpi:offlineImage cpi:source="wim:w:/sources/vista%20enterprise%20sp1/install.wim#Windows Vista ENTERPRISE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

Here’s a tip: What if you need to create several different answer files and they all need to be named autounattend.xml? In that case, just add comments to your answer files using standard HTML comment syntax as follows:

<?xml version="1.0" encoding="utf-8"?>
<!-- ############################################# -->
<!-- Answer file created in Deploying Vista Part 7 -->
<!-- ############################################# -->
<unattend xmlns="urn:schemas-microsoft-com:unattend">

and so on. We’ll continue this in the next article of this series

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part8.html

In the previous article of this series, we began using Windows System Image Manager (Windows SIM) to create and configure a basic answer file you can use to perform a completely unattended installation of Windows Vista onto bare-metal hardware. At the end of that article, you validated your answer file and saved it using the name autounattend.xml onto a USB flash drive.
Why did we name our answer file autounattend.xml instead of just unattend.xml? Because we’re going to use the Unattended Install From DVD method for installing Vista onto a system. In this method of deploying Vista, you need to have your answer file on removable media, typically either a USB flash drive or (for older systems that still support them) on a floppy disk. Let’s talk briefly about how Windows Setup uses answer files.

Windows Setup and Answer Files

In the second and third articles of this series, we examined how Windows Setup works and described the three phases of Setup and the seven configuration passes associated with Setup. When you run Windows Setup (setup.exe) to install Vista, you can do it with or without an answer file. Automated deployment of Vista requires using an answer file, and Setup.exe can use answer files in two ways: explicitly or implicitly. Let’s look at these two ways of specifying an answer file.
Explicit Answer File
You can explicitly specify an answer file when you run Setup.exe by using the /unattend switch. For example, if you run Setup from over the network and you have your answer file on one network share and your Vista installation files on another, you could launch Windows Setup by running the command <path_to_installation_files>setup /unattend:<path_to_answer_file>unattend.xml where unattend.xml is the name of your answer file. Of course, running a command like this from your destination computer means you need some operating system from which to install it, and long ago when Windows 95/98/2000 were used, this typically meant booting your destination computer using a network boot floppy. Or you could use setup /unattend to upgrade your existing version of Windows to a newer one. Then when Windows XP became available, OEMs and enterprise customers got to use WinPE (Windows Preinstallation Environment), a stripped-down version of Windows that you could use to boot a bare-metal system to a command prompt, connect to a network share, and start the Setup process. We’ll look at how to use Windows PE soon in a later article of this series.
Implicit Answer File
Setup.exe can also use answer files implicitly however, that is, without having to explicitly specify where you answer file is located. In fact, when Setup begins, it automatically looks in several locations in order to see whether an answer file is present, and if it finds one, it uses it to begin performing an unattended installation. Not only that, this implicit search for an answer file happens automatically at the start of every configuration pass that occurs during the Setup process including the windowsPE, offlineServicing, specialize, generalize, auditSystem, auditUser, and oobeSystem configuration passes. Finally, for this automatic implicit search for an answer file to work during the first two passes (windowsPE and offlineServicing) the answer file must be named autounattend.xml instead of the usual unattend.xml.
Here are the details: when Setup begins a configuration pass, it automatically looks for an answer file in the locations indicated in the following order:

1. In the registry in the location HKLM\System\Setup!UnattendFile
2. In the %WINDIR%\Panther\Unattend folder (but only if Setup is being launched from a previous version of Windows)
3. In the %WINDIR%\Panther folder, which is the location where Setup caches answer files. When Setup finds an answer file at the beginning of a configuration pass, it caches it in this directory so it can use this cached answer file for the remaining configuration passes provided no other answer files are found in a location of higher precedence in this search procedure.
4. In the root directory of removable media that are writable. Setup searches the root directory of each writable flash drive or floppy, in order of drive letter, until it finds an answer file.
5. In the root directory of removable media that are read-only. Setup searches the root directory of each read-only removable media, in order of drive letter, until it finds an answer file.
6. In the \Sources folder where your Vista installation files are found (windowsPE and offlineServicing passes only) and in the %WINDIR%\System32\Sysprep folder (all other passes). For the windowsPE and offlineServicing passes, your answer file must be named autounattend.xml. For all other passes, it must be named unattend.xml.
7. In %SYSTEMDRIVE% (the root of your system drive)

Performing an Unattended Install from DVD

Let’s try using the basic answer file we created in the previous article of this series and see whether it works or not. You need three things to perform your install:

• Your Windows Vista with SP1 Enterprise Edition product DVD
• Your autounattend.xml answer file saved in the root directory of a USB flash drive
• A destination computer that has no operating system installed on it

Follow these steps to install Vista using the Unattended Install From DVD method:

1. Turn on your destination computer, insert your Vista product DVD into your DVD-ROM drive, and plug your flash drive into a USB port on the computer.
2. Press CTRL+ALT+DEL to reboot your system.
3. Sit back and watch as the windowPE configuration pass launches and uses its implicit answer file search algorithm to find the autounattend.xml file in the root of your flash drive. Setup.exe then caches this answer file and uses it to automatically install Vista on your computer. During Setup, your computer will reboot twice and then you are eventually presented with the following screen (Figure 1):

Figure 1: First screen of machine OOBE
This is the first screen of the machine out-of-box-experience (OOBE), which is also called Windows Welcome, and it’s the start of a wizard that walks the user through the final steps of configuring his computer before he can log on and start using it. The screens presented by this Set Up Windows wizard require the user to perform the following tasks in the order indicated:

1. The user chooses a user name and picture. The user types a user name, a password, and a password hint. Typing a password hint is now required as of Service Pack 1 for Vista.
2. The user types a computer name and chooses a desktop background to use.
3. The user chooses an option on the Help Protect Windows Automatically page of the wizard. Typically you would select Use Recommended Settings here.
4. The user can review and modify his time and date settings including setting the time zone.
5. The user selects his computer’s current location, which can be home, work or public.
6. On the Thank You page, the user clicks Start. A message appears saying “Please wait while Windows checks your computer’s performance.” Once that is done, the logon screen appears, and the user types his password and logs on to his computer and can begin working.

What’s the point of having this machine OOBE as part of Setup? The main purpose is for OEMs who preinstall Vista on computers and then deliver these computers to customers. As a customer, you want your new computer to come with the username BoB configured when your name is Jane, or with the timezone set to Central when you live in the Pacific zone. So in a scenario where computers are being prepared for customers, some final customization steps must be left to the customer herself to perform.
But what if you’re an administrator in an enterprise however and you need to prepare a computer for a user on your network? You know the user’s name and the time zone your network is in—is there any way to automate this Windows Welcome process so that the user can just turn the computer on, log on, and get to work? Yes there is, and that’s what the next article in this series will talk about

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part9.html

In the previous two article of this series, we used Windows SIM to create and configure a basic answer file for unattended installation of Windows Vista onto bare-metal hardware using the Unattended Install From DVD deployment method. This method is useful if you have only a few Vista computers to deploy and/or if your destination computers are not connected to a network. As we saw in article eight, you pop your Vista DVD into the machine, plug in a USB flash drive with your answer file on it, reboot the system, and installation proceeds up to the beginning of Windows Welcome (also known as the machine out-of-box-experience or machine OOBE). At that point, if we’re using the autounattend.xml answer file we created in article seven of this series, the user has to perform the final configuration of his computer by himself, which includes creating a local user account on the computer, setting the time zone, choosing whether to install updates automatically, and so on.

The question we posed at the end of the last article was, is it possible to automate the Windows Welcome phase of Setup so that the user won’t have to perform these final steps? Yes it is, and you do this by configuring settings in your answer file to automate the machineOOBE configuration pass of Setup. Let’s do this now.
Opening your Minimal Answer File

On your technician computer, start Windows SIM, open your Vista SP1 Enterprise install image in the Image Pane, and then in the Answer File pane open the autounattend.xml file you created in article seven previously (see Figure 1):

Figure 1: Minimal answer file created in article seven earlier
Specifying a User Name and Password

In the Windows Image pane, expand the Components node to display the Microsoft-Windows-Shell-Setup node beneath it. Then expand Microsoft-Windows-Shell-Setup node to display the UserAccounts, then LocalAccounts, then LocalAccount. Right-click on LocalAccount and select Add Setting to pass 7 oobeSystem as shown in Figure 2:

Figure 2: Adding the Microsoft-Windows-Shell-Setup\UserAccounts\LocalAccounts\LocalAccounts component to the oobeSystem configuration pass of your answer file.
In the Answer File pane you should now have the LocalAccounts component selected under the oobeSystem pass.
Now in the Properties pane, type the user’s name (logon and display names), Administrators for the user’s local group, and an optional description (Figure 3):

Figure 3: Specifying a local user account and password
Note that we’re only creating a local user account here on the computer. If the computer will belong to a domain, you would typically create the domain user account ahead of time in Active Directory. You still have to create a local computer account as a fallback however, and it should belong to the local Administrators group on the machine since the default Administrator account is disabled in Vista.
In the Answer File, select the Password component beneath LocalAccount. Then in the Properties pane type a password for the user account you’re creating on the computer (Figure 4):

Figure 4: Assigning a password to the local user account you are creating on the computer
Specifying a Computer Name and Default Theme

Back in the Windows Image pane, right-click on the Microsoft-Windows-Shell-Setup node and select Add Setting to pass 4 specialize as shown in Figure 5:

Figure 5: Adding the Microsoft-Windows-Shell-Setup component to the specialize configuration pass of your answer file
In the Answer File pane you should now have the Microsoft-Windows-Shell-Setup component selected under the specialize pass.
Now in the Properties pane, type a name for the computer in the value box to the right of the ComputerName setting (Figure 6):

Figure 6: Specifying a name for the computer
Now wait just a minute. Why do we have to add the Microsoft-Windows-Shell-Setup component to our answer file when we did this in the previous section above where we added a local user account for the computer? Because (a) you can add many answer file components to more than one configuration pass and (b) the computer name can only be specified using an answer file in the specialize configuration pass and not during the oobeSystem configuration pass (see Figure 7):

Figure 7: There is no ComputerName setting under Microsoft-Windows-Shell-Setup for the oobeSystem configuration pass!
Now let’s specify the default Aero theme. In the Answer File pane, select Microsoft-Windows-Shell-Setup\Themes. Then in the Properties pane type the path to the default Aero theme as shown in Figure 8:

Figure 8: Specifying the default Aero theme
Specifying the Protect Your PC and Network Location Settings

Now let’s configure the Protect Your PC setting, which determines whether Vista will automatically download and install updates or not. In the Windows Image pane, right-click on OOBE under Microsoft-Windows-Shell-Setup and select Add Setting to pass 7 oobeSystem (Figure 9)

Figure 9: Adding the Microsoft-Windows-Shell-Setup\OOBE component to the oobeSystem configuration pass of your answer file
In the Answer File pane you should now have the Microsoft-Windows-Shell-Setup\OOBE component selected under the oobeSystem pass.
In the Properties pane, click in the value box to the right of the ProtectYourPC setting and type 1 to specify that Vista should automatically download and install updates when they become available.
Then in the Properties pane again, click the value box to the right of the NetworkLocation setting until a drop-down arrow appears. Click the arrow and select Work to indicate that the computer will be used at work (Figure 10):

Figure 10: The computer will automatically download and install updates when they become available on Windows Update, and the network location is configured as Work
Specifying the Time Zone

We’re almost done. In the Answer File pane, under oobeSystem, select the Microsoft-Windows-Shell-Setup component. Then in the Properties pane, I would type Canada Central Standard Time in the value box to the right of the TimeZone setting, but you would probably type something different—see this page on TechNet for what you can type here. The result is shown in Figure 11:

Figure 11: Specifying your time zone
Validating and Testing the Answer File

Now from Windows SIM’s menu, select Tools, then Validate Answer File. You should only see a series of Information messages in the Messages pane, and these you can ignore. If you see any Error or Warning messages, double-click on them and correct any errors you find in your answer file until validation succeeds.
Save your modified answer file using the same file name (autounattend.xml) as before. Then copy it to a USB flash drive and try using it together with your Vista SP1 Enterprise product DVD to perform an Unattended Install From DVD installation of Vista on a bare-metal system. Your installation should proceed in a completely unattended fashion, after which Vista will run is performance check (this can’t be prevented) and then you’ll be presented with a logon screen for Bob Smith. Bob can then type his password, log on, and start working on his computer

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part10.html

Let’s briefly recap what we have learned so far in this series of articles on deploying Vista. We began by examining the Windows Automated Installation Kit or Windows AIK. Then we looked at how Windows Setup works, focusing especially on understanding the seven different configuration passes of Setup. After that, we moved on to take a birds-eye view of different scenarios for deployment and how the Sysprep tool makes these scenarios possible. After this we introduced Windows System Image Manager or Windows SIM, a key tool you use to create answer files for automating the installation process. The three articles that followed then walked you through the process of creating a basic answer file that automates the Setup process including Windows Welcome, and which you can use to perform a completely unattended install of Vista using your product DVD together with a USB flash drive containing your answer file.
The unattended install from DVD method (sometimes called the boot from DVD method) is fine if you have only a few computers to install, but what if you have dozens of computers and you want to install them in one shot instead of one after another? Aha, now we’re moving into something different - deployment over a network - and we’ll need additional tools to make this work. The first new tool we’re going to need is called the Windows Preinstallation Environment or Windows PE, and that’s what we’ll begin looking at in this article. Then once we’re familiar with WinPE and how we can use it to perform network installs of Vista, we’ll learn how to use Windows Deployment Services to make our network installs even simpler.

What is Windows PE?

Basically, Windows PE is a minimal version of Windows you can use to boot a bare-metal system (a computer with no operating system installed) and then connect to a network share, download the installation files for the full version of Windows, launch Setup.exe, and install Windows on the computer. Why do we need Windows PE to do this? Well, it’s simple: you’ve got a file server over there with a shared folder on it that contains the Windows installation files, and you’ve got a bare-metal system over here with no operating system on it, and you’ve got them both connected to the network, so you turn on your bare-metal system and…well, how is a computer with no operating system on it supposed to be able to connect to a shared folder over the network and launch Setup.exe from that folder?
In the old days, we used a network boot floppy to make this happen. This was a bootable floppy disk from which you could run a network-aware version of MS-DOS, and to install, say, Windows 95, you would stick the floppy in your bare-metal system, turn the computer on, boot to DOS, and then manually (or automatically by launching a script) connect to the installation share on the network and run Setup.exe to begin the process of downloading the Windows installation files to the computer and running Setup on it to install Windows. Unfortunately, network boot floppies are no longer viable for a variety of reasons including lack of support for the NTFS file system, lack of support for 32- or 64-bit Windows device drivers, limited TCP/IP networking capabilities, and other reasons. What worked fine for installing Windows 95 or Windows 98 onto computers just doesn’t cut it anymore with Windows Vista.
By contrast, using the Windows AIK you can now create Windows PE boot media that supports NTFS, supports 32- and 64-bit Windows drivers, has full TCP/IP capabilities and which can be booted from a CD, a DVD, or even a USB flash drive. Then once you have booted your bare-metal system, you can manually (or automatically by using a script) connect to a network share that has the Windows Vista installation files stored on it and launch Setup.exe to install Vista onto the computer in completely unattended fashion using an answer file you created using Windows SIM.
Limitations of Windows PE

This doesn’t mean Windows PE can do everything however. For example, while Windows PE is a stripped-down version of the Windows operating system and provides you with a command prompt and can do networking and has a registry and so on, you can’t use it as your daily operating system for the simple reason that it automatically stops working and automatically after 72 hours of use. Windows PE also doesn’t support installing applications that use Windows Installer (.msi) files, and it doesn’t include the .NET Framework or the Common Language Runtime (CLR), so you really can’t run any office productivity applications on it. Windows PE also supports only a limited subset of the full Win32 application programming interfaces (APIs) so you really can’t develop useful applications to run on it either. So while Window PE is indeed Windows itself, it’s a very stripped-down version of Windows, not the full-blown version you’re used to working with each day.
All these limitations mean that Windows PE is really only useful for two things: to boot bare-metal systems so you can install Windows on them, and to boot into the Windows Recover Environment (WinRE) in order to troubleshoot a computer that has problems with its Windows installation. Actaully, Windows PE is used for one additional thing: each time you install Windows Vista (or Windows Server 2008) on a system, the very first phase of Setup is actually Windows PE at work.
Examining Windows PE Tools

As you can see from Figure 1 below, when Windows PE initializes it displays a command prompt.

Figure 1: The Windows PE command prompt
This command prompt is the only user-interface that Windows PE provides—there is no desktop and no GUI tools in Windows PE. There are a number of command-line tools available in Windows PE however, and these include the following:
This tool can be used to edit the boot configuration data (BCD) store, a store that describes boot applications and boot application settings. The BCD store in Windows Vista and Windows Server 2003 replaces the Boot.ini used by earlier versions of Windows.
Bootsect - Used to restore your computer’s boot sector (replaces FixFAT and FixNTFS used by previous versions of Windows)
DiskPart – Used to create and format partitions and volumes and perform other disk management tasks.
Drvload - Used for adding out-of-box drivers to a booted Windows PE image.
Oscdimg - Used for creating an .iso image of Windows PE so you can burn the operating system onto CD or DVD media to create a customized, bootable Windows PE CD or DVD.
PEImg - Used to create or modify a Windows PE image by adding drivers, importing packages, and so on.
In addition to the above tools there are others that are built into Windows PE. Plus you can add additional command-line tools to your customized Windows PE CD or DVD. For example, in the next article of this series we’ll walk through the steps of creating a bootable Windows PE CD that includes the ImageX.exe tool on it, and later on I’ll show you how you can use this tool on a Windows PE CD to capture an image of a sysprepped master computer so you can deploy the captured image onto bare-metal destination computers—a deployment scenario called image-based deployment that is popular with OEMs and large enterprises. But that is for next time

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part11.html

In the previous article we examined the Windows Preinstallation Environment (Windows PE) and what it is, what it is not, and what it can do and be used for. In this article we’re going to create a customized, bootable CD containing Windows PE. Then in the next article we’ll show how to use this CD to boot a bare-metal system so we can install Windows Vista on it by connecting to a network share that has the Vista installation files stored on it - in other words, to perform an image-based deployment of Vista over the network.
To create our bootable Windows PE CD, we will need our Windows Vista with Service Pack 1 product DVD media. This is important as there are several versions of Windows PE out there. Specifically, there’s Windows PE 1.0 which was based on the Windows XP kernel; then there’s Windows PE which is based on the Windows Vista RTM kernel; and finally there’s Windows PE 2.1 which is based on the Windows Vista SP1 kernel which is also the same as the Windows Server 2008 kernel. So if you want to deploy both Windows Vista SP1 and Windows Server 2008, you need to use the latest version of Windows PE which is version 2.1, and this means you need a technician computer that has the version 1.1 of the Windows Automated Installation Kit (Windows AIK) installed on it. And finally, you’ll need a CD burner and third-party CD-burning software so you can burn your customized Windows PE .iso file onto CD-R media. Got everything? Let’s go!

Creating a Customized Windows PE 2.1 Boot CD

Log onto your technician computer (I’m using a computer running Windows Server 2003 that has the Windows AIK installed on it) and click Start, All Programs, Microsoft Windows AIK, Windows PE Tools Command Prompt. As shown in Figure 1, this opens a Windows PE Tools Command Prompt window with C:\Program Files\Windows AIK\Tools\PETools as your current directory.

Figure 1: the Windows PE Tools Command Prompt on your technician computer
Type copype.cmd x86 C:\WinPE_x86 to run the copype.cmd command script which automatically creates a Windows PE build environment containing all the files needed for the 32-bit version of Windows PE:
C:\Program Files\Windows AIK\Tools\PETools>copype x86 C:\WinPE_x86
================================================== =
Creating Windows PE customization working directory
C:\WinPE_x86
================================================== =
1 file(s) copied.
1 file(s) copied.
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\bcd
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\boot.sdi
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\bootfix.bin
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\etfsboot.com
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\chs_boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\cht_boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\jpn_boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\kor_boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\boot\fonts\wgl4_boot.ttf
9 File(s) copied
C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\bcd
C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\chs _boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\cht _boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\jpn _boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\kor _boot.ttf
C:\Program Files\Windows AIK\Tools\PETools\x86\EFI\microsoft\boot\fonts\wgl 4_boot.ttf
6 File(s) copied
1 file(s) copied.
As shown in Figure 2, the copype.cmd script creates a new directory named C:\WinPE_x86 and this directory contains the files you will use shortly to create your Windows PE CD. The script also changes your current directory to your new build directory C:\WinPE_x86.

Figure 2: Windows PE build directory and files
If you explore this build directory, you will find various files and folders within. Table 1 provides a summary of the files and folders in this directory:
File or Folder
Description
\ISO
Contains the files needed to build an .iso file using Oscdimg.exe
\Mount
Use ImageX to mount the base Windows PE image to this folder when customizing your base Windows PE image
Etfsboot.com
A program that creates the CD boot sector
Winpe.wim
The base Windows PE image file
Table 1: Files and folders in the Windows PE build directory
Now let’s customize our Windows PE build environment by copying the ImageX.exe tool into it as we’ll need this tool later on for capturing an image of a master installation we wish to deploy. To copy ImageX.exe into our build environment, type copy “C:\Program Files\Windows AIK\Tools\x86\imagex.exe” C:\WinPE_x86\ISO\ at your Windows PE Tools Command Prompt:
C:\WinPE_x86>copy "C:\Program Files\Windows AIK\Tools\x86\imagex.exe" C:\WinPE_x86\ISO\
1 file(s) copied.
Next we’ll use the Oscdimg.exe tool to create an .iso image from our Windows PE build files. To do this, change your current directory to C:\Program Files\Windows AI\Tools\x86 and then typeoscdimg –n –bC:\WinPE_x86\etfsboot.com C:\WinPE_x86\ISO C:\WinPE_x86.iso at your command prompt like this:
C:\WinPE_x86>cd "C:\Program Files\Windows AIK\Tools\x86"
C:\Program Files\Windows AIK\Tools\x86>oscdimg -n -bC:\WinPE_x86\etfsboot.com C:\WinPE_x86\ISO C:\WinPE_x86.iso
OSCDIMG 2.54 CD-ROM and DVD-ROM Premastering Utility
Copyright (C) Microsoft, 1993-2007. #All rights reserved.#i
Licensed only for producing Microsoft authorized content.
Scanning source tree
Scanning source tree complete (17 files in 8 directories)
Computing directory information complete
Image file is 210825216 bytes
Writing 17 files in 8 directories to C:\WinPE_x86.iso
100% complete
Final image file is 210825216 bytes
Done.
Once Oscdimg.exe has finished its work (it takes a few minutes) you’ll now have a bootable .iso file of your customized Windows PE build environment in the root of your system drive as shown in Figure 3:

Figure 3: Bootable .iso file of your Windows PE build environment
The final step is to use your CD burner and third-party CD-burning software to burn this .iso file onto recordable CD-R media. The simplest arrangement is to have a CD burner and software installed on your technician computer, but if you don’t then you can copy your WinPE_x86.iso file (it’s about 206 MB) onto a network share or removable media and transfer it to the computer you have your burner on.
Testing Your Windows PE CD

To test your Windows PE and see if it works, insert it into the CD-ROM drive of a computer and turn the computer on. If your computer doesn’t have any operating system installed on it, Windows PE will load and initialize and you’ll get the command prompt shown in Figure 4. If your computer already has an operating system installed, press a key when prompted to boot from CD in order to load and initialize Windows PE.

Figure 4: Windows PE has loaded and initialized
Examining Windows PE

Finally, let’s take a few minutes and examine the Windows PE environment we’ve just booted into. If you type hostname at the X:\> prompt, you should see that your Windows PE installation has a computer name that begins with “minint-“ followed by some randomly-generated characters. If you type ipconfig you should see either a valid IP address obtained from a DHCP server (if there is one on your network) or an auto-generated IP address of the form 169.254.x.y. And if you type D:\imagex /? (or E:\imagex /? if your computer already has an operating system installed) you should see the syntax for using the ImageX command, which indicates that the ImageX tool is present on the Windows PE CD as intended. So far, so good.
What’s this X: drive stuff however? It’s called a RAM drive - that is, a disk volume contained in physical memory instead of on some physical device such as a hard drive. When you boot your computer using read-only bootable Windows PE media such as a CD, what happens is that Windows PE automatically creates a RAM drive and allocates 32 MB of space for this drive. This RAM disk is then used as a work area for any commands you run or any operations Windows PE needs to perform. Meanwhile, the Windows PE operating system itself is also loaded in its entirety into the physical memory of your computer, so this means once the X:\> prompt appears, you can eject your Windows PE CD and still be able to run commands like ipconfig and hostname and so on (though not imagex since that tool resides on the CD). This is handy in case you need to supply some additional drivers or scripts or something, as you can supply these files on a different CD which you can insert after you’ve removed your Windows PE CD.
Overall, Windows PE is pretty cool, and in the next article of this series you will see how to perform a simple, image-based deployment of Vista over the network by using your Windows PE CD as boot media for the bare-metal system you wish to install Vista on

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part12.html

In the previous two articles of this series we learned about the Windows Preinsallation Environment (Windows PE) and how to create a customized, bootable Windows PE 2.1 CD using the Windows Automated Installation Kit (Windows AIK) version 1.1, which provides you with tools you can use to deploy Windows Vista with Service Pack 1 and Windows Server 2008. In this article we’ll examine how to perform a basic image-based deployment of Windows Vista SP1 using the ImageX utility and the Windows PE CD we created in the previous article. Then in the next article we’ll walk through the actual steps of performing a simple, image-based deployment of Vista SP1.

Understanding ImageX

Before you can perform image-based deployment, you first need to understand the ImageX tool, which is included in the Windows AIK (and which we copied onto our Windows PE CD in the previous article). ImageX is a command-line utility for capturing, servicing and applying Windows Imaging Format (WIM) files, which are file-based Windows disk images used by Windows Vista and later. Table 1 shows the different command-line options available when using ImageX.





Table 1: Command-line options for ImageX
We’ll see examples of how to use ImageX when we walk through image-based deployment in a moment.
Steps for Image-Based Deployment

Before we walk through performing a simple image-based deployment of VistaSP1, let’s step back and take a high-level view of how the deployment process works. Image-based deployment is the process of creating a master image, capturing that image, and then applying the captured image to one or more destination computers. In more detail, the steps for performing image-based deployment look like this (see Figure 1):

Figure 1: Seven-step process for image-based deployment
Step 1: Install Vista on a reference computer that will server as the model for the other computers you want to deploy Vista onto. This reference computer is known as the master computer because it contains the master installation of Vista which you plan to duplicate onto multiple destination computers across your enterprise. You can install your reference computer manually, or you can do it using the unattended install from DVD method outlined in Part 8 of this series.
Step 2: Customize your master installation by adding drivers, turning on Windows features, installing applications, and performing other kinds of customizations needed by your users.
Step 3: Now sysprep your master installation to remove any machine-specific information from it such as security identifiers (SIDs).
Short aside: Step 3 is necessary whenever you want to duplicate an image and apply it to other machines because if you have two or more computers on your network that have the same SIDs, you’re in trouble. By design, each Windows installation has a unique machine SID that includes a randomly-generated 96-bit number. This machine SID is used as a prefix for the SIDs of any user and group accounts created on the computer. Specifically, the unique machine SID is concatenated with the relative ID (RID) of the user or group account to create a unique identifier for the account. So if you duplicate an image onto another computer without removing the SIDs first, you’ll end up with two computers that have identical SIDs, and one of the consequences of this is that user accounts on one computer will have access to files stored on removable media on the other computer even if NTFS permissions are configured to deny access. In other words, security breaks down when you duplicate installations that haven’t been sysprepped. Even worse security issues will occur if you have computers with duplicate SIDs in a domain including login problems, trust issues, problems accessing resources, roaming profile failures, and more.
Step 4: Boot your sysprepped master installation using the bootable Windows PE CD you created in the previous article in this series.
Step 5: Once the Windows PE command prompt is displayed, capture a Windows image of your master installation. Your captured image is called your base image because you will base your deployment on it.
Step 6: Copy your base image to a network share.
Step 7: You’re now ready to deploy your base image to your destination computers which currently have no operating system installed. To deploy the base image to a destination computer, use your bootable Windows PE CD to boot your bare-metal destination computer. Once the Windows PE command prompt appears, partition and format your hard drive using the Diskpart command. Then map a drive to the network share where your based image (the captured image of your master installation) is stored. Then use ImageX to apply the base image to your destination computer. Repeat as needed for as many destination computers as you need to deploy.
Variations on Image-Based Deployment

The above seven-step procedure outlines how to perform a simple, basic image-based installation of Vista onto multiple bare-metal systems starting from a customized reference installation you created. In the next article of this series we’ll walk through these steps and see in detail how to perform each step. There are two other ways of performing image-based deployment you should know about however. These include the following variations on the above process:

• Image-based deployment using Windows Setup. In this approach, you create your master installation and capture it to a network share as described above. Then you use Windows System Image Manager (Windows SIM) on your technician computer to create an answer file for unattended installation of your master installation by opening the captured WIM file in Windows SIM, creating your answer file, and saving the answer file to the same network share where the captured WIM file resides. Then you boot your destination computers using Windows PE, connect to the network share where the captured WIM file and answer file are located, and run Windows Setup by typing <mapped drive>\setup.exe /unattend:unattend.xml. Windows Setup then copies the captured image onto your destination computer and installs it using the options you’ve specified in your answer file. For more information concerning this scenario, see the Windows AIK Help file.
• Image-based deployment using Windows Deployment Services. In this approach, you create your master installation and capture it from a server running Windows Deployment Services (Windows DS). Windows DS is a server role in Windows Server 2008 that represents the next evolutionary version of Remote Installation Services (RIS) which first appeared in Windows 2000 Server. The nice thing about this approach is that you don’t need to use a Windows PE CD to boot each destination computer. Instead, you simply turn them on and they use PXE to obtain an IP address from a DHCP server, then they use TFTP to download a boot client from the Windows DS server, then the boot client applies the captured image. We’ll see how to use Windows DS soon in future articles in this series

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part-13-Performing-Image-Based-Deployment.html

In the previous article we examined how image-based deployment works. In this article, we’ll walk through the steps of performing a simple, basic image-based deployment of Windows Vista with Service Pack 1, Enterprise Edition. To do this, we’ll follow the seven-step process outlined in the previous article in this series.

Prerequisites for Performing the Walkthrough

To perform this walkthrough yourself, you’ll need two desktop computers:

• One to use as your reference computer on which you’ll install Vista, customize, sysprep, and capture your base image from.
• One to use as your destination computer - this one should have no operating system installed on it. Note that the disk drive on your destination computer should be the same size or larger than the one on your reference computer.

You’ll also need a DHCP server and a file server, which can both be the same computer if desired. And, of course, a network connecting your two desktop computers and server(s) together.
Finally, you’ll need the custom, bootable Windows PE CD you created in Part 11 of this series.
Step 1: Install the Reference Computer

Begin by installing Vista on a reference computer. You can use either manual or unattended installation to do this - see Part 8 of this series for how to perform an unattended install using your Vista DVD together with an answer file.
Step 2: Customize the Reference Computer

Log on to your reference computer and customize it as desired. We’ll perform one absolutely essential customization—installing games! Well, maybe not every administrator will agree, but that’s OK. Anyways, to enable the Games feature on Vista, open Control Panel, click Programs, click Turn Windows Features On Or Off, and select the checkbox labeled Games (Figure 1):

Figure 1: Turning on the Games feature on Vista
If desired, you could also install applications, customize the desktop, configure services, install device drivers, and perform other customizations your users will need on their computers. We’ll just stick with enabling Games to keep things simple at this point.
Step 3: Sysprep the Reference Computer

Open a command prompt on your reference computer, type cd sysprep to change the current directory to C:\Windows\System32\Sysprep, and type sysprep /oobe /generalize /shutdown to sysprep (or better, generalize) your reference computer by removing all machine-specific information from it such as security identifiers (SIDs), the contents of the event logs, system restore points, installed Plug and Play drivers, and so on. You can also do generalize your system by pressing WINDOWS KEY + R to open the Run box, typing sysprep and clicking OK which opens the C:\Windows\System32\Sysprep folder in Windows Explorer. Then double-click the Sysprep application in this folder to open the System Preparation Tool dialog and select the options shown in Figure 2:

Figure 2: Sysprepping your reference computer
Clicking OK starts the generalizing process, and when this is completed your system shuts down. For more information on using Sysprep, see Part 5 in this series.
Step 4: Boot the Reference Computer Using Windows PE

Now take the bootable Windows PE 2.1 CD you created in Part 11 of this series and boot your reference computer using it. After a short time, the Windows PE command prompt will be displayed.
Step 5: Capture a Base Image from the Reference Computer

When the Windows PE command prompt appears, type the following command:
D:\imagex /compress fast /capture C: C:\baseimage.wim “Base Image” /verify
This command capture an image of the entire C: drive of your reference computer and save this image as a WIM file named baseimage.wim in the root folder of C: drive. This captured image will be the base image you will deploy later onto your destination computers. Figure 3 shows the image capture process (which takes some time to complete) underway:

Figure 3: Capturing your base image from your reference computer’s boot/system volume
Step 6: Copy the Base Image to a Network Share

Once your base image has been captured - you’ll see a message saying “Successfully imaged C:\” when ImageX is done capturing the image - you now need to get your image file off of your reference computer and save it somewhere so that you can deploy it later onto your destination computers. The simplest way to do this is to use the net use command at the Windows PE command prompt to map a network drive to a shared folder on your file server.
For example, first create a shared folder named C:\Images on your file server and share this folder as IMAGES with Full Control permission for Everyone (both shared folder and NTFS permission). Then at the Windows PE command prompt on your reference computer, type net use Y: \\<name>\IMAGES where <name> is either the NetBIOS name or IP address of your file server. If a “password is invalid” message appears when you do this, type a username and password valid on your file server. Be sure to type the username in the form <computer_name>\<user_name> or <domain_name>\<user_name> depending on whether your file server belongs to a workgroup or a domain. If the net use command fails, it might be that your DHCP server isn’t working—check the leases in the scope and make sure Windows PE has leased an address from your server.
Once you’ve mapped the drive, type copy C:\baseimage.wim Y: to copy your captured base image file to the network share. Once this is completed (check the C:\Images folder on your file server to make sure the baseimage.wim file is actually there) you can now remove the Windows PE CD from your reference computer and power the computer off.
Step 7: Deploying the Base Image onto a Destination Computer

Now you’re finally ready to deploy your captured image onto one or more destination computers. Start by booting your destination computer using your Windows PE CD, and once the command prompt appears, use the following Diskpart commands to create a new primary partition, set the new partition as the active partition, and format the new partition as an NTFS volume:
diskpart
select disk 0
clean
create partition primary
select partition 1
active
format
assign letter=C:
exit
Figure 4 shows each of these commands at work:

Figure 4: Preparing the hard drive of the destination computer to receive the image
Tip: You could also create a batch file of Diskpart commands and save your file as part of your Windows PE build before you burn this onto a CD. Then you could simply run the batch file at the Windows PE command prompt in order to partition and format the disk of a destination computer in one step. We’ll look at this and other Windows PE customizations in a later article of this series, but for now we’re just covering the basics of how to perform image-based deployment
Once the disk drive of your destination computer has been suitably prepared, type the following command two commands at the Windows PE command prompt to connect to your network share and copy the base image from there onto the hard drive of your destination computer:
net use Y: \\<name>\IMAGES
copy Y:\baseimage.wim C:
Once again, <names> is either the NetBIOS name or IP address of your file server, and you may be prompted to supply credentials valid on your file server. And the copy operation may take some time to complete as the image file is typically couple of gigabytes in size. Once the copy operation is complete, you’ll see a message saying “1 file(s) copied.”
Now you’re ready to apply the captured image onto the hard drive of your destination computer. To do this, type the following command at your Windows PE command prompt:
D:\imagex /apply C:\baseimage.wim 1 C:
This will again take some time to complete (almost as long as capturing an image) and when it’s done you’ll see a message saying “Successfully applied image.”
You’re done. Remove the Windows PE CD from your destination computer, power the computer off, then power it on again. As the computer boots up, new SIDs will be generated for it and you’ll be presented with the machine out-of-box-experience (machine OOBE) as shown in Figure 5:

Figure 5: Machine OOBE on destination computer
This OOBE allows each user to customize their computer by giving it a name, creating a local user account, selecting a desktop background, and so on. For example, if you were an OEM and you were going to deliver the computers to customers, the customer would walk through OOBE the first time they turned the computer on. In an enterprise you would want to use an answer file to automate this portion of deployment—we’ll examine this issue in a future article in this series.
Finally, once you’ve completed the OOBE, you can log on and play FreeCell on your destination computer (Figure 6):

Figure 6: Productive use of time in the enterprise

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part14.html

In the previous thirteen articles of this series we have learned about the various components of the Windows Automated Installation Kit (Windows AIK) and how they can be used together to create customized solutions for unattended deployment of Windows Vista SP1 Enterprise edition in small, mid-sized, and large enterprise environments. The tools we have examined in these articles have included the System Preparation Tool (Sysprep), Windows System Image Manager (Windows SIM), the Windows Preinstallation Environment (Windows PE), ImageX, and a few other tools that are included in the Windows AIK. The reasons we've examined these different tools in depth are twofold:

1. To understand the deployment process by looking at how these tools interact with the three phases and seven configuration passes of the Windows Setup process.
2. To learn how organizations can create their own customized deployment solution using these tools in a way that can best suit their business needs.

But while the Windows AIK and its tools can be used to a wide variety of create custom automated deployment solutions for deploying Windows Vista, these solutions have no central management capability, which makes them hard to scale for large deployments. Imagine if you had dozens of images and dozens of different answer files to work with - how would you keep track of everything?
What you need for larger deployments is a centralized, server-based deployment solution, and that's exactly what Windows Deployment Services (Windows DS) provides. Windows DS is a server-based solution for deploying Windows images onto bare-metal systems over a network, and it has the kind of power, flexibility, and scalability that make it particularly useful for large-scale deployments. Windows DS is in fact the successor to Remote Installation Services (RIS), a server-based deployment solution that was first included in Windows 2000 Server. In this article and the next several articles of this series, we're going to look at how Windows DS works, its features and capabilities, how to install and configure it, and how to use Windows DS to perform unattended deployments of Windows Vista.
Note:
Although Windows DS is available for the Windows Server 2003 platform as part of Service Pack 2, this series of articles focuses on using the Windows Server 2008 version of Windows DS.
Overview of Windows DS

Windows DS is a Windows Server 2008 role that can be used for creating custom, sever-based solutions for deploying Windows Vista, Windows Server 2008, and (if configured appropriately) earlier versions of Microsoft Windows including Windows XP and Windows Server 2003. Windows DS can be used create and manage Windows images (.wim files) that can be used for booting and installing Windows onto bare-metal systems. If destination computers support the Pre-Boot Execution (PXE) environment, then you can simply turn on a destination computer and it will then automatically find a Windows DS server, download the necessary files, and perform an unattended install. And if you have older computers that don't support PXE booting, you can use Windows DS to create remote client boot disks that can kick start the installation process on the destination computers.
New Features of Windows DS in Windows Server 2008

We mentioned that Windows DS is simply the newest evolutionary version of RIS and that an earlier version of Windows DS is available for Window Server 2003. What the new version of Windows DS in Windows Server 2008 brings to the table are as follows:

• Support for the Windows imaging (WIM) format.
• An improved management interface.
• WDSUTIL.EXE, a new scriptable command-line tool.
• Networking improvements to make large-scale deployments more bandwidth-efficient.

Windows DS Requirements

Before you implement Windows DS on your network as a deployment solution, you need to be aware of its requirements. Windows DS can be implemented in two different ways:

• The default implementation, which requires an Active Directory environment that includes at least one domain controller, DNS server, and DHCP server. In a default implementation of Windows DS, you can either install Windows DS on a separate member server that belongs to your domain or you can install it on a domain controller. The preferred method is to install Windows DS on a member server that is not running the DHCP Server role, and the walkthroughs in future articles of this series will use this scenario.
• A custom implementation, which can be implemented in either domain or workgroup environments. This scenario is beyond the scope of this present series of articles here on WindowsNetworking.com

Windows DS Components

Windows DS is implemented as a server role on Windows Server 2008 and consists of three types of components:

• Server components
• Client components
• Management components
• The server components of Windows DS are located on the member server running the Windows DS role and consist of the following:
• Image repository – This is used for storing boot images, install images, and other types of files that may be needed when deploying Vista onto destination computers.
• PXE Server – A service that works together with a DHCP server and enables destination computers that have no operating system installed to boot remotely and begin the installation process.
• TFTP Server – A service that works together with the PXE Server to allow destination computers that have no operating system installed to download the Windows DS Client software so that an operating system can be downloaded and installed.
• Networking layer – Additional components that support multicasting of Windows image files and other features.

Figure 1 shows the server components of a Windows DS server and how they work together to make remote installation of Windows onto bare-metal systems possible.

Figure 1: Server components of Windows DS
The client components of Windows DS include the Windows DS client, which can be deployed either automatically over the network using the PXE and TFTP Server components or can be distributed manually on removable media for destination computers that do not support remote PXE booting. The Windows DS client displays a menu that can the remote user can use to select which Windows operating system image he wants to install on his computer, and once the user makes his selection the Windows DS client then requests the appropriate Windows image from the image repository on the Windows DS server, downloads this image to the destination computer, and launches Windows Setup in order to install the image on the destination computer.
The management components of Windows DS include the following:

• The Windows Deployment Services MMC console, which can be started from Administrative Tools on the Start menu.
• A command-line tool named WDSUTIL that can be used to perform all the tasks that the MMC console can be used for and more, and which can also be used to script Windows DS configuration and management tasks.
• The underlying Windows DS application programming interfaces (APIs) which can be used to build customized deployment solutions using Windows DS. These APIs are described in detail in the MSDN Library at Windows Deployment Services.

Figure 1 shows the management components of a Windows DS server and how they integrated with the Active Directory environment you need to use Windows DS in its default implementation scenario.

Figure 2: Management components of Windows DS
Conclusion

This article has looked at the rationale behind why Windows DS is needed and examined the different features and components of Windows DS. In the next article, we'll look at how to implement Windows DS within an Active Directory environment

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part15.html

In the previous article of this series we looked at the rationale behind why Windows DS is needed and examined the different features and components of Windows DS. In this present article and the next one, we will look at how to implement Windows DS within an Active Directory environment.
Implementing Windows DS within your organization's networking infrastructure is basically a three-step process:

• Preparing your environment to make sure it meets the requirements for implementing Windows DS.
• Installing the Windows DS role on one or more servers running Windows Server 2008.
• Performing the initial configuration of the Windows DS servers you have deployed.

This article will examine the first two steps while the next article will look at the third step in the Windows DS implementation process.
Step 1: Preparing Your Environment for Windows DS

To prepare your networking environment for implementing the Windows Server 2008 version of Windows DS, you need the following:
An Active Directory Domain Services environment with at least one domain controller, DNS server, and DHCP server.
A member server running Windows Server 2008 that is joined to the domain and has no roles installed on it.
Figure 1 shows the test environment we will be using for the next several articles. Our environment has two servers belonging to the contoso.com domain located in Seattle (SEA) as follows:

• SEA-DC1 is a domain controller that also has the DNS and DHCP Server roles installed.
• SEA-WDS is a member server that currently has no roles installed on it.
• One or more destination computers with no operating system installed on which you will be deploying Windows Vista SP1 Enterprise edition using your Windows DS deployment environment.

Figure 1: Our test environment for implementing Windows DS for these articles
Note:
For best results the member server you will install Windows DS on should have at least on additional disk volume in addition to the boot/system volume. As described in the next article of this series, this additional volume will be used to locate the repository, a series of folders where Windows images used for deploying Windows Vista will be stored.
Step 2: Installing the Windows DS Server Role

Once you have prepared your environment for implementing Windows DS, you can go ahead and install the Windows Deployment Services server role on one or more member servers in your domain. In our scenario, we are going to install the Windows Deployment Services role on the server named SEA-WDS. There are three ways you can install the Windows Deployment Services role on a server:
Using the Add Roles Wizard

• Using the ServerManagerCmd.exe command-line tool
• During an unattended install
• Let's examine each of these three methods in turn.

You can also upgrade an existing Windows Server 2003 server running the previous version of Windows DS to the Windows Server 2008 version of Windows DS.
Installing the Windows Deployment Services Role using the Add Roles Wizard

You can install the Windows Deployment Services role by using the Add Roles Wizard, which can be launched from either the Initial Configuration Tasks screen or from the Server Manager MMC console. Once the wizard has been launched, select the Windows Deployment Services role from the list of roles displayed as shown in Figure 2.

Figure 2: Using the Add Roles Wizard to install the Windows Deployment Services role on a server
The next screen of the wizard offers two role services you can install:

• Deployment Server – When installed together with the Transport Server role services, the Default Server role service provides the full Windows DS functionality of being able to use Windows DS to deploy Windows Vista onto bare metal systems over your network.
• Transport Server – When installed by itself, this role service offers only a subset of Windows DS functionality and can be used to build custom deployment solutions using Windows DS.

By default, both the Deployment Server and Transport Server role services are selected (Figure 3).

Figure 3: Installing the two role services for Windows DS
Finishing the wizard causes the Windows Deployment Services role with its two role services to be installed, which turns the member server into a Windows DS server which you can use for deploying Vista onto bare-metal systems.
Installing the Windows Deployment Services Role using the ServerManagerCmd.exe Command

The Windows Deployment Services role can also be installed from the command-line using the ServerManagerCmd.exe command-line tool. The following command will install the Windows Deployment Services role together with both of its two role services:
ServerManagerCmd –install WDS
If you wish to install only the Deployment Server role by itself, you can do so by using this command:
ServerManagerCmd –install WDS-Deployment
And if you wish to install only the Transport Server role by itself, you can do so by using this command:
ServerManagerCmd –install WDS-Transport
Installing the Windows Deployment Services Role during and Unattended Install

You can also install the Windows Deployment Services role as part of an unattended installation of Windows Server 2008 on a server. You can do this using the tools of the Windows AIK as described in the previous articles of this series. Specifically, using Windows System Image Manager (Windows SIM) you open the answer file you are using for your unattended install of Windows Server 2008 and perform the following steps:

1. Add the Microsoft-Windows-Shell-Setup\FirstLogonCommands setting to the oobeSystem configuration pass of Windows Setup.
2. Configure the above setting to run the ServerManagerCmd –install WDS command during the post-installation phase of Windows Setup.

Upgrading an existing Windows Server 2003 to the Windows Server 2008 Windows Deployment Services Role

You can also upgrade an existing Windows Server 2003 server running the previous version of Windows DS to Windows Server 2008, which will upgrade to the new version of the role. Upgrading an existing Windows Server 2003 Windows DS server is more complex however than performing a clean install of Windows Server 2008 and adding the Window DS role, particularly if your existing server itself was previously upgraded from a Remote Installation Services (RIS) server running Windows Server 2003 or Windows 2000 Server.
What makes the upgrade more complex is that in its Windows Server 2003 version Windows DS can run in one of three possible modes:

• Legacy mode – This is functionally equivalent to RIS on Windows Server 2003. This mode only lets you deploy legacy RISETUP/RIPREP images using OSChooser and does not support deploying WIM format images, so a Windows DS server running in this mode can only be used to deploy Windows XP and Windows Server 2003.
• Mixed mode – This mode lets you deploy both legacy RISETUP/RIPREP images using OSChooser and also newer WIM format images using Windows PE, so a Windows DS server running in this mode can be used to deploy Windows Vista, Windows Server 2008, Windows XP and Windows Server 2003.
• Native mode – This mode only lets you deploy WIM format images using Windows PE, so a Windows DS server running in this mode can only be used to deploy Windows Vista and Windows Server 2008.

Before you upgrade a Windows Server 2003 Windows DS server running in either legacy or mixed mode, you must change your Windows DS server so that it is running in native mode. More information about upgrading Windows DS can be found at Upgrading to Windows Server 2008.
Conclusion

This article has walked you through the first two steps of implement Windows DS: preparing your environment and installing the Windows Deployment Services role. The next article in this series looks at how to perform the initial configuration of your new Windows DS server