Hide or show the Office Insiders button on the Account page across all user profiles
This Automox Worklet™ controls the visibility of the Office Insiders button on the Account page in Word, Excel, PowerPoint, and Outlook. The Office Insiders button lets users enroll their own installation into Microsoft's pre-release build channel. Many organizations want to prevent that self-enrollment on managed endpoints to keep all installations on an approved, stable channel.
The Worklet targets the InsiderSlabBehavior DWORD under HKCU:\Software\Policies\Microsoft\Office\16.0\Common. It mounts a temporary PSDrive over HKEY_USERS and iterates every hive whose SID begins with S-1-5-21, which identifies standard interactive user accounts. For each matching SID, it compares the current InsiderSlabBehavior value against the configured target. Any SID whose value differs is flagged for remediation.
The Worklet only acts on hives that are already loaded in HKEY_USERS. It does not load or unload offline hive files. This means it applies to users who have logged in at least once on the endpoint since the last reboot.
The Office Insiders channel delivers pre-release builds that have not completed standard quality validation. On a managed fleet, any endpoint running an Insiders build falls outside the tested software baseline, which creates support complexity and can introduce compatibility issues with line-of-business applications. Allowing users to opt in on their own also means the IT team loses visibility into which endpoints are running which Office version.
The InsiderSlabBehavior DWORD accepts two values: 1 makes the Insiders button visible (the Office default), and 2 hides it. Setting the value through the Policies hive key means the configuration is treated as a managed preference, which takes effect the next time the user opens an Office app. The Worklet can be flipped in either direction, so a pilot group can be given visibility while the rest of the fleet is locked to the stable channel.
Evaluation phase: The Worklet creates a temporary PSDrive over HKEY_USERS and iterates all child keys. Any SID that matches S-1-5-21* and does not end in *_Classes is treated as an interactive user account. The script reads InsiderSlabBehavior from HKCU:\Software\Policies\Microsoft\Office\16.0\Common for each matching SID. If any value does not equal the configured $insiderVis target, the script increments a counter and exits 1 to flag the endpoint for remediation.
Remediation phase: For each SID whose InsiderSlabBehavior does not match the target, the Worklet creates the Policies\Microsoft\Office\16.0\Common path under HKEY_USERS if it does not exist, then calls New-ItemProperty with -Force to write the InsiderSlabBehavior DWORD. The script exits 0 after processing all non-compliant accounts and reports the count of remediated profiles.
Windows 10 or later
Microsoft Office 2016, Office 2019, Office 2021, or Microsoft 365 Apps (all use the 16.0 registry schema)
PowerShell 2.0 or later
Administrator privileges to read and write HKEY_USERS hives
Set $insiderVis to 1 (show button) or 2 (hide button) in both scripts before deploying the policy
Target users must have logged in at least once on the endpoint so their hive is present in HKEY_USERS
After remediation, every active user profile on the endpoint has InsiderSlabBehavior set to the configured value under HKCU:\Software\Policies\Microsoft\Office\16.0\Common. When a user next opens Word, Excel, PowerPoint, or Outlook, the Insiders button on the Account page appears or is absent according to the policy. No Office restart is required; the change takes effect on the next application launch.
To validate, open an Office app as a test user, navigate to **File → Account**, and confirm the Insiders button matches the configured state. To verify via the registry, run Get-ItemProperty "HKCU:\Software\Policies\Microsoft\Office\16.0\Common" and check the InsiderSlabBehavior value. On subsequent Automox evaluations, compliant endpoints exit 0 without re-running remediation. User profiles created after the initial run are picked up on the next evaluation cycle.


Loading...
Consider Worklets your easy button
A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy
By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in