Article ID: 2481190 - View products that this article applies to.
Using the User State Migration Tool (USMT) 4.0 to migrate from an x86 platform to an x64 platform, COM+ component settings will be corrupt.
Note The issue does not happen when migrating from x86 to x86 or x64 to x64 platforms.
Opening COMEXP.MSC or DCOMCNFG.EXE and navigating to Component Services\Computers\My Computer will result in the following on-screen error:
You do not have permission to perform the requested action.Additionally you may see Event ID 4434 logged in the Application log:
Log Name: Application
Event ID: 4434
Task Category: Security
A method call to an object in a COM+ application was rejected because the caller is not properly authorized to make this call. The COM+ application is configured to use Application and Compoinent level access checks, and enforcement of these checks is currently enabled. The remainder of this message provides information about the component method that the caller attempted to invoke and the identity of the caller.SVC/Lvl/Imp = 10/6/3, Identity=<<DOMAIN\Username>>
This issue is fixed in USMT 5.0. The recommended solution is to use USMT 5.0 for migrations instead of USMT 4.0. USMT 5.0 is part of the Windows Assessment and Deployment Kit (ADK):
To workaround the issue in USMT 4.0, you must specify a config.xml file and set the “Microsoft-Windows-COM-ComPlus-Setup” to not migrate.
If you are not already using a config.xml file for USMT, you can generate one automatically by specifying the /genconfig switch to scanstate.exe syntax. For example:
scanstate.exe /genconfig:config.xml /i:migdocs.xml /i:migapp.xml
For more information about USMT and config.xml files, see the following Microsoft TechNet Article:
Once you have generated the config.xml file, you must edit the following section, depending on source operating system (OS):
Windows XP - <component displayname="Microsoft-Windows-COM-ComPlus-Setup-DL" migrate="no"
Windows Vista or Windows 7 - <component displayname="Microsoft-Windows-COM-ComPlus-Setup" migrate="no"Save your changes to config.xml. Include the updated config.xml when using scanstate.exe to work around the issue. For example:
scanstate.exe c:\mystore /i:migdocs.xml /i:migapp.xml /config:config.xml /v:5This will execute scanstate.exe, using c:\mystore as the migration store, and include MigDocs.XML, MigApp.xml, and Config.XML for the migration with verbose logging enabled.
If you are in a scenario in which you have already migrated and COM+ is corrupted, you can use the following procedure to restore the original COM+ repository:
From an administrative command prompt, run these three commands:
Verify that R000000000001.clb is present. Then, copy it from the current directory to the root of the C drive by running this command:
copy R000000000001.clb C:\R000000000001.clb
Next, copy and paste the following VB script (between the dashed lines) to a.txt file and rename it COM_Restore.vbs (make sure to change the .txt file extension to .vbs).
Set objComCatalog = CreateObject("COMAdmin.COMAdminCatalog")
MsgBox "Backup Restored!"
Set objComCatalog = Nothing
Save the script to the root of C:\.
From the command prompt, run this command:
C:\cscript COM_Restore.vbsOnce you see the pop-up message stating that the backup is restored, restart the computer (this is required).
Finally, open Component Servers (dcomcnfg.exe) and see if you are still getting errors.
Note If you are logging in as a non-admin user and trying to start Component Services, the Event ID 4434 is expected. Non-admin users are not part of the administrator role of the COM+ System Application and, therefore, the security warning will get logged in the event log. This does not mean that the COM+ catalog is corrupted.
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.
Article ID: 2481190 - Last Review: November 27, 2013 - Revision: 8.0