Exchange Admin Center outage halts web console access for admins

The Exchange Admin Center outage started on the morning of October 12, European time, when Microsoft acknowledged that admins trying to reach the console might see an Internal Server Error message. Any admin could be affected, not just a subset of customers. Microsoft tracked the incident under the reference EX1500900 in its service health dashboard.

More than an hour after the first notice, Microsoft said it had found unexpected redirect errors when admins tried to load the console. A redirect is the web’s way of sending your browser from one address to another, and in this case the browser was being bounced somewhere it should not go, so the page never loaded. Microsoft said it was studying diagnostic logs and that admins still could not reach the console.

About two hours in, the company said it was testing a rollback of a recent change to the admin center and watching to see if that cured the problem. It did.

In its final update, Microsoft said a recent configuration change to the Exchange Admin Center had produced unexpected responses along the path that admin requests take, which stopped admins from getting in. Reverting that change brought the service back to normal.

A configuration change is an adjustment to settings rather than new software: a tweak to how servers route traffic, which features are switched on, or how requests are handled. These changes are often pushed out quickly and across the whole service at once, which is why a small mistake can lock out every customer at the same moment.

Microsoft said it would review the change so it does not repeat the error, and look at its monitoring and telemetry (the automatic health data its systems send back) to catch similar behavior sooner. The outage was fixed before the end of the working day in Europe. Microsoft said a preliminary post-incident report would follow within two business days, with a final report the following week.

The good news is that this outage hit the management console, not email itself. Messages kept flowing, and people could keep using Outlook as normal. Nothing in Microsoft’s updates suggested mail delivery was affected.

The catch is what IT teams could not do while they were locked out. The Exchange Admin Center is Microsoft’s web-based console for running Exchange Online, the email part of Microsoft 365. It is where admins create and manage mailboxes, set up distribution groups, write the mail flow rules that decide where messages go, and control permissions and security settings.

So if you started a new job that morning and needed a mailbox, lost access to a shared team inbox, or reported a suspicious email your IT team wanted to block with a rule, the fix may have had to wait. For a business, that can mean a delayed new starter, a stuck customer service queue or a slower response to a phishing attack. Microsoft did not suggest any other route for admins while the console was down.

This was not a one-off. Microsoft has a run of incidents caused by its own configuration changes. In September, a change left some users unable to reach SharePoint Online sites and pages. In April, another change knocked out Outlook for iOS. Last year, a configuration change took down parts of Microsoft 365 more broadly.

Each time, the fix was the same: undo the change. That points to the real issue, which is how changes are tested before they reach every customer. Cloud services are supposed to remove the burden of running email servers from companies, but it also means a single mistake at Microsoft lands on every organization at once, with nothing their own IT staff can do except wait.

The pattern is worth knowing if you are the person who has to explain to your boss why the admin console is down. In most of these cases the outage is short, fixed by a rollback, and followed by a formal report.

The most useful step is to know where Microsoft posts incident updates. The service health page in the Microsoft 365 admin center lists active incidents with their reference numbers, so admins can confirm quickly that a problem is on Microsoft’s side rather than their own.

It also helps to write down which urgent tasks depend on the admin console, such as new mailboxes, permission changes and emergency mail rules, and decide in advance who will tell staff about any delay. When the post-incident report arrives, it is worth reading for what Microsoft says it will change in its testing.