Backing Up Microsoft 365 Mail, Calendars and Contacts

Backing up Microsoft 365 with WholesaleBackup

Welcome to WholesaleBackup's guide to protecting Microsoft 365 mailboxes. Your backup client can back up and restore mail, calendars and contacts straight from a customer's Microsoft 365 tenant, alongside the files and folders it already protects. Let's get started!

Why back up Microsoft 365 at all?

Microsoft keeps your customer's mail highly available. It does not keep it recoverable. Retention policies expire, deleted items age out of the dumpster, a departing employee's mailbox is purged along with their license, and ransomware or a disgruntled administrator can empty a mailbox as easily as a file share.

WholesaleBackup stores every item twice:

• a full-fidelity copy that goes back into Exchange with its received date, read state, flags and categories intact, and
• a portable .eml copy that opens in Outlook or any mail program, and stays readable without any WholesaleBackup software at all.

What you need before you start

• A Microsoft 365 tenant, and either global administrator access to it or an administrator who can grant tenant-wide consent on your behalf.
• Your backup client already installed and running backups successfully. Microsoft 365 is an additional source, not a separate product.
• The build password for the client GUI, which protects the credential page.

Setup runs once per tenant and takes about fifteen minutes.

Step 1: Register an application in Microsoft Entra

WholesaleBackup reaches Microsoft 365 through an application you register in the customer's tenant. Nobody signs in and no mailbox password is involved — the application authenticates as itself, which is what lets an unattended backup run at 2 a.m.

1. Sign in to the Microsoft Entra admin center as a global administrator of the tenant you are protecting.
2. Go to Entra ID → App Registrations, then click New Registration.
3. Name it something a future administrator will recognize, such as WholesaleBackup — Microsoft 365 Backup.
4. Under Supported account types, choose Accounts in this organizational directory only.
5. Leave Redirect URI empty. There is no interactive sign-in.
6. Click Register.

On the overview page that appears, copy these two values somewhere secure — you will paste them into the backup client later:

Create a client secret

7. Open Certificates & secrets → Client secrets → New client secret.
8. Give it a description and an expiry. Note the expiry date — backups will start failing on that day, and this is the single most common cause of a cloud backup that stops working months later.
9. Click Add, then copy the Value column immediately.

The secret value is shown once. If you navigate away without copying it, delete it and create another. Save all three values into your password manager or documentation before continuing.

Step 2: Grant API permissions

In your app registration, go to API permissions → Add a permission → Microsoft Graph → Application permissions. Search for each permission below, check it, and click Add permissions.

Backup permissions (read-only)

Two of these are easy to get wrong:

• Mail.ReadBasic.All is not enough. It excludes the message body, so every .eml download fails while everything else looks healthy.
• MailboxItem.Export.All is the one backup needs. MailboxItem.ImportExport.All also satisfies it, but it can write to mailboxes, and a backup credential should never be able to.

Restore permissions (write)

The last two are optional. Grant them only if you back up calendars or contacts: they are write access to a person's calendar and address book, and mail restores perfectly well without them.

Grant admin consent

Back on the API permissions page, click Grant admin consent for \ and confirm. Every permission should then show Granted with a green check.

⚠️ This step is not optional and is not implied by adding the permissions. A token issued before consent carries none of them, so the client will authenticate successfully and then be refused on every call.

Should you use one application or two?

Two is the safer arrangement, and it is what we recommend. Register a second application for restore with the write permissions, and keep the backup application read-only.

The reason is that backups run unattended every night, while restores are rare and deliberate. If the backup credential cannot write to a mailbox, then no bug, no misconfiguration and no attacker who obtains that secret can alter a customer's mail through it. Combining them into one application works, and gives up that protection.

The backup client enrolls each credential with a purpose, so it knows which to use for which job. It will never reach for a write credential to run a backup.

Using a single application for both

You can register one application, give it the full set of permissions, and enroll it as both backup and restore. It works, and it is one less thing to set up.

What you give up is a guarantee. Credentials are always stored encrypted, never in plain text (see Step 3), but encryption protects the secret — it does not limit what the secret is allowed to do. A combined credential is permitted to rewrite every mailbox in the tenant, and it is the credential in routine use, night after night. Keep them separate and the one that runs unattended simply has no power to alter a customer's mail, whatever else goes wrong.

If you do combine them, Check permissions will flag the backup credential as holding more than it needs. That warning is not a fault to be silenced — it is this trade-off, reported.

Step 3: Enroll the credential in the backup client

On the machine running the backup client, open the client GUI and browse to the /cloud page. By default the GUI listens at https://client.backupops.com:3443, so the page is at https://client.backupops.com:3443/cloud.

⚠️ This page is reached by URL only and is not in the navigation menu, the same as the /host page. It asks for the build password before it will show anything.

Fill in the form:

If you registered two applications, enroll them one at a time — the backup one checked Backup, the restore one checked Restore.

Click Enroll. The credential appears in the Enrolled list above the form.

How the secret is stored

The client secret is never stored in plain text. It is encrypted into a key file beside the backup client's configuration, tied to that installation, and it is decrypted only inside the short-lived process that talks to Microsoft — never by the always-on service that serves this page.

It is also never written to a log, never shown again once entered, and never passed on a command line, where any other user on the machine could read it out of a process listing.

The enrolled list shows only the tenant, the client ID and whether a secret is stored. To change a secret — when it expires, for instance — enroll the same tenant and client ID again with the new value, and it replaces the old one.

Step 4: Verify the credential

On the /cloud page, click Check permissions beside the credential you just enrolled.

This is not a local check. It asks Microsoft for a token and reads back the permissions the token actually carries, which is the only way to be certain that consent took effect. Do this before you configure selections, not after the first backup fails.

You will see one of these:

A credential that reports Ready with a note about calendars and contacts is correct for a customer who only backs up mail. You do not need to grant permissions you have no use for.

If Check permissions reports something missing that you are certain you granted, the usual cause is that admin consent was not clicked, or was clicked before the permission was added. Consent applies to the permissions present at the moment you grant it.

Step 5: Choose what to back up

Go to Backup → Selections. A Microsoft 365 branch now sits beside Computer and Network.

If you do not see it, no credential is enrolled on this machine — go back to Step 3. The branch is hidden entirely rather than shown empty.

Expand it and the tree fills in as you go:

• Microsoft 365
• Contoso Ltd — the tenant
  • joe@contoso.com — a mailbox
  • Whole mailbox
  • Inbox
  • Calendar
  • Contacts

  • amy@contoso.com — a mailbox

     

Whole mailbox, or named folders?

Whole mailbox is the right default. It follows the mailbox as it changes — a folder created next month is included automatically, which a list of named folders would miss silently.

Checking a named folder includes that folder and everything filed beneath it.

What a whole-mailbox selection covers

The excluded kinds are not oversights. We include a kind only once we have exported it, restored it, and confirmed in Outlook that it came back usable — storing something we cannot give back is worse than not storing it.

You can still check one of those folders by name if you want its contents kept. It will back up; it just will not restore into Outlook as that kind of item.

Excluding a folder

Check the mailbox, then uncheck a folder inside it to exclude it. An exclusion covers everything beneath that folder, including subfolders created later.

A note on calendars and contacts

These are stored in the full-fidelity format only. They restore into a mailbox perfectly, but they cannot be written out as .eml files, because Microsoft offers no portable form for them. The tree tells you this when you hover over one.

Step 6: Run the backup

Microsoft 365 items back up as part of the ordinary backup. There is no separate schedule, no separate job, and nothing extra to start. Run a backup as you always would, or wait for the schedule.

What to expect on the first run

The first backup downloads every item in the selection, so it takes far longer than later ones. A mailbox of several thousand messages can run for a while, and Microsoft throttles per mailbox, which the client handles by waiting and retrying rather than failing.

Watch the Overview page while it runs. The progress counter names the item being fetched, in the same place it names a file:

joe@contoso.com/Inbox/Quarterly numbers

Every run after the first only fetches what changed. A second backup immediately after the first should store nothing at all.

Reading the log

The backup log reports one line per folder:

Cloud scope [joe@contoso.com]/[Inbox]: 412 item(s) cataloged, 0 new or
changed, 0 tombstoned, status COMPLETE

status COMPLETE is the line that matters. It means the client saw the whole folder. If a folder cannot be listed completely — a network drop, heavy throttling — the status says so, and the client will not conclude that missing items were deleted. Absence is only ever treated as deletion when the listing was complete.

You will also see a line per mailbox naming what was skipped:

Cloud scope [joe@contoso.com]: 4 folder(s) of a kind this version cannot
restore were skipped (tasks, notes, journals).

And, for accounts with no mailbox at all — unlicensed staff, service accounts, meeting rooms:

Cloud scan: [room1@contoso.com] has no mailbox to back up (unlicensed,
soft-deleted, or hosted on-premises). Skipped.

That is information, not an error. A wildcard selection walks every account in the directory, and most tenants have several with no mailbox.

Deleted mail is kept

When an item disappears from the mailbox, the client marks it deleted in the catalog rather than discarding it. It stays restorable until your retention setting ages it out. Recovering deleted mail is the most common reason anyone opens the restore page.

Step 7: Restoring

Go to Restore, and choose Microsoft 365 mail in the Restore selector at the top of the page. The selector only appears when this computer holds a Microsoft 365 backup.

The page lists what was backed up, not what is in the mailbox now. 

Finding what you need

1. Pick the mailbox.
2. Set Show to Everything backed up, Still in the mailbox, or Deleted from the mailbox. The last is the one to reach for when someone has lost something.
3. Pick a folder on the left, or leave All folders.
4. Check individual messages, or leave everything unchecked to restore the whole folder.

Checked messages win: if you check four messages while looking at a folder of nine hundred, you get the four. The button says which it will do before you press it.

Calendars and contacts are shown as a count rather than a list, and restore as a whole folder. Microsoft gives us no subject, sender or date for those items without opening each one, so there is nothing to list them by and nothing to choose between.

Choosing where it goes

Where restored items appear

Items go back into the mailbox they were backed up from — not yours. Restore Amy's mail and it lands in Amy's account. To restore someone else's items, pick their mailbox and restore from there.

A restore creates new folders and never alters, overwrites or merges into anything already in the mailbox. Depending on what you restored you may get up to three, and they are in three different places:

If you restored a calendar and cannot find it, check the calendar list rather than the folder tree. That is the single most common piece of confusion.

While it runs

Starting a restore switches you to the Overview page, the same as a file restore. A cloud restore appears in Details as a cloud restore session with its item counts and its own log, alongside every other operation.

Nothing is deleted from the mailbox and nothing existing is changed — a restore only ever adds.

What is covered, and what is not

Why calendars and contacts have no .eml

.eml is a mail format. Microsoft offers no portable equivalent for an appointment or a contact, so those items are stored in the full-fidelity format alone. They restore into a mailbox exactly as they were; they simply cannot be written out as files.

A .eml restore that includes them reports them as skipped, with the reason, rather than as failures.

A note on exact fidelity

A restored message is faithful in content — correct sender, recipients, subject, date, body and attachments — but it is not a byte-for-byte copy of the message as it arrived. Microsoft rebuilds the message when exporting it, and one visible consequence is that DKIM signatures will not re-validate on a restored copy.

For almost every purpose this is irrelevant. If a customer has a regulatory or e-discovery requirement for byte-original message capture, this is worth raising with them before they rely on it, because no third-party backup using Microsoft's export API can offer that.

Retention

Microsoft 365 items follow the same retention setting as everything else the client backs up. An item deleted from the mailbox stays restorable until your retention window passes, then ages out with the rest.

Troubleshooting

The Microsoft 365 branch is missing from Selections

No credential is enrolled on this machine. Go to /cloud and enroll one (Step 3). The branch is hidden rather than shown empty, so its absence means exactly this.

"Check permissions" says a permission is missing that I granted

Admin consent was not granted, or was granted before that permission was added. Consent applies to the permissions present when you click it. Add the permission, click Grant admin consent again, then re-check.

Backups worked for months and now fail to authenticate

The client secret expired. Create a new one in Entra (Certificates & secrets) and enroll the same tenant and client ID again with the new value. Note the new expiry date somewhere you will see it.

A mailbox is skipped with "has no mailbox to back up"

The account is unlicensed, soft-deleted, or hosted on-premises. This is normal for service accounts, meeting rooms and departed staff, and is reported as information rather than as an error. If a mailbox you expect is listed here, check its Exchange Online license.

"Not every folder could be listed for this mailbox"

The listing was incomplete, usually from throttling or a network interruption. Nothing is lost and nothing is wrongly deleted — an incomplete listing never causes the client to conclude items are gone. The next backup picks up where this one left off.

A restore into the mailbox failed for calendars or contacts

The restore credential lacks Calendars.ReadWrite or Contacts.ReadWrite. The log names which. Add it in Entra, grant admin consent, and run the restore again. Mail restores are unaffected.

I restored a calendar and cannot find it

Look in the calendar list, not the mail folder tree. A restored calendar is a calendar, so it appears where calendars appear. Contacts likewise appear in the address book.

"The engine is busy"

A backup or another restore is running. The client runs one engine at a time by design. Wait for it to finish and try again.

Still stuck?

The backup log names the mailbox, folder and item for every decision it makes, and the restore log names the mailbox items went back into. Send the relevant log to support@wholesalebackup.com and we will take a look.

If you find anything in this guide unclear, please send your questions, comments and feedback to support@wholesalebackup.com and we will revise the guide accordingly.