Microsoft has created an update for USMT 4.0 that adds support for Office 2010. USMT 4.0 migrations of Office 2010 are now supported .
You can get the update here: http://support.microsoft.com/kb/2023591
Here are some things you should be aware of:
The update also fixes a couple of issues around hard-link migration performance when copying a folder with a huge number of files and an issue that affected certain time zones.
This post was contributed by David Hornbaker, a Senior Consultant with Microsoft Services - U.S. East Region.
I know that USMT3 is no longer supported, BUT, can the USMT 4 MIGAPP.XML be used as a replacement file for the USMT 3 MIGAPP.XML, AS IS, or IF SO, with 'some' modifications, to 'add' Office 2010 migration support?
Thanks.. J P Morgan, email@example.com - 770-793-1946
@JPMorgan - no, the files are not compatible between versions i'm afraid.
Sirs , this is in reply to your response that the NEW USMT4 MIGAPP.XML is 'not compatible' with USMT 3 usage.
I would assume that you would KNOW for SURE!!, However i was curious as to 'why not' and the IMPACT of
using the USMT 4 MIGAPP.XML hot fix file (with Office 2010 support) and any 'loss' of data that would occur...
1) The 'default' MIGUSER.XML file are 99.9% idenical between USMT 4 and USMT 3 (except for a few comment lines)
SO, if MIGUSER.XML were 'identical' i assumed (i know what happens when you do this) that i COULD replace the MIGAPP.XML from USMT 4 and use with USMT 3.01.
I performed the 'swap' and based on my 'findings' (initial/limited testing results using log files findings)
1) specified the "/v:13" option
2) set the "mig_enabled_diag" variable.
AFTER running SCANSTATE 3.01 with above setting and NEW MIGAPP.XML from USMT 4 HOTFIX with Office 2010 support:
1) did not 'see' any obvious unusual Warnings/Errors logged, that were that diff between the logs files generated using
the OLD and NEW MIGAPP.XML files ( i would have assumed that the NEW MIGAPP.XML would have thrown syntax errors
in thye log files (ie debug log)if it was that incompatible)
2) The LOG file with OLD (original) USMT 3 MIGAPP.XML reported:
successfully completed send operation: stored 7731 objects
The MIG file created was 47,771 (in size)
3) The LOG File with NEW (hotfix) USMT 4 MIGAPP.XML reported:
successfully completed send operation: stored 7744 oobject
The MIG file created was 47,776 (in size)
The NEW MIGAPP actually found 13 more objects ( NOT LESS) to migrate.
The NEW MIG file is ONLY 5 bytes diff (larger) than OLD MIG file. SO i assume (that word again) that NO data lost??!!
The Trace/debug files were generated (MIG_Enable_Diag=) and other than ORDERING of "MIG UNITS" , i do not
'see' any obvious 'loss' of migration functionality between the TWO diff MIGAPP.XML files.
BUT this was ONLY a BACKUP, did NOT do a RESTORE to verify that ALL expected Setting/files were migrated!!!
PLEASE TELL ME I AM WRONG (AGAIN) AND THIS IS NOT DOABLE (safe) AND WOULD CAUSE LOSS OF DATA!!
Thanks.. J P Morgan
@JP Morgan - I understand your pain, it is something I've come across in the past. A while back I asked the product team this question and they told me that it shouldn't work, and more importantly is an unsupported configuration and could cause a corrupt store.
However, when I asked the question, the USMT 4.0 was still in beta. Your best bet would be to head over to the USMT blog (blogs.technet.com/.../usmt - although it looks like they haven't posted in a while) and ask this question, or get in contact with Microsoft support. I really don't have access to the information that you need.
Daniel,Thanks for your feedback.. see NED'S reply below. The USMT BLOG has had NO ACTIVITY since Aug 2008!!! ??? So that dosnt look like someplace to go!!
URL to Neds comment about USMT support..
NedPyle [MSFT] 18 Feb 2010 8:03 AM Comments 1
Ned here again. As odd as it sounds, when you call Microsoft for USMT 4.0 support, you will be sent to the Directory Services team. This is because we support user profiles loading and unloading, as that is a core piece of interactive logons. It’s a tangled web.
J P Morgan firstname.lastname@example.org 770-793-1946
From a schema/synatx standpoint the 4.0 migapp.xml will work - that is to say, it will run without fatal error using the 3.01 loadstate/scanstate. The store will not be corrupted. However, this XML has not been tested with USMT 3 (and never will be), so weird problems may be happening under the covers when you use it. No conspiracy here, we simply have no idea.
Now, if you are using USMT 3 because you *have* to (i.e. you are migrating to XP computers or from Win2000 computers) then a way around this would be to have Office *2007* installed on the destination computer. You migrate the user state and that will work fine. Then, install Office 2010 and it will upgrade everything in the user profile when the user first logs on later. That would be fully supported and would work fine.
If you are going to Vista or 7, you shouldn't be using 3.01, naturally. This is now all moot and you use USMT 4.0.
I hope this helps,
The 4.0 migapp.xml does "work" when used with USMT 3.01 - and by that I mean it is schema compatible, will not cause a fatal error during 3.0 scanstate/loadstate, and will not corrupt the store in any way. However, under the covers it may be causing issues within the migration. That 4.0 XML and Office 2010 have not been tested in any fashion with USMT 3 (and never will be), so while it might appear to work fine on the surface, we have zero idea of any more insidous problems. Because it is untested, it is considered unsupported.
Now, if you are using USMT 3.01 because you *have* to - such as migrating from Win2000 or to WinXP - I can offer you a supported workaround: migrate to a computer that has Office 2007 installed, then upgrade the office install to 2010 after the migration is done but before the users log on. 2010 will upgrade the office 2007 settings (as if there was no migration).
the link is broken support.microsoft.com/.../2023591