This update includes changes which require Microsoft .NET framework 4.7.2. Migration Manager for Exchange previously used .NET Framework version 4.5.2 which has passed Microsoft's lifecycle End-of-Support date. Ensure that your target operating systems are up-to-date and compatible with .NET Framework 4.7.2 or higher.
The minimum product version required for installing this hotfix is 8.15.
This update may require additional testing.
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 enhancements are implemented in this release:
Feature | Enhancement |
Ability to change the established direction of a Public Folder migration (MAgE) A new feature enables switching from OneWay to TwoWay and vice versa for started migrations. The existing feature "Smart Resync" can be used to change direction on the fly, sync missing items, and avoid duplicates. Details: A new parameter, Direction, has been added to the PowerShell cmdlet Restart-PublicFolderMigration . When the Direction parameter is used, and it does not match the current migration direction, then the SmartResync project option will be set to "True", database migration direction will be flipped and Resync will be initiated.Note: Use of the Direction parameter is mutually exclusive with using the PermissionsOnly parameter. Limitation: In case of changing from TwoWay to OneWay, already migrated target-to-source objects will not be cleaned up. | MMEX 352388 |
Added the ability to migrate multiple source organizations' public folders to the same target. | MMEX 360641 |
Public Folder supportability improvements: Minor changes to assist with setup and troubleshooting. | MMEX 319003 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
Problems when folder permissions cannot be assigned on secondary calendar folder. Scope: Migration Agent for Exchange (MAgE) Root-cause: ServiceLocalException occurs when folder permissions cannot be assigned on secondary calendar folder Fix: Implemented ServiceLocalException handling in EWSSyncConnector.dll | MMEX 444012 |
Problem connecting to a TLS 1.2 enabled Exchange Scope: Public folder migration by the Migration Agent for Exchange (MAgE) Root-cause: Script modification needed to implement TLS 1.2 protocol Fix: EScript modification to implement TLS 1.2 protocol | MMEX 313356 |
Correct the speed information reported in public folder sync logging. Scope: Public folder migration by the Migration Agent for Exchange (MAgE) Root-cause: Logging code did not report sufficient decimal digits. Fix: Changed log line format to improve accuracy. | MMEX 324445 |
Resolved issues using Native Move for migration Scope: Native Move migration by the Migration Agent for Exchange (MAgE) Root-cause: NETBIOS name of Exchange server was used instead of FQDN Fix: Corrected issue where NETBIOS name of Exchange server was used instead of FQDN. | MMEX 359304 |
Resolve issues with EWS API object identifiers. Scope: Public folder migration by the Migration Agent for Exchange (MAgE) Root-cause: Under certain circumstances, the Microsoft EWS API can return inconsistent unique IDs for the same object across different API calls. This change remediates this issue. Fix: Updated Import-PublicFolderMapping.ps1 script. | MMEX 382637 |
Legacy cryptographic functions detected by security scanning software. Scope: Update from previous MMEx product versions (prior to 8.14) Root-cause: Modern security-scanning software can detect the legacy support for upgrading old MMEx projects and warn about the cryptography functions. Fix: Legacy cryptographic functions removed. If you have a need to update pre-MMEx 8.14 projects, redeploying MAgE will update the database as necessary. | MMEX 384932 |
Http Headers namespace support. Scope: Public folder migration by the Migration Agent for Exchange (MAgE) Root-cause: While working with Microsoft, we found an issue with MMEx's http header processing, where an XML element expected by Microsoft was not present. This does not currently impact MMEX, but we are including this change to future-proof the product. Fix: Updated MAgE. | MMEX 381283 |
Resolve NullReferenceException in GetItemsToExport. Scope: Migration Agent for Exchange (MAgE) Root-cause: Logic error Fix: Updated MAgE. | MMEX 387377 |
Deprecation of Remote PowerShell (RPS) Protocol in Exchange Online PowerShell. Scope: Migration Agent for Exchange (MAgE) Root-cause: Microsoft has announced End-of-Support for the RPS protocol in 2023. Fix: Updated MAgE. | MMEX 404311 |
Upgrade .NET Framework version to .NET 4.7.2. Scope: All compomnents. Root-cause: Microsoft .NET Framework 4.5.2 is past the Microsoft End-of-Support lifecycle date Fix: Supporting library updates. | n/a |
Replace deprecated Microsoft APIs with modern equivalents:
Scope: All components Root-cause: Older Microsoft APIs are reaching their Microsoft End-of-Support lifecycle dates. Fix: Product updates. | MMEX 395164, MMEX 381940, MMEX 399421 |
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 |
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center