Setup Guides: Overview & Prerequisites

Every tenant needs the same two things before a backup can run: Microsoft 365 admin consent, and a storage account of your own already created. Retention and BYOK are optional, additional steps on top of that baseline.

The baseline: two prerequisites

Connecting a tenant requires a Microsoft 365 admin who can grant consent to the Microsoft Graph permissions BYOVault requests — this is a real Microsoft Entra consent grant, not a password entered into BYOVault.

See Required Graph Permissions for exactly what is requested and why, and Your Own Azure AD App if your security team wants to register and consent to BYOVault as its own app inside your tenant, rather than using BYOVault’s default multi-tenant app.

Backups also need somewhere to write to: an Azure Blob Storage account or an AWS S3 bucket that you own, attached on the tenant’s Storage tab before the first backup runs.

Azure Storage Account and AWS S3 Bucket each walk through creating one from a new subscription, including the container, IAM identity, and access key BYOVault’s Storage form asks for.

File servers need one more step, per machine
Backing up an on-prem file server additionally requires installing the file server agent on that machine and pairing it to the tenant. This is separate from, and in addition to, the two prerequisites above — it does not replace the storage account, which remains tenant-wide. See Installing the File Server Agent.

Optional: retention and BYOK

Locked retention and customer-managed encryption keys are both opt-in, and each requires its own one-time setup on top of the baseline above.

Provisioning a Retention Vault covers turning on a locked, provider-enforced vault for a tenant — a separate storage account or container from the one backups are written into day to day.

The lock is irreversible by design
Once a retention vault is provisioned, its lock cannot be undone. This is a real storage-layer commitment, not a setting you can later relax.

BYOK replaces BYOVault’s default shared master key with a key that lives entirely in your own Azure Key Vault or AWS KMS.

BYOK on Azure Key Vault and BYOK on AWS KMS each cover creating the key and granting BYOVault the narrow, wrap/unwrap-only access it needs to use it.

What is in this section