Office 365

All posts tagged Office 365

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 ‘’ (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 ‘’ 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 ‘’ 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’ 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’ 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 the implementation of a rich-coexistence environment between an Exchange 2010 On-Premise environment and Office 365 I had an issue with the Free/Busy which didn’t work correctly. Using the On-Premise environment I could retrieve the Free/Busy information from an Office 365 user but it didn’t worked from Office 365 to On-Premise. The error I got was that it couldn’t connect to the On-Premise environment

Because the Cloud couldn’t connect I decided to have a look at the TMG. In the logging no requests could be seen in the logging. So the requests where blocked somewhere else. To troubleshoot this issue I decided to connect to Office 365 via Powershell.

To check if the organization relationshop works correctly you can use Test-OrganizationRelationship, for example:

Test-OrganizationRelationship -identity “To_OnPremise” -UserIdentity

When I ran this cmdlet it gave the following error:

 So there was an issue with the delegation token. The delegation token is provided by the Microsoft Federation Gateway. There are two gateways:

  • Consumer, used by Windows Live and
  • Commerciële, used by Office 365 and Exchange On-Premise environments

To check which federation gateway is used by the solution you can use the Get-FederatedOrganizationIdentifier cmdlet. This cmdlet returned the following output:

As you can see the DelegationTrustLink has the value WindowsLiveID this means that the consumer version of the federation gateway is used. Because this gateway can’t be used by Office 365 you won’t get a token from the federation gateway.

A correct federation from Office 365 side will look like this:

As you can see the DelegationTrustLink has the value MicrosoftOnline, the commercial version of the Microsoft Federation Gateway.

To fix the issue you will need to contact Office 365 support. Support can recreate the federation trust which ensures that a token can be retrieved from the Federation Gateway