Planning Site System Roles for Operating System Deployments in Configuration Manager
Updated: May 14, 2015
Applies To: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1
The same planning steps that you consider when you set up other System Center 2012 Configuration Manager site system roles also apply when you configure roles for operating system deployments.
For example, if you plan to have more than one site system role on a server, consider the combined effect of all the site system roles on network performance, memory, disk storage, processor usage, and other server resources. Operating system deployments primarily affect these resources for distribution points and state migration points.
Use the following sections to help plan for distribution points and state migration points.
Distribution Points
Make sure that you have enough distribution points to support the deployment of operating systems to computers and verify the placement of these distribution points in the hierarchy. This kind of planning is basically the same as you would use for the deployment of other Configuration Manager packages. However, there are some considerations that are specific to operating system deployment.
One consideration is the number of computers that can be deployed at one time from a single distribution point. You must consider the processing speed and disk I/O of the distribution point, the available bandwidth on the network, and the effect that the size of the image package has on these resources.
For example, on a 100 megabyte (MB) Ethernet network, the maximum number of computers that can process a 4 gigabyte (GB) image package in one hour is 11 computers if you do not consider any other server resource factors.
8 Megabits transfers 1 Megabyte of data
100 Megabits/sec = 12.5 Megabytes/sec = 750 Megabytes/min = 45 Gigabytes/hour = 11 images @ 4GB per image
In reality, the number might be far less. So if you must deploy to a specific number of computers within a specific time frame, distribute the image package to an appropriate number of distribution points. For planning information about distribution points, see Planning for Content Management in Configuration Manager.
Important
Another consideration is that when you deploy operating system deployment task sequences to a collection of computers, Configuration Manager does not distinguish Configuration Manager site servers from other destination computers in the collection. If you deploy the task sequence to a collection that contains a site server, the site server runs the task sequence in the same way that any other computer in the collection runs the task sequence. Ensure that you remove the site system role from the site server before you deploy an operating system image to it, and then assign the site system role back to the site server after the operating system is deployed. In addition, if you distribute an image to a distribution point, the server has to receive its image package from a remote distribution point. You cannot distribute an image to a distribution point on the server and then deploy the task sequence that installs the operating system to the server.
PXE-Enabled Distribution Points
To deploy an operating system by using PXE, you must designate a distribution point that can respond to the PXE boot requests. The distribution point can then respond to the PXE boot request and determine the appropriate deployment actions to take. For more information about how to deploy operating systems by using PXE, see Planning for PXE-Initiated Operating System Deployments in Configuration Manager.
Multicast-Enabled Distribution Points
To deploy an operating system to multiple computers simultaneously, you must configure a distribution point that supports multicast. For more information about how to use multicast to deploy operating systems, see Planning a Multicast Strategy in Configuration Manager.
State Migration Point
The state migration point stores user state data that is captured on one computer and then restored on another computer. You must store the user state data on the state migration point when you use a side-by-side deployment. However, when you use the same computer, such as a deployment where you refresh the operating system on the destination computer, you can store the data on the same computer or on the state migration point. For some computer deployments, when you create the state store, Configuration Manager automatically creates an association between the state store and the destination computer.
As you plan for the state migration point, consider the following factors.
User State Size
The size of the user state directly affects disk storage on the state migration point and network performance during the migration. Consider the size of the user state and the number of computers to migrate. Consider also what settings to migrate from the computer. For example, if My Documents is already backed up to a server, then perhaps you do not have to migrate it as part of the image deployment. Avoiding unnecessary migrations can keep the overall size of the user state smaller and decrease the effect it would otherwise have on network performance and disk storage on the state migration point.
User State Migration Tool
To capture and restore the user state during the deployment of the operating systems, you must use a User State Migration Tool (USMT) package that points to the USMT source files. You must create this package in the Software Library/Application Management/Packages folder. Configuration Manager uses USMT 4.0, which is distributed in Windows Automated Installation Kit (Windows AIK), to capture the user state from one operating system and then restores it to another operating system.
For a description of different migration scenarios for USMT 4.0, see Common Migration Scenarios.
Retention Policy
When you configure the state migration point, you can specify the length of time to keep the user state data that is stored on it. The length of time to keep the data on the state migration point depends on two considerations:
The effect that the stored data has on disk storage.
The potential requirement to keep the data for a time in case you must migrate the data again.
State migration occurs in two phases: Capturing the data and restoring the data.
When you capture the data, the user state data is collected and saved to the state migration point. When you restore the data, the user state data is retrieved from the state migration point, written to the destination computer, and then the Release State Store task sequence step releases the stored data. When the data is released, the retention timer starts. If you select the option to delete migrated data immediately, the user state data is deleted as soon as it is released. If you select the option to keep the data for a certain period of time, the data is deleted when that period of time elapses after the state data is released. The longer you set the retention period, the more disk space you are likely to require.
Selecting Drives
When you configure the state migration point, you must specify the drive on the server to store the user state migration data. You select a drive from a fixed list of drives. However, some of these drives might represent non-writable drives, such as the CD drive, or a non-network share drive. In addition, some drive letters might not be mapped to any drives on the computer. You must specify a writable, shared drive when you configure the state migration point.