21 May 2019 by Steve Goodman
How to Migrate Exchange to Office 365: Step by Step – Part 2
How to set up Exchange Hybrid and migrate mailboxes.
If you do any kind of heavy work with Exchange Online in PowerShell you’ve probably come across throttling. This is applied at the Exchange Server level and restricts the amount of resources you can consume in the Office 365 environment.
Whilst they’re annoying and make our life miserable, we can understand why they are in place and have learned to work within their limits.
This article will aim to share what we’ve learnt about Office 365 Exchange Online throttling when it comes to PowerShell connections.
Firstly, let’s look at the default Office 365 throttling policy.
|PowerShellMaxConcurrency||3||The Number of simulatenous PowerShell Sessions a user can have open to Exchange Online|
|PowerShellMaxTenantConcurrency||9||The Number of simulatenous PowerShell Sessions a tenant can have open to Exchange Online|
|PowerShellMaxCmdlets||200||The number of cmdlets that can be run per PowerShellMaxCmdletsTimePeriod without being throttled|
|ExchangeMaxCmdlets||25||This parameter is similar to PowerShellMaxCmdlets but only for Exchange Online cmdlets|
|PowerShellMaxCmdletsTimePeriod||5||The time period, in seconds, that a user can run the number of cmdlets defined by the PowerShellMaxCmdlets or ExchangeMaxCmdlets parameter|
|PowerShellMaxCmdletQueueDepth||50||Defines the number of operations that a user can run simultaneously|
|PowerShellMaxDestructiveCmdlets||120||The number of cmdlets that can be run per PowerShellMaxDestructiveCmdletsTimePeriod without being throttled. A desuctive cmdlet is one that makes changes to the Office 365 environment (Such as Set or New cmdlets)|
|PowerShellMaxDestructiveCmdletsTimePeriod||60||The time period, in seconds, that a user can run the number of cmdlets defined by the PowerShellMaxDestructiveCmdlets parameter|
There are very clearly defined boundaries as to how many cmdlets you can run and how quickly.
It may seem like you have a lot of room to play with, but when you start piping cmdlets together such as Get-Mailbox | Get-MailboxStatistics you very quickly consume your whole throttling budget – especially if you have a lot of mailboxes in your tenant.
Most of these limits apply to the User Account that is connected to Exchange Online. You can get around some of these by using different user accounts for different tasks.
If you exceed any of the limits mentioned above, you will be throttled by Exchange Online and your scripts will run slower. This will result in “Mirco Delay” warnings being displayed in PowerShell that look something like this.
WARNING: Micro delay applied. Actual delayed: 12 msecs
WARNING: Micro delay applied. Actual delayed: 33 msecs, Enforced
Microsoft has a support article about this problem but it is not very useful.
If you continually breach this throttling policy, your account may become locked for a certain period of time. This is bad as it means you cannot perform any Exchange Online actions whilst the account is locked.
A locked account will show an error in PowerShell that looks something like this:
This operation exceeds the throttling budget for policy part ‘LocalTime’, policy value ‘3000000’, Budget type: ‘PowerShell’. Suggested backoff time 887405440 ms.
(PolicyDN: CN=OrganizationThrottlingPolicy,CN=Global Settings, …;
Snapshot: Owner: Sid~XXXXXXXXX~PowerShell~false
LastTimeFrameUpdate: 08/21/2013 8:22:51 PM
LastTimeFrameUpdateDestructiveCmdlets: 08/21/2013 8:22:51 PM
LastTimeFrameUpdateMaxRunspaces: 08/21/2013 8:22:51 PM
The important part here is the Locked: True and LockRemaining: 10.06:30:05.4400000 attributes. This tells you that the account is locked and that it will remain locked for 10 days and 6 hours.
If you try to run any Exchange Cmdlets within this lock period it will double the lockout window!
In our experience this time frame is also often incorrect, and we’ve seen accounts become unlocked sooner or later than the LockRemaining time specified.
It is almost impossible to get this throttling policy changed.
We have heard of some large companies who were successful in lobbying Microsoft to get their policy modified or increased.
If you want to go down this route we suggest logging a support ticket explaining the business case why you need the policy increased and then get your Microsoft Account Manager or TAM to push the ticket within Microsoft to the correct team. 99% of the time your request will be denied.
Here are some tips to avoid getting throttled: