DEV Community: Contenteditor

How Outlook OST Files Work and When OST Recovery Is Actually Needed

Contenteditor — Mon, 28 Sep 2026 12:56:14 +0000

Microsoft Outlook uses Offline Storage Table (OST) files to maintain a local copy of mailbox information for supported accounts such as Microsoft Exchange and Microsoft 365.
Because an OST contains emails, contacts, calendar items, attachments, and other mailbox information, it is sometimes treated as though it were simply another Outlook data file that can be moved, opened, or converted whenever Outlook stops working.
The reality is more nuanced.
An OST normally exists as part of a relationship between Outlook, the Outlook profile, the mailbox account, and the mail server. Understanding that relationship can help determine whether an OST actually needs recovery or whether the underlying Outlook or mailbox problem should be fixed instead.

What Does an OST File Actually Do?

When Outlook is configured with a supported Exchange or Microsoft 365 account and Cached Exchange Mode is enabled, mailbox information can be stored locally in an OST file.
A simplified representation looks like this:
Exchange / Microsoft 365
|
v
Mailbox
|
v
Outlook Profile
|
v
Local OST

The OST allows Outlook to work with previously synchronized mailbox information even when network connectivity is temporarily unavailable.
When connectivity is restored, Outlook can synchronize changes with the server mailbox.
This is why an OST should generally be considered a local synchronized mailbox cache, rather than an independent backup of the mailbox.

Where Is the OST File Stored?

On a typical Windows installation, Outlook data files may be found within the user's local profile.
A commonly encountered location is:
C:\Users<username>\AppData\Local\Microsoft\Outlook\

However, the actual location can vary depending on the Outlook version, account configuration, Windows environment, and organizational settings.
Finding an OST file also does not necessarily mean that the file can simply be attached to another Outlook profile and used like a PST.

OST and PST Are Not Interchangeable

OST and PST files can contain similar types of Outlook information, but they serve different purposes.
An OST is typically associated with a synchronized mailbox and Outlook profile.
A PST is an Outlook data file commonly used for storing and transferring Outlook information.
Conceptually:
OST
|
+-- Associated with mailbox/profile
|
+-- Supports offline mailbox access
|
+-- Synchronizes with the mailbox
|
+-- May become orphaned if its original relationship is lost

PST
|
+-- Outlook data storage
|
+-- Can be opened through supported Outlook workflows
|
+-- Commonly used for transferring or retaining Outlook data

This difference becomes particularly important during troubleshooting and recovery.

Why Can an OST Become Inaccessible?

An inaccessible OST does not always mean the file itself is corrupted.
Several different conditions can produce what appears to be an OST problem.
For example, Outlook may fail to access mailbox data because of:

Network or connectivity problems
Authentication problems
Microsoft 365 or Exchange availability
Outlook profile corruption
Synchronization problems
Local storage issues
OST file corruption
Removal of the original mailbox
Loss of the original Outlook profile
Changes to the account or Exchange environment Therefore, immediately attempting to convert the OST is not always the correct first step.

A Better Troubleshooting Sequence

Before attempting independent OST recovery, work through the environment logically.
Step 1: Check the server mailbox
Determine whether the original Exchange or Microsoft 365 mailbox still exists and contains the required information.
If the server mailbox is healthy, the OST may not be the primary recovery source.
Step 2: Check connectivity and authentication
Verify that Outlook can communicate with the service and that the account can authenticate successfully.
A temporary connection or authentication failure does not make an OST orphaned.
Step 3: Check the Outlook profile
Determine whether the existing Outlook profile can be repaired or recreated.
If Outlook can reconnect to the mailbox and synchronize the required information again, rebuilding the local cache may be preferable to recovering the old OST.
Step 4: Check synchronization
If the mailbox still contains the required data, determine whether Outlook can create a new local synchronized copy.
Step 5: Examine the OST
Independent OST recovery becomes more relevant when the normal mailbox/profile relationship cannot be restored or when the OST may contain required information that is unavailable from the server.
The decision process can therefore be summarized as:
Can Outlook access the mailbox?
|
Yes
|
v
Use normal Outlook/server options

    No
    |
    v

What Is an Orphaned OST?

An orphaned OST is generally an OST that remains available locally but can no longer be used normally through its original mailbox/profile relationship.
This can occur in scenarios involving an unavailable mailbox, removed account, old Outlook profile, or an Exchange environment that can no longer be restored.
For example:
Original Exchange Mailbox
X
|
Relationship lost
|
v
Existing OST

The local OST may still contain mailbox information, but normal synchronization with the original mailbox is no longer possible.
This is very different from a temporary network outage.

Does an Orphaned OST Need to Be Converted?

It depends on whether the information in the OST is still required and whether another valid copy exists.
Suppose the original mailbox remains available on Microsoft 365 and contains everything required. In that situation, restoring Outlook connectivity or recreating the profile may solve the problem.
Now consider a different situation:
Original mailbox: unavailable
Original profile: unavailable
OST file: available
Required mailbox data: only present in OST

In this scenario, independent OST recovery becomes much more relevant.

Can You Rename an OST File to PST?

No.
For example, changing:
mailbox.ost

to:
mailbox.pst

does not convert the data.
It only changes the filename extension.
OST and PST files have different purposes and internal relationships. A proper recovery or conversion process must read the accessible mailbox information from the OST and export it into an appropriate PST structure.

When Is an OST Recovery Tool Appropriate?

A dedicated OST recovery tool becomes useful when normal Outlook and server-side recovery options cannot provide access to required mailbox information.
Examples can include:

An orphaned OST
An inaccessible OST
A damaged OST
An unavailable original mailbox
An Outlook profile that cannot be restored
An old OST retained after an Exchange environment was removed
Required locally cached information that is unavailable from the server In these circumstances, the objective is not simply to change the file extension. The objective is to scan the OST, identify accessible mailbox information, preview or validate the data, and export the required items to an appropriate destination. For this type of scenario, EdbMails OST to PST Converter provides OST scanning, mailbox preview, and recovery options for offline, orphaned, inaccessible, and corrupted OST files. You can review the recovery options and supported workflow on the official EdbMails OST to PST Converter page.

Preserve the Original OST Before Recovery

If an OST contains potentially important information, avoid unnecessarily working on the only available copy.
A safer workflow is:
Original OST
|
+----> Preserve original
|
+----> Create working copy
|
v
Scan / Recover
|
v
Validate output

Keep the original file intact wherever possible.
Perform recovery against a working copy and validate a sample of the recovered mailbox information before relying on the complete export.
For important business data, this also preserves the source if another recovery approach needs to be attempted.

OST Recovery Should Be a Decision, Not the First Reaction

When Outlook reports a data-file or connection problem, it can be tempting to immediately search for a converter.
A more useful troubleshooting sequence is:
Mailbox availability
↓
Network / authentication
↓
Outlook profile
↓
Synchronization
↓
OST condition
↓
Independent recovery

This helps distinguish an Outlook connectivity problem from an actual data-recovery scenario.
If the server mailbox remains healthy, restoring Outlook may be enough.
If the mailbox/profile relationship cannot be restored and the OST contains required information unavailable elsewhere, OST recovery becomes a reasonable next step.

Final Thoughts

An OST file is not simply a portable copy of an Outlook mailbox. It normally functions as part of a synchronized relationship involving Outlook, an account/profile, and Exchange or Microsoft 365.
That distinction changes how OST problems should be approached.
Before recovering or converting an OST, determine whether:

The original mailbox still exists.
Outlook can reconnect to the mailbox.
The Outlook profile can be recreated.
The required information can be synchronized again.
The OST contains information unavailable from another source. Only after these checks does it make sense to determine whether independent OST recovery is necessary. Understanding this workflow can prevent unnecessary conversion and help ensure that recovery is used for the scenarios where it is actually required.

EWS Is Being Disabled in Exchange Online: What Breaks and What Replaces It?

Contenteditor — Fri, 28 Aug 2026 12:19:52 +0000

I keep a running list of things that quietly stopped working in client environments over the years, and near the top is a category I'd call "the integration nobody remembers configuring." A backup job, a booking system, a CRM add-in installed by someone who left the company three years ago. Half the time these things are still talking to Exchange using an old protocol that most admins stopped thinking about once they finished their last migration project.

That protocol is Exchange Web Services, and its clock is running out. Not in some vague "eventually" sense either. Microsoft has published dates, and the first one is close enough that if you haven't looked at your tenant's EWS usage yet, now is the time.

What is actually changing

EWS has been around since Exchange 2007. It's a SOAP-based API that lets applications read and write mailbox data: messages, calendar items, contacts, tasks, free/busy info, and a fairly deep set of Exchange-specific operations that never got exposed anywhere else. For a long time it was the standard way for a third-party app to talk to an Exchange mailbox without going through MAPI or IMAP.

Microsoft announced in 2018 that EWS would stop receiving feature updates. That part is old news and most of us shrugged it off, because "no new features" doesn't mean "stops working." What changed the calculus was the Midnight Blizzard incident in January 2024, where EWS access was implicated in a breach against Microsoft's own corporate systems. After that, the retirement stopped being a slow background migration and became a scheduled shutdown with real dates attached, and the scope widened from just third-party apps to Microsoft's own products as well.

There's a middle option for tenants that need more runway. If you configure an AppID allow list and explicitly set EWSEnabled to true before the October cutoff, EWS keeps working for the apps on that list until the final shutdown in April. Microsoft has said they'll pre-populate an allow list based on observed usage if you don't do it yourself, but I wouldn't trust that to match what you actually rely on. Automated lists built from telemetry tend to catch the noisy stuff and miss the low-frequency scheduled jobs that only run once a quarter.

One thing worth repeating because people mix it up constantly: this only affects Exchange Online. On-premises Exchange Server is not part of this change. If you're running a hybrid environment, the on-prem side keeps EWS working exactly as it always has, which creates its own confusion when half your integrations still function and the other half don't.

What can actually break

This is the part that matters more than the dates. EWS touches more than people expect because it was the path of least resistance for a decade of tooling.

The obvious candidates are backup and archiving products. A lot of third-party backup solutions for Microsoft 365 mailboxes were built on EWS because it exposed granular item-level access that other APIs didn't have at the time. If a backup vendor hasn't finished their Graph migration, your nightly jobs could start failing silently, which is worse than failing loudly.

Booking and resource management systems are another common one. Meeting room booking displays, scheduling assistants, and free/busy lookup tools built before Graph matured often used EWS calendar operations directly.

Then there's the long tail: internal PowerShell scripts written years ago that pull mailbox statistics or export calendar data, custom CRM connectors that sync contacts, migration and export tools, compliance or eDiscovery tooling that does mailbox searches, and old on-prem monitoring agents that check mailbox health. None of these show up on anyone's radar until they stop working, because they run unattended.

Authentication is a separate failure mode worth calling out. Even before the hard disablement dates, a lot of EWS-based apps have been breaking because they still rely on Basic Auth or older NTLM-based flows, which Microsoft has been retiring on its own separate timeline. If an app is failing today, before October 2026, it's worth checking whether the actual cause is an auth protocol issue rather than EWS access itself. I've seen people assume the EWS retirement had already started when the real problem was Basic Auth being turned off in their tenant months earlier.

Applications I'd check first

If I were triaging a tenant today, I'd prioritize in roughly this order:

Backup and data protection tools: these run automatically and failures are easy to miss until you actually need a restore.
Any custom-built internal tool: anything written in-house is the highest risk because no vendor is pushing an update for you.
Migration and PST export utilities: if you're mid-project or planning one, this intersects directly with the deadline.
Calendar and room-booking systems: these tend to be visible and loud when they break, but that doesn't make them low priority.
Compliance, legal hold, and eDiscovery tooling: breakage here has regulatory implications, not just operational ones.
Old mobile device management or ActiveSync-adjacent tools: less common now, but they still turn up in older environments.

Microsoft's EWS Usage Reports, available in the Microsoft 365 admin center, will show you which app registrations are actually calling EWS in your tenant right now. That's a better starting point than guessing, because usage patterns rarely match what's documented anywhere. There's also an EWS Code Analyzer tool Microsoft released for scanning custom code for EWS calls, which is worth running against any internal scripts or applications your team maintains.

Microsoft Graph as the replacement

Graph is the unified API Microsoft wants everything to use going forward, covering not just Exchange but SharePoint, Teams, OneDrive, and the rest of the Microsoft 365 stack through one consistent REST interface with OAuth 2.0 and modern app registration. For most day-to-day mailbox operations, sending and reading mail, managing calendar events, working with contacts, it's a genuine improvement. The permission model is more granular, the auth flow doesn't rely on legacy protocols, and you get delta queries for efficiently syncing changes instead of polling everything repeatedly.

For a typical line-of-business app that reads a user's inbox or creates calendar events, moving to Graph isn't a huge lift. The concepts map reasonably well and the documentation is solid.

Where it's not a clean swap

This is where I'd push back on anyone treating Graph as a drop-in replacement, because it isn't, not yet.

Public folders are the biggest gap. Import and export of mailboxes made it into preview during 2025, but that explicitly excludes Microsoft 365 Groups and public folder mailboxes. If your organization still leans on public folders for shared calendars or departmental inboxes, and a lot of organizations quietly still do, there's no clean Graph equivalent for some of that access today.

Archive mailbox operations have had ongoing gaps. Delta queries for recurring calendar events are another area Microsoft has specifically called out as needing more work, which matters if your integration does anything with recurring meeting series rather than single events. User configuration data, things like certain mailbox-level settings, doesn't have full coverage yet either.

There's also an administration API gap. A lot of tenant and mailbox-level admin operations that EWS could do just aren't fully available through Graph yet, though Microsoft has an admin API in preview specifically to close that hole.

None of this means Graph migration should wait. It means the migration plan needs a parity check as its own step, not an assumption. Some of these gaps are closing on a rolling basis, so what's missing today might be covered by the time your project actually executes, but you can't assume that without checking current documentation at the time you do the work.

What I'd check before the October deadline

Practically, here's the sequence I'd work through on any tenant:

First, pull the EWS Usage Reports and get an actual list of what's calling EWS, rather than relying on institutional memory of what integrations exist. Second, for each item on that list, find out if the vendor has already shipped a Graph-based version, because a lot of major backup and archiving vendors have been actively working through this. Third, for anything custom-built internally, run it through the EWS Code Analyzer and budget real development time, not "we'll get to it," because Graph's permission model often requires different app registrations and consent flows than what the old EWS app had.

Fourth, decide on your allow list strategy before the end of August 2026, since that's the window Microsoft has flagged as the safe cutoff to configure EWSEnabled and an AppID allow list without risking an automatic, possibly incomplete, list being applied on your behalf. Fifth, if you find something depending on public folders or another known Graph gap, don't try to force a workaround, flag it and check current parity status closer to your actual cutover date since Microsoft has been closing these gaps incrementally.

Where migration projects fit in

Mailbox migration tooling is one of the categories worth checking carefully, because a fair number of migration and export utilities, especially older ones or scripts built for a specific one-time project years ago, were written against EWS since it exposed the granular mailbox access migration tools need. If you're planning a migration, whether that's on-prem Exchange to Exchange Online, cross-forest, or between different Exchange versions, it's worth confirming ahead of time whether the tool you're using has already moved to Graph-based access or still depends on EWS staying available. I ran into this while looking at options for an Exchange to Exchange Online project and noticed that EdbMails supports direct migrations between on-premises Exchange servers and Microsoft 365 without requiring PowerShell scripting, which at least removes one layer of custom scripting that would otherwise need its own EWS dependency check. Whatever tool you land on, confirm its current auth model as part of vendor selection rather than assuming it, since this is exactly the kind of detail that changes between versions. If you're weighing tools for an Exchange Migration, that's a reasonable point to add to your evaluation checklist alongside the usual concerns around downtime, mailbox mapping, and delta sync.

Beyond the tooling itself, migration projects can surface EWS dependencies you didn't know you had. Pre-migration assessment scripts, mailbox permission audits, and post-migration validation checks are all places where someone historically reached for EWS because it made a particular query easy. If a migration is already planned for sometime around the October 2026 to April 2027 window, it's worth treating the EWS retirement as part of the same project rather than a separate concern, since the two timelines are likely to overlap for a lot of organizations.

A practical checklist

Run EWS Usage Reports in the Microsoft 365 admin center to see what's actually calling EWS in your tenant
Run the EWS Code Analyzer against internal scripts and custom applications
Contact every third-party vendor with an EWS-dependent product and get a written timeline for their Graph migration
Identify anything touching public folders specifically, since that's the largest current parity gap
Check whether any failures you're seeing right now are actually Basic Auth or NTLM related rather than EWS access itself
Decide on an allow list strategy and configure EWSEnabled before the end of August 2026 if you need the extended runway
Re-verify Graph parity status close to your actual cutover date, since Microsoft has been closing gaps on a rolling basis
If a migration project is already scheduled, fold the EWS dependency check into that project's scope instead of treating it separately
Document what you find, because six months from now nobody will remember which app needed which fix

Final thoughts

The EWS retirement isn't a surprise change, it's been telegraphed since 2018, but the concrete dates are what actually get people moving. October 2026 sounds distant right up until it isn't, and the applications most likely to break are exactly the ones nobody's watching: the scheduled job, the internal script, the integration installed by someone who's no longer around to explain it.

The good news is that the tooling to find these dependencies already exists, and Microsoft Graph handles the majority of common scenarios well. The part that takes actual discipline is going through the list methodically instead of waiting for something to fail in production and working backward from there.