Exchange Migrator 2.x
When migrating a mailbox, Exchange Migrator seems to "hang" for a long time with no feedback from the wizard.
Exchange Migrator takes a long time to migrate a mailbox without reporting any status.
The Exchange Migrator
EMDevlog.txtfile shows a long delay between events.
EMDevlog.txt file shows, this delay occurs immediately following an attempt to write information to the
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.
While the mailbox is migrating, open SQL Enterprise Administrator and view the
FolderNonMigratedAcltables 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.
The mailbox should still migrate successfully, it may just take some time.