A State Migration Point (SMP), is a site system that SCCM uses for the migration of a user state from one computer to another. For instance, it has the ability to migrate a user profile from XP to Windows 7 and scenarios include migrating from the same source computer to a different operating system, or to a different computer. The user's state which can include Outlook caches, addresses, IE favourites etc are stored on the SMP until the user state is completely restored in the destination computer. SMP can also be configured to store the user state in case of roll backs for a set period of time.
SMP is used in conjunction with the User State Migration Tool (USMT). However, please bear in mind that USMT and SMP are separate components by design. I'll explain briefly. First, a SCCM Task Sequence (TS) action is used to request the user state store (RequestStateStore) and then through the ReleaseStateStore action, interacts with the SMP. The RequestStateStore's role is to search for a suitable SMP and sets the OSDStateStorePath TS variable. Note that USMT is only invoked when the Capture User State or Restore User State actions are called. The UNC path that was specified in the OSDStateStorePath variable is then read or written by USMT. After it has done its Capture or Restore, the ReleaseStateStore action then tells the SMP that the user state has been saved or restored. The two (USMT/SMP) are distinct as the actions that call USMT are not related to SMP.
Now that we have gotten a quick summary of SMP, here is a link to Technet that explains how to setup SMP in your SCCM environment. I will not be covering the installation or configuration in this post. Instead, I would like to focus on various settings within the Task Sequence when you initiate a capture of the user state with SCCM in a protected site setup. I had some failures working with SMP in a protected site setup and would like to share my findings here. Now to begin with, SMP works in a way that is similar to how a Distribution Point (DP) functions. So we have the following points:
Now, sounds all about right isnt? Well no, epic fail! (as seen from the client SMSTS.LOG)
I did a SQL Profiler trace and that had actually returned the correct site system that was setup. SO WHAT WAS WRONG?
We all know how DPs work and therefore I was surprised that the SMP was being treated like a DP in SCCM. Due to the fact that we had to protect all the sites in this configuration, it made using the SMP role a little more complex. Theoretically, we had catered for the protected boundaries by introducing an unprotected site system with a SMP role that would store all the user states. However, a little more had to be done in order for it to work! That's the screen below of the Distribution Point settings for the TS advertisement. Notice the highlighted part. Now, as you can see from the log above, the clients on the secondary boundaries had failed to get a response from the site server hosting the SMP role. Note that all secondary boundaries have been defined in the primary site as well. I would have thought that requests from the clients in the secondary site boundaries would be accepted by the primary in this case, regardless of having checked "When no local distribution point is available, use a remote distribution point". I reckon its by design then since it reiterates the findings of the troubleshooting done prior in the logs and the SQL Profiler - that SMP is detected, but the client cannot access it somehow.
So, please ensure that your DP settings look exactly like this if you have all your sites protected and have introduced an unprotected site system to house SMP. Hope this helps! Please feel free to share with me your thoughts!
Powered by Zimbra