What Happens During Offload?
Section titled “What Happens During Offload?”When a SharePoint Document Library item is offloaded to Microsoft Azure Blob Storage, the binary content of each selected version is stored as a separate blob.
In SharePoint, the original binary content of each offloaded version is replaced by a small reference file of less than 1 KB. This file contains the Azure Blob Storage reference in plain text.
To identify an offloaded version, SMART Offload adds the following prefix to its Check-In comment:
SMART Offload: <Timestamp> <File size>
Any existing Check-In comment is retained on the second line. All other item information remains unchanged, including metadata and version history metadata.
What Happens During Restore?
Section titled “What Happens During Restore?”Restore reverses the offload process. The binary content of the selected versions is restored to SharePoint, and the SMART Offload prefix is removed from their Check-In comments. Any original comments are preserved.
Choose What to Offload
Section titled “Choose What to Offload”You can offload the entire file, including its current version, or offload only historical versions while keeping the current version in SharePoint.
Keeping the current version in SharePoint preserves its availability for search indexing and Microsoft 365 Copilot.
Users with the appropriate permissions can continue editing the current version and creating new versions. These additional versions can subsequently be offloaded incrementally.
Tip: Inspect Individual File Versions
Section titled “Tip: Inspect Individual File Versions”Using Microsoft Azure Storage Explorer, administrators with the appropriate access can view and manage individual file versions stored as blobs. Versions in an online access tier can also be downloaded and opened directly. Archived blobs must first be rehydrated to an online tier.
Security and Connection to Azure Blob Storage
Section titled “Security and Connection to Azure Blob Storage”SMART Offload uses a Shared Access Signature (SAS token) as its authentication method for connecting to Microsoft Azure Blob Storage.
The SAS token allows you to define access permissions, a validity period and restrictions such as the public IP addresses permitted to connect. Treat the token as a credential and store it securely.
Blob Storage Access Tier
Section titled “Blob Storage Access Tier”SMART Offload uses the storage account’s default access tier when uploading blobs. Azure Lifecycle Management can subsequently move blobs to another tier, such as Archive, according to your configured rules.
Blobs moved to Archive must be rehydrated to an online tier before their content can be downloaded or restored to SharePoint.
Blob Naming Convention
Section titled “Blob Naming Convention”Each blob has a unique name that combines the SharePoint URL, version number and GUID.
Name format:
<SharePoint URL> <Version> <GUID in 8-4-4-4-12 format>
Example:
Tenant/sites/Site/Library/Folder/Filename 1.0 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Blob Index Tags
Section titled “Blob Index Tags”Blob index tags allow you to search for file versions within the blob container. Each stored file version is tagged using the fields listed below.
Azure stores index tag values as text. Use the specified formats when constructing queries, particularly for dates and file sizes.
| Tag name | Format | Description |
|---|---|---|
| RestoreDate | yyyy-mm-dd hh:mm:ss | The timestamp when the file version was last restored to a SharePoint Document Library. |
| UploadDate | yyyy-mm-dd hh:mm:ss | The timestamp when the file version was uploaded to Azure Blob Storage. |
| SharePointModifiedDate | yyyy-mm-dd hh:mm:ss | The value of the SharePoint [Modified] column. |
| Size | 12 digits, padded with leading zeros | The file version’s size in bytes. Leading zeros allow text-based comparisons to follow numeric order. |
| GUID | 8-4-4-4-12 | The value of the SharePoint [Unique Id] column. All versions of the same SharePoint file share this GUID. |
Important: Keep Hierarchical Namespace Disabled
Section titled “Important: Keep Hierarchical Namespace Disabled”SMART Offload requires a storage account with hierarchical namespace disabled. Keep this setting disabled to support the blob index tags and other storage features used by the solution.
See also