migration

All posts tagged migration

Relinquishing job because the mailbox is locked

During a migration to Office 365 I had this issue. The migration of a mailbox was stalled several times with the following entry logged in the migration log Relinquishing job because the mailbox is locked. Sometimes this occurs only once but I have seen times that the mailbox will get stuck in this phase.

12/20/2013 9:24:08 AM [DB4PR04MB459] The Microsoft Exchange Mailbox Replication service ‘DB4PR04MB459.eurprd04.prod.outlook.com’ (15.0.842.8 caps:01FF) is examining the request. 12/20/2013 9:24:09 AM [DB4PR04MB459] Connected to target mailbox ‘Primary (4ca8eac9-f378-4e82-8d07-f984c64176e8)’, database ‘EURPR04DG029-db041’, Mailbox server ‘DB4PR04MB459.eurprd04.prod.outlook.com’ Version 15.0 (Build 842.0). 12/20/2013 9:24:09 AM [DB4PR04MB459] Connected to target mailbox ‘Archive (07121074-d871-4db9-9f4e-153010131a50)’, database ‘EURPR04DG029-db041’, Mailbox server ‘DB4PR04MB459.eurprd04.prod.outlook.com’ Version 15.0 (Build 842.0). 12/20/2013 9:24:14 AM [DB4PR04MB459] Connected to source mailbox ‘Primary (4ca8eac9-f378-4e82-8d07-f984c64176e8)’, database ‘MB_Others’, Mailbox server ‘CAS02.corp.local’ Version 14.3 (Build 158.0), proxy server ‘CAS01.corp.local’ 14.3.151.0 caps:05FFFF. 12/20/2013 9:24:15 AM [DB4PR04MB459] Connected to source mailbox ‘Archive (07121074-d871-4db9-9f4e-153010131a50)’, database ‘MB_Archives_Large’, Mailbox server ‘CAS02.corp.local’ Version 14.3 (Build 158.0), proxy server ‘CAS01.corp.local’ 14.3.151.0 caps:05FFFF. 12/20/2013 9:24:15 AM [DB4PR04MB459] Relinquishing job because the mailbox is locked. The job will attempt to continue again after 12/20/2013 9:29:15 AM.

When searching in Googl you will see several tips but most of them will point to TMG or a Firewall which will block the large amount of requests Office 365 sends because it thinks it’s unsafe. Microsoft has published a Knowledge Base article about this which you can find here.

The solution Microsoft offers is raising the value of the Custom Limit in the Flood Mitigation Settings. Microsoft will tell you to raise this number to a higher value but it depends on the amount of mailboxes how high you will configure this value.

TMG Flood Migration settings

Of course this is a nice solution but it might require the modification of the value multiple times. Despite this value will be applied to all IP addresses including those from evil users. There must be a nicer solution. A more suitable solution is to not apply the Flood mitigation settings to the IP addresses of Office 365.

To configure this it is recommended to create a computer group which contains the separate IP addresses and subnets which are being used by Office 365. In the image below you can see an example.

Floot Mitigation - IP Exceptions

For a complete overview of the IP addresses used by Office 365 you van visit the following pages:

Exchange Online Protection IP addresses
Office 365 URLs and IP address ranges

It is recommended to visit both pages and add the IP’s and subnets to the computer group. Once the group is created add the group to the IP Exceptions tab. Once the configuration has been activated in TMG you wille see that the migrations will continue and will not stop anymore. This last benefit has another benefit the migration of a mailbox will be completed faster.

During a cross-forest migration from Exchange 2003 to Exchange 2010 I found a nasty issue while migration a mailbox. The first 10% of the move request went OK but after that it failed. In the first 10% the mailbox is created, the folder structure is created and permissions are set on the folders.

I started looking in the event log as, by default, enough information is logged here to see why a move request failed and found the following event:

Mailbox move for ‘xxxxxxxxxxxxxxxxxxxxxx’ (d126705e-af4d-4aca-83c6-0ea443a2ad60) has failed.

Error code: -2147024809

MapiExceptionInvalidParameter: Unable to set properties on object. (hr=0x80070057, ec=-2147024809)

Diagnostic context:

    Lid: 18969   EcDoRpcExt2 called [length=363]

    Lid: 27161   EcDoRpcExt2 returned [ec=0x0][length=108][latency=0]

    Lid: 23226   — ROP Parse Start —

    Lid: 27962   ROP: ropSetProps [10]

    Lid: 17082   ROP Error: 0x80070057

    Lid: 30561 

    Lid: 21921   StoreEc: 0x80070057

    Lid: 27962   ROP: ropExtendedError [250]

    Lid: 1494    —- Remote Context Beg —-

    Lid: 26426   ROP: ropSetProps [10]

    Lid: 47113 

    Lid: 7915    StoreEc: 0x80070057

    Lid: 5263    StoreEc: 0x80070057

    Lid: 19768 

    Lid: 4559    StoreEc: 0x80070057

    Lid: 1750    —- Remote Context End —-

    Lid: 26849 

    Lid: 21817   ROP Failure: 0x80070057

    Lid: 25761 

    Lid: 1940    StoreEc: 0x80070057

    Lid: 25297 

    Lid: 21201   StoreEc: 0x80070057

Context:

Mailbox: Primary (d126705e-af4d-4aca-83c6-0ea443a2ad60)

Folder: ‘/Top of Information Store/Taken/xxxxxx’, entryId [len=46, data=00000000109014FD0A523641A2C3C55606B5EA8201006E5BA8745959BC4C9F7B175EAE3144A80000378F00370000], parentId [len=46, data=00000000109014FD0A523641A2C3C55606B5EA820100C0260BEE56B49E4981448625D74A5AAB0000000400470000]

Operation: LocalDestinationFolder.SetSecurityDescriptor

SD: O:S-1-5-21-3869603026-3631219241-1903344517-3835G:S-1-5-21-3869603026-3631219241-1903344517-513D:AI(A;OIIO;0x1f0fbf;;;S-1-5-21-3869603026-3631219241-1903344517-3835)(A;CI;0x1fc9ff;;;S-1-5-21-3869603026-3631219241-1903344517-3835)(A;OIIO;0x1208a9;;;S-1-5-21-4230955503-526549450-3057572010-5377)(D;OIIOID;0x1f0716;;;S-1-5-21-3869603026-3631219241-1903344517-2781)(A;CI;0x1208a9;;;S-1-5-21-4230955503-526549450-3057572010-5377)(D;CIID;0xdc916;;;S-1-5-21-3869603026-3631219241-1903344517-2781)

As you can see above it has some problems with the Taken folder. When we had a look at this folder together with the end-user we found out that specific permissions where set in the folders. So we asked if he could remove them on one of the folders to check if that fixed the issue. After the user had done this we were a step further but, as expected, had the same issue with another folder. As it isn’t an option to remove all permissions before migrating the mailbox I decided to contact Microsoft.

After we contacted Microsoft a lot became more clear. During the migration of a mailbox from Exchange 2003 to Exchange 2010 the process will try to regenerate the ACL’s on the Exchange 2010 side. This because Exchange 2010 does use the ACL’s in another way then Exchange 2003. It can happen that the an ACL get’s corrupt which will cause the migration of the mailbox to fail.

The solution: redefine the permissions via Outlook either by removing and adding them again or by changing them to something else and then change them back to the original permissions. Not a really nice solution but you can continue migrating.

Collegue Michel de Rooijave me another tip, try to use PFdavAdmin with this tool it’s possible to fix AC’L’s of mailboxes.

During a cross-forest test migration from Exchange 2003 to Exchange 2010 I got the following error:

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> Failed to find the address type object in Active Directory for address type “SMTP:AMD64”.
Failed to cleanup the source mailbox after the move.
Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

When I looked in the old and new environment I found out that the mailbox both existed in the old and new environment. In this  case you might have a big issue even when the mail is delivered in the Exchange 2003 environment  and the homeMDB attribute is not updated. Updating the attribute may take a while due to AD replication, in this case mail is not delivered in the new mailbox and so mails will not be placed in the new mailbox.

To prevent this issue Microsoft has released a hotfix for Exchange 2003 which can be found on the website below.

open