Windows 7 / Getting Started

---

Operating System Installers

Use this node to manage the actual Windows source files as copied from official Microsoft media (virtual or physical). The entire contents of the media are used to install the OS from scratch. Operating system installers are typically used only during automated image creation (described in the "Automatic Image Creation" section) but can also be used during mass deployments of an OS. They are not typically used for this purpose, as installing an OS from source files takes longer than deploying an image. In addition, raw source files straight from the media do not contain the latest security updates and are not customized for your organization. For a complete discussion of why you should use captured images, see the "Image Operations" section.

To import a new operating system installer, follow these steps:

1. Copy the entire contents of the Windows installation media to its own folder. This is typically within your software or source repository and must be accessible to the site's AD account and a UNC path. Creating a parent folder for all your OS source folders is highly recommended for organizational purposes, with each separate OS edition and version in its own distinct subfolder.
2. Navigate to Software Library → Overview → Operating System Installers . All currently imported OS source files display on the right.
3. Choose Add Operating System Installer from the ribbon, or right-click the context menu to launch the Add Operating System Installer Wizard. Only two significant pages are in this wizard.
   • Data Source: Enter the path to the source files folder created in step 1.
   • General: On this page, enter metadata describing the OS being added including the Name, Version, and Comment. The name entered here displays in the console and so should be explicitly descriptive of the OS added; for example, Windows 7 Enterprise Service Pack 1 (x64).

Boot Images

From the perspective of a client system involved in OSD, WinPE is the core foundation of the entire process. It is required because the main operations of the deployment cannot actually occur from within a full install of Windows. Specifically, formatting the disk and applying an image file cannot happen while the target disk drive is in use and must be initiated from something that does not live on or run from that target disk.

WinPE is ideally suited for this task because it is small, easy to deliver, fast, and runs from a RAM disk without the need for persistent storage. WinPE also shares the core kernel and driver model with Windows itself, can run any valid native Windows executable, and provides much of the same automation enabling functionality including batch scripting and VBScript.

WinPE is contained in the boot images and delivered to a client system in one of three ways:

• PXE during a network boot
• Removable media such as a CD or DVD-ROM
• Download from a DP

The approach you choose does not matter to the OSD process, as long as WinPE is delivered to the target system. The next sections discuss these delivery methods.

PXE Booting

PXE booting is typically used for bare-metal or new hardware installations when the system does not have a ConfigMgr client agent installed or the currently installed OS cannot be started. PXE is a well-defined, industry standard used by ConfigMgr. ConfigMgr has almost no part in PXE booting a system; the majority of the work is performed by the target system's NIC and the network infrastructure.

NOTE: PXE BOOT DELIVERS ONLY BOOT IMAGES
The PXE boot process delivers only the initial boot image in ConfigMgr. All other content including the OS image, drivers, updates, applications, and such is delivered from a DP. With the unification of the PXE role with the DP in ConfigMgr 2012, this distinction may be less important than it was in ConfigMgr 2007, but it is still an important and useful fact for troubleshooting the OSD process.

Here are the criteria required for using PXE boot:

• A DHCP server must be available for use.
• The network must allow the PXE broadcast packets to reach the PXE server. PXE and DHCP use BOOTP (Bootstrap Protocol), which is a broadcast-based protocol. Layer 3 network devices do not pass broadcast traffic by default; the PXE server must be on the same network segment as the client attempting to PXE boot, or you must configure your Layer 3 network devices to forward the broadcasts to the PXE server using IP helpers.
  Most organizations already have BOOTP broadcasts forwarded on their Layer 3 devices to support DHCP; configuring them to forward BOOTP broadcasts to support PXE is a nearly identical process with the only difference being a different destination server.
  Alternatively, you can configure DHCP options 66 and 67 in your DHCP scopes. These options instruct the NIC to look to a specific PXE server instead of using broadcasts to find one.
  IP helpers are generally the preferred method because they do not rely on any intelligence or assumption of capabilities of the NIC in the target system.
• You must enable the boot images for PXE. This is a commonly forgotten step:
  • Choose the boot image you want to make available using PXE, and choose Properties from the ribbon bar or right-click context menu.
  • On the boot image's Properties dialog, select the Data Source tab.
  • Select the Deploy this boot image from the PXE service point check box at the bottom of the page.

The boot image is now available to PXE boot systems on any PXE-enabled DP to which you assign the boot image.

NOTE: X86 OR X64 BOOT IMAGES FOR PXE
There are two basic types of boot images available: one for each major Windows architecture type. You should make both available on your PXE-enabled DPs. WDS requires a basic set of files for servicing PXE requests. This basic set of files is machine architecture- specific and independent of the OS architecture you are deploying. WDS extracts these files from the boot images you make available. To service both types of systems, both boot image architectures must be available to WDS to extract and use both sets of architecture-specific files. This has nothing to do with the OS architecture you are deploying; even if you are not deploying x64 editions of Windows and never actually use the x64 boot images, if the systems you are PXE booting have x64 hardware (which almost all do now), they require the x64 PXE files delivered from the PXE server.

Removable Media

You typically use removable media for bare-metal installation of new hardware where PXE booting is not feasible. This includes the following situations:

• The target system is across a WAN link. Although it is possible to PXE boot over a WAN link, performance can vary and may be unacceptable.
• The network infrastructure does not forward the PXE broadcasts, and DHCP options 66 and 67 cannot be configured.
• Another PXE server is already configured in the environment and cannot be supplanted or disturbed.
• Unavailable because the target system does not support it. (It has been a long time since network cards did not support network boot using PXE, but it is possible.)
• When you want to be absolutely certain that a system does not connect to the network prior to being fully loaded and fully patched to a designated baseline.
• The target system is in a protected subnet such as a DMZ (demilitarized zone, also referred to as a perimeter network ) and cannot communicate back to the site system.

The main limitation of removable media is version control. Making changes to boot images hosted on a PXE server is trivial; making changes to boot images on multiple pieces of media no longer in your control or possession and in production use is often a logistical challenge.

You can create images for removable media by right-clicking any task sequence or the actual Task Sequences node in the navigation tree and choosing Create Task Sequence Media from the ribbon bar or right-click context menu. This launches the Task Sequence Media Wizard, allowing you to choose which type of media to create. You can burn the resulting image to a CD or DVD or place it on a bootable USB device. You can create three types of task sequence media:

• Stand-alone media : Creates a self-contained disk image that contains WinPE and all the packages and information specific to a task sequence-except for software updates.
  Using stand-alone media allows you to run a task sequence on a target system without connectivity to a ConfigMgr site system.
  When you create stand-alone media, the system prompts for a distribution point from which to copy packages. You can set task sequence variables specific to this media image, allowing you to customize the task sequence while knowing that it will not connect to the site server during installation.
  The system also prompts you to choose a media size during the creation of the image: 650MB (CD), 4.6GB (DVD), or 8.5GB (DL-DVD). Depending on the size of packages included in the task sequence, there may be multiple disk images created; choosing the CD image size of 650MB guarantees multiple images. When you boot a system to stand-alone media, it acts as if the task sequence used to create the media were advertised to the system with a required deployment.
• Bootable media : Creates a burnable image of the chosen boot image. You can also initiate the task sequence in a bootable media image from within Windows using the autorun feature of the image.
  A new option for ConfigMgr 2012 is to create bootable media that is not specific to a single site; this is called dynamic media and allows you to use the media at any site in the hierarchy. Dynamic media first contacts the MP specified during the creation of the media and then is redirected to a closer MP based on the boundaries of all sites in the hierarchy. Dynamic media is the default option.
  Site-based media is the same as the bootable media created in ConfigMgr 2007 and can communicate only with the MP at the single site specified during the creation of the media. If your hierarchy contains only a single site, there is no functional difference between these two options.
  You can also add prestart commands (as described in the "Boot Image Customization" section) and custom task sequence variables (as described in the "Variables" section) that are specific only to the boot media when creating bootable media.
  NOTE: VERSION MISMATCH
  If the bootable media used to boot a system does not contain the latest version of the boot image available, OSD downloads the latest version of the boot image from a DP and restarts the system into this latest version of the boot image, similar to the process described in the "Using a Distribution Point" section. This ensures the most current version of the boot image is always used.
• Capture media: Creates a CD that allows you to capture a reference system outside of a task sequence; the image is not bootable, and you must initiate it from within an installed OS using the Autoplay function or by manually running TSMBAutorun from the SMS\bin\i386 folder.
  Capture media can be useful in a variety of circumstances, such as if you already have a perfect reference system or a perfect process for creating the reference system. Another use of the capture media would be importing an image from a competitive imaging system: you would first deploy the image to a suitable reference system and then recapture it into a WIM format using the image capture media. Using capture media is covered in the "Manual Image Creation" section.
• Prestaged media: Creates a WIM file used by a custom task sequence to prestage the OS image on a computer, which saves time and network bandwidth when deploying new computers. The network bandwidth in question here is directly related to the WIM file itself, which can be several GB in size. By not downloading a large WIM file, you conserve network bandwidth and save deployment time.
  When shipping computers from an original equipment manufacturer (OEM) to your organization, the computers arrive at your business with the OS image prestaged. You can then PXE boot them, and using another task sequence to deploy the OS, you modify the Format and Partition Disk step to check for the presence of a variable, called OEMmedia. If True, it skips this step (which is what you want because the WIM file is located on the hard disk already).
  When you create prestaged media, the WIM image is first staged to the logged on user's temp folder, so be sure there is enough free space before starting this task. Otherwise, it will fail with an out of disk space message even though it is pointed to a drive or UNC with several GB of free space more than required.

The final method to deliver WinPE is through ConfigMgr itself! If a system already has a ConfigMgr client agent installed and an OSD task sequence is deployed to the client and initiated, ConfigMgr downloads the boot image containing WinPE to a special pseudopartition on the hard drive. This pseudo-partition is then set as the active partition. An automatic reboot is initiated, and the system is booted into the WinPE image contained in the active pseudo-partition. This method allows for tasks before the reboot into WinPE, including capturing user state or other data collection activities that can be used or restored during the deployment.

The "Task Sequence Targeting" section discusses deployments further.