Jason Sypkens's questions

I'm attempting to introduce USMT into my company's environment for all of our future migrations. While doing some testing, I have a backup store that refuses to restore, with some very bizarre results.

When extracting a small MIG file (600MB), that would normally only take a couple of minutes to complete - it goes on and on for about 20-30 minutes. The loadstate.log file get enormous, filled with this, just repeating (over about a million lines in the log):

2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Compressed=C:, Mapped=C:, DestExpanded=C:\
2013-06-21 18:08:23, Info                  [0x080000] Creating stream copy in C:\Users\SYPKENJM\AppData\Local\Temp\tmp848C.tmp\Temp\tmp5290.tmp (362 bytes)
2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Links C:\Users\SYPKENJM\AppData\Local\Temp\tmp848C.tmp\Temp\tmp5290.tmp and C:\Users\SYPKENJM\AppData\Roaming\Microsoft\Windows\Recent\Local (C) (667).lnk differ in target paths: 'C:\' vs. 'C:\'
2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Compressed=C:, Mapped=C:, DestExpanded=C:\
2013-06-21 18:08:23, Info                  [0x080000] Creating stream copy in C:\Users\SYPKENJM\AppData\Local\Temp\tmp848C.tmp\Temp\tmp5291.tmp (362 bytes)
2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Links C:\Users\SYPKENJM\AppData\Local\Temp\tmp848C.tmp\Temp\tmp5291.tmp and C:\Users\SYPKENJM\AppData\Roaming\Microsoft\Windows\Recent\Local (C) (668).lnk differ in target paths: 'C:\' vs. 'C:\'
2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Compressed=C:, Mapped=C:, DestExpanded=C:\
2013-06-21 18:08:23, Info                  [0x080000] Creating stream copy in C:\Users\SYPKENJM\AppData\Local\Temp\tmp848C.tmp\Temp\tmp5292.tmp (362 bytes)
2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Links C:\Users\SYPKENJM\AppData\Local\Temp\tmp848C.tmp\Temp\tmp5292.tmp and C:\Users\SYPKENJM\AppData\Roaming\Microsoft\Windows\Recent\Local (C) (669).lnk differ in target paths: 'C:\' vs. 'C:\'
2013-06-21 18:08:23, Info                  [0x080000] pCompareLnkContent: Compressed=C:, Mapped=C:, DestExpanded=C:\

I can see some hidden lnk files in there that match these log entries (like, "Local (C) 581.lnk", but I don't know where they came from. This machine was imaged fresh just for this USMT test, so it seems that USMT must have created those files. The loadstate.log ends up being about 180MB, then it finally moves on.

I've ran usmtutils /extract, and it extracts very quickly - and those Local (C) ###.lnk files are there, in appdata/microsoft/windows/recent folder. It's just a lnk that points to the C:\ drive.

Anyone have any insights, troubleshooting steps, or similar experiences?

Starting to build our customized migdocs config xml, and I am finding that USMT doesn't seem to support the Known Folder IDs, although this blog post seems to indicate that it should fully support them.

USMT now supports all of the KNOWNFOLDERID types now. Previously some (such as FOLDERID_Links) were not and required some hacking.

Looking through scanstate logs, and it appears that the only Known Folder ID that it is supported is the Downloads folder. This is also the only folder that I've seen used in other forum posts. We can use hardcoded paths or (hopefully) CSIDL references, but would like to use KnownFolderID's as they are the replacement for CSIDL, and should be supported.

This is an example of my usage in the MigDocs.xml:

<pattern type="File">%FOLDERID_ProgramFiles%\FolderName\* [*]</pattern>

If I have this pattern in an exclude, I find that it isn't excluded. If I change this line to:

<pattern type="File">C:\Program Files\FolderName\* [*]</pattern>

Then it works.

Edit to add information: - We're running this in offline mode, in Windows PE (actually, Windows RE from DaRT for Windows 8), and running it against an installation of windows 7.