SharePoint carries its own instructions in its name, and almost nobody reads them. It is a point — singular, fixed, the place everyone agrees to look. From a PMBOK perspective it is where a baseline lives once it has been approved through Perform Integrated Change Control. From a PRINCE2 perspective it is where the Project Board’s signed-off Business Case sits, permissioned so that only the PM and named stakeholders can touch it. The whole governance model — audit trail, version history, access control — depends on there being exactly one point, not two.
This is the story of how a routine move to Azure Virtual Desktop quietly turned that one point into two, without a single warning dialog, error message, or failed save. Nothing broke. Nothing looked wrong. That is precisely what makes it dangerous.
What Governance Actually Requires From a Repository
Before diagnosing what went wrong, it is worth being precise about what a controlled document repository is actually promising. It is not just storage. It is three specific guarantees, and a project management framework only works if all three hold at once.
Authorisation
A document reaches the repository only after the right people have approved it — a Charter signed off under Develop Project Charter (PMBOK 4.1), or a Business Case approved by the Project Board under PRINCE2. The repository is downstream of a decision, not a substitute for one.
Version Control
There is one lineage. Every save is a new version of the same document, not a new document that happens to share a name. When someone says “the latest schedule,” there is exactly one file that claim can point to.
Access Control
Permissions are set at the repository, not at the device. The PM, the Board, and named stakeholders can edit; everyone else can read or nothing at all. This is what makes the repository auditable — the permission list is the governance control.
Notice what none of those three guarantees say anything about: which application you opened the file in, or which device you were sitting at. They are properties of the repository. The moment a save can silently land somewhere that carries none of those three guarantees, governance has not been weakened — it has quietly stopped applying at all, for that copy.
The Day the Repository Split in Two
Here is the scenario, and if it sounds familiar, that is because it is happening in a great many tenants right now, usually discovered by accident.
An organisation moves its knowledge workers to Azure Virtual Desktop. You install the Microsoft app, sign in, and land on a VDI session that looks and feels like your normal desktop. You navigate to SharePoint, open the project repository, find the folder structure you have used for months, and open the project schedule. You edit it. You save it. Everything about the experience tells you that you just updated the controlled copy of the schedule — the one the Project Board expects to be reading from, the one that has to survive an audit.
You do this for several days. Then, for whatever reason — a different machine, a day working from your own desktop rather than the VDI — you open SharePoint directly, outside the virtual session. None of your changes are there. Not one. The document sitting in the governed, permissioned, audit-ready repository is days out of date, and it does not know that a different, edited version of itself exists anywhere.
Every save succeeded. Windows did exactly what it was configured to do. The document you edited for days is not lost, corrupted, or unsynced in the way people usually mean by that word. It is sitting somewhere else entirely — in a personal store, under your name, with no Project Board permission on it, no audit trail tying it to the project, and no relationship to the copy everyone else is still reading.
Known Folder Move: The Mechanism Nobody Told You About
The feature responsible has a name, and it is not a bug: Known Folder Move (KFM). Microsoft’s own documentation on redirecting Windows known folders to OneDrive describes exactly what it is designed to do — redirect a user’s Desktop, Documents, Pictures, Screenshots, and Camera Roll folders so that they are physically stored in that user’s personal OneDrive, while looking, to every application including Office, exactly like the familiar local folder they have always been.
That is the entire trick, and it is a good one for its intended purpose. A user does not have to change a single habit. They keep saving to “Documents” the way they always have. Office keeps defaulting there. File Explorer shows the same path. Nothing in the interface distinguishes a KFM-redirected Documents folder from an ordinary one — by design, because the entire point of the feature is that the user should never notice.
Now put that feature inside a VDI session. An Azure Virtual Desktop session typically runs on a non-persistent machine image with a separate, session-scoped user profile — often managed through FSLogix profile containers — that has its own OneDrive sync client state. That sync relationship is entirely independent of whichever sync relationship your physical desktop maintains under the same identity. A SharePoint document library that is synced or added as a shortcut is a separate relationship again, governed by its own permissions and its own sync engine, unaffected by whether KFM happens to be switched on. Three independent stores, one human being, and nothing in the interface that flags which one just received your edit.
Three sync relationships, one identity: a SharePoint library, a VDI session’s redirected OneDrive, and a physical desktop’s redirected OneDrive — none of them aware of the other two.
| Where the Save Actually Landed | Who Controls Access | Does the Board’s Sign-Off Apply | What an Audit Finds |
|---|---|---|---|
| SharePoint document library | Permissions set on the library — PM, Board, named stakeholders | Yes — this is the point the Business Case was approved at | A clean version history tied to the approved baseline |
| VDI session’s redirected OneDrive | The individual user, personally — no Board, no PMO | No — this copy was never presented to the Board | An untracked file with no relationship to the project record |
| Desktop’s redirected OneDrive | The individual user, personally — a different cache again | No — and possibly out of date with the VDI copy too | A third timestamp, agreeing with neither of the other two |
Idempotency, Properly Defined
It is worth borrowing a term from software engineering here, because it names the failure precisely. An operation is idempotent if performing it once, or performing it many times, leaves the system in exactly the same resulting state. Pressing a lift call button twice does not summon two lifts. A well-designed API call that sets a record’s status to “approved” produces the same end state whether it is called once or accidentally called five times.
A controlled document repository makes an implicit idempotency promise of its own: opening the project schedule, editing it, and saving it should converge on one current state, no matter which device, which session, or which day you did it from. That is what “single source of truth” actually means in operational terms — not just that a single copy exists, but that the act of updating it is idempotent with respect to location. Save the schedule from the VDI on Monday, save it again from your desktop on Tuesday, and you should get one schedule, twice updated — not two schedules, once each.
When the same nominal action — open the schedule, edit, save — produces two different resulting states depending on which redirected folder happened to be listening, the operation has stopped being idempotent. This is not a sync delay or a conflict that will resolve itself. It is a structural fork, and nothing in the workflow was designed to notice or repair it.
Artefacts, Versions, and Two Different Meanings of “Latest”
The word “artifact” means two related but distinct things, and the gap between them is exactly where this problem lives. In PMBOK terms, an artefact is a project management document or deliverable — a Scope Statement, a schedule, a Business Case — a thing with governance status attached. In software configuration management, an artefact is an immutable build output tied to a specific commit in a version-controlled history, where every fork is deliberate, visible, and eventually merged.
Engineering tolerates branching precisely because it is disciplined about it. A branch is created on purpose, is visible to everyone with access to the repository, and is merged back through a reviewed process that reconciles the differences. SharePoint’s version history assumes the same discipline for project artefacts: every save checks in as the next version of the same lineage, visible to anyone who opens the version history pane.
A OneDrive shadow copy created by folder redirection has none of that discipline. It is a branch nobody created on purpose, that nobody else can see, with no merge process and no review — the worst combination available: branching without visibility, and no reconciliation ceremony to bring it back. It is not really a version of the artefact at all. It is a separate document that happens, for now, to share the artefact’s content and filename.
Why the Board’s Sign-Off Might Not Mean What You Think
This is where the PRINCE2 and PMBOK governance model actually breaks, not just the file sync. A Project Board approves a Business Case at a specific version, found at a specific, secured location. That approval is only meaningful if the approved copy and the copy the PM is actually working from are provably the same file. If the PM has spent the preceding week editing that Business Case through a VDI session with Known Folder Move quietly redirecting Documents to a personal OneDrive, the “latest” version the PM has in front of them during the Board meeting may never have touched the governed repository at all.
Now run the audit. Which timestamp does the auditor trust — the SharePoint version history, showing nothing edited in three weeks, or the PM’s laptop, showing daily edits the whole time? Both are honest records. Neither is wrong. They are simply records of two different files that both, at some point, believed themselves to be the project schedule.
Signs Your Organisation Already Has Two Versions of the Truth
- Controlled documents get opened via a desktop shortcut or a mapped drive, with nobody checking whether that path actually resolves to the SharePoint library
- Known Folder Move is switched on tenant-wide with no separate policy for non-persistent VDI or AVD sessions
- Nobody can say, for a specific controlled document, which device holds the authoritative copy right now
- A schedule or Business Case is edited for days without anyone checking the SharePoint version history to confirm the edits actually arrived
- The Project Board signs off a document version without anyone confirming it is the same file currently open on the PM’s machine
- Controlled documents are always opened directly from the SharePoint library — via the browser or “Open in Desktop App” — never via a locally redirected folder shortcut
- Known Folder Move and OneDrive sync are explicitly scoped, or disabled, for VDI and AVD session profiles
- SharePoint version history is checked before every Board sign-off, not assumed to be current
- IT and the PMO agree, in writing, on which repository is authoritative before any migration to Azure or VDI begins
Why the Azure Default Is, Frankly, Crazy
None of this is a software defect in the sense of something failing to work as designed. Known Folder Move works exactly as documented. That is the crazy part. It was designed to solve a consumer-grade problem — a user losing their files when a laptop dies — by silently substituting a personal cloud store for a folder name the user already trusted. That default is reasonable for a home user’s Desktop. It is not reasonable applied, by default, to a knowledge worker whose “Documents” folder is where they open project artefacts from a governed, permissioned, audited repository.
Three things make this genuinely dangerous rather than merely inconvenient. First, it is silent: there is no dialog that says “this save just went to your personal OneDrive, not the SharePoint library.” Second, it is session-scoped in a VDI context: a physical desktop and a VDI profile can each maintain their own independent redirected OneDrive under the very same identity, so even a user who understands KFM perfectly on their own laptop can be caught out the first time they touch a VDI session with a different profile state. Third, and worst, there is no failure: the save reports success, because as far as Windows is concerned, it saved the file exactly where it was told to — the Documents folder. It is the organisation’s assumption that Documents still means the SharePoint library that quietly stopped being true.
This is a governance gap, not purely a technical one — and it is closable with the right tenant policy, covered below. But it is closable only because someone went looking for it. Nothing about the default experience invites that search.
What To Actually Check
- Confirm, for every controlled project repository, whether it is set up in SharePoint as a synced library, a OneDrive shortcut, or opened purely through the browser — these are three different relationships with different failure modes, and most teams cannot currently answer this question.
- Check whether Known Folder Move is enabled by policy on the Azure Virtual Desktop image or FSLogix profile, and whether that policy differs from the one applied to physical desktops in the same tenant.
- Standardise on opening controlled documents directly from the SharePoint library — via the browser, or Office’s “Open in Desktop App” from within SharePoint — rather than through a local Documents shortcut, on every device including VDI.
- Before any Board or governance sign-off, open the document’s version history in SharePoint directly and confirm the most recent version matches what is being presented, rather than trusting that a save on someone’s machine reached the repository.
- Where VDI or AVD is non-persistent, treat that as a reason to disable or tightly scope Known Folder Move on the session profile, since there is no long-lived local state worth protecting there in the first place.
- Get IT and the PMO to jointly document, in the project’s Configuration Management Strategy or equivalent, exactly which repository is authoritative and exactly how it is accessed — before, not after, a VDI or Azure migration.
Conclusion: Take the Point Back
A repository is not a folder that happens to look familiar. It is a set of guarantees — authorisation, version control, access control — that only hold if every save actually lands there. Azure Virtual Desktop did not remove those guarantees from SharePoint. It simply made it easier than it has ever been for a save to quietly land somewhere those guarantees do not apply, without a single signal that anything unusual happened. The fix is not exotic. It is the same discipline PMBOK and PRINCE2 have always demanded of a controlled repository — know, provably, where the point actually is — applied one layer earlier, to the folder redirection settings nobody thought to audit until the version history told them the truth.
Further Reading
This article draws on Microsoft’s own documentation for Known Folder Move and OneDrive/SharePoint sync behaviour, alongside PMBOK and PRINCE2 configuration management principles.