Site System Roles
There are two main supporting roles for OSD: distribution points (DP) and state migration points (SMP). These are discussed in the next sections.
Distribution Points
DPs are responsible for making all content used in ConfigMgr available to the clients. This also includes everything OSD needs to deploy Windows to a client system including
- Driver Packages
- Boot Images
- Operating System Installers
- Operating System Images
- Applications
- Software Distribution Packages
- Software Update Deployment Packages
With System Center 2012 Configuration Manager, the DP also handles all PXE and TFTP responsibilities for bare-metal booting of a target client system and delivery of the WinPE boot image. You probably already have a DP installed in your environment because ConfigMgr is limited without one.
PXE
For core OSD functionality, there is nothing additional to install or set up in ConfigMgr. To enable PXE boot capabilities for new computer scenarios in which existing data on the system is not a concern, follow this simple list of steps (because site configuration is global in nature, this can be done on any primary site in the hierarchy):
- Navigate to Administration → Overview → Distribution Points.
- Select the DP you want to enable PXE on from the list shown in right pane, and
choose Properties from the ribbon bar or the right-click context menu.
NOTE: YOU CAN ENABLE ONLY SERVER-HOSTED DISTRIBUTION POINTS FOR PXE
You can only enable DPs hosted on Windows Server operating systems for PXE because this capability is actually provided by WDS, which is a server-only component. If you require or desire PXE-initiated OSD functionality at locations where you do not or cannot have a server OS, you should consider a third-party product offering client OS-hosted, peer to peer PXE capabilities such as Adaptiva's OneSite. - Select the PXE tab on the DP's Properties dialog box.
- Check Enable PXE support for clients and acknowledge the resulting dialog box detailing the port requirements for PXE. Note the text under this check box: Windows Deployment Services will be installed if required. This is actually only true for Windows Server 2008 and 2008 R2; WDS is not automatically installed for Windows Server 2003 systems. For Windows Server 2003 systems, see http://technet.microsoft.com/en-us/library/cc766320(v=WS.10).aspx#BKMK_InstallingWDS for installation instructions. For Windows Server 2008 or 2008 R2, manually installing WDS is not necessary but possible using the Add Roles capabilitie. (http://technet.microsoft.com/en-us/library/cc771670(v=WS.10).aspx#BKMK_InstallingWDS contains explicit details of doing so). No configuration of WDS in the OS is needed or recommended as this is handled by ConfigMgr. Note that WDS is not supported on server core editions of Windows Server 2008 and 2008 R2.
- The following options are also available after PXE is enabled:'
- Allow this distribution point to respond to incoming PXE requests: This must be checked to actually activate the system's PXE capabilities.
- Enable unknown computer support: As described in the "Unknown Computers" section, this enables the DP to provide PXE boot capabilities to clients not known or prestaged in ConfigMgr. If you select this check box, Microsoft warns you about the potential for accidentally deploying Windows to systems where it should not be deployed. Heed this warning and plan your use of unknown computer support carefully. One way to mitigate this risk is to enable a password, as described in the next bullet.
- Require a password when computers use PXE: This self-describing option provides a level of security to prevent unauthorized or accidental imaging or reimaging of systems on the network. This is a shared password, so is not a perfect security mechanism, but it adds a level of user interactivity that can prevent deploying the corporate image to unauthorized users or the random user that accidentally PXE boots their system.
- User device affinity: This option disables the use of user device affinity, allows it with manual approval, or allows it with automatic approval for task sequences initiated using PXE from this DP. See the "User Device Affinity" section for further coverage of user device affinity.
- Network interfaces: If your DP happens to be multihomed, you can choose to allow PXE services on all or specify network interfaces in this section of the dialog.
- Specify the PXE server response delay (seconds): If you have multiple
PXE servers responding to PXE requests in a subnet or through the use of IP
helpers, you can set a precedence order using this delay; delaying the DP from
responding to PXE requests allows other potential PXE servers to handle PXE
requests first. If they choose not to reply to the system attempting to PXE
boot, the DP responds to the system after the configured delay.
This is by no means a perfect prioritization system as the PXE booted system must be completely ignored by the first PXE responders for it to attempt to boot to later responders. For a ConfigMgr DP, if unknown computer support is enabled, it will never ignore a PXE request. Since the behavior of other PXE services in your environment may vary, testing is in order if you plan to coordinate the efforts of multiple PXE-enabled DPs or other PXE services.
A question often fielded by ConfigMgr OSD implementers is how an organization can have multiple PXE providers on the same network subnet. Usually, the client organization already has a PXE server in place to support a legacy imaging product. The real answer to this question is that it depends on the network infrastructure, not on ConfigMgr.
PXE is a standards-based protocol based on DHCP and network broadcasts. The network card installed on a system controls the actual booting of a system; this is completely independent of ConfigMgr. Generally, the first PXE provider to respond to a PXE request is chosen by the network card that is booted. On a network level, it is best to segregate PXE providers on separate subnets to control the broadcasts.
You can also specify a specific PXE server using DHCP options 60, 66, and 67; however, these options are specific to a single network subnet and cannot be made more granular for PXE booting purposes. There are other options including a newer PXE specification, but this problem is completely outside the bounds of ConfigMgr and WDS.
Two excellent resources for detailed PXE information are at http://technet.microsoft.com/en-us/library/cc732351.aspx and http://support.microsoft.com/kb/244036 . The second reference is a dated KB article referring to RIS, but the general PXE information is still valid.
In this tutorial:
- Operating System Deployment
- What is OSD
- What is New in OSD
- Deployment Scenarios
- Tools Incorporated into OSD
- Windows Automated Installation Kit
- User State Migration Tool and USMT Customization
- OSD Phases
- OSD Building Blocks
- Driver Packages
- Operating System Installers
- Drivers in Boot Images
- Task Sequences
- Task Sequence Properties
- Task Placement
- Task Conditions and Grouping
- Targeting and Execution
- Execution Context
- Customizing Task Sequences
- Site System Roles
- Multicast
- State Migration Point
- Driver Management
- Drivers in the Image
- User State
- USMT
- Computer Associations
- User State Without SMP
- Image Operations
- Manual Image Creation
- Image Upkeep
- Image Deployment
- User Device Affinity
- Deployment Challenges
- Hardware Considerations
- Monitoring Task Sequence Deployments
- Troubleshooting Operating System Deployment
- The Smsts.log File