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. 

The intended audience includes SharePoint administrators, Azure administrators, and IT personnel responsible for infrastructure integration and user support related to 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. 

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. 
• 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. 

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 .url 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. 

• 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. 

• 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. 

• 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). 

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. 
• SharePoint throttling is mitigated using retry logic, exponential backoff, and ISV tagging. 

ShArc requires coordination across several administrative domains. The following roles are typically involved in setup, operation, and support: 

• 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. 

• 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. 

• 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. 

• 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. 

The following technical requirements must be met before installing and operating ShArc: 

• 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.

• 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. 

ShArc is licensed based on the total volume of SharePoint data actively offloaded to Azure Blob Storage. 

• 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. 

• 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. 

Licenses are provided as annual subscriptions and include: 

• Technical support 
• Regular software updates 
• Full access to the ShArc platform 

• ShArc licenses are not tied to the number of users, SharePoint sites, or tenants. 
• Multi-tenant and partner use is supported via separate agreements. 

• 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 

• 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). 

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. 

• 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. 

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. 

• 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 

• 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. 

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. 

The ShArc user interface currently consists of three main functional areas: Offload, Restore, and Progress. This section outlines available and planned configuration options. 

Offload 

• Users can specify a SharePoint document library URL, site URL, or the tenant root URL. 
• Conditions for offloading currently include: 
• File(s) not modified for a specified number of weeks 
• File size greater than a specified threshold (per file) 
• All conditions are combined using logical AND. 
• The preview displays an estimated number of files that match the criteria before starting the offload operation. 

Restore 

• Allows admins to specify a SharePoint target URL to restore previously offloaded files. 
• Restores apply to entire offloaded locations, based on what's stored in Azure. 

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 (age, size, location) and can combine multiple filters using AND logic.
• Policies can be adjusted, disabled, or deleted directly within the UI.
• Scheduling
  ∘  The Scheduling feature automates the execution of configured policies at regular intervals.
  ∘  Scheduling can be enabled directly on the Policies Editor page.
  ∘  When Scheduling is enabled, the offload is triggered immediately once and then continues to run automatically based on the configured interval.
  ∘  By default, the interval is set to run once every week after the previous offload has completed.
  ∘  The interval can be adjusted in the Settings (gear icon in the upper right corner). The configuration is expressed in hours, defining the waiting time between consecutive executions.
  ∘  Adjustments to the interval will take effect on the next scheduled run.
  ∘  Updated or modified policies are automatically applied during the next scheduler cycle.
  ∘  If SharePoint throttling occurs during scheduled runs, increase the interval between executions to reduce load.

Progress 

Displays execution summary of offload jobs: 

• Source URL 
• Conditions applied 
• Start/end time, duration 
• File count and size before/after offloading 
• Percentage complete 

For current information on how logging is handled in ShArc, including access to temporary Log Analytics-based logging, please refer to: 
https://www.layer2-sharc.com/temporary-log-analytics-logging 

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. 

• 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. 

• 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. 

• Regularly validate that offload conditions and logic match compliance and retention guidelines. 
• Adjust policy assignments when organizational structures or usage patterns evolve. 

• Monitor expiration of app credentials such as client secrets. 

• 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. 

• Remove deprecated policies or configuration objects. 

• 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. 

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. 

• How to Get the Logs: https://www.layer2-sharc.com/how-to-get-the-logs 
• Temporary Analytics Logging: https://www.layer2-sharc.com/temporary-log-analytics-logging 

• Deployment Guide: https://www.layer2-sharc.com/deployment 
• Change Service Account: https://www.layer2-sharc.com/change-service-account 
• Windows File Association: https://www.layer2-sharc.com/windows-file-association 

• Security Measures: https://www.layer2-sharc.com/security-measures 
• Known Issues: https://www.layer2-sharc.com/known-issues 

• Change Log: https://www.layer2-sharc.com/change-log