What is New in OSD

Although on the surface OSD doesn't appear to be that different from its ConfigMgr 2007 predecessor, there are several improvements or additions to functionality. Here is a list summarizing these changes; complete discussions of each are incorporated into the appropriate or relevant sections of the tutorial.

• Offline Servicing: This new capability lets you schedule ConfigMgr to apply updates to an OS image imported into ConfigMgr without actually deploying the image. This potentially removes the need to deploy updates during an image capture or deployment, greatly reducing the time and effort spent on them and ensuring that operating systems deployed by ConfigMgr are fully updated before brought online. This task is discussed in the "Image Maintenance" section.
• Media Updates: A small number of updates are incorporated into the media-based boot image capabilities of ConfigMgr. These allow for greater automation by exposing previously hidden features in the boot media creation user interface, including
  • Specifying a prestart command (formerly known as a pre-execution hook). Prestart commands run first when a system is booted and allow you to provide custom actions such as displaying a user interface, querying ConfigMgr, or overriding predefined deployment behavior.
  • Suppressing all start-up dialog boxes during deployment for a true unattended experience.
  These improvements are discussed in the "Boot Images" section.
  Hierarchy-wide media is an additional improvement. Previously, boot media created by ConfigMgr hard-coded the management point (MP) that it would contact for policies. This caused issues when the hierarchy contained multiple sites because the boot media would always "phone home" instead of contacting the nearest MP. The home MP might be located across a wide area network (WAN) link or not have the correct policies for the client being deployed.
  Hierarchy-wide media dynamically finds the correct MP based upon site boundaries. You can override this by setting a variable in a prestart command. Using site-specific media is still an option, however.
• USMT 4.0 Integration: Although Service Pack (SP) 2 brought User State Migration Tool (USMT) 4.0 support to ConfigMgr 2007, its new features were never integrated into the interface. These are now fully exposed in the user interface. USMT 4.0 is discussed in the "State Migration" section.
• Application Integration: The awesome new application model is integrated into OSD. However, with the new application model and focus on user-centric deployment comes a shift in the philosophy of when to install applications: during OS deployment or after? The "User Device Affinity" section discusses this dilemma and its ramifications.
• PXE Service Point Updates: The PXE (Preboot eXecution Environment) service point is no longer a separate role in ConfigMgr; its complete functionality is now rolled into the distribution point (DP). A dedicated DP share is no longer required, which should eliminate the confusion its presence caused in ConfigMgr 2007. Windows Deployment Services (WDS) is still required for PXE functionality.
• Deployment Alignments: This is less of a new feature as it is a unification of terminology and user interface elements, resulting in a common administrative experience for software distribution, software updates, and OSD. Monitoring of each of the features is now combined in the Deployments node of the console under the Monitoring workspace. In addition, OS deployments are made available to users using the new Software Center, similar to both software distribution and software updates.
• Centralized Management: This is also not actually a feature but instead the result of changes in the ConfigMgr hierarchy implementation. Essentially, all OSD objects are global data and editable from the central administration site (CAS) or any primary site. This includes task sequences, which can now be deployed from the CAS or primary site. Computer associations can also be created and maintained at either the CAS or primary site, although both the specified source and destination systems must exist in the same primary site.

The first part of this tutorial covers base OSD functionality and sets the stage for the remainder of the tutorial. Using OSD also means implementing one site role-a distribution point-and can include the use of one other site role. Their installation and use is later covered in the "Site System Roles" section; this was not included at the beginning because their use is in OSD is mainly as supporting roles. Understanding the concepts of and base functionality of OSD is required before you can assess and implement these roles.