HomeAboutAll Posts

How LinkFixer Advanced Silently Destroys OneNote Notebooks on SharePoint Online

By Denis Molodtsov
Published in SharePoint
March 30, 2026
2 min read
How LinkFixer Advanced Silently Destroys OneNote Notebooks on SharePoint Online

How LinkFixer Advanced Silently Destroys OneNote Notebooks on SharePoint

If you’re planning a SharePoint migration and someone suggests using LinkFixer Advanced to preserve hyperlinks - keep it away from your OneNote notebooks. I documented this issue as a result of hundreds of Client’s OneNote files being damaged in a recent migration project. Do not repeat my mistake by testing only on Word or Excel files.

The Problem

LinkFixer Advanced’s “inoculation” process is designed to inject tracking metadata into files before a migration so it can repair broken links afterward. For Word, Excel, and PowerPoint files, this works fine - those are ZIP archives (OOXML), and LinkFixer stores its identifiers in a standard custom properties XML file inside the container.

OneNote files are different. The .one format is a proprietary binary revision store (MS-ONESTORE) - not a ZIP container. LinkFixer doesn’t simply inject a few bytes. It rewrites the entire file with a new structure, changing the file identity GUID, zeroing out the legacy version identifier, altering the file format GUID, and embedding its tracking artifacts (an XML property block, a 1x1 transparent GIF, and a PNG image).

This rewrite alone loses content. In our lab testing, readable text strings dropped by ~32% before SharePoint even noticed something was wrong.

Then It Gets Worse

Within minutes, SharePoint’s background converter detects the structurally invalid file and attempts to repair it. The result: an additional 38–59% file size reduction. The converter destroys page dates, formatting metadata, section references, hyperlink URLs, and revision history - while preserving LinkFixer’s injected artifacts intact.

The damage is two-stage:

  1. LinkFixer rewrites the file → content loss, broken GUIDs
  2. SharePoint converter “repairs” it → further content destruction

OneNote Desktop may refuse to open the damaged sections entirely, reporting them as “misplaced sections.” OneNote for the Web can sometimes still render partial content, which means users may not notice the damage immediately - they just keep editing on top of a corrupted binary.

How OneNote Versioning Saves You

Here’s the critical insight that makes recovery possible: normal OneNote editing never creates SharePoint version history.

OneNote syncs via the FSSHTTP/Cobalt protocol, which sends incremental binary deltas to SharePoint. These syncs increment internal counters but never bump the SharePoint UIVersion. A notebook can go through hundreds of edits and remain at version 1.0 with zero entries in version history.

When LinkFixer writes the modified file back to SharePoint, it uses a non-FSSHTTP channel (REST API or WebDAV). SharePoint recognizes this as an external modification and automatically snapshots the current clean file as version 1.0 before accepting LinkFixer’s write. This snapshot is your recovery point.

Detection

Any .one file at UIVersion 2.0 or higher was modified by something outside OneNote’s native sync. In environments where no other tools write to .one files, this is effectively the damage indicator.

For definitive confirmation, download the file and search the binary for the ASCII string LINKTEK. If present, it’s LinkFixer damage. This produces zero false positives.

Recovery

The fix is straightforward: restore version 1.0 from SharePoint version history using Restore-PnPFileVersion. The clean pre-inoculation snapshot contains all original content with no LinkFixer artifacts.

The catch: any edits users made after inoculation exist only in the damaged current version and will be lost when you restore. The sooner you act, the less work is at risk.

Key Takeaways

  • LinkFixer Advanced rewrites .one files - it doesn’t just inject metadata
  • The rewrite changes the file’s identity GUID, format GUID, and loses content
  • SharePoint’s background converter then destroys more content trying to repair the damage
  • Recovery is possible via SharePoint version history (the v1.0 snapshot)
  • Detection: UIVersion > 1.0 on any .one file, confirmed by LINKTEK string in the binary
  • Stop users from editing damaged notebooks immediately - every edit after inoculation is lost upon restoration

Tags

SharePointSharePoint Online

Share

Previous Article
Troubleshooting SharePoint "Sorry, You Don't Have Access"
Denis Molodtsov

Denis Molodtsov

Microsoft 365 Architect

Related Posts

Decoding the SharePoint Search Schema - A Guide to Crawled Property Prefixes
Decoding the SharePoint Search Schema - A Guide to Crawled Property Prefixes
March 30, 2026
2 min

Quick Links

AboutAll Posts

Social Media