Question about Scanstate & Loadstate for large amount of files/directories
We are working on migrating from Windows XP to Windows 7 - using the USMT from Microsoft as one of the components. So far, everything is working well with regards to what we are copying, expect and are looking for.
However, we have run into something that's causing some pain points - and was wondering if others have run into this and what is possible to correct.
Here is the batch file that we use for Scanstate, with some data generalized:
IF NOT EXIST \\SERVER\WIN_7_MIGRATE\Workstation_Data\%computername% MD \\SERVER\WIN_7_MIGRATE\Workstation_Data\%computername%
\\SERVER\WIN_7_MIGRATE\USMT\x86\scanstate.exe /o \\SERVER\WIN_7_MIGRATE\Workstation_Data\%computername% /vsc /i:\\SERVER\WIN_7_MIGRATE\USMT\x86\MigUser.xml /i:\\SERVER\WIN_7_MIGRATE\USMT\x86\MigApp.xml /i:\\SERVER\WIN_7_MIGRATE\USMT\x86\MigUserCustom.xml /l:\\SERVER\WIN_7_MIGRATE\Workstation_Data\%computername%\scanstate.log /listfiles:\\SERVER\WIN_7_MIGRATE\Workstation_Data\%computername%\scanstatefiles.log /c /localonly /v:15 /uel:30
The problem we are experiencing, is when users have a TON of individual files/folders inside a directory we are migrating, e.g. My Documents.
We had one machine take 16 hours, as an example, which created log files that were just shy of 300mb - and a .MIG file of about 42GB - which had 1,203,819 lines in the scanstatefiles.log
Another case took about 40 minutes for 8GB, which had 30,743 files in the scanstatefiles.log
As a result, I'd assume the extreme time duration was due to the quantity of files, and not necessarily the size of the .mig file
Looking at Scanstate documentation - I see there is a /p switch. However, that will only estimate the store size - not the file count.
We are looking to define a consistent process that can be used in all scenarios, whereas now it's luck of the draw with regards to the tech experience due to the wild variation it takes for Scanstate to complete.
Looking to see what input others may have that have gone through this already. Is there any other way we can estimate the time it will take, without impacting the systems or using disk space, so that we can more accurately plan which machines get done when?
Thanks in advance
There are no answers at this time