Windows - Enterprise Branding - Set Login Screen Background

What the Windows login screen branding Worklet does

This Automox Worklet™ enforces a custom background image for the Windows login screen, also known as the lock screen, on Windows 8.1 and later endpoints. The Worklet downloads an image from a URL you supply, caches it locally under the Automox agent directory, and writes the registry policy values that control the login screen for both Windows Professional and Windows Enterprise editions.

Downloaded images are stored at C:\ProgramData\amagent\WorkletCache\Enterprise-Branding\AX-LockScreen.* and the format is identified by loading the downloaded bytes into a System.Drawing.Image object and reading its RawFormat property. JPEG, PNG, BMP, GIF, and TIFF are all supported. Caching the image locally means the login screen continues to render correctly even when the source URL is unreachable, such as on a fresh boot before VPN tunnels come up.

Registry handling differs by edition. On Enterprise endpoints, the Worklet writes HKLM:\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage along with the NoChangingLockScreen value to lock the setting against end user changes. On Professional endpoints, it writes HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP\LockScreenImagePath, which is the consumer-grade CSP path Windows Personalization honors when the policy path is unavailable. The AllowLockScreenImageChange parameter controls whether NoChangingLockScreen is set to 1.

Why enforce a custom login screen background

The login screen is the only branded surface Windows shows before a user authenticates. It is the natural location for acceptable use policies, legal banners required by HIPAA or PCI-DSS environments, and the IT contact details an end user needs when they have forgotten their password or locked themselves out. Without enforcement, end users or OEM refresh tools can replace the configured image, and Windows feature updates can silently revert the Personalization CSP value.

The Worklet reads both LockScreenImage (Enterprise) and LockScreenImagePath (Professional) on every evaluation and compares each string value against the expected cache path. It also reads the NoChangingLockScreen DWORD to confirm it matches the AllowLockScreenImageChange parameter. Any mismatch queues remediation and restores the configured state on the next policy run.

How login screen enforcement works

1. Evaluation phase: The Worklet verifies that C:\ProgramData\amagent\WorkletCache\Enterprise-Branding exists and that a cached AX-LockScreen.* file is present. It then reads both registry policy paths to confirm that LockScreenImage (Enterprise) or LockScreenImagePath (Professional) points at the cached file. If the AllowLockScreenImageChange parameter is set to false, the NoChangingLockScreen value is also verified at 1. Any missing path, missing file, or mismatched value flags the endpoint as non-compliant and queues remediation.

2. Remediation phase: The Worklet creates the cache directory if needed, runs a DNS resolution check and a TCP port reachability check against the configured ImageURL, downloads the image bytes with System.Net.WebClient, loads them into a System.Drawing.Image object to identify the format and pick the correct file extension, and saves the file as AX-LockScreen.<ext>. It then creates the policy and CSP registry keys if absent, sets LockScreenImage and LockScreenImagePath to the cached path, and writes the NoChangingLockScreen DWORD to 0 or 1 based on the AllowLockScreenImageChange parameter. A non-zero exit code is returned on DNS failure, TCP failure, unsupported image format, or registry write errors so the failure surfaces in Automox activity logs.

Login screen enforcement requirements

• Windows 8.1 or later, Professional or Enterprise edition. Windows Home does not honor the Personalization policy keys

• Windows activation. Microsoft blocks personalization changes on unactivated systems, and the script documentation notes the Worklet will not function without an activated license

• Network reachability from the endpoint to the ImageURL host, including any required proxy or VPN path

• Image asset in JPEG, PNG, BMP, GIF, or TIFF. Recommended dimensions are 1920×1080 or larger so the image renders sharply on high-DPI displays

• Policy parameters set in the Automox console: ImageURL (the source URL) and AllowLockScreenImageChange (true or false to control NoChangingLockScreen)

• A user logout or system reboot for the new image to render. The next sign-in screen reflects the change

Expected login screen state after remediation

After remediation and a sign-out or reboot, the configured image renders as the Windows login screen background on every targeted endpoint. The cached file is present at C:\ProgramData\amagent\WorkletCache\Enterprise-Branding\AX-LockScreen.<ext>, and the registry holds the corresponding pointer for the endpoint's Windows edition. On Enterprise, that is HKLM:\SOFTWARE\Policies\Microsoft\Windows\Personalization\LockScreenImage. On Professional, it is HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP\LockScreenImagePath.

When AllowLockScreenImageChange is false, NoChangingLockScreen is set to 1 and the Personalization page in Windows Settings shows the lock screen image as managed by your organization. End users cannot replace it through the Settings UI. Validate by querying the registry with Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Personalization' or Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP', and confirm the LockScreenImage or LockScreenImagePath value matches the cache location.

To roll the image forward, update the ImageURL parameter in the policy and rerun the Worklet. The remediation script overwrites the cached file in place and refreshes the registry pointer, so a second sign-in shows the new image without manual cleanup. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again, because the evaluation phase finds the file and registry values already aligned.