Quest® Migration Manager for Exchange®
Version 8.15
Update 20210830EX - Readme
August 30, 2021
Public folder synchronization feature
Verifying successful completion
This update may require additional testing.
The minimum product version required for installing this hotfix is 8.15.
For complete product information, please refer to the Quest Migration Manager for Exchange product documentation and to the System Requirements and Access Rights document.
IMPORTANT:
The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
Quest Software recommends applying the latest Exchange Server Cumulative Updates and Security Updates. For a discussion of why this is important please see "Why Exchange Server updates matter" on the Microsoft Exchange Team blog.
Quest Software validates the most recent update of Migration Manager for Exchange against the latest Exchange Server Cumulative Updates and Exchange Server Security Updates as they are released by Microsoft.
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
Mailboxes could become stuck in a failed state. The MAgE log contains the following entries: "Error System.Management.Automation.RemoteException: Failed to communicate with the mailbox database." Scope: Native Move migrations Root-cause: Platform changes to "ResourceUnavailable" and "ConnectionFailedTransientException" exception reporting in Native Move PowerShell cmdlets. Fix: Exception processing was updated to handle these platform changes. | MMEX 276420 |
A NullReferenceException in SyncFolderHierarchy method. The error message "System.NullReferenceException: Object reference not set to an instance of an object." could appear. Scope: All MAgE migrations Root-cause: If a folder was deleted after synchronization was started, the Exchange server returns a null value as folder information, but MAgE still tries to access that field. Fix: MAgE will properly handle folders deleted after synchronization has started. | MMEX-11179 |
When syncing data to Office 365, the error message "The server terminated an operation because it encountered a client request loop. Please contact your app vendor." could appear. Scope: Office 365 migrations Root-cause: If the service account name provided to Migration Manager for Exchange was not identical in its use of upper and lower case to the account name in Office 365, this circumstance causes the agent to repeatedly and unnecessarily request access tokens. This results in performance issues which can cause the error cited above. Note that this can be avoided by ensuring that the service account name provided to Migration Manager for Exchange is identical to the account name in Office 365. Fix: The agent's comparison code was adjusted to be case-insensitive. | MMEX-11163 |
Current feature status:
Category | Feature | Supported | Comments |
Synchronization | 2-way synchronization | yes | |
---|---|---|---|
Migration from Exchange 2007 | NO | ||
Migration from/to Exchange 2019 | yes | Currently the following scenarios are supported: from Exchange 2019 to Exchange 2013/2016/2019 or to Office 365. | |
Migration from Exchange 2010/2013/2016 | yes | Currently the following scenarios are supported: to Exchange 2013/2016/2019 or to Office 365. | |
2-way synchronization for selected folders | NO | Synchronization direction can be set for all folders only. | |
Add, update, delete messages | yes | ||
Update public folders automatically | yes | Permissions including group permissions will be updated; renamed and/or moved public folder will be handled by ID. | |
Handle deleted folders automatically | yes | PublicFolderRecycleBin parameter of migration project can be used to specify whether to move deleted public folders to the Migration Manager Recycle Bin folders or permanently delete them. | |
Add new top-level folders | yes | New top level public folders can be detected and added to migration automatically by MAgE using DetectNewTopLevelFolders parameter. For details refer to Configuring Migration Using PowerShell. | |
Handle new subfolders of synced top-level folders automatically | yes | ||
Synchronize folders’ mail-enabled status | yes | ||
Re-migrate folders deleted on target | yes | If previously migrated folder has been deleted in target and need to be migrated from the scratch, the Remove-MMExPublicFolderMigration cmdlet can be used to remigrate this folder. | |
Resync | yes | ||
Synchronize permissions | yes | With PermissionsOnly switch for Restart-MMExPublicFolderMigration cmdlet you can synchronize permissions only | |
Synchronize SMTP address and advanced folder properties | yes | ||
Configuration | Define migration scope | yes | MigrateOnly parameter can be used to manage migration scope. |
Modify migration scope | yes | Migration can be suspended/resumed for specified public folders. Additional root folders can be added to migration scope. | |
Content filtering | yes | ||
Support for existing content structure on target | yes | ||
GUI | NO, MIGRATION BY MMEX POWERSHELL SCRIPTS ONLY | ||
System requirements | Minimal requirements | 1 host, 1 agent | |
Performance | Overall performance | high | |
Monitoring | Synchronization statistics | yes |
IMPORTANT: This section is for information purposes only, refer to online product documentation for actual information.
The following enhancements were implemented in this release:
Enhancement | Issue ID |
The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-10800, MMEX-11044 |
Subfolders can be excluded from Public folder synchronization by MAgE. Additional project option introduced: DetectNewSubPublicFolders. There is a new “DetectNewSubPublicFolders” parameter added to Set-MMExProjectOptions/Get-MMExProjectOptions/Reset-MMExProjectOptions cmdlets to control whether to automatically migrate all or migrate some sub public folders which is specified in mapping file. For example, there exist source public folder “\root” which contains sub folder "sub1" and "sub2", if user use Import-MMExPublicFolderMappings cmdlet to import the mapping file, and filter to exclude “sub2”. If parameter “DetectNewSubPublicFolders” is set to false, MMEx will only migrate “\root” and its sub folder “sub1”. If parameter “DetectNewSubPublicFolders” is set to true, MMEx will migrate “\root” with all the sub folders in it. For details refer to the Configuring Migration Using PowerShell. | MMEX-10815 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
In certain situations, Import-MMExPublicFolderMapping could not create target public folders because of improper mailbox names and therefore migration could not start. Scope: Public folder job by the Migration Agent for Exchange (MAgE) Root-cause: Office 365 has a known issue where some tenant accounts create Public Folder mailbox names with an unnecessary, seemingly random suffix. Microsoft has acknowledged this issue and has added it to their development backlog. There is no ETA for implementation or delivery of a change, and no tracking ID is currently available. Fix: If this situation occurs, use the Change Import-MMExPublicFolderMapping cmdlet procedure. It will modify the Public Folder mailbox names to remove the incorrect suffix and name the folders as expected. | MMEX-11035 |
Slow migration speed, SQL timeout errors in cases with large numbers of skipped and/or failed items. Scope: All migration scenarios supported by MAgE Root-cause: Sub-optimal SQL server queries. Fix: SQL server stored procedures calls optimized, now makes one call per skipped or failed item instead of two. MAgE and SQL server load should be decreased in cases where there are many skipped and/or failed items. | MMEX-4086 |
Errors “folder not found” during public folder scripts execution. Further migration of affected folders is impossible. Scope: Public folder synchronization by MAgE Root-cause: Public folders created with PowerShell are not visible for EWS before replication completes. Fix: A waiting period for replication was added. The operations will be retried every 30 seconds, for a maximum of 30 minutes. | MMEX-11020 |
Slow migration speed, SQL timeout errors, very large ICS_CACHE table on SQL server. Scope: All migration scenarios supported by MAgE Root-cause: MAgE pre-caches all the items IDs in a SQL server table. Fix: MAgE migration workflow changed: Query a portion of items on Exchange server, cache with SQL server, migrate that portion of items, delete entries from SQL server, repeat. | MMEX-7111 |
Some public folders failed to migrate. Scope: Public folder synchronization by MAgE Root-cause: Microsoft bug: public folders unique IDs are not consistent. Fix: MAgE implements a workaround to fix public folders unique ids stored in the SQL database. | MMEX-10433 |
Resync could be slow in cases of two-way synchronization. Scope: All migration scenarios supported by MAgE Root-cause: MAgE logic error, source items processed twice. Fix: Fix the program logic to not reset source synchronization state twice. | MMEX-10846 |
Migration of particular mailbox or public folder stuck on 99% and can never be completed. Scope: All migration scenarios supported by MAgE Root-cause: MAgE logic issue: source exchange items which failed to migrate and later deleted on source can never be deleted from the SQL table which prevents migration completion. Description: MAgE logic fixed: If a source item does not exist anymore, delete the corresponding entries from the SQL table. | MMEX-10847 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
If user migrate public folder from on-premise to office365 using two-way synchronization, it will generate duplicated public folder items reside at on-premise. Scope: Public Folder synchronization by MAgE Root-cause: The root cause is that MAgE agent will get different unique id when calling Microsoft EWS API even if for the same item or folder. Fix: Now MAgE add FixPublicFolderUniqueId and FixPublicFolderUniqueIdResyncFeature parameters on Set-MMExProjectOptions/Get-MMExProjectOptions/Reset-MMExProjectOptions cmdlets to fix this issue. If set FixPublicFolderUniqueId to true, MAgE agent will automatically fix public folder’s unique id when migrating public folder from on-premise to office365 using two-way synchronization, otherwise MAgE agent will not adjust public folder item’s unique id. If set FixPublicFolderUniqueIdResyncFeature to true, MAgE agent will automatically clean up the existed duplicate public folder items on on-premise side when resyncing public folders from on-premise to office365 using two-way synchronization, otherwise MAgE agent will not clean up the duplicated items. | MMEX-10634 |
The following enhancements are implemented in this release:
Feature | Enhancement | Issue ID |
Using new -PermissionOnly switch you can select to resynchronize content and permissions or to resynchronize permissions only. This parameter can be used both with Restart-MMExMailboxMigration and Restart-MMExPublicFolderMigration cmdlets. | MMEX-10017, MMEX-1785 | |
Collections can now be created not only from the Migration Manager Console UI, but can also be created using PowerShell. This release introduces the New-MMExCollection cmdlet to create collections. The parameter set for the New-MMExCollection cmdlet has now been updated to handle additional collection properties. For details refer to the Configuring Migration Using PowerShell. | MMEX-10323 | |
Get-MMexCollectionMember is now enhanced to return SMTP for collection members. Some parameter names are changed. For details refer to the Configuring Migration Using PowerShell | MMEX-10377, MMEX-10471 | |
Collections can now be removed not only from the Migration Manager console UI, but can also be removed using PowerShell. This release introduces the Remove-MMExCollection cmdlet to remove specified collections. | MMEX-10379 | |
You can now add members to specified collections using Add-MMExCollectionMember cmdlet. For details refer to the Collection Member Management. | MMEX-10381 | |
You can now remove specified members of specified collections using Remove-MMExCollectionMember cmdlet. For details refer to the Collection Member Management | MMEX-10382 | |
Support added for the scenario where two source organization names have the same name with different letter case. Now you can provide organization ID to specify unique organization. For details refer to Collection parameters subsection of Configuring Migration Using PowerShell User Guide section. | MMEX-10240 | |
Now new top level public folders can be detected and added to migration automatically by MAgE using DetectNewTopLevelFolders parameter for Set-MMExProjectOptions cmdlet. Both of the following conditions should be satisfied:
| MMEX-10276 | |
A new parameter MinProcessingInterval is introduced for Set-MMExCollection, Get-MMExCollection and Reset-MMExCollection cmdlets. It specifies the minimum time interval in minutes that must pass before an item in collection can be processed again. NOTE: if MinProcessingInterval is not set for a collection, the global interval set (MinMailProcessingInterval, MinCalendarProcessingInterval, MinNativeMoveProcessingInterval, MinPublicFolderProcessingInterval, MinMailProcessingIntervalInSync, MinCalendarProcessingIntervalInSync, MinNativeMoveProcessingIntervalInSync, MinPublicFolderProcessingIntervalInSync) by Set-MMExProjectOptions will be used. . | MMEX-9689 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
Public folder is not synchronized, and the following error is reported: Error Cannot bind to the root folder %FolderPath%. Inner exception: The specified object was not found in the store., The process failed to get the correct properties. And a manual check shows that the service account has not been granted client permissions for this public folder. Scope: Public folder synchronization by MAgE Root-cause: Invalid source and target match may result in the removal of owner permissions for the service account on the target public folder. MAgE cannot sync this folder in the case. Fix: The permissions synchronization algorithm has been improved, and the corresponding error handling has been implemented. An incorrect matching will no longer prevent MAgE from syncing all valid data for a public folder. | MMEX-10286 |
MAgE failed to synchronize data due to issue with message processing, and the following error is reported for the message: Microsoft.Exchange.WebServices.Data.ServiceResponseException: The specified object was not found in the store. Scope: All migration scenarios supported by MAgE Fix: These messages will no longer prevent MAgE from syncing all valid data. Most of messages will be migrated succesfully. Refer to Known Issues in case the problem persists. | MMEX-10624 |
Target public folder failed to be created in the specified mailbox using Import-MMExPublicFolderMapping cmdlet, and no event is reported. Scope: Public folder synchronization by MAgE Root-cause: EWS cannot set pr_replica_list property for Microsoft Office 365 now and if the EWS was used to create the public folder, the public folder mailbox cannot be specified and the public folder is created in the mailbox containing its parent public folder. Fix: Now the processing algorithm is enhanced to avoid the issue and the public folder mailbox will be created properly. NOTE: Import-MMExPublicFolderMapping cmdlet will create a transient public folder “MMExTransientFolder” under the root public folder, but it will be removed when this cmdlet is completed. | MMEX-10581 |
This release introduces the following features and enhancements:
The following enhancements are implemented in this release:
Feature | Enhancement | Issue ID |
General | A new parameter PreferInternalEwsUrl is introduced for Set-MMExOrganizationProperties. If AutodiscoverUrl is specified for the Exchange organization and the PreferInternalEwsUrl parameter is set to True, MAgE will first try to use the internal EWS Url. The default is False, this means MAgE first tries the external EWS Url. NOTE: The parameter is used only when AutodiscoverUrl is specified. | MMEX-10098 |
Parameter set for Get-MMExCollection, Reset-MMExCollection, and Set-MMExCollection cmdlets is now updated to handle more collection properties. For details refer to the Configuring Migration Using PowerShell | MMEX-9720, MMEX-9719, MMEX-9628, MMEX-10038 | |
Mailbox Synchronization | Mailbox switch process is now enhanced and MAgE will attempt to complete the mailbox immediately after SyncPeriodAfterSwitch passes. The MinMailProcessingIntervalInSync is not now used as reference, because it may take a long time to complete a mailbox according to the default interval values. | MMEX-9688 |
Public Folder Synchronization | All new subfolders of public folders that are already included in synchronization scope will be detected and automatically added to the project. For working migration projects no action is required. Consider, top-level public folders (not nested to the folders included in the synchronization scope) intentionally cannot be handled automatically and should be added as described in Public Folder Synchronization by MAgE document. | MMEX-9908 |
Public Folder Synchronization feature is enhanced. Refer to Public Folder Synchronization (MAgE) document for job scheduling procedure and for additional information on Set-MMExGroupMatching and Sync-MMExMailPublicFolder cmdlets. | MMEX-9507, MMEX-9508 | |
Set-MMExGroupMatching cmdlet should only be used for the Microsoft Office 365 target, it is not required for on-premises targets. To handle on-premises migration scenarios, Set-MMExGroupMatching is not executed now as part of Start-MMExPublicFolderMigration. | MMEX-10097 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
Ready to switch status for migrated mailbox cannot be achieved and the following error message is reported:MigrationManagerForExchange.General.DotNet.AggrException: Exception of type 'MigrationManagerForExchange.General.DotNet.AggrException' was thrown. ---> MigrationManagerForExchange.Shared.Heart.MigrationManagerException: No mailbox with such guid. . Scope: All migration scenarios supported by MAgE. Root-cause: Mailbox synchronization may hang in case a calendar item that was already migrated has been deleted in the source. Fix: If the calendar item deletion matched with deleted source item cannot be handled due to an exception, MAgE reports the issue, and the target mailbox can be processed successfully. Besides the error handling for such messages, additional validation of messages matching is implemented to avoid isssues described here and in MMEX-9164 resolved in the previous product update. | MMEX-9510, MMEX-9270 |
Sync-MMExMailPublicFolder does not work and the following error is reported: Cannot find path 'HKCU:\Software\Quest Software\Migration Manager for Active Directory\Directory Migration' because it does not exist. Scope: Public folder synchronization by MAgE Fix: The issue is now resolved. | MMEX-9702 |
This release introduced the following features and enhancements:
The following enhancement is implemented in this release.
Feature | Enhancement | Issue ID |
General | The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-9277 |
LDAP Signing Configuration Requirements subsection is now added to System Requirements and Access Rights document. For details on Network security: LDAP client signing requirements policy refer to LDAP Signing Configuration Requirements. For working migration projects, no action is required. Scope: All supported scenarios | MMEX-9165 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
After nested public folder is moved to the root (matched with target All Public Folders), the matched target public folder is not moved to All Public Folders. Scope: Public folder synchronization by MAgE Root-cause: The information about All Public Folders root folder was not stored properly. Fix: Now public folder moving to the root is handled properly by MAgE. | MMEX-8097 |
Ready to switch status for migrated mailboxes cannot be achieved and the following trace is logged: Warning Item 'UniqueId' isn't deleted. Result = 'Error'. ErrorCode = '...'. The following error code values can be reported in the message:
All migration scenarios supported by MAgE Root-cause: The problem occurs for the Calendar items that were previously migrated in another synchronization process. For example: target mailbox has been recreated; or the message has been copied from shared calendar of another mailbox. So matching of the item is pointing to the wrong target item which is not in scope of current migration. Fix: Processing algorithm is changed, MAgE now will treat the above errors as not critical for the current migration process and will synchronize the message. The informational trace will be logged for such messages: Info Item 'UniqueId' cannot be deleted. Result = 'Error'. ErrorCode = '...'. | MMEX-9164 |
Migration Manager Recycle Bin should be excluded from processing scope. Scope: Public folder synchronization by MAgE Fix: Existing subfolders of source Migration Manager Recycle Bin are now excluded from processing scope. These subfolders will not be created in the target during synchronization, and the contents of these subfolders will not be migrated. | MMEX-9352 |
The following known issue exists at the time of the update release:
Defect ID | Issue Description |
MMEX-10166 | Not suspended public folder is not synchronized, because it is marked as Failed in the project database. Workaround: Resync this public folder to restart the synchronization for this folder. |
MMEX-9539 | Quest Migration Manager 8.15 product updates should not be uninstalled from the list of installed updates in the Installed Updates section. The product update removal is not supported. Workaround: You can only completely uninstall Quest Migration Manager for Exchange 8.15. For more information on how to perform the necessary operations in order to avoid possible issues, refer to the Post-Migration Activities document. |
Product name | Version | Platform |
Migration Manager for Exchange | 8.15 | All supported |
The following files are shipped:
To install the update, complete the following steps:
The installation does not affect existing settings. All your projects remain intact and can be continued after installation.
To determine if this update is installed, complete the following steps:
Quest creates software solutions that make the benefits of new technology real in an increasingly complex IT landscape. From database and systems management, to Active Directory and Office 365 management, and cyber security resilience, Quest helps customers solve their next IT challenge now. Around the globe, more than 130,000 companies and 95% of the Fortune 500 count on Quest to deliver proactive management and monitoring for the next enterprise initiative, find the next solution for complex Microsoft challenges and stay ahead of the next threat. Quest Software. Where next meets now. For more information, visit www.quest.com.
Technical support is available to Quest customers with a valid maintenance contract and customers who have trial versions. You can access the Quest Support Portal at https://support.quest.com.
The Support Portal provides self-help tools you can use to solve problems quickly and independently, 24 hours a day, 365 days a year. The Support Portal enables you to:
© 2021 Quest Software Inc.
ALL RIGHTS RESERVED.
This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software Inc.
The information in this document is provided in connection with Quest Software products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest Software products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST SOFTWARE ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest Software makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest Software does not make any commitment to update the information contained in this document.
If you have any questions regarding your potential use of this material, contact:
Quest Software Inc.
Attn: LEGAL Dept
4 Polaris Way
Aliso Viejo, CA 92656
Refer to our Web site, https://www.quest.com, for regional and international office information.
Quest Software is proud of our advanced technology. Patents and pending patents may apply to this product. For the most current information about applicable patents for this product, please visit our website at https://www.quest.com/legal.
Quest, the Quest logo, and Join the Innovation are trademarks and registered trademarks of Quest Software Inc. For a complete list of Quest marks, visit https://www.quest.com/legal/trademark-information.aspx. All other trademarks and registered trademarks are property of their respective owners.
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center