Deploying a workspace key
A workspace can be created with encryption turned on, and the files published into it are then encrypted by the add-in on your own Windows machines under one key you generate and hold. This is how that key reaches every machine that needs it.
The key
One string on one line: SYNK1- and seven groups of eight, sixty-eight characters in all. It uses no letter that can be confused for a digit, case does not matter and spaces are ignored, so it survives being read down a phone line. The last four characters are a checksum, so a key with one character wrong is refused when it is pasted rather than quietly becoming a different key.
One key opens every workspace you own — each workspace's own identity goes into the derivation, so twenty of them under one key stay cryptographically unrelated. That is what makes this one deployment rather than one per job. Its id is sixteen hex characters, shown beside the workspace, and quoting it in a ticket says which key without sending the key.
Where a machine looks
Four places, in this order. The first key whose id matches the workspace wins.
- Every user of a machine
HKLM\SOFTWARE\Policies\Syncture → Keys, a REG_MULTI_SZ holding one key per line. What Group Policy and Intune write, and the first place looked at.
- A deployment package
Any *.key file under C:\ProgramData\Syncture\Config\Keys\, UTF-8, one key per line. Lines beginning # are notes.
- One signed-in user
The same REG_MULTI_SZ under HKCU\Software\Syncture, or any *.key file in %APPDATA%\Syncture\Keys\. For one architect on one laptop.
- A vault you already run
Either registry key's KeyFile value, holding a path to a file or a folder of them. Your tooling writes a file and Syncture reads a file, with no integration either way.
Nowhere else. There is no environment variable, no hidden location and no cloud fallback, and reading any of them needs no administrator rights, because the add-in runs as the user.
Putting it there
On one machine, in an elevated PowerShell window.
& ([scriptblock]::Create((irm https://syncture.com/key.ps1))) set SYNK1-… -MachineAcross an estate, whatever you already run writes one of those four locations: a Group Policy preference, an Intune Win32 app, an RMM package, or a scheduled task filling a KeyFile path from your vault. The exact click paths, fields and permissions are in the deployment handbook, which is written to be forwarded whole.
& ([scriptblock]::Create((irm https://syncture.com/key.ps1))) checkOne line per location, a tick or a reason, and never a key. It exits non-zero when a location holds something that is not a key, which is what an RMM reads as a compliance check.
Two rules
Add a key, never replace one
Every location holds a list and a machine picks the one whose id matches the workspace. Add the new key, prove it across the estate, then remove the old one. Overwriting the value in a single edit takes every machine dark at the next policy refresh.
Deploy before anybody publishes
A workspace's key cannot be changed after it is made. Lose it and the versions published into that workspace are gone, for you and for Syncture alike, and no support request changes that. A workspace nobody can open costs nothing; a workspace full of models nobody can open costs the job.