Quest® Migration Manager for Exchange®
Version 8.14
Update 20200326EX - Readme
March 27, 2020
Public folder synchronization feature
Verifying successful completion
This update may require additional testing.
The minimum product version required for installing this hotfix is 8.14.
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:
See New in This Update for new features and system requirement changes, introduced by this update, and for a list of issues, resolved in this update.
Refer to Known Issues for known issue that exists at the time of the update release.
This release introduces the following features and system requirement changes:
The following enhancement is implemented in this release.
Enhancement | Issue ID |
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 |
Information about ports required by Migration Manager components related to Exchange migration needs to be updated. Scope: Exchange migration Fix: Information about ports used by Migration Manager components for Exchange migration is now enhanced. For details refer to Ports used by Migration Manager for Exchange Components. For working migration projects, no action is required. | MMEX-9086 |
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:
Scope: 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 |
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 2016/2019 or to Office 365. | |
Migration from Exchange 2010/2013/2016 | yes | Currently the following scenarios are supported: to Exchange 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 folders | yes, but rerun needed | Synchronization should be rerun to add new folders. | |
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 | ||
Synchronize SMTP address and advanced folder properties | yes | ||
Configuration | Define migration scope | yes | MigrateOnly parameter can be to specify root folders to synchronize. |
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.
This release introduced the following features and enhancements:
Feature | Enhancement | Issue ID |
Public Folder Synchronization | Public folder synchronization is now supported by MAgE. Scope: Migration to Microsoft Exchange 2019 | MMEX-7810 |
Public Folder Synchronization | MAgE can now automatically handle public folder hierarchy changes related to deleted (both soft or hard deleted) public folders during one-way and two-way synchronization. Refer to
Public Folder Synchronization (MAgE) document for details. Public folders matched with deleted (soft or hard deleted) public folders by default are moved to source or target Migration Manager Recycle Bin public folders or permanently deleted depending on UsePublicFolderRecycleBin parameter value. New migration project parameter UsePublicFolderRecycleBin is introduced in this release. This parameter is intended for public folder synchronization using MAgE / MMExPowerShell module. It specifies whether public folders matched with deleted (soft or hard ) public folders will be stored in Migration Manager Recycle Bin public folder. Migration Manager Recycle Bin public folders are now created automatically, if necessary. For more information on migration project parameters, refer to Configuring Migration Using PowerShell. Scope: All migration scenarios supported by MAgE | MMEX-8005, MMEX-8382, MMEX-8082, MMEX-8383, MMEX-8657, MMEX-8006 |
The following is a list of issues resolved by this update.
Resolved issue | Issue ID |
The migration process may become abnormally slow with high SQL server CPU load. This situation is typical for migration projects with large amounts of data in ITEM_MATCH table. Scope: All migration scenarios supported by MAgE Root-cause: MAgE performs SQL queries without using the proper indexes. Fix: MAgE now uses proper indexes in SQL queries. | MMEX-8960 |
Feature | Enhancement | Issue ID |
General | Now Transport Layer Security (TLS) protocol support is enhanced to remove the limitation for the case where TLS 1.2 is the only enabled for Migration Manager for Exchange Database Server. Migration Manager for Exchange now fully supports environments where the version 1.2 is the only enabled version of TLS protocol. IMPORTANT: For environments where the version 1.2 is the only enabled for Exchange Database Server, the following additional software is required:
Scope: All migration scenarios | MMEX-8563 |
Resolved Issue | Issue ID |
MAgE may fail to get user settings for some email addresses. The following error message is reported:
Error Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (404) Not Found.
Scope: All migration scenarios supported by MAgE Root-cause: X-AnchorMailbox header was not included in request when connecting to Autodiscover to retrieve mailbox settings for synchronization initiation. Fix: MAgE now includes the X-AnchorMailbox header in the request when it connects to Autodiscover to avoid the issue for all mailboxes. | MMEX-8465 |
Feature | Enhancement | Issue ID |
General | Due to deprecation of MAPI/CDO library it is no longer required to be installed. Scope: All migration scenarios | MMEX-8272 |
Feature | Enhancement | Issue ID |
General | Logging has been improved to provide the identifier of the source object and the identifier of the target in case the object found by MAgE using X500 (equal to the source LeDN) on the target is not included in the Directory Synchronization project and the trace is logged, e.g.,: Source guid: 2c98a8a6-de46-4e8d-b97e-932f5803d1cb, matched guid: 192142fb-85da-4823-b7d9-d0bdbfb94c94, DirectoryId from ResolveNames: 5c8f1494-b217-4f8f-9bc0-8af3b4e77011...This data may be useful for troubleshooting purposes. TIP: If according to the trace, object GUIDs do not match, the following workaround can be used for proper re-matching objects:
Scope: | MMEX-7614 |
Public Folder Synchronization by MAgE | MAgE now can automatically handle public folder moving, moved public folders will be detected, and then structure will be synchronized depending on synchronization direction option selected. Refer to Public Folder Synchronization (MAgE) document for details. | MMEX-7371 |
Resolved issue | Issue ID |
The mailbox that has been already switched may be set to unswitched state unexpectedly. Scope: Calendar synchronization by MAgE to Office 365 Root-cause: If any exception occurs, the mailbox can be considered as not existing, and then Migration Agent for Exchange will initiate provisioning of the mailbox that results in changing mailbox status. Fix: The mailbox detection algorithm is now improved. MAgE considers the mailbox state and autodiscover response to avoid the issue. | MMEX-7840 |
Feature | Enhancement | Issue ID |
General | The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-7697 |
Now specific message classes can be skipped on collection level during migration using PowerShell. This release introduces the New-MMExMessageFilter cmdlet to create message filters for mail, calendar, and public folder collections and new MessageFilter parameter for Set-MMExCollection cmdlet. For more information about MessageFilter parameter for Set-MMExCollection cmdlet, refer to Configuring Migration Using PowerShell | MMEX-5698 | |
The Migration Manager for Exchange PowerShell Module can now be accesses from Start menu. | MMEX-2077 | |
Public folder migration to Microsoft Exchange 2019 using legacy public folder agents is now supported. Refer to Target Exchange 2019 Environment preparation document for details. | MMEX-7830 | |
Public Folder Synchronization by MAgE | Public Folder synchronization now can be started in express mode with minimal customization using Start-MMExPublicFolderMigration cmdlet. For more information, refer to Public Folder Synchronization (MAgE) document for details. | 7384 |
MAgE now can automatically handle public folder renaming in the source, renamed public folders will be detected and then will be renamed in the target by MAgE. | MMEX-7284 | |
Sync-MMExMailPublicFolder is enhanced to synchronize custom attributes and public folder mailbox visibility in the GAL, as well as to unconditionally copy legacyExchangeDN of each source public folder as an X500 address for migrated target public folder. For more information, refer to Public Folder Synchronization (MAgE) document. | MMEX-7535 |
Resolved issue | Issue ID |
MAgE may be unable to switсh a mailbox, and the following error message is reported Error System.Web.Services.Protocols.SoapException: The account does not have permission to impersonate the requested user. Scope: Manual and automatic mailbox switch to Office 365 by MAgE Root-cause: Changes in Microsoft Office 365 processing procedures. Fix: Now MAgE is enhanced to avoid the issue in switch procedure. | MMEX-7790 |
Native Move job may fail, and the the following error message is reported Parameter set cannot be resolved using the specified named parameters. Scope: Mailbox migration using the Native Move job Root-cause: Due to target mailbox database switchovers or failovers during Native Move job processing Mage may connect to wrong server. Fix: Now the mechanism of server selection for move request after switchover or failover of target mailbox database is enhanced to avoid the issue. | MMEX-7248 |
Public folder synchronization using Initialize-MMExPublicFolderMigration cmdlet with correct parameters fails, and the following error message is reported The operation couldn’t be performed because object <domain>\<user> couldn’t be found on <DC FQDN>. Scope: Public folder synchronization from Exchange 2010 to Microsoft Office 365 by MAgE Root-cause: Initialize-MMExPublicFolderMigration cmdlet fails to initiate Public folder synchronization in case service account and source Microsoft Exchange 2010 server are located in different domains. Fix: Now MAgE is enhanced to process entire forest structure. | MMEX-7687 |
Feature | Enhancement | Issue ID |
General | The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-7697 |
Now specific message classes can be skipped on collection level during migration using PowerShell. This release introduces the New-MMExMessageFilter cmdlet to create message filters for mail, calendar, and public folder collections and new MessageFilter parameter for Set-MMExCollection cmdlet. For more information about MessageFilter parameter for Set-MMExCollection cmdlet, refer to Configuring Migration Using PowerShell | MMEX-5698 | |
The Migration Manager for Exchange PowerShell Module can now be accesses from Start menu. | MMEX-2077 | |
Public Folder Synchronization | Public Folder synchronization now can be started in express mode with minimal customization using Start-MMExPublicFolderMigration cmdlet. Refer to Public Folder Synchronization (MAgE) document for details. | MMEX-7384 |
MAgE now can automatically handle public folder renaming in the source, renamed public folders will be detected and then will be renamed in the target by MAgE. | MMEX-7284 | |
Sync-MMExMailPublicFolder is enhanced to synchronize custom attributes and public folder mailbox visibility in the GAL, as well as to unconditionally copy legacyExchangeDN of each source public folder as an X500 address for migrated target public folder. For more information, refer to Public Folder Synchronization (MAgE) document. | MMEX-7535 |
Resolved issue | Issue ID |
MAgE may be unable to switсh a mailbox, and the following error message is reported Error System.Web.Services.Protocols.SoapException: The account does not have permission to impersonate the requested user. Scope: Manual and automatic mailbox switch to Office 365 by MAgE Root-cause: Changes in Microsoft Office 365 processing procedures. Fix: Now MAgE is enhanced to avoid the issue in switch procedure. | MMEX-7790 |
Native Move job may fail, and the following error message is reported Parameter set cannot be resolved using the specified named parameters. Scope: Mailbox migration using the Native Move job Root-cause: Due to target mailbox database switchovers or failovers during Native Move job processing Mage may connect to wrong server. Fix: Now the mechanism of server selection for move request after switchover or failover of target mailbox database is enhanced to avoid the issue. | MMEX-7248 |
Public folder synchronization using Initialize-MMExPublicFolderMigration cmdlet with correct parameters fails, and the following error message is reported The operation couldn’t be performed because object <domain>\<user> couldn’t be found on <DC FQDN>. Scope: Public folder synchronization from Exchange 2010 to Microsoft Office 365 by MAgE Root-cause: Initialize-MMExPublicFolderMigration cmdlet fails to initiate Public folder synchronization in case service account and source Microsoft Exchange 2010 server are located in different domains. Fix: Now MAgE is enhanced to process entire forest structure. | MMEX-7687 |
System Requirement Change | Issue ID |
The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-7060 |
Microsoft Windows Server 2019 can now be used as agent host for legacy public folder agents. | MMEX-7006 |
Quest Migration Manager Console can now work with Microsoft Windows Server 2019. | MMEX-6739 |
Quest Migration Manager Console can now work with Microsoft SQL Server 2017. | MMEX-6739 |
Resolved issue | Issue ID |
MAgE is unable to switсh a mailbox. Scope: Mailbox switch/unswitch from Exchange 2010-2016 to Office 365 by MAgE, in case External EWS URL is unavailable Root-cause: Migration Manager for Exchange will always choose external EWS URL at first even it is unavailable. Fix: Now the EWS URL selection algorithm is enhanced and IsExternal flag is used to define the EWS URL to connect. | MMEX-6770 |
Ready to switch status for migrated mailbox cannot be achieved if there are any folders of IPM.ApplicationData class on the source. Scope: All migration scenarios supported by MAgE Root-cause: MAgE considers migration of folders of IPM.ApplicationData class as required to achieve the Ready to switch status for migrated mailbox. Fix: New parameter FolderClassesToSkip is introduced in this release for cmdlet Set-MMExProjectOptions. Now folders with class "IPF.Files" and "IPM.ApplicationData" are skipped by default and this cannot be overridden by the FolderClassesToSkip parameter. For more information, refer to Configuring Migration Using PowerShell. | MMEX-6768 |
Enhancement | Issue ID |
Now specified mailboxes can be temporarily excluded from the migration process using Powershell cmdlet. This release introduces the Suspend-MMExMailboxMigration and Resume-MMExMailboxMigration cmdlets to perform suspend and resume mailbox migration. NOTE: These cmdlets could be useful for troubleshooting purposes. These operations complement the functionality of the Disable collection option implemented in the user interface. Suspended mailbox will not be processed even if corresponding collection is Enabled. For more information, refer to Configuring Migration Using PowerShell. | MMEX-6433 |
Resolved issue | Issue ID |
MAgE fails to create New-MoveRequest or to perform automatic switch of the mailbox with the following error message: Error 0xe1000005. Internal DSA error.
Scope: All migration scenarios supported by MAgE, in case standalone server is acting as agent host, and neither Console nor Directory Synchronization Agent (Directory Migration Agent) is installed. Root-cause: After public update 20181130EX was installed, MBRedir.dll and QsCore.dll were not updated automatically. Fix: Now these components are updated automatically. | MMEX-6664 |
Enhancement | Issue ID |
Now migration can be restarted for specified mailbox using Powershell. This release introduces the Restart-MMExMailboxMigration cmdlet to perform this operation. NOTE: This operation is also known as Resync in user interface. For more information, refer to Configuring Migration Using PowerShell. | MMEX-5986 |
Resolved issue | Issue ID |
Specific Search Folders created outside of the well-known location for user-created Search Folders may not be synchronized by Migration Manager for Exchange correctly.
Scope: Migration from Exchange 2010 or later in case UseEwsProtocolForSourceIfAvailable is set to True Root-cause: Unlike the user-created Search Folders that are processed by Client Profile Updating Utility, necessary information about the search folders created by some third-party applications cannot be retrieved due to Microsoft limitations and hangs the processing. Fix: Processing of folders with Search Folder Type will be skipped under migration process to avoid the issue. | MMEX-6322 |
In case of specific proxy server configuration the migration session may fail with the following error message: Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (403) Forbidden. | at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverRequest.InternalExecute....
Scope: All migration scenarios supported by MAgE. Root-cause: MAgE cannot connect to some instances of Exchange servers in case of specific proxy server configuration. Fix: Now agent has been enhanced to avoid the issue. | MMEX-6475 |
Quest Migration Manager for Exchange can now function in Microsoft Windows environments where FIPS 140 revision 2 ( FIPS 140-2) mode is enabled. FIPS 140-2 compliant algorithms will be used for all security related purposes in projects created after installation of this update. For more information about FIPS 140-2 mode refer to System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.
The following is required to support new feature introduced by this release:
Note: The FIPS 140-2 environment support cannot be ensured in all projects created before this update is installed.
Enhancement | Issue ID |
The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-5740, MMEX-5605 |
Due to discontinuation of support for Transport Layer Security (TLS) versions 1.0 and 1.1 soon in Microsoft Office 365 as declared in Preparing for the mandatory use of TLS 1.2 in Office 365, Migration Manager for Exchange components are modified to work with Microsoft Exchange Servers or with Microsoft Office 365 where Transport Layer Security (TLS) version 1.2 is enabled.
Known limitation: Migration Manager for Exchange Console may not work with SQL Servers where the version 1.2 is the only supported version of Transport Layer Security (TLS) protocol.
To support this new feature, system requirements are changed for the following servers:
For details, please refer to the System Requirements and Access Rights document.
Enhancement | Issue ID |
Overall migration processing is optimized to avoid PowerShell throttling limits in Office 365. Now Remote Windows PowerShell is no longer used by MAgE to verify every mailbox during every session, and multiple remote PowerShell sessions are not created every time. All required checks are performed through the use of Exchange Web Services (EWS). MAgE uses only the Microsoft Online Services Sign-In Assistant to assign subscription plan for new mailbox. Due to this enhancement the administrative account used for mail and calendar synchronization processing is not more affected with the Exchange Online PowerShell throttling in Office 365. It is no longer necessary to create multiple administrative accounts for calendar synchronization and mailbox migration collections to avoid PowerShell throttling issues. Scope: Migration to Microsoft Office 365 | MMEX-4997 |
Enhancement | Issue ID |
Get-MMExCollection, Get-MMExCollectionStatistics, Get-MMExMailboxStatistics cmdlet usage is now enhanced to increase usability.
Get-MMExCollectionStatistics and Get-MMExMailboxStatistics can take input submitted through the pipeline from Get-MMExCollection. Type and Name parameters now become optional for these cmdlets. Refer to
Configuring Migration Using PowerShell for details and examples. Scope: All migration scenarios supported by MAgE | MMEX-4669 |
Resolved issue | Issue ID |
PFTA fails to restore some messages during backward synchronization. PFTA log file contains the following error message: CopyFromPST Error -2147221246 The client operation failed. - MAPI_E_NO_SUPPORT (Microsoft Exchange Server Information Store) File: 'aeCopyProp.cpp' Line: '95' (Subject: 'D9B98D6E3C1210428DC3C95F2D6FCF78000000F28A25', SourceKey: 'D9B98D6E3C1210428DC3C95F2D6FCF78000000F28A25').
Scope: Public folder synchronization to Microsoft Office 365 Root-cause: The values of some properties, for example PR_CREATOR_ENTRYID, can be incorrectly determined by PFTA for some messages and, as result, these messages cannot be restored. Fix: Now message handling has been enhanced to avoid the issue. | MMEX-5061 |
Enhancement | Issue ID |
The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-4475 |
Remote Windows PowerShell usage is now optimized. MAgE now calls required cmdlets directly with Invoke-Command instead of importing a remote PowerShell session with all Exchange Online cmdlets. Scope: Migration to Microsoft Office 365 | MMEX-4715 |
Resolved issue | Issue ID |
MAgE may fail to process the folder with description containing restricted characters and the migration cannot be completed.
Scope: All migration scenarios supported by MAgE, in case UseEwsProtocolForSourceIfAvailable is set to True Root-cause: Target Exchange server cannot accept EWS request containing characters restricted in XML 1.1 specification. For details see https://www.w3.org/TR/2006/REC-xml11-20060816/#charsets. Fix: Now the restricted symbols in folder description are detected by MAgE and are replaced with “?” to ensure successful folder processing. | MMEX-3593 |
Mailbox included in any collection may not be resynced after re-enabling the collection.
Scope: All migration scenarios supported by MAgE Root-cause: Pending mailbox resync may be cancelled in case the collection containing the mailbox was disabled and then enabled again. Fix: Now pending resync is handled properly in this case. | MMEX-2657 |
PFTA may fail to assign public folder client permissions during synchronization. PFTA log file contains the following error message: CFolder::CopyFromPST Error -2147467259 The client operation failed. - MAPI_E_CALL_FAILED (Microsoft Exchange Information Store) File: 'aeMAPIFolder.cpp' Line: '2554' (Folder: 'TestPublicFolder', SourceKey: '9D9547CA873429449B988E70C779926E00002F9E9998').
Scope: Public folder synchronization to Microsoft Office 365 Fix: Now public folder client permissions assignment has been enhanced to avoid the issue. | MMEX-4636 |
Mailbox status In Progress or Switched (Sync Pending) remains unchanged. Mailbox Statistics
pane contains the following error message in Most recent error column: FolderInfo is not found in database.
Scope: All migration scenarios supported by MAgE Root-cause: MAgE cannot correctly process mailbox in case the folder hierarchy is changed in some unusual ways after the folders have been synchronized. For example, one of well known folders might have been deleted from source mailbox for unknown reason. Fix: Now these well-known folder changes are processed to ensure successful mailbox synchronization. | MMEX-4490 |
Mailbox status In Progress or Switched (Sync Pending) remains unchanged. Mailbox Statistics
pane contains the following error message in Most recent error column: The folder 'Contacts' was not processed. Messages in folder: '2'. Probably the given folder does not exist in target mailbox. If the problem is persistent, please resync mailbox with ClearAllSyncDataOnResync.
Scope: All migration scenarios supported by MAgE Root-cause: MAgE cannot correctly process folders in case the folder hierarchy is broken in some unexpected ways after the folders have been synchronized. For example, one of well known folders may not exist in target mailbox for unknown reason. Fix: Now the missing folders will be created in target to ensure successful mailbox processing. | MMEX-4252 |
Enhancement | Issue ID |
Project database design is enhanced to significantly drop the CPU utilization in some specific cases. Scope: All migration scenarios in case a considerable part of messages should not be migrated according to filter configuration. IMPORTANT: This hotfix affects only new databases that will be created after the hotfix is installed. | MMEX-4293 |
The set of granular permissions is defined for Service Accounts that are used for data migration to Microsoft Office 365. You do not need to perform any permission changes for existing projects. You can create new accounts as previously, or use only the granular permission set. For more information, refer to https://support.quest.com/technical-documents/reference-materials-for-migration/8.14/migrating-to-microsoft-office-365/beforeyou-begin/preparing-microsoft-office-365-environment/creating-office-365-administrative-accounts. Scope: Migration to Microsoft Office 365 | MMEX-4239 |
Resolved issue | Issue ID |
Clicking Show Associated Collections option after the host or agent is selected in the Agent Management tree view generates the following error message: The method or operation is not implemented.
Scope: Migration to Microsoft Office 365 Fix: Now selecting the Show Associated Collections displays the list of associated collections. | MMEX-4326 |
Some messages can be filtered improperly under migration.
Scope: All migration scenarios supported by MAgE Root-cause: Message class handling procedure is not case insensitive. The message class names were specified on Filters page in collection properties using incorrect letter case. Fix: The message class handling procedure has been enhanced to avoid the issue. Now, for example, IPM.Note class is handled on the same manner as ipm.note class. | MMEX-4117 |
The primary SMTP address may be changed unexpectedly in some environments after switch.
Scope: Migration to Microsoft Office 365 Root-cause: TargetAddress property of source object is stamped with primary SMTP instead of secondary smtp after switch. Fix: Now the TargetAddress property processing is enhanced and does not affect user experience. | MMEX-4263 |
Quest Migration Agent for Exchange MAPI Assistant COM+ components still use "Dell" as a prefix.
Scope: All migration scenarios Fix: Now the COM+ components do not have "Dell" in their names. | MMEX-4242 |
Enhancement | Issue ID |
Logging has been improved to display some events that were marked as warnings but have no impact on migration process using Info status. Scope: All migration scenarios supported by MAgE in case MAPI is used for migration source | MMEX-3063 |
Considering the latest changes incorporated by Microsoft, possible issues related to the endpoint ConnectionUri used for connecting to the
Microsoft Office 365 tenant using PowerShell have been prevented. The recommended https://outlook.office365.com/powershell-liveid/ ConnectionUri
value is used instead of obsolete https://ps.outlook.com/powershell/ Scope: Microsoft Office 365 migration scenarios | MMEX-3133 |
Mailbox processing is now enhanced to avoid multiple errors related to cmdlet failure in Event Log of the Microsoft Exchange server.
Below you can see example of the error: Log Name: MSExchange Management Source: MSExchange CmdletLogs Event ID: 6 Task Category: General Level: Error Keywords: Classic User: N/A Description: Cmdlet failed. Cmdlet Get-ExchangeServer, parameters -Identity "YourDatabaseAvailabilityGroup" -ErrorAction "SilentlyContinue". Scope: All migration scenarios supported by MAgE in case SupportADSyncThroughThirdPartyTools is set to True | MMEX-3891 |
To improve supportability for very slow Public Folder synchronization processes (considerably less than 1 GB per hour), new functionality
has been introduced. Now, for working with Exchange 2013, you can manually set the Public Folder synchronization agents to use local XML file settings to connect to Public Folder Administrator mailbox. For more information see the following KB article:
https://support.quest.com/migration-manager-for-exchange/kb/235311 Scope: Public Folder synchronization to or from Microsoft Exchange 2013 | MMEX-3652 |
Resolved issue | Issue ID |
Mailbox remains in the In Progress state with unchanging percentage value in progress column with the following message in the MAgE log: The property has an invalid value. Scope: All migration scenarios supported by MAgE Root-cause: This error may be received from Exchange in case MAgE is retrieving large property set. Fix: Now property set retrieving procedure has been optimized to avoid the issue. | MMEX-3825 |
Migration process can be stopped. The following error is displayed: System.Management.Automation.Remoting.PSRemotingTransportException:
Connecting to remote server failed with the following error message : [] Access Denied. For more information, see the about_Remote_Troubleshooting Help topic. Scope: Migration to Microsoft Office 365 Root-cause: If Configure Office 365 setting page in collection property has been reviewed, it is possible that the previously provided password information stored in the project database may be corrupted. As a result, the Access Denied error can appear. Fix: Password processing for custom Microsoft Online Services ID account has been improved to avoid the issue. | MMEX-3916 |
Enhancement | Issue ID |
Microsoft SQL Server 2016 is now completely supported as a Migration Manager for Exchange Database Server. | MMEX-3554 |
The following Exchange versions have been verified and confirmed as completely supported migration sources and targets:
| MMEX-3461 |
Folder-level permission processing performance is now improved by using cached information about matched users for setting permissions on mailbox folders. Scope: All migration scenarios supported by MAgE. | MMEX-3308 |
Resolved issue | Issue ID |
Public Folder Target Agent fails to synchronize some specific client permissions and messages to O365 with the following error in log: CAddrBook::Resolve Error -2147220477 Too many names have been found in the directory service or the server has exceeded its time limit for searching. Type more letters of the name and try again. - MAPI_E_TABLE_TOO_BIG (Microsoft Exchange Address Book) Low level error: 0x0 File: 'aeaddrbook.cpp' Line: '512'
Scope: Public folder synchronization to Microsoft Office 365 Root-cause: Permissions and messages for source users that have not matched target users, added to AD migration project. Fix: Now the permissions and messages are processed correctly for all users. | MMEX-3426 |
Migration process is not started for new mailboxes with the following message: Error Microsoft.Exchange.WebServices.Data.AutodiscoverLocalException: The Autodiscover service couldn't be located. Exchange 2010 SP1 is displayed in the log file instead of correct Exchange 2003 version.
Scope: Migration from Exchange 2003 after installing the following Migration Manager for Exchange updates:
Root-cause: Soft fault of exchange server version identification algorithm. Fix: Exchange server version identification algorithm is now fixed. After installing this update all mailboxes will be processed correctly. | MMEX-3399 |
In case target service account has been changed the custom Notification Message may be reset to default. Scope: All migrations to on-premises Exchange organizations supported by MAgE Root-cause: Migration Manager console can rewrite Notification Message to default text in case any Mailbox synchronization job properties has been changed. Fix: Now Migration Manager console does not reset custom Notification Message in case the job property changing. | MMEX-3379 |
Enhancement | Issue ID |
Manual and automatic mailbox switch procedures are now improved by means of using cached URL, if any, for connecting to target mailbox via EWS instead of using Exchange Autodiscover service. Scope: All on-premises migration scenarios supported by MAgE | MMEX-3314 |
In order to deal with security concerns all the downloadable package executables are now signed with SHA2 certificates and can be downloaded as the signed self-extracted archive. | MMEX-3179 |
Now users can see the detailed information of migrated Contact Group members using OWA access in case these members are matched and were added to Contact group from Outlook Contacts. Scope: Migration scenarios supported by MAgE from Exchange 2010 at source to Exchange 2013 or Exchange 2016 at target and SupportADSyncThroughThirdPartyTools is set to True | MMEX-3020 |
Resolved issue | Issue ID |
MAgE may sync mailbox to wrong target mailbox if several mailboxes in target have the same X500 address (set by mistake) with Source LEDN. Scope: All supported migration scenarios when a third-party tool is used for directory synchronization (SupportADSyncThroughThirdPartyTools is set to True) Root-cause: MAgE use for synchronization the first discovered target mailbox that matches the X500 address with source LEDN. Fix: Now in case several mailboxes have the same X500 address the migration process will be stopped with error message Several mailboxes in target have the same X500 address, correct X500 addresses for matching source and target mailboxes. | MMEX-3215 |
Mail-enabled root public folder became hidden from the Global Address List.
Scope: Two-way public folder synchronization of root public folders in case of HiddenFromAddressListsEnabled attribute is set to False Root-cause: Public Folder Source Agent incorrectly processes HiddenFromAddressListsEnabled attribute. As a result root public folder became hidden from the Global Address List after backward sync. Fix: Now the HiddenFromAddressListsEnabled attribute of mail-enabled public folders is processed correctly for all folders, including root public folders (as specified in public folder synchronization collections). IMPORTANT: Mail settings for Public Folders are synchronized according to Advanced Agent Management option selected. | MMEX-3123 |
The Error during check connect to database or update version database message can appear when you try to run Migration Manager Console after installing of 20170630EX product update. Scope: Mailbox migration using the Native Move job. Projects where the EXCH_SERVER_PROPERTY table of SQL database was improperly edited by user (e.g. under Running Native Move with MMEX when Load Balancers are used in source or target Exchange organizations) Root-cause: Previous version of UpdateDB.sql cannot process such EXCH_SERVER_PROPERTY table entries. Fix: Now the SQL database updating procedure was improved to process such entries correctly. | MMEX-3014 |
Under new legacy agent installation to the Agent Host, console does not automatically install updates for legacy agents, if any. Scope: All supported migration scenarios with legacy agents, including public folder synchronization Root-cause: Incorrect update verification procedure for automatic agent installation. Fix: Now automatic agent installation means legacy agent will be installed with the latest update. Additionally the latest update can be installed manually. | MMEX-2841 |
The Object reference not set to an instance of an object message can appear in case restarting of Migration Manager Console after agent host deleting. Scope: All supported migration scenarios Root-cause: Agent host can be deleted from Agent Management in specific case of agent instance installed on it is assigned as the Default agent for any synchronization job. Fix: Now the agent host deletion processing have been modified to avoid the issue. Agent host cannot be deleted from Agent Management in the case of agent instance installed on it is involved in some job. To remove the agent host from database using Agent Manager, you need to delete all associations with this server in mailbox and calendar synchronization collections, and replace it in the Default Collection Options | Default agent settings of each affected mailbox/calendar synchronization job. | MMEX-2700 |
Mailbox migration process may hang for the specific mailbox (other mailboxes in the collection are correctly processed.) The following error is displayed: Operation is not valid due to the current state of the object. Scope: All migration scenarios supported by MAgE Root-cause: The problematic mailbox contains the message that is very close to the maximum size allowed by Migration Manager for Exchange settings (specified in SizeLimitInMbPerBatchUploadToO365, SizeLimitInMbPerBatchUploadToExchange.) In some cases, it may result in producing MAgE batch that exceeds the maximum allowed size. Fix: MAgE now try to upload messages with critical size to target mailbox. In case this attempt will be unsuccessful due to target Exchange settings, the error returned with target Exchange will be logged. | MMEX-2314 |
Feature | Enhancement | Issue ID | ||||
General |
|
Resolved issue | Issue ID |
Migration from partly supported Exchange Server versions (Exchange 2010 prior to SP2 and from Exchange 2013 prior to SP1) is not allowed. Scope: Migration from Exchange 2010 prior to SP2 and from Exchange 2013 prior to SP1. Root-cause: Exchange Server version detection procedure cannot handle Exchange 2010 prior to SP2 and Exchange 2013 prior to SP1 correctly. Fix: Now migration from partly supported Exchange Server versions (Exchange 2010 prior to SP2 and from Exchange 2013 prior to SP1) is allowed. | MMEX-2675 |
Mailbox cannot be switched in case of target Office 365 or Exchange 2013 (or later) does not have Public Folder mailbox.
Scope: Migration scenarios supported by MAgE to Microsoft Office 365 or Exchange 2013 (or later) without Public Folder mailbox in target. Root-cause: Mailbox cannot be switched successfully in case the TargetPublicFolderEMailAddress property is empty. Fix: Now mailbox switch does not depend on Public Folder mailbox presence in target. | MMEX-2546 |
Display Name is not shown in migrated contacts at target only for users who access them using Outlook Web Access. Scope: Migration scenarios supported by MAgE from Exchange 2010 at source to Exchange 2013 or higher at target, in case of UseEwsProtocolForSourceIfAvailable is set to True (default value). Root-cause: Issue is caused by property set differencies between Exchange 2010 and Exchange 2013 or higher only in case of Outlook Web Access is used. Fix: Display Name is now generated and displayed correctly for Outlook Web Access. | MMEX-2495 |
Manual mailbox switch may be unsuccessful for particular cases of load balancer solutions at target. Scope: Mailbox migration in case of load balancer solutions in target Exchange environment, in case of SupportADSyncThroughThirdPartyTools is set to True. Root-cause: By default, PowerShell session is created with the Exchange server that has been used to add the target Exchange organization. In case of load balancer solutions the FQDN of the target Exchange server cannot be found and need to be specified manually for successful completion of manual mailbox switch. Fix: PSConnectionServer now also specifies FQDN of the target Exchange server or load balancer to find target mailbox information for manual switch. | MMEX-2494 |
PFTA restarting in case of exceeding the default system handles limit of 1500 can slow down migration process. Scope: Public folder synchronization using Outlook 2016 to Exchange 2016 or Microsoft Office 365 Root-cause: PFTA restarts automatically upon reaching or exceeding the maximum default value of 1500 system handles. Fix: Now the default value of system handles is increased up to 3000 for all legacy agents to avoid the situation. | MMEX-2313 |
PFTA stops processing when it tries to compact PST file in case of content cannot be fully synchronized. The last log message is the following: MailContainer::Compact TraceMsg 1702 Starting to compact PST file. Scope: Public Folders migration to Exchange 2016 Fix: Now the PST file compacting and archiving completes successfully and does not stop migration process. | MMEX-1769 |
Ready to switch status for migrated mailbox cannot be achieved if there are any folders of IPF.Files class at source. Scope: Mailbox migration from Exchange 2016 Root-cause: MAgE consider the migration of folders of IPF.Files class as required to achieve the Ready to switch status for migrated mailbox. Fix: Any folder of IPF.Files class including subfolders will be skipped under migration process to avoid the situation. | MMEX-1727; PT143029371 |
Migration Manager for Exchange is configured to assign a license of subscription A, but MAgE fails to assign that license to a Microsoft Office 365 user who already has a license of subscription B.
Scope: All migrations to Office 365 Root-cause: MAgE was not configured to assign selected license in case of Microsoft Office 365 user had multiple licenses from different subscription plans, and by default the license that is already registered in project is used. Fix: To use improved license assigning mechanism of MAgE for multiple license usage is recommended to reconfigure subscription settings through Migration Manager console UI. | MMEX-1722; PT142210619 |
If JunkEmail is specified in the list of WellKnownFoldersToSkip (see details at Configuring Migration Using PowerShell) mailbox processing might hang at migration stage "In Progress" and so can’t be switched automatically. A message The folder 'Junk-E-Mail' was not processed. Messages in folder: '2'. Probably the given folder does not exist in target mailbox. If the problem is persistent, please resync mailbox with ClearAllSyncDataOnResync. is displayed. Scope: Mail synchronization jobs at the following scenarios:
MAgE mechanism to detect JunkEmail folder might fail under the certain circumstances. Fix: To avoid the issue MAgE mechanism for detecting JunkEmail was improved. | PT143310703 |
The following known issue exists at the time of the update release:
Defect ID | Issue Description |
N/A | After this update is installed, your migration project cannot be opened, and the following error message is reported: Cannot retrieve SQL connection properties.
After launching Migration Manager for Active Directory, if you go to Project | Open Project, the tabs, beginning with Set Auxiliary Account... are grayed out.
QuestMM.log (located in %ProgramFiles%\Quest Software\Migration Manager\Active Directory) contains the following error message: AMMProjectLib.AMMProject.1 System.String get_DefaultUser() Error 0 System.NullReferenceException: Invalid pointer
at AMMProjectLibLib.AMMProjectClass.get_DefaultUser() at Quest.MigrationManager.OpenProjectWizard.AgentsCredentials.Fill(AMMProject prj, AMMProjects prjs, Boolean ReadOnly) Scope:
Migration project is not properly configured. Workaround: Refer to KB 291530 for instructions on how to resolve the issue. Contact Quest Support in case you have any issues. |
Product name | Version | Platform |
Migration Manager for Exchange | 8.14 | All supported |
The following files are shipped:
To install the update, complete the following steps:
NOTE: During the Repair operation for an instance of MAgE agent or for the certain agent role, this update will be installed on all instances of all MAgE agent roles that reside on the agent host.
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 provides software solutions for the rapidly-changing world of enterprise IT. We help simplify the challenges caused by data explosion, cloud expansion, hybrid datacenters, security threats, and regulatory requirements. We are a global provider to 130,000 companies across 100 countries, including 95% of the Fortune 500 and 90% of the Global 1000. Since 1987, we have built a portfolio of solutions that now includes database management, data protection, identity and access management, Microsoft platform management, and unified endpoint management. With Quest, organizations spend less time on IT administration and more time on business innovation. 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:
© 2020 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.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center