One of the
nightmares projects I’ve been working on recently (with my guru co-worker ZenShaze) deals with integrating SCCM and a product that reverts workstations to a previous state. Like a forced “snapshot” that will remove malware and unwanted programs with a single reboot. The software essentially “anchors” specific files and directories and allows any changes made to those anchored targets to be saved after a reboot – everything else gets locked down and reverted to an earlier state.
Not a big issue when it comes to ConfigMgr running normally – until you run a Task Sequence that calls for a reboot. When this happens, SCCM makes several changes to the OS that will stage and persist the Task Sequence environment after you bounce the machine and if those changes aren’t anchored in the snapshot software, then you get a busted Task Sequence that simply disappears after reboot. After anchoring some of the more obvious locations, we were still not able to get the TS to persist, so I downloaded a program called Zsoft Uninstaller that’s able to track changes to your machine from an earlier state and used that to dig deeper into what was going on.
Using Zsoft, I got a picture of what my machine looked like before a TS with reboot hit my machine. Then I ran an advertised TS that only had the Restart Computer step (configured to go back into the full OS) and set the countdown timer to an hour or so. After the TS ran and the countdown timer began, I ran Zsoft again to compare what changes had taken place since my earlier state. The results were several pages long! It turns out that not all of the locations were necessary to anchor in order to get the TS to persist correctly, but here are the specific files, folders and registry locations. Note that the locations will differ depending on your architecture and environment – and all locations are recursive.
C:\_SMSTaskSequence – This cache folder contains much of what is needed by the Task Sequence you’re running…
C:\Windows\system32\wbem – For WMI…
C:\Windows\system32\CCM – For the ConfigMgr client…
C:\_SMSTSVolumeID.7159644d-f741-45d5-ab29-0ad8aa4771ca – For mapping disk volumes to be used, I believe – despite the appearance, the file name is the same for all machines…
C:\Windows\Temp – For the OS…
C:\boot\boot.sdi – For RAMDISK booting…
And I think that just about does it. The following locations were changed with the TS, but we didn’t find that they needed to be anchored. Your mileage may vary.
Also note that if you’re using USMT, you’ll need to anchor the State Store path, as well.