Read the following guide to find out all the important information about ShArc for IT administrators.
1. Introduction
Purpose of the Guide
This guide provides administrators with detailed instructions and background information for configuring, maintaining, and supporting the ShArc solution in Microsoft 365 environments. It serves as a technical reference for day-to-day operations as well as long-term lifecycle management.
Target Audience
The intended audience includes SharePoint administrators, Azure administrators, and IT personnel responsible for infrastructure integration and user support related to ShArc.
Overview of ShArc
ShArc is a solution for managing storage in SharePoint Online by relocating less frequently used content to Azure Blob Storage. The primary benefit is cost savings by offloading content to a more affordable storage tier. Additionally, this approach improves site performance and supports internal retention strategies. Users retain seamless access to their content while IT gains flexibility in managing storage growth.
2. System Overview
Architecture Components
ShArc consists of several key components, each playing a specific role in ensuring seamless offloading, secure data access, and integration with Microsoft 365:
- SharePoint Online: Hosts the original document libraries. Once files are offloaded, stub files remain in place and continue to be managed through the familiar SharePoint interface.
- Azure Blob Storage: Stores the offloaded content. Blob Storage is scalable, cost-efficient, and fully integrated into the Microsoft Azure ecosystem.
- Azure Table Storage: Stores information about incomplete files for automatic cleanup. Like Blob Storage, Azure Table Storage is scalable, cost-efficient, and integrated into the Azure ecosystem.
- ShArc App Service: A containerized web application running in the customer’s Azure tenant. It provides all backend logic and API handling necessary for policy execution, logging, and processing offload/restore events.
- ShArc Client (SPA): The web frontend (single page application) served by the App Service. Users and admins access this interface to trigger or monitor operations.
- Log Analytics Workspace (optional): If enabled, this component collects operational logs and system telemetry for diagnostics or usage monitoring.
- Azure Entra ID (formerly Azure AD): Provides centralized identity management, authentication, and role-based access control for all user interactions.
This architecture ensures that all data stays within the customer’s Azure environment and supports flexible deployment, scaling, and cost control.
Core Workflow: Offloading and Onloading
Offloading
Files in SharePoint libraries are selected for offloading based on defined policies (e.g. last modified date, file size).
ShArc moves the file content to Azure Blob Storage and replaces it with a stub file – a .sharc file containing a secure link to restore the file on demand. The stub retains:
- File metadata
- SharePoint file ID
- File path
- Original filename (plus .sharc extension)
Onloading (Restoring)
When a user opens a stub file, they are redirected to a ShArc page indicating the file is being restored. Once the onload is complete, the file is reinserted into SharePoint at its original location and opened automatically.
Access and Transparency
- Users interact with stub files like regular SharePoint documents via SharePoint, Teams, or OneDrive.
- Stub files can be moved, renamed, deleted, or edited in terms of metadata.
- All file metadata remains searchable. However, content-based search is only available after the file has been restored.
- End users experience minimal workflow disruption. The only visible difference is the presence of a .sharc file with a custom icon.
Technical Deployment Details
- All ShArc components are deployed in the customer's Azure tenant.
- The platform is designed to scale horizontally (adding more containers) and vertically (adjusting compute resources).
- ShArc supports various storage tiers (e.g. Hot and Cool) depending on the customer's performance and cost needs.
- The SPA runs fully client-side and only communicates with the ShArc API using valid, token-authenticated sessions.
- The backend server is containerized and communicates securely via HTTPS.
- Offloaded content never leaves the tenant’s cloud boundary.
Security Model
- All communication uses HTTPS with TLS encryption.
- Admin interfaces are only available to SharePoint or Global Admins.
- Only users with appropriate SharePoint permissions can view or trigger file restores.
- Every API call requires a valid access token.
- Authentication and authorization are enforced via Azure Entra ID using OAuth 2.0 (PKCE flow).
Scalability and Performance
ShArc is optimized for large-scale deployments:
- ShArc App Service can scale out across multiple containers.
- Azure Blob Storage supports geo-redundancy, lifecycle rules, and access tiering.
- Azure Table Storage supports geo-redundancy through the storage account.
- SharePoint throttling is mitigated using retry logic, exponential backoff, and ISV tagging.
3. Roles and Responsibilities
ShArc requires coordination across several administrative domains. The following roles are typically involved in setup, operation, and support:
SharePoint Administrator
- Configures and manages document libraries and site structures.
- Defines which sites or libraries are subject to offloading policies.
- Ensures permission settings align with ShArc access and restore processes.
- Supports end users with SharePoint-related access or visibility issues.
Azure Administrator
- Sets up and maintains Azure Blob Storage containers for ShArc.
- Manages authentication, authorization, and access policies between Azure and Microsoft 365, ensuring that required permissions are in place for ShArc to operate correctly.
- Monitors storage usage and ensures appropriate resource scaling.
- Maintains the hosting environment for the ShArc App Service.
ShArc Administrator
- Operates the ShArc management interface.
- Creates and adjusts offloading policies.
- Initiates restore jobs when needed (library/site/tenant level).
- Reviews logs and handles error scenarios.
- Serves as the primary point of contact for operational issues.
End User Support (Helpdesk / 1st-Level Support)
- Assists users encountering issues with stub files (e.g. access errors, missing files).
- Escalates technical problems to the appropriate admin (ShArc, SharePoint, or Azure).
- Communicates expected behavior and limitations of ShArc to end users.
Note: These roles describe functional responsibilities rather than distinct individuals. Depending on the organization's size and structure, one person may take on multiple roles.
4. Prerequisites
The following technical requirements must be met before installing and operating ShArc:
Microsoft 365 & SharePoint Online
- A Microsoft 365 tenant with active SharePoint Online usage.
- Admin access to manage SharePoint sites and libraries.
- Sufficient privileges to configure app permissions and site settings.
Azure Blob Storage Setup
- An Azure subscription with permission to create and manage Blob Storage accounts.
- A designated storage container for offloaded file content.
- Appropriate lifecycle and access policies defined in Azure to support durability and security.
Service Account Requirements
ShArc requires a dedicated Microsoft 365 service account for authentication and authorization when interacting with SharePoint Online and Azure resources.
Purpose of the Service Account
The service account is used by ShArc to:
- Access SharePoint Online for offload and restore operations
- Maintain access to all sites and libraries
- Execute automated background jobs
The service account is not tied to an individual user and should be treated as a long-lived technical account.
Licensing Requirements
The service account must be assigned a valid Microsoft 365 license that includes SharePoint Online and OneDrive access.
- A license such as Microsoft 365 Business Standard, Business Premium, E3, or E5 is sufficient.
- An E5 license is not mandatory; however, in environments with very large data volumes or intensive initial offloading, a higher license tier may help reduce SharePoint throttling.
The service account is not tied to an individual user and should be treated as a long-lived technical account.
Required Permissions
The service account must be assigned the following permissions:
- SharePoint Administrator role in Microsoft 365
- Site Collection Administrator permissions on all SharePoint sites that are processed by ShArc
To simplify permission management, ShArc provides an optional background job that automatically assigns the service account as Site Collection Administrator across all site collections at regular intervals. This is strongly recommended for production environments to avoid restore or access limitations when files are moved between sites.
Security
- ShArc does not impose any restrictions regarding Microsoft security features.
- Multi-Factor Authentication (MFA) is recommended for the service account.
- Privileged Identity Management (PIM) is not supported, as the service account requires permanent access.
Operational Notes
- During initial setup, a personal admin account can temporarily be used if a service account is not yet available; however, switching to a dedicated service account is recommended before moving to production.
- The service account may appear as “Modified by” only in edge cases where the original user no longer exists in the tenant (for example in case of deleted users).
- All actions performed by the service account are logged and auditable via Azure Log Analytics.
5. Licensing and Access
ShArc is licensed based on the total volume of SharePoint data actively offloaded to Azure Blob Storage.
License Metric
- Licensing is tied to the maximum offloaded storage volume, measured in 1 TB increments. Only the highest volume reached at any time counts toward the license.
- Once a file is restored to SharePoint, the corresponding storage capacity is released and becomes available again.
License Increments and Scalability
- Customers can begin with a small volume (e.g. 1 TB or 2 TB) and increase their license as needed. Upgrades to higher license tiers are possible at any time.
- A free proof-of-concept license is available.
Subscription Model
Licenses are provided as annual subscriptions and include:
- Technical support
- Regular software updates
- Full access to the ShArc platform
License Scope
- ShArc licenses are not tied to the number of users, SharePoint sites, or tenants.
- Multi-tenant and partner use is supported via separate agreements.
Temporary Overage Tolerance
- A 10% buffer beyond the licensed volume is allowed without technical enforcement or service interruption.
- This is intended to accommodate unexpected data growth, migrations, or restructuring.
- Customers will be proactively informed if usage approaches or exceeds the licensed threshold, and can choose to:
- Review and reduce storage
- Restore files
- Or upgrade to the next license tier
Tenant Binding and Transfers
- By default, licenses are bound to a specific Microsoft 365 tenant upon activation.
- Transfers between tenants are not supported by default but can be approved by Layer2 in special cases (e.g. mergers, reorganizations, managed service setups).
Compliance and Monitoring (coming soon)
ShArc will include built-in tools for license tracking and compliance:
- Usage Reporting – Displays total used and available storage in the admin interface.
- Threshold Alerts – Warnings when usage approaches 90% or exceeds the licensed volume.
- Grace Period – A 10% overage is tolerated before any escalation.
Azure Blob Storage Requirements
- In addition to the ShArc license, customers must have an active Azure subscription and provision Azure Blob Storage.
- Storage costs are billed directly via Azure and are not included in the ShArc license.
Customers can choose the storage tier that best fits their retention and access needs:
- Hot Tier – Optimized for frequent access. Highest cost per GB stored, lowest access cost.
- Cool Tier – For infrequently accessed data. Lower storage costs, but with higher access charges.
Support for additional tiers may be introduced in the future.
Access Control and Permissions
ShArc implements fine-grained role-based access control (RBAC) using Microsoft Entra ID (formerly Azure AD). Roles are enforced both within the ShArc application and across the underlying infrastructure.
Application-Level Roles in ShArc
- Administrator – Full access to configuration, policy management, logs, and monitoring
- End User – Can only view and restore their own archived files via the stub file interface; no access to configuration or policies
Infrastructure-Level Roles (Azure RBAC)
- Only designated Azure roles (e.g. subscription administrators, storage account owners) can access archived data at the Blob level
- Azure Storage RBAC and Conditional Access policies enforce least-privilege access
- All permissions are checked dynamically during key operations such as file restores, policy edits, and rule previews
This separation of access ensures that sensitive operations and storage access are tightly controlled and auditable.
6. Installation and Setup
ShArc is currently deployed via a PowerShell-based installation script. A designated team member will guide the customer through the deployment process. Prior to installation, a preparation email will be provided outlining the required steps and information.
7. Configuration Options
The ShArc user interface is structured around a set of core functional areas for offloading, restoring, and policy management, complemented by global UI controls for configuration, system information, and display preferences.
This section outlines the available configuration options and how they are accessed within the interface.
Core Functional Areas
Offload
Users can specify a SharePoint document library URL, site URL, or the tenant root URL.
Conditions for offloading currently include:
- Files not modified for a specified number of weeks
- File size greater than a specified threshold per file
- File extensions to be included or excluded
File extension filters can be used to explicitly include or exclude specific file types from offloading.
Excluded file types are ignored during estimation, simulation, and execution. All conditions are combined using logical AND.
Before starting the offload operation, ShArc provides two validation steps:
- An estimation that runs significantly faster and provides a rough, high-level indication of the expected number of matching files and data volume
- A simulation that evaluates the offload in detail and returns precise information about the files that would be processed
The simulation allows administrators to review the expected outcome before initiating the actual offload.
Restore
Allows administrators to specify a SharePoint target URL to restore previously offloaded files.
Restores apply to entire offloaded locations, based on the data stored in Azure Blob Storage.
Policies
The Policy Editor is the central interface for managing reusable offload policies across multiple sites.
- Policies can be created and assigned at Domain, Site, Subsite, or Library level
- Policies define the logic for what qualifies as offloadable data, such as age, size, and location
- Multiple conditions are combined using logical AND
- Policies can be adjusted or deleted directly within the UI
- Similar to SharePoint permission inheritance, policies are inherited through the hierarchy until they are overwritten by another policy
Scheduling
The Scheduling feature automates the execution of configured policies at regular intervals.
- Scheduling can be enabled directly on the Policies Editor page
- When enabled, the offload is triggered once immediately and then continues to run automatically based on the configured interval
- By default, the interval is set to run once per week after the previous offload has completed
- The interval is configured in the Settings menu, accessed via the gear icon in the upper right corner
- The value is expressed in hours and defines the waiting time between consecutive executions
- Changes to the interval take effect with the next scheduled run
- Updated or modified policies are automatically applied during the next scheduler cycle
- If SharePoint throttling occurs during scheduled runs, increasing the interval can help reduce load
Progress
The Progress view displays execution summaries of (simulated) offload jobs, including:
- Source URL
- Applied conditions
- Start and end time, including duration
- File count and size before and after offloading or restoring
- Percentage complete
Global UI Controls
In addition to the core functional areas, ShArc provides several global UI elements accessible from the upper right corner of the interface.
Information Menu
The Information menu, accessed via the small “i” icon, provides read-only system and context information, including:
- ShArc version and server-related status information
- The currently signed-in user
- Availability and behavior of direct file restore functionality, including platform-specific notes
This menu is intended to support diagnostics, verification, and support scenarios.
Settings Menu
The Settings menu, accessed via the gear icon, contains global configuration options that affect scheduling, storage configuration, pricing estimates, and tenant-level settings.
These settings include:
- Policy background scheduling intervals
- Azure Blob Storage configuration, such as the container used for offloaded files
- Pricing parameters used for internal cost estimation
- Tenant configuration, including the SharePoint URL and the configured Service Account
The Service Account can be changed directly from this menu.
Changing the Service Account is not possible while an offload or restore process is active.
Display Mode
A display mode toggle, represented by a sun or moon icon, allows switching between light mode and dark mode.
This setting affects only the visual appearance of the user interface and does not impact system behavior or processing.
9. Maintenance Tasks
ShArc is designed as an “always-on”, low-maintenance solution. The technical core typically requires no manual intervention. However, a few organizational and operational checks should be performed regularly to ensure consistent behavior.
Offload Configuration Review
Check if selected SharePoint URLs (sites/libraries) are still valid and relevant.
Ensure that offload thresholds (e.g. age, size) reflect current storage and performance objectives.
Validate that no business-critical or actively used content is unintentionally targeted.
Azure Cost Tracking
Regularly monitor Azure Blob Storage consumption and associated costs.
Validate that the storage tier, redundancy model, and lifecycle policies align with expected usage and budget.
Review Log Analytics cost impact if temporary logging is enabled.
Reviewing Policies
Regularly validate that offload conditions and logic match compliance and retention guidelines.
Adjust policy assignments when organizational structures or usage patterns evolve.
Token and Access Management
Monitor expiration of app credentials such as client secrets.
Version Updates
Updates to ShArc are announced via email.
To apply an update, a restart of the ShArc App Service in Azure is required.
It is recommended to monitor emails for version announcements and plan restarts accordingly.
Cleanup Routines
Remove deprecated policies or configuration objects.
Tenant-wide Access Sync
A background job ensures that the ShArc app account is explicitly registered as Site Collection Administrator on all SharePoint sites across the tenant.
This does not extend the app's permissions beyond what it already has via its Graph and SharePoint API scopes, but it makes its access visible in the site admin list.
The registration is essential to ensure restore functionality across sites, even if stub files are moved between locations.
10. Resources and Troubleshooting
The following official Layer2 ShArc resources provide additional guidance, tools, and documentation for administrators. These pages are maintained continuously and reflect the current product state.
Diagnostic and Log Access
System Setup and Configuration
Compliance and Operations
Product Maintenance