The user’s custom IE7 favorites
1. Process Monitor (download x86/x64 )
2. Windows System State Analyzer , included as part of the Windows Server Logo Tools (download x86 , x64 )
1. I install WSSA and start it up (as an Administrator).
2. I use the Tools menu to modify the options to monitor only registry and the user profiles directory. You can go as deep as the test user but some settings might exist in the All Users or Public profiles. I avoid scanning the entire drive, drivers, or services.
3. I start my application. In this case, I run Internet Explorer and open the Favorites menu (I want to be as close as possible to the change to avoid gathering unrelated data)
4. I start a Baseline Snapshot and allow it to complete then move to section “Make the Change”.
1. I Install ProcMon and start it up (as an Administrator).
2. I disable capturing and set the following filters to gather registry changes:
Operation is regSetValue
Note: I may have to do this multiple times for various filters. For example, if I wanted to see file changes I’d switch my filter to instead:
Operation is CreateFile
Path begins with c:\documents and settings
3. I start my application In this case, I run Internet Explorer and open the Favorites menu (I want to be as close as possible to the change to avoid gathering unrelated data)
4. I clear the current data then start capturing.
1. I alter my setting using the application. For example, here I move the AskDS blog link to the top of my favorites menu. Where it belongs. :)
2. I close the application to flush the change into the registry (there’s no guarantee that my change was immediately stored).
Order = <binary goo>
click picture to see in large-o-vision
Findstr.exe /s /i "currentversion\explorer\menuorder" *.*
<pattern type="Registry">HKCU\SOFTWARE\Microsoft\Internet Explorer\* [*]</pattern>
<pattern type="Registry">HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\* [*]</pattern>
<pattern type="Registry">HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoComplete\* [*]</pattern>
<pattern type = "Registry">HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Favorites\* [*]</pattern>
<pattern type="Registry">HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Webcheck\* [*]</pattern>
<pattern type="Registry">HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\* [*]</pattern>
<pattern type="Registry">HKCU\SOFTWARE\Microsoft\Search Assistant\* [*]</pattern>
<pattern type="File">%CSIDL_LOCAL_APPDATA%\Microsoft\Internet Explorer\* [*]</pattern>
<pattern type="File">%CSIDL_LOCAL_APPDATA%\Microsoft\Windows\History\* [*]</pattern>
<pattern type="File">%CSIDL_APPDATA%\Microsoft\Windows\Cookies\* [*]</pattern>
<pattern type="File">%CSIDL_APPDATA%\Microsoft\Internet Explorer\* [*]</pattern>
Important note: Windows Vista and Windows 7 also include XML in the %systemroot%\winsxs\manifests folder, stored as .manifest files. You should examine these files with FINDSTR.EXE if you do not return any data when searching the USMT manifests and using a Vista or Windows 7 computer as the source machine. They are used automatically if there is no replacement manifest.
There are a lot of manifests here and the ones that have a migration scope that includes “USMT” are the only ones that matter; the latest versioned one will be used if there are multiples:
To find them all on your test computer, search your windows\winsxs\manifests folder like this:
C:\Windows\winsxs\Manifests>findstr /m /i "usmt" *.manifest
1. I run scanstate to gather the settings on my test XP computer.
2. I run loadstate to restore the settings on my test Windows 7 computer.
Critical note: remember, I am using the USMT manifests for both the scanstate and loadstate. If those manifests are not available, my settings will not migrate. If you look very carefully at the debug logs you will see the indications of failure:
"Downlevel Manifests Folder is not present. System component settings will not be gathered."
The ReplacementManifests folder used to service system component manifests is not present. OS settings migration will be done with system component manifests installed onto the system.
The manifests might be missing because:
C:\>c:\usmt\x86\scanstate.exe c:\store /i:migapp.xml /i:migdocs.xml
C:\>\\server\share\scanstate.exe c:\store /i:migapp.xml /i:migdocs.xml
C:\>c:\usmt\amd64\scanstate.exe c:\store /i:c:\usmt\xml\migdocs.xml /i:c:\usmt\xml\migapp.xml
Instead of doing this ( good ):
C:\usmt\x86\>scanstate.exe c:\store /i:migapp.xml /i:migdocs.xml
C:\>NET USE U: \\server\share
U:\>scanstate.exe c:\store /i:migapp.xml /i:migdocs.xml
C:\usmt\AMD64>scanstate.exe c:\store /i:c:\usmt\xml\migdocs.xml /i:c:\usmt\xml\migapp.xml
Notice how the executable is running within the folder path in the latter examples. There’s no USMT command-line to provide a path to the manifest folders! You can also run into this issue with SCCM or MDT as well, see:
3. Before I log on to the test destination computer with my test user I load his user registry hive with regedit.exe and validate that the settings transferred:
It looks good so I unload the hive. Don’t forget to do this!
4. Then I logon as the migrated test user, but don’t start Internet Explorer. I examine the registry again and make sure it’s still unchanged. Why this step? The settings could be changing due to:
- A logon script
- A group policy
- The act of logging on itself (as the first logon triggers a number of “personalization” steps that might override certain migrated settings).
5. If I still didn’t know why the data was changing, I’d run Process Monitor in boot logging mode to see when and where the settings changed. That’s a theory though - I’ve never reached this stage using this methodical approach.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.