
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.
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.
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:
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.
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.
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.
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.
.one files - it doesn’t just inject metadataUIVersion > 1.0 on any .one file, confirmed by LINKTEK string in the binary




