Michael Niehaus' Windows and Office deployment ramblings
When using MDT task sequence templates for ConfigMgr, we expect to keep user state locally if you are refreshing existing machines. But if you are replacing a computer, the user state needs to be stored on a ConfigMgr state migration point. In that setup, you would run two different task sequences:
There were a variety of issues in the task sequence templates that resulted in this not working right in some scenarios, so you’ll see some extensive changes in he SCCM_ClientReplace.xml template, rearranging steps, adding steps, adjusting conditions, etc. (The rearranging is necessary because you can’t release a state store from within Windows PE – that needs to be done in the full OS.) There were a few related adjustments in SCCM_Client.xml too, primarily adjusting the conditions used on various steps to make sure that the user state and computer backup always end up at the same location: If user state goes the SMP, both will go to the SMP; if user state is kept locally, the backup will be kept locally too. (Most of those conditions were already present, but the case-sensitive checks were causing them to not be evaluated correctly.)
At the same time, we fixed an issue where a failure in the “Restore User State” step might not be noticed because the step was configured to continue on error. That makes sense in cases where there was no user state captured, but if there is a valid user state store present, we should use it. So additional conditions were added to the step to cause it to be run any time user state exists and skipped otherwise, and if it fails, the task sequence will fail.
A quick reminder too: If you don’t want computer backups to be performed (often the case because they take so long), you need to edit the CustomSettings.ini file in the settings package being used so that it specifies “ComputerBackupLocation=NONE”.
would you be willing to show what your customsettings.ini file would look like?
sieht wer flügel ? butterfly effect