Admins can set a different policy helper program per operating system with a new policyHelpers setting.
What's wrong with this entry?
Settings now take a policyHelpers object keyed by macos, linux, windows and wsl, alongside the existing single policyHelper. A bad individual entry is ignored with a status warning, but a structurally invalid policyHelpers object coming from an OS-admin policy source stops startup.
- WSL falls back to the
linuxentry under some conditions. - If no entry matches the current platform and there is no singular
policyHelperfallback, a warning is emitted and no helper runs.
"policyHelpers" could not be parsed: expected an object mapping OS keys
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.232
Warnings when policy helper settings are nested in the wrong place
Both mention policy helper managed
-
v2.1.232
A failing policy helper now falls back to its fixed payload
Both mention policy helper managed
-
v2.1.232
Policy helper executable paths must be in normalized form
Both mention policy helper managed