Self-service PowerShell throttling policy relaxation for Exchange Online

Many vendors, Microsoft included, enforce strict throttling policies on their services in order to make sure that resources are not being hogged by a single user/process. In the Exchange world, throttling policies were first introduced in Exchange 2010 and have been present in each server version since. With the move to the cloud, they become even more vital, given the multi-tenant nature of the service.

It’s understandable why Microsoft wants to enforce such limitations, and one can even argue that the decision to remove the ability to even see the current throttling policy values that are in effect in Exchange Online was justified as well. However, it’s not that uncommon for organizations to have a legitimate need to go beyond the limitations enforced by throttling policies, for example when performing a migration from on-premises or third-party solution. In such scenarios, a process was made available for requesting temporary relaxation of the throttling controls, although Microsoft still had the last word in terms of the duration and actual throttling values.

Few months back, Microsoft decided to make this process a bit easier, by releasing a self-service experience for checking the current settings and updating the configuration to a more relaxed set of values. At the time, I decided to skip covering this new experience, as there’s not much you can say about it and even less in terms of actual configuration, and frankly I’m not a fan of that stupid “AI” support assistant. Since then, Microsoft has added additional scenarios, so I guess I have to play along 🙂

One new scenario in particular is relaxing the throttling controls for PowerShell cmdlet execution. To request this, you need to again open the Microsoft 365 Admin Center, then go to Support > New service request. In the “Need help?” pane, enter “PowerShell throttling” or similar keywords, and you will be presented with the following:

Here, you are given the option to Temporarily update throttling policies for a migration or Update throttling policies to align with your tenant size. Pressing the Run Tests button for either of these will initiate a (not so) short check and once the results are back, you will be presented with the option to Update settings, provided the automated diagnostic tool determined there is room for improvement. All you need to do is select the consent checkbox and press the button.

Overall, the process is pretty much identical with the EWS throttling scenario, and fairly straightforward, though I would much prefer to have this exposed on an actual page instead of having to go through the “Need help?” pane. Anyway, the end result is what’s important here, and being able to perform this without having to open a support case (or provide justification) is a good step forward. Nowhere in the process you will be presented with the actual values though, so the experience remains as convoluted as ever.

Do note that this is not a “golden ticket” and you should still add appropriate anti-throttling handling within your migration and reporting scripts. Same old recommendations still apply, at least until Microsoft releases a full set of REST-based cmdlets or their corresponding Graph API endpoints.