Partager via

10 Things You Need to Know when Deploying Windows Vista

  • Article

I have just spotted this on the US TechNet Magazine site and thought it would be great to share......

So here are 10 deployment differences between Windows® XP and Windows Vista™ that you'll be glad you discovered when it's time to make the move.

1. Windows Vista Images Are Bigger

With Windows XP and Windows 2000, it was possible to create images that would fit easily on a single CD (less than 700MB). Even organizations that added applications, drivers, and utilities to their image typically ended up with an operating system image in the 1GB to 3GB range.

With Windows Vista, image size begins at about 2GB—compressed. Once this image is deployed, the size is often around 5GB or more, and there's no way to reduce it. If you add additional applications, drivers, or other files, this image obviously grows even larger.

So how will you deploy the image? Does your network have the necessary capacity? (10MB networks or non-switched networks are not sufficient.) If you want to use CDs, how many can you deal with? You'll need three or four. DVDs (with a capacity of 4.7GB each) are now easy to create, so you can deploy using DVD drives if you have them. (If not, consider adding DVD drives when buying the next round of PCs.)

With USB memory keys growing in size (as large as 4GB or more) and shrinking in price, it would be quite easy to use one for deploying Windows Vista, since you can make a bootable key as long as the computer's BIOS supports it.

Finally (though this doesn't relate to image size), take note that there is no longer an I386 directory. Instead, all components, whether installed or not, reside in the Windows directory (although not in the standard SYSTEM32 directory). When installing a new component, the necessary files will be pulled from this location.

2. Security Is Enhanced

A number of Windows Vista security enhancements will impact deployment. For example, configuring Windows Vista to support "low rights" users, where the logged-on user does not have administrator rights, is easier. Some applications failed to work on Windows XP when users did not have administrator access because they assumed they would have full access to the C: drive and all parts of the registry. With Windows Vista, applications that attempt to write to restricted areas will have those writes transparently redirected to other locations in the user's profile.

The second big change here is that non-administrators can load drivers. This lets users attach new devices without needing to call the help desk in tears.

The third difference you'll find is that Internet Explorer® can automatically install ActiveX® controls using elevated rights. A new service can perform these installations on the user's behalf (if, of course, the IT administrator allows this via Group Policy).

Some of you may currently be using Power User rights on Windows XP, but this really does not offer many benefits (in terms of restricting user rights) over simply granting full Administrator privileges. Because of this, the Power Users group in Windows Vista has been removed, although it can be put back if required using a separate security template that can be applied to an installation of Windows Vista.

Sometimes you will need administrator rights, but this doesn't mean you want to run with admin rights all the time. So Windows Vista adds User Access Control (UAC), which causes most user applications—even for Administrators—to run with restricted rights. For applications that require additional rights, UAC will prompt for permission, asking either for permission to run with elevated privileges or for other user credentials that can replace the logged-on users.

There are also enhancements to the firewall built into Windows Vista. The new firewall can now control both inbound and outbound traffic, while still being fully configurable via Group Policy.

Finally, BitLocker™ full-volume encryption, which is included with Windows Vista Enterprise and Ultimate, allows the entire operating system volume to be encrypted. The volume can then be read only from within Windows Vista and only when the right keys are provided, either from the computer's built-in Trusted Platform Module (TPM) 1.2 chip, a USB key, or typed into the keyboard. (Note that only TPM 1.2 or later is supported.)

3. Windows Vista Is Componentized

One of the biggest architectural changes in Windows Vista is that it is now a completely componentized operating system. This affects deployment in the following ways.

Configuring which Windows Vista features should be installed requires configuring the components to be enabled. New tools, like the Windows System Image Manager, shown in Figure 1, assist with this.

Security updates, language packs, and service packs are simply components. Tools such as Package Manager (PKGMGR) can be used to apply these to Windows Vista.

In addition, all servicing can be performed offline or online. You can even apply changes to Windows Vista or a Windows Vista image when Windows Vista is not currently running. This is ideal for deployments: the operating system can be patched before it boots onto your network for the first time.

Drivers are also treated as components, so they can be added and removed easily—even offline. This means you can add drivers to existing images, even just-in-time (as the machine boots for the first time) during the deployment process. And this applies to mass-storage drivers as well; no longer do you need to create a new image just to add a new mass storage driver.

Windows Vista exposes more settings, with most components providing configurable options, so it's easier to set installation defaults that can be managed on an ongoing basis using Group Policy. For a rundown of new tools in Windows Vista, see the sidebar "Tools You Need; Tools to Forget."

Tools You Need; Tools to Forget

Here’s a rundown of the tools you’ll be using when you roll out Windows Vista, followed by a list of the tools you can retire for good once Windows Vista arrives.

USE THESE:

  • SYSPREP This is the updated version, modified for Windows Vista.
  • SETUP A new installation tool for Windows Vista, replaces WINNT and WINNT32.
  • IMAGEX The new command-line tool for creating WIM images.
  • Windows System Image Manager A tool for creating and modifying unattend.xml files.
  • PEIMG The tool for customizing Windows PE 2.0 images.
  • Windows Deployment Services The new version of RIS, which adds the ability to deploy Windows Vista and Windows XP images, as well as Windows PE 2.0 boot images.
  • PNPUTIL This is the new tool for adding and removing drivers from the Windows Vista driver store.
  • PKGMGR Also new, this Windows Vista tool is used for servicing the operating system.
  • OCSETUP This replaces SYSOCMGR and is used for installing Windows components.
  • BCDEDIT A new Windows Vista tool for editing boot configuration data.
  • Application Compatibility Toolkit 5.0 This updated tool lets you assess whether your applications are compatible with Windows Vista.
  • User State Migration Tool 3.0 An updated tool for capturing and restoring user state, supports Windows XP and Windows Vista, as well as all versions of Office including 2007.
  • BitLocker The full-volume drive encryption capability included in Windows Vista Enterprise and Ultimate editions.

FORGET THESE:

  • Remote Installation Services RIS has been replaced by Windows Deployment Services (WDS) but still offers legacy support on Windows Server 2003; RIPREP and RISETUP are not possible with Windows Vista.
  • Setup Manager/Notepad Use Windows System Image Manager instead for editing unattended setup configuration files.
  • WINNT.EXE and WINNT32.EXE Use SETUP instead.
  • SYSOCMGR Replaced by OCSETUP, PKGMGR.
  • MS-DOS Boot Floppies Forget them. Use Windows PE!

4. Text-Mode Installation Is Gone

The basic process used to install Windows XP has been unchanged since the earliest days of Windows NT®. This time-consuming procedure involved an initial text-mode installation step in which every operating system file was decompressed and installed, all registry entries were created, and all security was applied. Now with Windows Vista, this text-mode installation phase is completely gone. Instead, a new setup program performs the installation, applying a Windows Vista image to a computer.

Once this image is applied, it needs to be customized for the computer. This customization takes the place of what was called mini-setup in Windows XP and Windows 2000. The purpose is the same: the operating system picks the necessary settings and personality for the specific computer it was deployed to.

The image preparation process has also changed. With Windows XP, you would "Sysprep" a machine to prepare the reference operating system for deployment. With Windows Vista, you'll still run Sysprep.exe (installed by default in C:\Windows\System32\Sysprep), which will "generalize" the machine for duplication.

Windows Vista (any version) is provided on the DVD as an already-installed, generalized (Sysprepped) image, ready to deploy to any machine. Some customers may choose to deploy this image as-is (possibly injecting fixes or drivers using the servicing capabilities described earlier).

5. Boot.ini Is History

That's right, the Boot.ini file is not used in Windows Vista or in the new Windows PE 2.0. Instead, a new boot loader, bootmgr, reads boot configuration data from a special file named BCD. A brand new tool called bcdedit.exe (or a separate Windows Management Instrumentation or WMI provider) is used to maintain the contents of the BCD. A Windows PE 2.0 boot image can be configured in BCD too, making it easy to boot into either Windows Vista or Windows PE without making any other changes to the machine. This flexibility can be useful in recovery or maintenance scenarios.

6. Settings Are Configured in XML

With Windows XP (and previous versions of Windows PE) configuration information was stored in various text files. These text files have been replaced with an XML file.

Unattend.txt, which was used to configure how Windows XP is installed, has been replaced by unattend.xml. Unattend.xml also replaces three other files:

  • Sysprep.inf, which was used to configure how a Windows XP image is customized when deployed to a machine using a mini-setup.
  • Wimbom.ini, which was used to configure Windows PE.
  • Cmdlines.txt, which was used to specify a list of commands to execute during mini-setup.

An example of unattend.xml can be downloaded from TechNet Magazine at microsoft.com/technet/technetmag/code06.aspx.

You may still use separate files if you want, though. You don't need to put all configuration items in a single unattend.xml file. The high-level schema of the new XML configuration file is well defined, with each phase of the deployment process represented. The actual configuration items are specified on the appropriate operating system components and these items are dynamically discovered from the components themselves.

With Windows XP, most IT professionals used Notepad to edit the various configuration files. You can still do that, but the Windows System Image Manager tool I discussed earlier can be used to inspect the Windows Vista image, determine what settings are available, and allow you to configure each one.

Another tool to aid deployment is the User State Migration Tool (USMT) 3.0, which is expected to be released at the same time as Windows Vista. It will also use XML configuration files in place of the .inf files that were used in previous versions. See "Migrating to Windows Vista Through the User State Migration Tool" for more information.

7. No More HAL Complications

With Windows XP, technical restrictions prevented the creation of a single image that could be deployed to all computers. Different hardware abstraction layers (HALs) meant you had to maintain multiple images. (For more on this see the Knowledge Base article "HAL options after Windows XP or Windows Server 2003 Setup") Most organizations needed two or three images per platform (x86 and x64) and some chose to have even more—though each image brings added costs and complexity.

In Windows Vista, those technical restrictions are gone; the operating system is able to detect which HAL is required and automatically install it.

8. Windows PE Rules

Windows PE 2.0, the new version that will be released with Windows Vista, is a key part of the deployment process. Even the standard DVD-based installation of Windows Vista uses Windows PE 2.0, and most organizations will be using it (often customized for the organization's specific needs) as part of their deployment processes.

Compared to MS-DOS®-based deployment, Windows PE 2.0 brings numerous benefits, including less time spent trying to find 16-bit real-mode drivers. (It's not even possible to find these any more for some newer network cards and mass storage adapters.) Better performance from 32-bit and 64-bit networking stacks and tools, as well as large memory support are also advantages. And don't forget support for tools such as Windows Scripting Host, VBScript, and hypertext applications.

Windows PE has been available for a few years (the latest version, Windows PE 2005, was released at the same time as Windows XP SP2 and Windows Server 2003 SP1), but not all organizations could use it; it required that you have Software Assurance on your Windows desktop operating system licenses. With Windows PE 2.0, that's no longer the case. All organizations will be able to download Windows PE 2.0 from microsoft.com and use it freely for the purposes of deploying licensed copies of Windows Vista.

Like Windows Vista itself, Windows PE 2.0 is provided as an image that is componentized and can be serviced both online and off. As with Windows PE 2005, several optional components can be added, although Windows PE 2.0 includes some new ones: MSXML 3.0, Windows Recovery Environment, language packs, font packs, and so on. New tools like peimg.exe are provided for servicing Windows PE 2.0. Peimg.exe can also be used for adding drivers—including mass storage devices, which no longer require any special handling.

9. It's All about Images

With Windows XP, some companies used the image creation capabilities of the Systems Management Server (SMS) 2003 OS Deployment Feature Pack or third-party image creation tools. There was no generic image creation tool available from Microsoft. That's changed with Windows Vista: new tools have been created to support the Windows Imaging (WIM) file format. Unlike many other image formats, WIM images are file-based, enabling them to be applied to an existing partition non-destructively. This has great advantages in deployment processes, since user state can be saved locally instead of on a network server, eliminating what is frequently the largest source of network traffic during a deployment.

Because WIM files are file-based images, they (obviously) are not sector-based, so there are no issues around different-sized disks or partitions. A WIM image contains only the contents of a single disk volume or partition, so if you have multiple partitions to capture, you create a separate image for each one. But each of these images can be stored in the same WIM file, since the WIM file format supports multiple images per file.

The WIM file format also supports single-instance storage, so duplicate files (even from different images) are automatically removed. Between this and the advanced compression techniques employed, WIM images are typically smaller than images created by other tools. However, because of the extra processing, they do take longer to create. This size versus performance trade-off is fair enough; since you typically capture the image only once and then deploy it many times, the network traffic savings can be substantial.

The IMAGEX command-line tool interfaces with the lower-level WIMGAPI API (which is fully documented for use in custom tools too), and is used to create and manipulate WIM images. It also provides a mechanism for mounting a WIM image as a file system. Once mounted, the image can be read and modified using standard Windows tools since it looks like a normal removable media drive. This facility opens up whole new servicing opportunities.

10. Deployment Is Language-Neutral

Windows XP supported different languages in two ways. You could either deploy localized versions of Windows XP, requiring a different image for each language, or you could deploy an English Multilanguage User Interface (MUI) version with added language packs. There were advantages and disadvantages to each approach, but in most cases organizations that needed to support multiple languages took the MUI route, dealing with the limitations of running with an operating system that was effectively English at its core. Organizations that worked only with one language typically chose to use only the localized versions.

Now with Windows Vista, the entire operating system is language-neutral. One or more language packs are added to this language-neutral core to create the image that is deployed (although only some versions of Windows Vista support multiple languages).

Servicing of Windows Vista is also language-neutral, so in many cases only one security update is needed for all languages. And configuration is language-neutral, so one unattend.xml can be used for all languages.

Help Is Available

The changes I've described mean that the image creation and deployment processes you've been using for Windows XP will need to be updated. In some cases, these updates might be minor; in others (such as an MS-DOS-based process using cmdlines.txt), significant changes may be required. To help, Microsoft has created new tools, guidance, and step-by-step procedures. These are included in the Solution Accelerator for Business Desktop Deployment (BDD) 2007.

BDD 2007 breaks down the deployment process into more manageable pieces, with different teams managing each component. Guidance, checklists, and tools are provided for each team to help with the tasks they need to perform (see Figure 2).

BDD 2007 is currently available for download from connect.microsoft.com after you sign up for the open beta program. Contained in the download are all the required Windows Vista deployment tools, including Windows PE 2.0, ImageX, Windows System Image Manager, and USMT 3.0, along with documentation explaining how to use them in an end-to-end process. The final version of BDD 2007 will be released at about the same time as Windows Vista. For a look at BDDWorkbench, see Figure 3.

The goal of BDD 2007 is simplification. Even if you don't have an existing image creation and deployment process, you should be able to use BDD to set one up quickly. Two deployment methods are provided:

  • Lite Touch, which was completely rewritten, requires user interaction to start deployment. It doesn't require any special infrastructure although it can utilize Windows Deployment Services, the next version of Remote Installation Service (RIS).
  • Zero Touch, which requires no user intervention, is layered on top of the SMS 2003 OS Deployment Feature Pack.

The new features in BDD 2007 include driver repository and injection, full computer backup processing, integration of all the Windows Vista deployment tools, and more. BDD 2007 will include all the source code for all of its automation tools, so you can modify it to meet your specific needs or copy and paste it into your own solutions. The source code is provided without restriction.

For more information on BDD 2007, see the TechNet Desktop Deployment center.

Comments

  • Anonymous
    August 16, 2007
    Thanks for including that, very usefull info for sysbuilders :) (Even though it was pinched ;))