20-20-20 Vision for Workplaces · last updated 03/09/2026
Two files reach your machines: your settings, and the application. This page covers putting both in place across an estate, by Group Policy, by Intune, or by a script for organisations that run neither. A single machine takes about five minutes; a fleet takes as long as your existing tooling takes to push an MSI.
If you are being asked what this software does on an endpoint before you are allowed to deploy it, that is the security & IT reference, and it is written to be forwarded without editing.
| Operating system | Windows 10 or 11, x64 |
|---|---|
| Rights | Local administrator to install. The application itself never needs elevation and never asks for it |
| Identity | Active Directory or Entra ID. A licence belongs to a person rather than a machine, so there has to be a directory account to recognise them by. Standalone machines with local accounts are not a fit for Workplaces |
| Network | Outbound HTTPS to admin.20-20-20-vision.com,
and nothing else |
| From us | The installer (per-machine MSI) and the Group Policy template, both under Settings → Download in your dashboard. If no release has been published to your organisation yet, ask and we will send both directly |
| From your dashboard | Your organisation key. One key for the whole estate; nobody types a licence key on a machine |
This is the only part of the page worth reading if you read nothing else, because getting it backwards is the most common way a rollout goes wrong and it does not look like an error when it does.
Settings before the installer, not after. The application reads its configuration when it starts. Install it onto a machine with no settings written and it launches unconfigured: it holds no organisation key, so it cannot check a licence, and it shows the person the first-run setup wizard asking them to choose the schedule you have already chosen for them.
Nothing is broken if it happens - write the settings and restart the application, and it picks them up. But on a fleet it means a wave of confused people and support calls that a different running order would have avoided.
The application looks in three places, in this order, and takes the first value it finds. All three are machine-scope and unwritable by a standard user, which is the only reason locking a setting means anything.
| Precedence | Location | Written by |
|---|---|---|
| 1 | HKLM\SOFTWARE\Policies\20-20-20 Vision |
Group Policy or Intune. This is where an ADMX template writes and where administrators expect to find it, so it wins |
| 2 | HKLM\SOFTWARE\20-20-20 Vision |
Set at install time |
| 3 | %ProgramData%\20-20-20 Vision\policy.json |
For estates that deploy a file more easily than a policy |
The application never writes to any of them. That is deliberate: it runs unelevated, so it could not modify a locked setting even if it tried, which is what makes a lock a lock rather than a suggestion. A malformed value falls back to the application's own default rather than failing, because a bad policy push must never leave an estate with software that will not start.
For estates with a domain and a Central Store. The one most customers use.
20-20-20-Vision.admx from the template download and put it in
your Central Store: \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\.
Put 20-20-20-Vision.adml in the en-US subfolder beneath
it.Computer Configuration, not User Configuration. The template targets the machine hive, which is what makes it apply to whoever signs in and what makes it unwritable by them. Group Policy also removes its values cleanly when a machine leaves scope, which the other two routes do not.
For cloud-managed estates, with or without a domain.
Intune reads the same ADMX. Import it as an imported administrative template and the categories above appear exactly as they do in the Group Policy editor; assign the profile to your device groups.
If you would rather not import a template, the third
location in the table above is the simpler path: deploy
%ProgramData%\20-20-20 Vision\policy.json as a file, or push the same
registry values with a script. Both are read identically. The dashboard writes the
script for you - see Route C.
For organisations with neither Group Policy nor Intune, and for handing to an IT provider who has their own tooling.
Under Settings → Configure your machines your dashboard generates a
.cmd file per named configuration. It writes your organisation key and
settings, and then installs the MSI if the installer is sitting next to it - in that
order, for the reason above. Put the two files in one folder and run it with
administrator rights on each machine, or hand it to whoever pushes your software.
It is plain text and every line says what it does, so whoever you ask to run it can read it before they do. You can save more than one, if different groups of people need different settings.
If you run application control, use Route A or B instead. AppLocker, WDAC and ThreatLocker commonly block script interpreters and anything they launch. The MSI and the ADMX are all you actually need; the script is a convenience for estates with no tooling, not the intended route for one that has some.
One key covers the whole estate. It goes on every machine by whichever route you chose, and nobody types anything: there is no per-machine licence key, no activation step and no prompt in front of the person using the computer.
Two things about it are worth knowing before somebody in your security review asks.
Setting a value and fixing a value are separate decisions. Anything you push becomes the default; anything you also lock stops being theirs to change.
Under Group Policy that is the Settings users cannot change policy, which takes
the names of the settings you want fixed. By script it is the Locked value,
a comma-separated list of the same names, or LockAll for "none of this is
theirs".
A locked setting appears in the application greyed out and marked “Set by your organisation”, rather than silently refusing to work. Somebody who wonders why they cannot change it can see that it was a decision and whose.
Theme and language are never locked, including by
LockAll. Freezing somebody's dark mode achieves nothing your DSE programme
cares about and buys you an irritated user, so the option is not offered.
One setting is worth thinking about harder than the rest. Limits on switching reminders off is where the master switch, the hush and the snooze allowance live. Every other lock is decorative while one toggle turns the reminders off entirely, so if you are deploying this as evidence for a DSE programme, that is the category to look at.
A per-machine MSI, x64, installed silently:
msiexec /i "20-20-20-Vision-Teams-<version>.msi" /qn /norestart
Replace <version> with the release you downloaded from your
dashboard, for example 20-20-20-Vision-Teams-1.0.4.msi.
Deploy it however you normally deploy an MSI - Group Policy software installation, Intune, Configuration Manager, or your provider's own tooling. There is nothing special about it and it takes no properties: your settings come from the registry, not from the command line, which is why they go on first.
It installs to %ProgramFiles%\20-20-20 Vision Teams\ and runs as the
signed-in user. No service, no scheduled task, no driver, and no elevation once it is
installed.
The installer, the install path and the executables still carry this tier's previous
name, Teams. The product is 20-20-20 Vision for Workplaces; the strings in
the build have not caught up yet, and what you type has to match what is on disk. When a
release changes them, this guide changes with it.
Deploying the software licenses nobody. A licence is something an administrator assigns to a named person, and that is the only thing that entitles anybody to anything.
Your dashboard's list of people is a roster: the people you put on it, and nobody else. A machine reporting an account you have not listed is told it holds no licence, and nothing about it is recorded, counted or shown to you. There are two ways onto the list:
DOMAIN\user and the account SID - and
is incapable of reading anything else in your directory.Then assign licences on the people page. Tick as many people as you like and assign in one go; a selection that does not fit the licences you hold is refused whole rather than filled in the order the table happens to be sorted in, because that would let a column heading decide which of your staff get licensed.
Nothing is ever unassigned automatically. Not when somebody drops out of the synced group, not when a machine is uninstalled, not when a machine goes quiet, and not when a term ends. Those are flagged for an administrator to act on, never acted on for you.
Three checks, on one machine, before you push to the rest. They are worth doing in this order because each one rules out the causes of the next.
reg query "HKLM\SOFTWARE\Policies\20-20-20 Vision"
Your organisation key and whatever else you pushed should be listed. If this is
empty, nothing else on this page will work and the problem is in your policy or your
script, not in the application.The application never updates itself and never downloads anything. New versions are an MSI you deploy over the top, on your schedule, through the tooling you already use. Settings and licence assignments survive it.
Because the version each machine is running is reported on its licence check, the dashboard can tell you when part of your estate is behind a release you have deployed elsewhere - one email to your administrators, listing counts. It is the only thing that version number is used for.
To remove it:
msiexec /x "20-20-20-Vision-Teams-<version>.msi" /qn
reg delete "HKLM\SOFTWARE\Policies\20-20-20 Vision" /f
Under Group Policy the second line is unnecessary: taking the machine out of scope removes the values for you. And note that uninstalling does not unassign anybody. An administrator gave that licence to a named person; a rebuilt machine is not them changing their mind about who should have it.
Every one of these has a symptom that looks like something else, which is why they are worth reading before you start rather than after.
| What you see | What it usually is |
|---|---|
| A person is on the list, holds a licence, and Last used says never | Their machine is reporting a different identifier from the one you listed.
An estate where the user principal name attribute was never populated has
machines reporting DOMAIN\user while your pasted list holds email
addresses. Syncing the security group avoids it entirely, because the script
posts the SID and the DOMAIN\user as well as the address. |
| People saw a first-run setup wizard, and your settings are not applied | The installer ran before the settings were written. Write them and restart the application. |
| It worked for a fortnight and then stopped reminding anybody | Outbound access to admin.20-20-20-vision.com is blocked. The
application keeps working for 14 days from its last successful licence check and
then stops. This is the single most common cause of what looks like a fault in
our software, and Ringfencing rules that permit the executable but not its
destination are the usual reason. |
| The setup script does nothing, or is blocked | Either it was not run as administrator - it checks, and says so - or application control has blocked the interpreter. Use Group Policy or Intune instead. |
| The sync script refuses to run, saying no members were found | A typo in the group name, or the account it runs as cannot read the group. It refuses deliberately: sending an empty group would mark everybody in your estate as having left, and the far end cannot tell an empty group from an unreadable one. |
| Someone is told they hold no licence, and they are not on your list | Working as intended. Running the software puts nobody on the roster and gives nobody a licence. Add them and assign one. |
| More people are assigned licences than the estate has | The licences assigned earliest stay in force and the rest do not, until you either buy more or unassign somebody. Nobody is unassigned for you, and the dashboard shows exactly who is affected. |
| A blocked executable on first run | A default-deny product blocks anything it has not seen before. Both executables are listed on the security reference; prefer publisher-based rules to hash-based ones, or you will approve a fresh block at every release. |
Deployment and technical questions go to dev@20-20-20-vision.com and reach the people who write the code. Tell us how your machines are managed and what you have tried, and you will get an answer rather than a ticket number.