Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

System Center Configuration Manager 2007 : Operating System Deployment - What Works Best for You

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
11/8/2012 4:43:16 PM
As with most things Microsoft, there are multiple paths to the same destination, none of them specifically wrong or right. For example, if you want to lock your screen—always a good idea when you step away from your desk—there are a number of ways you can accomplish this:
  • Simultaneously press the Windows key and L.

  • Press Ctrl-Alt-Del and select Lock this computer.

  • Create a desktop shortcut with the command line RUNDLL32 USER32.DLL,LockWorkStation.

OSD includes similar flexibility, allowing disparate organizations to use the same tool differently to meet their needs. Nearly every step of the process is customizable, and you can tailor it as necessary. Although this flexibility sometimes leads to uncertainty and conflicting opinions as to the best way to get things done, ultimately the only thing that matters is if it works for you and fits your organization’s goals and requirements.

Having discussed tools used by OSD, the next section covers OSD itself.

OSD Scenarios

Here are the three main scenarios for operating system deployment, and OSD addresses all three:

The next sections describe these scenarios.

New System

The new system scenario is the easiest to deal with because you do not have to worry about user state—a user’s state includes all the data, documents, and configuration of the system and applications that are unique to that user. This scenario simply involves wiping a system, whether it is straight from the vendor or previously used inside your organization, and deploying the image and applications to it.

In-Place Migration

An in-place migration is one where the system is currently in use but needs to have its operating system reloaded. This reload can be the result of a variety of reasons:

  • An upgrade such as Windows XP to Windows Vista.

  • The current operating system installation is broken beyond repair.

  • The operating system installation does not meet current standards.

After a process is in place to quickly rebuild systems using OSD, organizations typically choose to re-image a system when the helpdesk spends a set amount of time troubleshooting without resolving an issue. This approach provides a way to decrease those helpdesk costs spent on fixing operating systems.

Side-by-Side Migration

A side-by-side migration usually occurs as the result of a hardware refresh. In this scenario, a new system physically replaces a user’s system and might involve an operating system switch. Both in-place and side-by-side migration scenarios add the complexity of user state migration.

Official Microsoft Scenarios

For the record, there are five scenarios in existing Microsoft documentation:

  • New System— This is the same as the New System scenario just described in the “New System” section.

  • Refresh— This is an in-place migration without upgrading the operating system.

  • Replace— This is a side-by-side migration without upgrading the operating system.

  • Upgrade— This is either an in-place or a side-by-side migration, including the upgrading of the operating system.

  • OEM— This is a scenario available to Original Equipment Manufacturers (OEM) using the MDT to prepare systems for customer or end-user delivery.

The primary difference in these scenarios from the ones previously presented in the “OSD Scenarios” section is the distinction made for upgrading the operating system. This distinction, although significant to the end-user, does not affect the actual operation of OSD, which does not change how it operates based upon the starting and ending operating system.

Imaging Goals

The core building block, which OSD builds on, is an image of a fully installed reference Windows system. Reference systems are systems used to build baseline images for deployment to the rest of the systems in the organization. Because hardware differences between a reference system and target deployment systems can cause issues, you must often use multiple reference systems to model your environment and thus create multiple images.

Enabling creation and deployment of this image is what OSD focuses on. However, OSD cannot automate the actual choice or definition of what goes into an image because this is not a technical decision.

A general definition of an image is a single file that stores all the files and information for a specific disk drive volume on a computer system. This file is portable and can be copied or deployed to a destination system.

Deploying the image file creates an exact duplicate of the original source volume. This allows you to easily copy the content of a disk drive volume containing an operating system, installed applications, and customizations to multiple other destination systems. In effect, the image clones the source system and allows rapid deployment of an operating system on a large scale. The process of copying the image to multiple machines is much quicker than doing a native Windows install and requires little manual intervention relative to a full Windows installation that includes applications and other miscellaneous configurations.

A prerequisite to the imaging process is inventorying all software and hardware in your organization. This helps ensure you take into account all possible variations—you must know all the possibilities to create the best possible images.

A question often asked is whether to include applications in the image and which ones. Do you include Microsoft Office? Microsoft Silverlight? Questions like these abound and fuel the continuing debate between using a thick or a thin image. The distinction between thick and thin images is somewhat subjective, so let’s start with some simplistic definitions:

  • Thick image— An image including the OS, OS updates and patches, miscellaneous components, drivers and applications

  • Thin image— An image containing the OS with only a minimal set of updates and patches

Conventional wisdom is that a thin image is the better choice—why is this the case? A thin image is easier to maintain; it contains a minimal set of components and thus a smaller set of components that require updates. Like many theories, this one sounds great, but reality gets in its way; because you want to automate maintenance of images, this should be a minor concern.

Offline Image Maintenance

If you forget to add something in an image or need to add something simple to an image without having to create it again, never fear, ImageX is here.

Using ImageX, you can mount a WIM image file into an empty folder using the command imagex /mountrw <image_path> <image index> <mount path>, where the mount path is an empty folder. This loads an image to that empty folder, where you can access the entire file system contained in the image file as if it were part of the file system of the host operating system.

For example, if you have a WIM file called XPSP3.wim at the root of your C: Drive, you can load that WIM file to an empty folder on your C: drive named mount with the following command:

imagex /mountrw c:\XPSP3.wim 1 c:\mount

This mounts the image in a read-write mode; if you want to mount the image in a read-only mode, use /mount instead of /mountrw. Now you can open either Windows Explorer or a command prompt and manipulate the contents of the WIM file by navigating to C:\Mount. Figure 1 shows a folder listing of a sample captured Vista WIM file mounted in this fashion.

Figure 1. Mounting a captured WIM file

For example, you can add a bitmap file to the Windows folder (accessed at c:\mount\windows) or add a ReadMe.txt file to the All Users desktop (accessed at c:\mount\Documents and Settings\All Users\Desktop). You can make changes to the default user’s Registry hive using reg.exe . The following example shows setting the wallpaper for the default user:

Load the default user’s Registry hive: reg.exe load HKU\Mount c:\mount\Documents and Settings\Default User\ntuser.dat.

Modify the desired setting: reg.exe add HKU\Mount\Control Panel\Desktop /v Wallpaper /t REG_SZ /d %SystemRoot%\CompanyLogo.bmp.

Unload the Registry hive: reg.exe unload HKU\Mount.

If you mount a Windows Vista WIM, you can also use the Windows SIM and Windows Package Manager from the WAIK to manipulate the image further, including performing the following tasks:

  • Adding drivers

  • Adding language packs

  • Adding or removing packages such as security updates or service packs

Microsoft discusses each of these methods in detail at http://technet.microsoft.com/en-us/library/cc732695.aspx.

To save changes that you make to a file system contained in the WIM file using this mounting method, use the following command: imagex /unmount /commit c:\mount. Note the /commit option in the command line; without this option, no changes made to the mounted WIM are saved.

The WAIK must actually be installed on the host system to use ImageX to mount images. You cannot simply copy the ImageX executable to a system and use it to mount an image.

Here are several goals for the deployment images:

  • Hardware agnostic— Few organizations can actually standardize on a single hardware system for all their desktops, so this goal should be obvious. What might not be as readily obvious is that it is achievable! The main obstacles to this goal are drivers and the Hardware Abstraction Layer (HAL) in Windows XP. Windows Vista (and Windows 7) change the way mass-storage drivers are handled and automatically change HALs as needed, so these concerns are no longer valid for the newer operating systems.

  • Universal— Images should be a baseline for all deployments in an organization; they should contain the greatest common denominator of all the desktop needs in an organization. If not everyone requires a specific application, component, driver, and so on, it should not go into the image—you want to layer it on after deploying the image. This simple but important goal greatly affects your success with OSD. Creating an optimal universal baseline relies on your knowledge of the hardware and software in use at your organization and the accuracy of your inventory.

  • Deployment speed— Although not as important as the previous goals, deployment speed is still a valid goal and becomes important if the network is not as fast as it should be or a wide area network (WAN) is involved. Applications and components included in an image only slightly increase the time it takes to deploy a system, because they are already installed and do not have to be pulled across the network separately. Applications and components layered on after the deployment might increase overall deployment time significantly because they are pulled over the network. Typically, installations include some files not even installed on the system, such as setup.exe or alternate language resource files (in the form of Dynamic Link Libraries or DLLs), which are installed only on systems supporting those languages. This can have a greater impact than is first realized.

  • Ease of maintenance— In traditional, image-only deployment systems, ease of maintenance is typically the most important factor. Creating and updating images is often an intensive and lengthy manual process. Images created for these systems are typically thinner, to avoid putting in any components that might need updating. This ultimately increases overall deployment time and can increase the complexity of the deployment. ConfigMgr automates creating images, greatly easing this burden and freeing you from making decisions about your images that are based solely on maintaining the images.

An additional consideration is whether you can install an application generically or have its internal unique identifiers stripped. Sysprep does this for Windows, and OSD properly prepares the ConfigMgr Client if installed, but you must also think about the applications in the image. Some centrally managed antivirus products have trouble when installed in an image; they customize themselves to the specific system they are installed on and do not behave well when copied to another system as part of an image. This is something to verify with the vendors of the products you plan to incorporate into the image and is an area you should test.

Ultimately, thin versus thick is a moot argument. Every deployment image will probably be somewhere in the middle, and what is right for one organization might not be right for another. Having a thin image, just for the sake of having a thin image, should not be a primary goal. Maintaining images, if it is automated and done correctly, is a minor concern.

Hardware Considerations

Sometimes, hardware differences between references systems can cause problems. If you create the image properly, it can truly be hardware-agnostic. This task is sometimes more difficult in Windows XP than Windows Vista because of HAL issues and SATA (Serial Advanced Technology Attachment) drivers, but it is not impossible. To implement OSD successfully, you should derive a full inventory of all hardware used in the targeted environment. From this inventory, it can be determined if any anomalies exist, if all the drivers are still available from the manufacturer, or if all the systems meet the minimum requirements for the operating system you deploy.

When deploying Windows XP and Windows Server 2003, different HAL types are potentially the biggest obstacle to creating a hardware agnostic image. Here are the six HAL types available:

  • ACPI Multiprocessor PC

  • ACPI Uniprocessor PC

  • Advanced Configuration and Power Interface (ACPI) PC

  • MPS Multiprocessor PC

  • MPS Uniprocessor PC

  • Standard PC

The non-ACPI HALs in the preceding list are legacy types and normally needed only for very old hardware. Based on your hardware inventory, you probably can rule out their use completely.

You can identify the exact HAL in a captured image by right-clicking the image in ConfigMgr and choosing Properties. In the resulting dialog box, choose the Images tab at the top; see Figure 2 for an example.
Figure 2. Identifying an image’s HAL type

Eliminating legacy hardware typically leaves the three ACPI HAL types that follow three rules for imaging:

  • Images created with ACPI Uniprocessor PC HAL— You can deploy these images to hardware requiring either ACPI Uniprocessor or ACPI Multiprocessor HALs.

  • Images created with ACPI Multiprocessor PC HAL— You can deploy these images to hardware requiring either ACPI Uniprocessor or ACPI Multiprocessor HALs.

  • Images created using the Advanced Configuration and Power Interface (ACPI) PC HAL type— You cannot use these images on systems requiring either of the other two HAL types. Luckily, hardware requiring this HAL type is outdated and no longer common.

This means you have to create only one image to support all your systems because they all require either ACPI Uniprocessor or ACPI Multiprocessor HALs. If through trial and error or through your hardware inventory you discover that another HAL type is in use, the only currently supported method of deploying images is to create multiple images, each containing a different HAL.

Mass storage drivers present a similar challenge; because they are essential to booting a system, they are referred to as boot critical. Neither Windows XP nor Windows Server 2003 includes a huge variety of the modern boot critical drivers; this includes a lack of SATA drivers, which are becoming more and more popular. You add boot-critical drivers to Windows XP and Windows Server 2003 in a different way than all other hardware drivers; you see this when manually installing a system requiring a boot-critical driver because you need to push F6 to install the driver during the blue screen pre-installation phase. OSD gracefully handles this situation with little overhead or extra work. Some trial and error testing may be involved, though.

Both Windows Vista and Windows Server 2008 include the most popular SATA drivers out of the box. If you do encounter a drive controller requiring a driver not included out of the box, you can load the driver the same way as other hardware drivers—this is due to an architectural change made by Microsoft in the handling of boot critical drivers in Windows Vista and Server 2008.

Although creating multiple images initially sounds like a hassle, it should not be. If you have properly automated your image build process using a Build and Capture task sequence , creating the multiple images is as simple as running that sequence on a system supporting each type of HAL in your inventory. The task sequence is automated, so the images will be identical except for the HAL type that they contain.

In addition, using the magic that is ImageX, these images can be merged into a single file using the /append option: imagex /append <image_path> <image_file> <"image_name"> [<"description">]. Because of the single instancing of WIM images, the resulting WIM file contains only one copy of each file in common between the images (which will be every file except one, the hal.dll). The result is that the WIM file will be only slightly larger than maintaining separate WIM files for each version.

The only real pain point with this solution is finding a reference system for each type of HAL. Because most of these HALs are legacy and only used on aging or outdated hardware, chances are that you do not have any in your lab and must be creative in procuring one from an active user.

Other -----------------
- System Center Configuration Manager 2007 : Operating System Deployment - Tools Overview
- Windows Server 2003 on HP ProLiant Servers : Migration Tools (part 2)
- Windows Server 2003 on HP ProLiant Servers : Migration Tools (part 1)
- SQL SErver 2008 : Resource Governor in action
- SQL SErver 2008 : Resource Governor - Workload groups, Resource pools
- Windows Server 2008 Server Core : emoving Files with the Del and Erase Commands, Compressing Files with the Diantz and MakeCab Utilities
- Windows Server 2008 Server Core : Comparing Two Files with the Comp Utility, Copying Files with the Copy Command
- Microsoft Lync Server 2010 Monitoring : Configuration
- Windows Server 2008 R2 file and print services : Administering File Shares (part 3) - Publishing shared folders to Active Directory
- Windows Server 2008 R2 file and print services : Administering File Shares (part 2) - Securing shared folders
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server