Issues when Migrating Exchange

Oct. 8th 2015

Error 2060 When Running Public Folders Sync Job


Public folder Sync job is configured and running using legacy agents. During the sync, error 2060 “ImportPF Error 2060 Public store was not found on the current server” is showing up in the logs. Public Folders exist in the target and all the necessary rights are granted and working correctly.


This is a replication issue. Check whether the administrative mailbox specified for the public folder synchronization job is associated with public store on the same Exchange server. In this case, the Public Folder was homed to another server that did not have the Admin mailbox. Once this was changed, the Sync Job was able to find the PF database and import the contents from the source.


MaGE Native Move Error “Invalid situation the version of source or target side is not supported”


Client is migrating from Exchange 2007 to 2007 with an Exchange 2010 CAS server in the target organization. During configuration of the MaGE agent the following error occurs in the console:

“Invalid situation the version of source or target side is not supported”


Documentation states that as long as there is a 2010 CAS server in the organization, Native Move can be used to migrate mailboxes. However, this is not entirely correct. Because the MaGE agent is using the native move PowerShell cmdlet in Exchange 2010, it expects the target mailboxes to reside on a 2010 database server. Since the mailboxes were being hosted on a 2007 server in the target, this was not possible. Legacy agents were then set up and configured and mailboxes were migrated without incident.


Mail Items Missing After Switch to Target


Client users are stating that email is missing from their new target mailbox. Checked Mail Agent logs for any sync errors and attempted to perform a full resync of mailbox from Source to Target. Migration Manager Statistics and logged in comparisons of source to target show mailbox sizes to be the same.


While troubleshooting, it was revealed that 5 months earlier there had been a catastrophic failure of the source mail server and the server had been recovered through via recovery group. The OSTs had been preserved during this process and was found to contain the missing mail. Using a 3rd party utility to convert the backup OST to a PST, the client was able to import mail items to the new target mailbox.


Posted by bc-admin | in Migration Manager for Exchange | Comments Off on Issues when Migrating Exchange

Migration Manager – Office 365 Preparation

Aug. 29th 2014

Migration Manager – Office 365 Preparation

Office 365 provides many services for organization wide communication and productivity.  With the growing maturity of the Office 365 product, many organizations are migrating their email and instant messaging services from on premise solutions to cloud (hosted) based solutions.  To aid in this migration, Dell Migration Manager is able to assist in performing the Exchange Migration from on premise Exchange to Office 365 successfully.

There are some preparations that are needed to the Office 365 Tenant before it may be used as part of a migration project within Dell Migration Manager.

Configure Domains in Office 365

This step will enable your migration domains as an accepted domain within the Office 365 Tenant.  With these domains present in the Office 365 configuration, Migration Manager will be able to propagate the source email address to the Office 365 mailbox.

The Steps in adding a managed domain in Office 365 are:

  1. Navigate to Admin->Office365->Domains->Add a domain
  2. Enter your domain name and click next
  3. Verify your domain ownership by creating a TXT record in your public facing DNS using the information provided in the wizard screen. (An MX record may be used instead of a TXT record, but the TXT record is the safer method)
  4. Once the DNS entry has been added and propagated, click the Done, Verify Now button.

You can also use the PowerShell cmdlet New-MsolDomain to add your domains.  See for information on how to use the cmdlet.

Create Admin Accounts

Migration Manager needs three Admin account to perform its tasks. The three Admin accounts are for provisioning accounts, synchronizing calendars, and migrating mailboxes. An Exchange Online license will be required for each of these accounts. The next step is to launch PowerShell and ensure that unsigned scripts may be executed. This is accomplished with the command:

Set-ExecutionPolicy -Execution Policy Unrestricted

If this command fails because of permissions, close PowerShell and run PowerShell as administrator.Now, the QMM module must be imported for usage. Navigate to <CD>\QMMEx ResKit\Scripts\CreateQSAdminAccountsInMSOL and execute the following command:

Import-Module .\CreateQSAdminAccountsInMSOLModule.ps1

Lastly, execute the following command to create the accounts from the CSV in Office 365:

Create-QSAdminAccountsInMSOL <CSV> <User> <Password> <Tenant domain>.onmicrosoft.comWhere <CSV> is the CSV file created containing the user accounts to be created. This must be specified fully qualified, i.e. C:\Temp\QMMAccounts.csv, or dot sourced, i.e. .\QMMAccounts.csv if the CSV is located in PowerShell’s current working directory.

The <User> and <Password> are credentials of a Global Administrator user that already exists in Office 365. The cmdlet will use these credentials to connect to and create the user accounts listed in the CSV.

Finally the <Tenant Domain> is the domain that is assigned to the Office365 tenant when it is created. All Office365 tenant have a domain such as this.

After executing this script, all the users specified in the CSV will be created in the Office 365 tenant with the Global Administrator and ApplicationImpersonation roles assigned.

NOTE: Three accounts is the minimum recommended number of accounts for an on premise to Office365 migration, but multiple account for the mailbox migration and calendar synchronization processes may be necessary for increasing the migration performance.


Configure Regional Settings for Admin Accounts

When the Global Admin accounts are created, they have no region information specified in them. If this is left un-configured, Migration Manager will report errors about the time zone being incorrect. This setting is assigned on a user by user basis and each of the Global Admin accounts above must be logged into individually to set their regional information. After the account is logged in, click the Outlook link at the top of the page and select the appropriate time zone and language for the account.


Disable Calendar Repair Assistant

When migrating with Migration Manager, the Calendar Repair Agent must be disabled for all mailboxes will be migrated for the entire duration of the migration. The following command will disable the CRA for all mailboxes in Office365:

Get-Mailbox -ResultSize Unlimited | Set-Mailbox -CalendarReparDisabled $true

The reason behind this step is that, because of Calendar Sync delay, the CRA will see that the user has accepted the meeting but the meeting does not appear on the users’ calendar.  Because of this, the CRA will add the meeting to the users’ calendar and this will result a duplicate calendar entry as soon as the sync creates the entry.

Of course the above command must be issued from the MSOL PowerShell interface

Once the steps above have been completed, the Office 365 Tenant will be ready for insertion into a QMMEX project as the destination.


Author: Russ Burden, Technical Architect, LeadThem Security

Posted by bc-admin | in Migration Manager for Exchange, Quest Migration Manager | Comments Off on Migration Manager – Office 365 Preparation

QMM 8.9 Automation Error *FIX

Aug. 21st 2013


Here is the Fix for this error:

If you are encountering an error in the public folder sync for some of the PST files

“PowerShellCmdExec::Init  Error  440  Automation error”

QUEST Article 101427

This hotfix only applies to exchange agents MTA,MSA,CSA in order to fix public folder agents you must

  1. Apply The hotfix
  2. Stop all Quest Services on the box with the issue
  3. Reinstall MAPi CDO
  4. Run QMMExInstallAssemblies.bat in the QMM install directory
  5. Reboot QMM Box that has the issue

Article By: Wayne Thompson, Exchange Architect






Posted by bc-admin | in Quest Migration Manager | Comments Off on QMM 8.9 Automation Error *FIX