How Squirrel SharePoint Stubs Work: Technical Reference

What a Squirrel Stub Is

When Squirrel archives a file from a SharePoint document library to customer-owned Azure Blob Storage, the original file is removed from SharePoint and a small marker file - a stub - is left in its place. The stub serves two purposes: it preserves discoverability of the archived item in the SharePoint interface, and it provides the click-target that triggers transparent restoration when the file is needed again.

This page documents what a Squirrel stub actually does, what it preserves from the original file, and how it behaves under common SharePoint operations. The intent is to give SharePoint administrators, M365 architects, and compliance teams a precise reference rather than a marketing summary.

Stub Filename and Extension

The stub preserves the original filename and appends .html as the file extension.

Original file	Stub in SharePoint
Q4-Forecast.xlsx	Q4-Forecast.xlsx.html
Contract-2024.docx	Contract-2024.docx.html
Architecture-Design.pdf	Architecture-Design.pdf.html
Engineering-Spec.dwg	Engineering-Spec.dwg.html

The doubled extension is deliberate. The original filename and extension are preserved verbatim so that users searching by name or filtering by file type can still find the archived item. The trailing .html makes the stub an HTML file from SharePoint's perspective, which means the stub click-through happens through the browser HTML handler. When a user clicks the stub, the browser opens the HTML payload and the restore action is triggered from there.

Implications:

• SharePoint search indexes the stub as an HTML file rather than as the original Office document type. Search by filename still works because the original filename is preserved in the stub name; search by full-text content reflects what is in the HTML stub rather than the archived file body.
• SharePoint filters by file extension that filter on .xlsx, .docx, etc. will not match stubs. Filters on .html will.
• Microsoft Copilot grounding sees the stub as HTML content. Where archived content needs to remain grounded in Copilot, Nutshell AI embeds a summary of the original document in the HTML stub so the semantically relevant content remains in the index.

Metadata Preservation

The stub preserves the metadata of the original file and the original modified date.

What carries forward onto the stub:

• Custom SharePoint column values - project codes, classification metadata, business owners, retention designations, custom dropdowns
• Original modified date - the stub appears with the same last-modified timestamp as the original file, so views sorted by date show stubs in their correct chronological position
• Author / Created By field metadata
• Standard SharePoint document properties that the parent library tracks

This means views, filters, and reports that depend on SharePoint metadata continue to function across archived content without modification. A SharePoint view that lists all documents owned by a specific business unit shows stubs alongside active files in the correct positions.

For the full lifecycle context of how SharePoint metadata interacts with archiving, see SharePoint document libraries and SharePoint document library sizing.

Stub Permissions

The stub inherits permissions from the parent SharePoint library.

This is a deliberate architectural choice with two consequences:

1. Library-level permissions carry through. Anyone who has access to the parent SharePoint library can see and click the stub. The stub does not introduce a new permission boundary - it inherits the existing one.

2. Per-item shares on the original file are released at archive time. If the original file had specific sharing relationships - an external guest with explicit access to that single file, a "Specific people" share, an "Anyone with the link" anonymous URL - those shares are released along with the file. The stub does not carry forward those file-specific shares.

The practical implication for sharing lifecycle: shares on archived files do not survive the archive event. If external access to an archived file is required again after restore, a fresh share must be issued. For the broader context of how Squirrel's file-level model compares to Microsoft's native site-level Microsoft 365 Archive, see Squirrel vs Microsoft 365 Archive in 2026.

Restore Mechanics

When a user clicks a Squirrel stub, the original file is restored from Azure Blob Storage back into SharePoint with full fidelity:

• The original file - the actual bytes of the original document, not a derivative or summary
• All versions - every version that existed on the original file when it was archived is restored, in original chronological order
• All metadata - custom column values, dates, author information, document properties
• Same SharePoint item identity - the restored file occupies the same item position the stub occupied, preserving any view ordering or report referencing

Restoration is not "create a new SharePoint item from archive bytes" - it is "rehydrate the original SharePoint item." Post-restore, the file is materially indistinguishable from its pre-archive state in terms of content, version history, and metadata.

The one element that does not carry through restoration is the file-specific sharing relationships that were released at archive time. The restored file has the parent-library default permissions; any external access required after restore needs a fresh share.

External Guest Behaviour

External guest users with access to the parent SharePoint library can click a stub and trigger restoration.

This is sometimes assumed to be an internal-users-only operation, but it is not. The stub click-through is a SharePoint operation against an item the guest has library-level access to read, and Squirrel processes the restore action regardless of whether the requesting identity is an internal user or an external guest with the same library access.

The practical implication: external partners collaborating on a SharePoint library that contains archived content do not need to involve an internal administrator to access archived files. They click the stub like any other SharePoint item and the archived file is rehydrated transparently into their workflow.

The guest cannot, however, recover a file-specific share that was on the original file - that share was released at archive time. The guest can access the restored file because they have access to the parent library, not because the original file-specific share persisted.

Where Stubs Appear in the Microsoft 365 Surface Area

Squirrel stubs are visible across the Microsoft 365 surfaces where SharePoint document library items are visible:

• SharePoint web interface - stubs appear in document libraries with their preserved filename and metadata
• OneDrive Sync client on Windows and macOS - synced libraries surface stubs in the file explorer with the .html extension visible
• Microsoft Teams - stubs appear in the Files tab of any channel backed by a SharePoint document library

Stubs do NOT currently appear in Office Online (the in-browser Word/Excel/PowerPoint editing surfaces) or in Office desktop applications when opening files directly from those apps. Mobile coverage varies by client; admins evaluating Squirrel for mobile-heavy environments should validate the specific mobile client behavior against their tenant.

Implications for SharePoint Operations

The technical behavior of stubs affects how they interact with common SharePoint operations:

• Search by filename works - the original filename is preserved in the stub name
• Search by full-text content returns the stub HTML body unless Nutshell AI summaries are enabled for the library, in which case the embedded summary of the original document is indexed
• Document properties view shows preserved metadata; users see stubs in their correct positions in views sorted by date or filtered by custom columns
• Sharing actions on stubs create shares on the stub item; if the file is later restored, the share is on the restored item (which now has library-default permissions, not the original's file-specific shares)
• Deletion of a stub removes the stub from SharePoint and triggers the Squirrel deletion workflow against the archived file in Azure - subject to the customer's Squirrel retention policy, which controls whether the archive is deleted, retained, or held
• Renaming a stub is supported in current Squirrel versions; the rename does not affect the underlying archived file in Azure

Implications for Microsoft Copilot Grounding

By default, Microsoft Copilot grounds on what is in the SharePoint search index. An HTML stub with no semantic content from the original file would not provide Copilot with useful grounding signal.

Nutshell AI addresses this by generating summaries of archived documents and embedding them in the HTML stub body. With Nutshell enabled, Copilot continues to find archived content in its grounding pass and surfaces it in responses with the original filename, preserved metadata, and the AI-generated summary - while the actual document bytes sit in customer-owned Azure Blob Storage outside the SharePoint pool.

For the full Copilot integration model, see Microsoft Copilot and archived SharePoint content.

Implications for Data Loss Prevention and Sensitivity Labels

Stubs are HTML files from SharePoint's perspective. This affects how DLP policies and sensitivity labels apply to them:

• DLP content scanning on the stub scans the HTML body, not the original file content. Sensitive information types that were detectable in the original Office document may not be detectable in the stub HTML.
• Sensitivity labels applied at the library or site level apply to the stub through container labelling. Sensitivity labels applied to the original file are released along with the file at archive time, similar to file-specific sharing relationships.
• Trainable classifiers applied to the library evaluate the stub HTML content.

For most compliance scenarios, the recommended pattern is to apply sensitivity labels at the library or container level so that they apply both to active content and to stubs uniformly, rather than relying on per-file labelling that is released at archive time.

For the design distinction between sensitivity labels and retention labels in SharePoint, see sensitivity labels vs retention labels in SharePoint.

What Stubs Are Not

To eliminate ambiguity in vendor evaluations, the following are common assumptions about stub behavior that do NOT apply to Squirrel:

• Stubs do not preserve file-specific sharing relationships from the original file
• Stubs do not preserve file-specific sensitivity labels applied to the original file at the per-item level
• Stubs do not appear in Office Online or Office desktop applications when files are opened directly from those apps
• Stubs are not placeholders that automatically rehydrate on any access - the user must explicitly click the stub or trigger restore through the Squirrel admin interface
• Stubs are not standalone archive references that can be moved to other tenants - the link between the stub and the archived file in Azure is bound to the customer's Squirrel deployment

Frequently Asked Questions

Q: What file extension does a Squirrel stub have?

A: The stub preserves the original filename and appends .html. So Report.xlsx becomes a stub named Report.xlsx.html in SharePoint.

Q: Does the stub preserve the original modified date?

A: Yes. The stub shows the same last-modified timestamp as the original file, so views sorted by date and date-based filters continue to work correctly.

Q: Can an external guest user trigger a Squirrel restore?

A: Yes, provided they have access to the parent SharePoint library. The stub click-through is a SharePoint operation against an item the guest has library-level read access to, and Squirrel processes the restore action regardless of whether the requesting identity is internal or external.

Q: When a stub is restored, what comes back?

A: The original file with all its versions, all its metadata, and the same SharePoint item identity. The restored file is materially indistinguishable from its pre-archive state.

Q: What permissions does the stub have?

A: The stub inherits permissions from the parent SharePoint library. File-specific shares that existed on the original file (external guest grants, "Specific people" links, "Anyone with the link" URLs) are released along with the file at archive time and do not carry forward to the stub.

Q: Are stubs visible in OneDrive Sync and Microsoft Teams?

A: Yes. Stubs appear in SharePoint web, OneDrive Sync (Windows and Mac), and Microsoft Teams (in the Files tab of channels backed by SharePoint libraries). They do not appear in Office Online or Office desktop applications when opening files directly from those apps.

Q: How does Microsoft Copilot interact with archived content?

A: By default, Copilot grounds on the HTML stub body, which has limited semantic content. With Nutshell AI enabled, Squirrel embeds an AI-generated summary of the original document in the stub HTML so Copilot continues to find archived content in its grounding pass.

Q: What happens if a user deletes a stub?

A: Deleting the stub triggers the Squirrel deletion workflow against the archived file in Azure Blob Storage, subject to the customer's Squirrel retention policy. The retention policy controls whether the archive is deleted immediately, retained for a defined period, or held indefinitely.

Related References

For the broader Squirrel architecture and feature set:

• Squirrel overview - the product page
• Squirrel Recycle Bin Capture - the deletion-preservation feature that intercepts deletions before they reach the Preservation Hold Library
• Nutshell AI - the Copilot grounding feature for archived content
• SharePoint archiving guide - the design context for file-level archiving
• Enterprise buyer's checklist for SharePoint archiving - the evaluation reference
• How to replace the SharePoint Preservation Hold Library - the cost-control story
• Microsoft Copilot and archived SharePoint content - the Copilot integration model