What Happened
A Microsoft 365 outage took Outlook, Exchange Online, Microsoft Teams and Copilot offline for users worldwide, and it ran into a second day. Microsoft said it was investigating the disruption and working to restore service. ChannelPro described the outage as putting MSPs on continuity duty, with the disruption beginning on Thursday, Nov. 12 and continuing into Friday morning.
SecurityWeek reported that Microsoft said failed server health checks disrupted Outlook and other Microsoft 365 services. SecurityWeek also reported that Microsoft said it was still investigating the cause and had disclosed no evidence of a cyberattack.
Microsoft was trying different ways to identify the cause and get its servers back online, using what it described as a measured approach to identify and repair affected infrastructure, according to SecurityWeek.
For an MSP, the first hour of an outage like this is not really a technical problem. It is a phone problem. When Outlook stops, clients stop working, and they call you. The faster you can tell a client whether the problem sits on your side or Microsoft's, the less time you spend on calls that fix nothing.
Microsoft 365 Outage Timeline
- Thursday, Nov. 12: A widespread Microsoft 365 outage begins, interrupting services across the stack as users report connectivity problems worldwide.
- Thursday, Nov. 12: Microsoft says failed server health checks disrupted Outlook and other Microsoft 365 services, and that it is still investigating the cause with no evidence of a cyberattack disclosed.
- Friday morning, Nov. 13: The outage stretches into a second day, and ChannelPro reports MSPs on continuity duty.
- Friday, Nov. 13: SecurityWeek reports Microsoft is trying different ways to identify the cause and restore servers, using a measured approach to identify and repair affected infrastructure.
- Friday, Nov. 13: Infotech publishes a research note on immediate actions for IT leaders, saying recovery should be verified across workflows and security controls.
Who Is Affected
The reporting names multiple Microsoft 365 services, with Outlook, Exchange Online, Microsoft Teams and Copilot called out specifically. Users reported connectivity problems worldwide, so the impact was not limited to one region or one tenant size.
In practice, the clients who feel this first are the ones who live in email and chat. A business that runs quoting, invoicing or support through Outlook loses revenue time the moment it goes dark, and it will call whoever answers.
- multiple Microsoft 365 services
- Outlook
- Exchange Online
- Microsoft Teams
- Copilot
Why This Costs MSPs Money
An outage like this does not create a billable project. It creates a queue of calls, and most of them are not billable either. Engineers who were booked on scheduled work get pulled onto triage, and that scheduled work either slips or gets absorbed.
There is also the trust cost. A client does not care whether the failure is Microsoft's. They care how quickly you told them what was happening and what you were doing about it. MSPs that can answer that question in the first ten minutes spend far less of the day apologising.
This is why continuity is a service you either have ready or you invent under pressure. The teams that handle outages well have a short script, a way to see which clients are affected, and a known answer for where their data sits if the worst case turns out to be data loss rather than a service failure.
Technical Details
No CVE identifiers were published in the reporting reviewed for this incident. No affected versions were given, because this is a service side outage rather than a vulnerability in a fixed product release.
No attack vector has been stated. Microsoft has disclosed no evidence of a cyberattack, and the cause remains under investigation. The only technical cause offered by Microsoft in the reporting is failed server health checks that disrupted Outlook and other Microsoft 365 services.
The services named in the reporting are Microsoft 365 services overall, with Outlook, Exchange Online, Microsoft Teams and Copilot called out. That is the full extent of what the sources state about this incident.
What MSPs Should Do
There is no patch to deploy here, because no attack has been disclosed and no vulnerable version has been named. The work is continuity, verification and communication.
- Work out exactly which clients and which workloads are affected before you promise anyone a fix time. Use Microsoft service health information and your own monitoring together.
- Identify which business processes depend on the affected services, including ticketing, invoicing, alerting and any automated notification that leaves the building by email.
- Verify recovery workflow by workflow as service returns. A single successful sign in does not prove that mail flow, calendar or chat is working for the client.
- Re-check the security controls that sit in front of those workflows once things are back, because a rushed recovery can leave something switched off or bypassed. Infotech said recovery should be verified across workflows and security controls.
- Confirm that backup jobs ran through the window and that the copies are intact and readable, rather than assuming last night's job completed.
- Check whether mail queued during the outage has been delivered and whether anything was lost or duplicated.
- Tell clients what you are seeing and when you will update them next, then keep that promise.
- Log the incident afterwards, including how you found out, how you communicated and what you would change next time.
How EnterProtect Helps
Service outages and data loss are different problems, and MSPs need an answer for both. EnterProtect backup keeps clean restorable copies of the workloads your clients depend on, so a bad day does not turn into an unrecoverable one.
When something does go wrong with the data itself, EnterProtect recovery is about getting a client running again with as little disruption as possible. That matters most in the moments when a client is already angry about something outside your control.
As a standing practice, it is also worth knowing which of your clients are running versions of software that are exposed to known issues. EnterProtect vulnerability scanning finds exposed versions so that question has an answer before a bad week forces it.
The point is simple. You cannot stop Microsoft from having a bad day. You can make sure your clients' data is somewhere you can restore from when the bad day reaches them.
Frequently Asked Questions
What Caused the Microsoft 365 Outage?
Microsoft said failed server health checks disrupted Outlook and other Microsoft 365 services. SecurityWeek reported that Microsoft was still investigating the cause and had disclosed no evidence of a cyberattack. The company said it was taking a measured approach to identify and repair affected infrastructure.
Which Microsoft 365 Services Were Affected by the Outage?
The outage hit multiple Microsoft 365 services, including Outlook, Exchange Online, Microsoft Teams and Copilot. Users worldwide reported connectivity problems, so any client relying on those workloads was exposed. The practical impact was worst for anyone who runs email and chat as the centre of their working day.
Was the Microsoft 365 Outage a Cyberattack?
Microsoft has disclosed no evidence of a cyberattack, and it said the cause was still under investigation. No threat actor has been named in the reporting. Until Microsoft says otherwise, treat this as a service availability failure and tell clients that is what the reporting describes.
What Should MSPs Do During a Microsoft 365 Outage?
Work out which clients and workloads are affected first, then check Microsoft service health against your own monitoring. Verify recovery workflow by workflow rather than with a single sign in test, and confirm backup jobs completed. Infotech said recovery should be verified across workflows and security controls.
Should MSPs Restore From Backup During a Microsoft 365 Outage?
Usually not. A service side outage is not data loss, and a rushed restore can overwrite newer data with older copies. Restore only when data has genuinely been lost or corrupted, and confirm what you are restoring and where it will land before you start.
How Do MSPs Know When Microsoft 365 Is Fully Recovered for a Client?
Do not rely on one successful login. Test each workflow your client depends on, including mail flow, calendar, Teams and any automation that sends notifications. Infotech said recovery should be verified across workflows and security controls. Tell the client when each workflow has been confirmed rather than when service was announced as restored.
Sources
- Massive Microsoft 365 outage disrupts Outlook, Teams, Copilot worldwide (Bleepingcomputer)
- Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams (Securityweek)
- Microsoft 365 outage stretches into second day, putting MSPs on continuity duty (Channelpro)
- Microsoft Struggles to Restore Email and Other Services in a Global Outage (Securityweek)
- Microsoft 365 recovery progresses, but MSPs face an uneven return to service (Channele2E Rss)
- Microsoft 365 Outage: CIOs Should Verify Recovery Across Workflows and Security Controls, Says Infotech (Prnewswire Tech)
- Key channel headlines: M365 global outage, Commvault adds new AgentRecover capabilities and more (Channelpro)