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:
- Certain settings and customizations in MS Word won’t migrate from any version to Word 2010, because of with the way Word is designed and how data is stored in “HKEY_CURRENT_USER\software\Microsoft\Office\<OfficeVersion>\Word\Data".
- Many Office settings (across all Office apps) won’t migrate when going from 32-bit Office to 64-bit Office. This is due to the way that the settings are stored in 64-bit Office installations.
- If you’ve launched Office on the destination PC as a user before doing the migration of that user’s profile, most of your settings won’t migrate. This happens because Office relies on some code that only runs the first time that an Office app is launched to migrate settings.
- This update isn’t a magic bullet. You may still need to do some customization to make USMT fit your particular configuration.
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.
Also Michael Niehaus has a blog about the release of this KB that are of note.
A new hotfix for USMT 4.0 was released today to support migrating Office 2010 settings. (It includes other fixes too.) You may want to download this and integrate it into your deployment processes. The full instructions for doing this (including what needs to be done with MDT and ConfigMgr) are included in the KB:
There is one complication that you should be aware of if you are using ConfigMgr and moving from Windows XP or deploying Windows XP. USMT 4.0 uses a set of manifest files to determine what needs to be migrated from Windows XP. These manifest files are stored in the “DLManifests” folder, which is part of your USMT package in ConfigMgr. There is an issue though where Scanstate.exe can’t find this DLManifests folder when run from ConfigMgr. In MDT 2010 Update 1, we included a workaround for this, copying the folder where Scanstate can find it:
‘ Workaround for USMT bug in Windows 7 AIK
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" then
oUtility.RunWithHeartbeat "cmd.exe /c xcopy /iesryhd """ & sUSMTPath &"\DlManifests"" """ & oEnv("SystemRoot") & "\system32\DlManifests" &""" 1>> " & oLogging.LogPath &"\zticopyUSMT.txt 2>>&1 "
Notice that this checks specifically for build 6.1.7600.16385 of Scanstate.exe, the version released in the Windows 7 version of Windows AIK, as we expected this problem to be fixed in the next version of USMT. Well, it wasn’t. But once you install the KB 2023591 hotfix, the version changes to 6.1.7601.21645 and our fix stops working.
You can work around this by fixing the fix, to read like this:
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and (oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" or oFSO.GetFileVersion(sFoundScanState) = "6.1.7601.21645") then
If you aren’t using ConfigMgr or don’t have Windows XP around any more, you won’t need to worry about this.