We (at coolOrange) do a lot of iterative configuration work against customer requirements — build a vault, apply a configuration, test it, adjust, repeat. Today the two operations at the heart of that loop are UI-only in the ADMS Console: Export Configuration and creating a new vault from a configuration file.
Everything either side of those two steps is already scriptable. Connectivity.ADMSConsole.exe covers backup, restore, defragment, purge, migrate, library attach/import/export and filestore validation. The DTU gets us the ability to load a fully developed Vault from a metadata package. The Web Services SDK gets us most of the way on the object model. But the moment we need to stand up a fresh vault from a known-good configuration, a human has to click through the console — which means it can't live in our build scaffolding, and the configuration itself can't be meaningfully version-controlled alongside the rest of our work.
The ask is simple: give us either
- CLI operations for creating a vault from a configuration file and exporting a vault's configuration (-Ocreatevault / -Oexportconfig / -Oimportconfig, or whatever fits your switch conventions), or
- an aggregated administrative API surface that covers the same ground, so we can drive it from PowerShell or .NET.
Either would do. We're not asking for anything the console doesn't already do — just a non-interactive way to reach it.
The payoff for us is that vault configuration becomes a source-controlled artifact we can diff, review and roll forward, and spinning up a disposable test vault stops being a manual chore. I'd guess we're not the only shop doing repeatable configuration work who'd use this.
Happy to elaborate on our specific workflow if it's useful.
Thanks,
@milt
