How ShareMaster Archive works
Contents
Archive moves the CONTENTS of files you no longer open into storage you own, and leaves a small placeholder in SharePoint where each file was. The placeholder keeps the file's name, its history, its permissions and its place in the library, so nothing looks deleted and nothing moves. Clicking it fetches the file back. Every page about it is listed below - the three setup steps first, then how a run actually works.
What it does
- Your files' contents end up in YOUR Azure storage account, in YOUR subscription. ShareMaster never holds a copy and never sees the bytes.
- SharePoint keeps a placeholder in place of each archived file. Same name, same folder, same permissions, same item identity, same version history.
- Each run decides what clicking its placeholders does - Replace in place puts the file back, Download a copy hands back a copy - and writes that into each placeholder. The placeholder itself is a .shurl file, or a Windows .url shortcut for classic libraries. Setup makes both available, so each run can choose either.
- Setup runs once per organisation and has three steps. Archiving is then something you do as often as you like, and it reports before it changes anything.
- Nothing is archived by setup. Setup only builds the machinery.
How it runs
- Grant consent. Creates an application in your directory and asks an administrator to approve it.
- Configure Blob Storage. Creates or chooses the Azure storage account the file contents live in.
- Archive endpoint. Creates the endpoint in your own subscription that serves an archived file back, then registers the .shurl file type against it so clicking one works.
- Then: On Demand Archive. Choose an organisation, a scope and the rules. Report first by default; archive when you are ready.
How it works
Archive puts things in three places. In your Microsoft 365 tenant: one application registration called ShareMaster Archive, its consent grants, the .shurl file type registered on that application, and, in each library a run touches, the placeholders it writes and up to two hidden columns you opt in to. In your Azure subscription: a storage account with a private container for the file contents, a second container in the same account holding the endpoint's code, and the endpoint itself, a Function app on a pay-per-use plan with a managed identity. On this computer: the setup records, run history and reports.
What reaches ShareMaster's own servers is deliberately small. Setup records the tenant's id and display label against your ShareMaster account, and keeps a copy of each setup record there (ids, resource names, addresses and dates, never a credential) so another computer signed in to the same account finds the same setup. The endpoint asks sharemaster.io whether the tenant's archive is licensed, sending the tenant id, the action and its own version, never who clicked; if no answer comes, the file is served anyway. When the endpoint fails, it reports the kind of failure and the tenant id, never a file name or an address. The .shurl icons are public images served from sharemaster.io.
File contents never pass through ShareMaster. A run downloads each file from SharePoint to this computer and uploads it straight to your storage, and a click is served from your storage to the person who clicked. Every setup step reads what exists before it creates anything, creates only what is missing, and reads Microsoft's or Azure's own answer back before reporting success, so running a step again is safe and is how a half-finished setup is repaired.
What you need
- An administrator who can approve an application in your directory.
- SharePoint Administrator, for the tenant-wide .shurl file type.
- An Azure subscription you can create a storage account in, or one that already exists.
- A Storage Blob Data role on the archive account for whoever runs an archive - Owner is not one of them.
What it will not do
- Files carrying a retention label, including a record label, are never archived.
- Whether a SITE is under a retention policy or a legal hold is not checked. On a site that is, SharePoint can keep its own copy of every file archived there until the policy ends, so the space may not be freed.
- A file that is checked out is skipped.
- Version history is not moved, so a file with a very large history reclaims less than its current size suggests.
Contents
- Step 1: Grant consent: What application is created, what it can reach, and why it can reach no site at first.
- Step 2: Configure Blob Storage: What is created in Azure, how it is locked down, and what the redundancy and tier choices mean.
- No Azure subscription? How to fix it: When step 2 finds no subscription it can use: why, and what to do about each cause.
- The Archive app was given too much? How to fix it: When step 1 finds permissions beyond Sites.Selected: where to remove them.
- Things to look at on your storage account: What each finding on an existing account means, and where to change it in Azure.
- Step 3: Archive endpoint: The endpoint that serves a click, why it runs in your tenant, and what reaches us.
- The .shurl file type: Registered by step 3, and checking its availability in SharePoint.
- Running an archive, screen by screen: From the tile to the report: what each screen asks and when you are signed in.
- Record when files are restored: How the hidden library column protects recently restored files.
- Which files qualify, and which are refused: Age, size, excluded types - and the refusals no setting overrides.
- Report first, then archive: What Report only gives you, and how to act on what it found.
- ShareMaster link, or Windows shortcut?: Which KIND of placeholder a run leaves behind, and why one of them is recommended.
- Restore or download: what a click does: What each does when somebody clicks it, and why a run leaves only one kind.
- How a file is archived without risking it: The fixed order of the steps, and the line no failure is allowed to cross.
- What happens to previous file versions: Why a run can free nothing, and what recycling the older versions really does.
- Does a minimum size make archiving faster?: Only when the location holds a lot of small files - and by how much.
- What happens when someone clicks an archived file: The whole path, from the click to the file opening, and who is allowed to do it.
- Getting files back: One file, a library, or all of it - including without ShareMaster.
- Looking at what is in your archive: Browsing the container itself: what the folders are, and what a download is not.
- How much your archive holds: Files and space per site and library, and what else is in the container.
- What this costs, and how to undo it: Where the storage charges come from, and how to get every file back out.
- When something does not work: Each failure that has actually happened, what it means, and what to do.