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 in the 8.0.1.743 version

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. In-place metadata injection is not possible on this format, so LinkFixer doesn’t even try. Binary reflection of LinkFixer.exe shows its OneNoteFileHandler class delegates every .one operation to a bundled third-party library, Aspose.Note for .NET (version 25.6.0.0), via a four-step pipeline: load the file into Aspose’s in-memory model, walk the pages to find hyperlinks, mutate them, then call Aspose.Note.Document.Save() to write the whole file back in place.

That last step is where the damage starts. Aspose.Note’s save path is a lossy round-trip. It can only re-emit the subset of OneNote features its object model represents: plain and styled text runs, basic hyperlinks, simple images, basic tables, page outlines. Everything else - ink strokes, embedded file attachments, audio/video, math equations, complex drawings, custom tags, author attribution, sub-page hierarchy, internal revision history, and any extensibility blobs Microsoft has added to MS-ONESTORE that Aspose hasn’t implemented - is silently discarded because it was never in the model on load. The file LinkFixer uploads back to SharePoint is already smaller and already missing content, and Aspose raised no exception to tell LinkFixer anything was lost.

Then It Gets Worse

Around 8 minutes after LinkFixer uploads the file, SharePoint’s server-side OneNote file handler runs a background normalisation pass on the non-Cobalt write. This is not triggered by user access - it runs on every affected file regardless of whether anyone opens the notebook. The converter further modifies the file, compounding the Aspose-side loss: additional size reduction, a new file identity GUID, and further stripping of OneNote’s internal revision history. End-to-end, files come out 38-59% smaller than the original and missing page dates, formatting metadata, section references, hyperlink URLs, and revision history. LinkFixer’s injected artifacts (an XML property block, a 1x1 transparent GIF, a PNG image) survive both stages intact.

The damage is two-stage:

1. Aspose.Note’s lossy save (client-side, immediate) → content outside Aspose’s object model is silently dropped
2. SharePoint’s background converter (server-side, ~8 min later) → further content destruction during normalisation

OneNote Desktop may refuse to open the damaged sections entirely. 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.

The critical implication: this procedure is unsafe even if LinkFixer’s own logic is perfect. LinkFixer could identify every hyperlink correctly and rewrite every URL to exactly the right new path, and Aspose.Note’s save would still destroy the content that falls outside its model. There is no flag, option, or LinkFixer version upgrade that changes this, because Aspose.Note is the only OneNote engine LinkFixer has.

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 one of the two methods:

1. Restore-PnPFileVersion. The clean pre-inoculation snapshot contains all original content with no LinkFixer artifacts.
2. Navigate to the storage metrics, find the damaged .one and .onetoc2 files, and restore the previous version from there. You will need to click on Version History for both the .one and .onetoc2 files.

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 has no OneNote engine of its own - it delegates every .one operation to Aspose.Note for .NET and uses Document.Save() to write files back
• That save is a lossy round-trip - anything outside Aspose’s object model (ink, embeds, equations, drawings, revision history, etc.) is silently dropped
• SharePoint’s background converter then runs ~8 minutes later and destroys more content during normalisation
• The procedure is unsafe by construction - even flawless link-matching logic cannot rescue a lossy save
• 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