Change Windows 7/8/10/11 Wallpaper

What the Windows wallpaper enforcer does

This Automox Worklet™ enforces a standard desktop wallpaper across every user profile on a Windows endpoint. The Worklet copies the wallpaper image into a managed directory on disk, enumerates every user profile on the endpoint, and writes the desktop registry values that point each profile at the new image. Both signed-in users and offline profiles receive the update.

The Worklet enumerates user profiles by reading HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and matching the security identifier (SID) pattern. For any profile whose hive is not currently loaded, the script calls reg load HKU\<SID> against the ntuser.dat file, applies the wallpaper values, then unloads the hive. A user who has not signed in for weeks still receives the new wallpaper the next time they log on.

The script writes three values under registry::HKEY_USERS\<SID>\Control Panel\Desktop: Wallpaper (the full path to the image), TileWallpaper (set to 0 so the image does not tile), and WallpaperStyle (set to 10 for fit-to-screen). The two parameters at the top of remediation.ps1 control the deployment: $imageWallpaper is the source filename and $imageDirectory is the on-disk destination, which defaults to C:\Wallpaper.

Why enforce a standard wallpaper at fleet scale

Desktop wallpapers are a quiet baseline control. They reinforce acceptable use messaging, surface the helpdesk number on every screen share, mark the difference between production and test endpoints, and signal that a misplaced laptop is corporate property. The control breaks down the moment a user changes the image, a re-imaged endpoint reverts to the OEM default, or a new hire profile lands on the box without ever picking up the policy. None of those failures are loud; they only surface in a screenshot taken during a client call.

Desktop wallpaper on Windows lives under HKCU\Control Panel\Desktop\Wallpaper for each loaded user hive, and a user can change it from Settings in three clicks. Apply this Worklet on a recurring policy schedule so the corporate image path is rewritten under every loaded and offline profile on every pass. A weekly run restores the standard background after re-imaged hardware, dormant profiles that wake up at quarter-end, and any user who manually swapped the image from Settings.

How Windows wallpaper enforcement works

1. Evaluation phase: The evaluation script exits 1 on every run, which Automox treats as non-compliant and triggers remediation on every policy cycle. This unconditional remediation pattern is intentional for branding controls, because the wallpaper must be rewritten across every loaded and offline user hive whenever the policy runs, regardless of the current state on disk or in the registry.

2. Remediation phase: The script creates C:\Wallpaper if it does not exist, copies the source image into it, then walks every entry under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. For each profile, the Worklet calls reg load HKU\<SID> when the hive is offline, writes the Wallpaper, TileWallpaper, and WallpaperStyle values under HKEY_USERS\<SID>\Control Panel\Desktop, and then unloads the hive. The script exits 0 on success.

Windows wallpaper enforcement requirements

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

• Administrative rights for the Automox agent so the script can write under HKEY_USERS and load offline user hives via reg load

• Wallpaper image file (JPG, PNG, or BMP) staged at the source path that remediation.ps1 reads at runtime

• Free disk space under C:\Wallpaper (or your configured $imageDirectory) on every target endpoint

• Update $imageWallpaper and $imageDirectory at the top of remediation.ps1 before deploying the policy

• A reboot or Windows Explorer restart for the wallpaper to render on currently signed-in sessions, even though the registry values apply immediately

Expected desktop state after wallpaper enforcement

After the Worklet runs, every user profile on the endpoint resolves Wallpaper to the path under C:\Wallpaper, TileWallpaper to 0, and WallpaperStyle to 10. Signed-in users see the new wallpaper at their next sign-in, after Windows Explorer is restarted, or after the endpoint reboots. Offline profiles pick up the new image the first time the user logs in, because the registry hive was patched while it was unloaded.

Validate the change by inspecting registry::HKEY_USERS on a remediated endpoint. The command Get-ChildItem registry::HKEY_USERS | Where-Object { $_.PSChildName -match '^S-\d-\d+-(\d+-){1,14}\d+$' } returns one entry per loaded profile, and Get-ItemProperty against each profile's Control Panel\Desktop key shows the three values above. Capture the output with the policy run identifier for audit evidence. The wallpaper persists across reboots and survives normal Windows update cycles, and the next evaluation flags any endpoint where a user has reverted the image so the Worklet restores it.

Pair this Worklet with a Group Policy or Intune restriction on wallpaper customization when end users have local admin rights, because admin-level accounts can still change the image manually between policy runs. The Worklet does not require Active Directory. It remediates workgroup endpoints, contractor laptops, and remote workers that rarely reach a domain controller. That coverage gap is exactly where Group Policy-only deployments tend to fail.