MetaConfig

MetaConfig fixes document metadata in place. It does not upload, move, rename, or delete anything. The files must already be in the library; what changes is the column values attached to them.

That constraint is the point. Most tooling that touches a document library can move content, which makes it something you schedule a change window for. MetaConfig can only write column values, and only the ones you listed, so the worst case is a metadata correction you can put back.

Why libraries end up wrong

Metadata rots quietly. A retention column gets added after ten thousand documents are already filed. A migration lands content with every managed column empty. A department renames a choice value and every historical document keeps the old one. None of this breaks anything loudly, so it sits there until search stops working, a retention policy fails to apply to the documents it was written for, or an auditor asks how you classify records and the honest answer is that most of them are not classified at all.

How a run works

1. Validate. The JSON is schema checked before any network call: required keys, known types, taxonomy shape. Choice values are checked against the column's own options, so a value that is not on the list fails the run before a single file is opened.
2. Resolve. Target one file, a list, or a folder. Each field is confirmed to exist on the library before anything is written.
3. Preview. A current versus proposed table prints for every field on every file. This always happens, on every run.
4. Snapshot. On apply, the current state of every targeted file is captured first. If the backup fails, the run aborts with nothing written.
5. Apply. Only when you pass -Apply. Results are reported per field, so one bad field does not abort the rest.

The undo is conflict-aware

A restore reads a snapshot and puts the captured values back, riding the same writer, the same gates, and the same transcript as any other apply, and staying report-only until you pass -Apply.

What makes it usable a week later is that it does not assume the world stopped. For every field it reports what was captured, what the run applied, what is live right now, and what it intends to do about it. If someone edited that field after the run you are undoing, it says Conflict instead of quietly reverting their work. If putting the captured value back means clearing a field that now has content, it says Clear rather than calling that a restore.

What it refuses to do

• Write anything without -Apply.
• Touch system and versioning columns (ID, FileRef, ContentTypeId, Created, Modified, Author, Editor, and others), even when the metadata file lists them.
• Accept a Choice value that is not one of the column's options. The check is case and whitespace sensitive, and there is no switch to override it.
• Apply without a backup. A failed snapshot aborts the run.

Requirements

PowerShell 7.4 or newer and PnP.PowerShell 3.x. Windows PowerShell 5.1 is not supported, because PnP.PowerShell dropped it at v2.0. Interactive sign-in needs an app registration client ID; app-only runs use a certificate.