Unable to free up space after a MDT Refresh
As mentioned, I recently had the pleasure to meet Jeremy Chapman and we had a chat about some Deployment related topics. We also covered some problems we experienced so far and one thing I had forgotten already (Yes, I should have blogged about it already so it’s not gone) was about a specific situation you can run into if you are using MDT and the new hard-linking capabilities of USMT 4 during ConfigMgr OS Deployments. It’s basically about deleting certain files but not freeing up the space used by those files.
USMT hard links
The great thing about using hard links is, that it is incredibly fast. The backup and restore steps in a refresh scenario go down to a few minutes even for profiles with GByte worth of data. The USMT rules define which files need to be backed up. In former versions of USMT these files would have been copied to a specific directory on the local hard drive. With hard links enabled (what is the default on MDT 2010 refreshing towards Windows 7) USMT 4 will now create a hard link (think of it as an additional reference) to this already existing file. So the file itself stays the same. It’s just being referenced now from several locations in the directory structure. If the “original“ file is now deleted by the Task Sequence, while it prepares the hard drive for the new OS, just one reference to this file is deleted. And as long as there are still other references to this file, it will not really get deleted.
Bear with me for a moment. It’s important to understand this behavior as this is causing an interesting issue after the refresh has finished.
Capture and Restore User State
So the “Capture User State” step is creating a bunch of new hard links/references to existing files under a protected folder (Typically %SystemDrive%_SMSTaskSequenceStateStore). A bit later, all files and folders from the hard drive except this protected folder will be deleted. Then later in the process the “Restore User State” step will copy all the files back to it’s original location. But it’s doing this the same way it has backed them up. It’s creating a new hard link/reference to the file at the original location. This mainly to be able to recover them even if an error occurs during this process.
Then one of the last default steps in the Task Sequence (actually no matter if the Task Sequence succeeded or failed) is to move this StateStore folder to a different location within the new Operating System (Move State Store step calling ZTIMoveStateStore.wsf) so it doesn’t get deleted together with the _SMSTaskSequence folder at the end of the process. Typically it will end up at %WinDir%TempStateStore. As mentioned already, this step only exists in the ConfigMgr MDT templates. It won’t get called on plain MDT LTI deployments.
Now let’s imagine you have refreshed your computer to Windows 7. Some time after the refresh you are deleting a lot of the stuff that has been backed up during the Refresh. But no matter how much you delete, the free space on your hard drive does not increase. You try to search for the files you have just deleted and as expected, can’t find them anymore. So …
… what happened?
Well, these files are still there! They hide within the %WinDir%TempStateStore Folder! As you remember, there is an additional hard link that had been used to backup and recover the files and then was moved to this location. And as we know now, as long as there is at least one hard link to a file, this file will not be deleted. What is an expected behavior on the backup process is now causing some confusion if you aren’t aware of this. And the default search does not include this folder, so you won’t even find them.
To get really rid of the files you want to delete you would also have to delete them from this location.
My preferred way to solve this problem is to add a step to the Win7 Task Sequence, that adds a scheduled task to delete the whole StateStore Folder after a certain period of time (eg. 2 or 4 weeks). This way you can still recover the files backed up, even if the recover process failed at some point and are still able to delete the files after the specified period of time.
Another option would be to schedule the built-in Disk Cleanup Utility (btw, did you know that you can easily add a couple additional items to the cleanup utility? See http://www.zhacks.com/2010/04/09/windows-7-extended-disk-cleanup-with-10-extra-items/ for details) or other tools like ccleaner or similar.