Change Screensaver

What the screensaver enforcement Worklet does

This Automox Worklet™ enforces screensaver and idle-lock policy across every user profile on a Windows endpoint. The Worklet writes four registry values under HKEY_USERS\{SID}\Control Panel\Desktop for every profile it finds: ScreenSaveActive, SCRNSAVE.EXE, ScreenSaverIsSecure, and ScreenSaveTimeOut. Together these values control whether the screensaver activates, which .scr binary runs, whether the workstation locks on wake, and how long the endpoint stays idle before either kicks in.

The Worklet enumerates user profiles from HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList using a SID regex match. For each profile, it checks whether the ntuser.dat hive is already mounted under HKEY_USERS and loads it with reg load when it is not. It then applies or reads the four values and unloads the hive again with reg unload after a forced [gc]::Collect() releases the file handles. Logged-in users and logged-out users are covered in a single run.

One behavior is worth flagging because it powers most compliance use cases. Setting ScreenSaveActive to 0 while leaving ScreenSaverIsSecure at 1 causes Windows to lock the workstation after the ScreenSaveTimeOut idle period without ever displaying a screensaver. That is the configuration most enterprises actually want: a quiet idle lock that satisfies a CIS Benchmark idle-lock control without inflicting an animation on the user.

Why enforce screensaver and idle-lock policy

Idle-lock is one of the oldest and most quietly violated security baselines on Windows. The CIS Benchmark for Windows 10 (control 19.1.3.3 in current versions) sets the idle timeout to 900 seconds with a password-protected screensaver. That control translates into the same four registry values this Worklet writes, on every user profile on every endpoint. Group Policy can deliver the values on domain-joined workstations. It still leaves a gap on Azure AD-joined laptops, kiosks, shared workstations, and the long tail of profiles that have logged in once and never been touched by gpupdate since.

Screensaver idle-lock is a per-user registry setting under HKCU\Control Panel\Desktop, and a user can disable it in one click from Settings. Apply this Worklet through the workstation security policy so ScreenSaveActive, ScreenSaverIsSecure, and ScreenSaveTimeOut are written against every loaded user hive on first pass. A weekly evaluation reasserts the idle lock after the next user-driven Settings change. The enforcement maps to CIS Benchmark 19.1.3 and NIST 800-53 AC-11 for session lock controls.

How screensaver enforcement works

1. Evaluation phase: The evaluation script reads HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList to build the list of user SIDs on the endpoint. For each profile, it loads the ntuser.dat hive when it is not already mounted, then reads ScreenSaveActive, SCRNSAVE.EXE, ScreenSaverIsSecure, and ScreenSaveTimeOut from HKEY_USERS\{SID}\Control Panel\Desktop. The script compares those four values against the policy variables defined at the top of evaluation.ps1. Any mismatch exits 1 and Automox schedules remediation. A clean match exits 0 and the endpoint stays compliant.

2. Remediation phase: The remediation script walks the same profile list and writes all four values to HKEY_USERS\{SID}\Control Panel\Desktop with Set-ItemProperty. After each write, it reads the value back with Get-ItemPropertyValue and prints a per-user PASS or FAIL line to Automox activity logs. A corrupted profile or a permission problem on one hive will not hide behind a clean exit code on the others. Hives that were loaded by the script are unloaded with reg unload after [gc]::Collect() releases the file handles. A trapped exception exits 90 so script failures surface as a distinct error code rather than as silent success.

Screensaver enforcement requirements

• Windows 7, 8, 10, 11, or Windows Server with PowerShell 2.0 or later

• Automox agent running with SYSTEM privileges, which is the default on managed endpoints

• Set $screensaveActive to "1" to run the screensaver, or "0" to lock the workstation on idle without a visible screensaver

• Set $screensaveExe to the full path of the .scr binary you want, for example C:\Windows\system32\Bubbles.scr, C:\Windows\system32\scrnsave.scr (blank screen), or a signed corporate-branded .scr staged into C:\Windows\system32\

• Set $screensaverIsSecure to "1" to require a password on wake; this is the value that converts the screensaver into a real session lock

• Set $screensaveTimeOut to the idle seconds before the screensaver or idle lock activates; "600" is ten minutes, "900" is the CIS baseline, and "1200" is twenty minutes

• Keep all four variables identical at the top of evaluation.ps1 and remediation.ps1; a mismatch will cause the endpoint to flip-flop between compliant and non-compliant on every run

• Pre-stage any non-default .scr file on the endpoint with a Software Deployment Worklet before scheduling this one, so the path in $screensaveExe resolves on every workstation

Expected screensaver state after enforcement

After remediation, every user profile on the endpoint has ScreenSaveActive, SCRNSAVE.EXE, ScreenSaverIsSecure, and ScreenSaveTimeOut set to the configured values under HKEY_USERS\{SID}\Control Panel\Desktop. Currently logged-in users pick up the change at the next idle window without a sign-out. Some sessions need a workstation lock-and-unwind or a sign-out for the new SCRNSAVE.EXE binary to load. New sign-ins inherit the configured values from first logon because the values are written to the user hive, not to a transient session.

Validate the enforcement with two checks. First, on a pilot endpoint, run Get-ItemProperty -Path "registry::HKEY_USERS\<SID>\Control Panel\Desktop" and confirm the four values match the policy variables. Second, lock the workstation with Windows-key + L, wait the configured timeout, and confirm the screensaver activates and prompts for a password on wake when ScreenSaverIsSecure is 1. For audit evidence, capture the four registry values per user and store them alongside the Automox policy run identifier. Subsequent evaluations report compliant without re-running remediation because the four values already match. The only time the Worklet rewrites them is when a user opens Settings and drifts the baseline, which is exactly the workflow the Worklet is here to close.