Windows 7 / Getting Started

---

User State

User data is the reason that we all exist, and we want to handle it with special care. Adding users' settings to their data gives us the users' state. A major goal in any system migration is to prevent users from losing any productive time because they do not have or cannot find their data. Although it is definitely a best practice to have users store their data in a central location, such as a server-based file share or a SharePoint site, this might not be possible for a variety of reasons because your organization might not enforce a centralized storage model. In addition, central data storage schemes tend to overlook things such as wallpaper, Outlook settings and configuration, and desktop shortcuts, letting these remain local to each system. When performing an OS deployment, you want to capture and restore the users' state to their new systems as seamlessly as possible.

OSD in ConfigMgr automatically uses USMT to identify, store, and restore user data according a set of XML configuration files built into USMT. The data can be stored locally, useful (but not required) for a refresh scenario in which the hardware is not replaced or stored on a state migration point for the replace scenario where new hardware is introduced.

The main benefits of local storage are that it minimizes network traffic and eliminates the need for server-based storage. This allows potentially quicker migrations and indefinite storage of the data archive.

CAUTION:
Although more efficient and quicker, storing user state locally during a deployment has associated risks: specifically, the dependence on the local hard disk maintaining its integrity and not corrupting the data. This is typically an acceptable risk because that's where the data was initially but is still a risk to be accounted for.

In the case of a replace scenario, you must use the state migration point. (This is not entirely true; see the "User State Without SMP" section for further details.) This is essentially a secure file share for storing the USMT-produced archive. ConfigMgr encrypts and tags archives placed here for a specific destination system, using a computer association. If you did not create a computer association before running a Capture User State task in a task sequence, OSD creates it, specifying the same destination and source systems. ConfigMgr automatically purges the archives placed on a state migration point after the state is restored, based on the settings of the SMP.

The best part about state migration in ConfigMgr is it is simple and straightforward to set up. The only overhead truly incurred by state migration is storage space, and this is automatically maintained and cleaned. By default, the built-in wizard to create Image Deployment task sequences adds the steps to provision space on the state migration point, capturing user state data and transferring it to the SMP. It also adds the necessary tasks to retrieve the state from the SMP and apply it to the destination system.

This default behavior is perfect for a refresh scenario and works for a replace scenario with several small additions:

• Create a computer association to specify the source and destination systems by navigating to Assets and Compliance -> User State Migration and choosing Create Computer Association from the ribbon bar or right-click context-menu. If no association exists when storage is provisioned from the state migration point, a computer association is created with the same source and destination as the system being imaged-this is the desired configuration for refreshes. Alternatively, for a replace scenario, you must manually create a computer association before capturing the user state data; this computer association configures a pre-existing source system and a new or different destination system.
• You should also create a new task sequence to capture the user state data. You can create this abbreviated task sequence using the New Task Sequence Wizard, choosing to create either a custom task sequence or install an existing image package task sequence, and deleting everything except the three relevant capture state tasks.

Here are the four tasks associated with user state:

• Request State Store
• Release State Store
• Capture User State
• Restore User State

The Request State Store and Release State Store are always used, regardless of whether you capture or restore the user state. These tasks deal with the storage space on the state migration point where the user state data is stored.

The Release State Store task has no options, and the main option for the Request State Store task is determining whether user state is retrieved or stored. This task also either creates or retrieves the encryption key that protects the user state data; the encryption key is stored along with and is specific to a single computer association. As stated earlier in this section, this computer association is created automatically with the same source and destination system if the association does not already exist during a user state capture. If you perform a user state restoration and no computer association exists, the user state tasks are gracefully skipped.

The Capture User State and Restore User State tasks do exactly as their names imply. The two main configuration options for both of these tasks are a required package containing the USMT files and an optional package containing the custom USMT configuration files. Neither package requires any program files because they both just make the necessary files available for ConfigMgr to use. The "Creating the USMT Package(s)" section describes creating the USMT tools package.