Resolution
Exchange Migrator 2.x
symptom
When migrating a mailbox, Exchange Migrator seems to "hang" for a long time with no feedback from the wizard.
symptom
Exchange Migrator takes a long time to migrate a mailbox without reporting any status.
symptom
The Exchange Migrator
EMDevlog.txt file shows a long delay between events.cause
As the EMDevlog.txt file shows, this delay occurs immediately following an attempt to write information to the FolderIndex and FolderNonMigratedAcl tables. The function that seems to hang the migration operation is called DBStoreFolderAcls. In the example below, the bold entries indicate where the delay occurs:
2005-08-15 21:05:29:::(254587) --- Worknode SUCCEEDED --------------------- [MigrateData]
2005-08-15 21:05:29>>>(254588) StoreFolderACL
2005-08-15 21:05:31>>>(254589) CDBMgr::Process()
2005-08-15 21:05:31===(254590) Operation Name [BSTR='DBStoreFolderACLs']
2005-08-15 21:05:31>>>(254591) CDBMsg::DBStoreFolderACLs
2005-08-15 21:05:31<<<(254592) CDBMsg::DBStoreFolderACLs
2005-08-15 21:51:56<<<(254593) CDBMgr::Process()
2005-08-15 21:51:56:::(254594) Updated database successfully
2005-08-15 21:51:56<<<(254595) StoreFolderACL
2005-08-15 21:51:56:::(254596) --- Worknode SUCCEEDED ---------------------
The cause of this delay is an excessive number of ACEs placed on both the mailbox and its subfolders. Each folder in a mailbox has one entry in the FolderIndex table. This entry connects the folder name to the FolderID. The ACL information is stored in the FolderNonMigratedAcl table. This table contains one entry for each ACE in the folder permissions, and each entry references the FolderID for the folder.
fix
While the mailbox is migrating, open SQL Enterprise Administrator and view the
FolderIndex and FolderNonMigratedAcl tables in the EMA database to check if they are populating with many entries. If they are populating rapidly, allow Exchange Migrator to completely finish the mailbox migration.note
The mailbox should still migrate successfully, it may just take some time.