Windows Customizations with PowerShell

This post was updated on June 18th, 2026.

This post has been rewritten from the ground up. The original version of this solution was a Configuration Manager task sequence script driven by a Parameters.ini file. It worked, but it was built for a Windows 10 task-sequence world, and a lot of its customizations were applied as policies that locked the setting so the user could no longer change it.

The modern version is a complete redesign for Windows 11 and Intune/Autopilot. It is a Win32 app that runs during the Autopilot device Enrollment Status Page and applies a curated set of customizations as defaults that a non-admin user can still change. This post covers the high-level concepts. The full setting list and the deeper implementation details live in the docs in the GitHub repo, so I won’t duplicate all of that here.

The solution can be downloaded from my GitHub. https://github.com/ConfigJon/Windows-Customizations

Defaults, not policies

Intune Settings Catalog / CSP policies and Group Policy lock a setting. The control is greyed out and the user can’t touch it. That’s the right tool when you need to enforce something, but most of the “customizations” admins ask for aren’t really things that need to be enforced. They’re just sensible defaults for a fresh machine: set shortcuts on the taskbar, show file extensions, drop a few preinstalled apps, set the corporate wallpaper. Locking those down is heavy-handed, and it generates help-desk tickets when a user wants their own preference back.

This solution is preference-based. Instead of writing policy keys, it seeds the Default User registry hive (C:\Users\Default\NTUSER.DAT) and other per-user default locations. Every new user profile created on the device inherits the configuration, but each user remains free to change any of it afterward, just like they could on a clean install of Windows.

Locking mechanisms are still available for the handful of settings that have no changeable equivalent (for example, the Edge first-run experience), but they are optional and off by default. A stock build is 100% user-changeable.

How it works

The engine is data-driven. There are three pieces:

A code-owned catalog (package\Engine\Catalog.psd1) that describes every available customization: its mechanism, registry target, allowed values, and documentation. You don’t edit this for a normal deployment.
A per-deployment config (package\Config\Settings.json) where you select values. Omitting a setting leaves it unconfigured, which is the modern equivalent of commenting out a line in the old Parameters.ini.
A small generic applier that reads the catalog and dispatches each selected setting to the right mechanism handler (Default User hive, HKLM, Policy, file copy, app removal, DISM, or a bespoke handler).

Adding or changing a customization is a data edit, not a code edit. The applier is idempotent, so it is safe to re-run during ESP retries or after a version bump.

Here is a trimmed example of a Settings.json.

{
    "$schema": "./Settings.schema.json",
    "Organization": "Contoso",
    "FailureMode": "Lenient",
    "Customizations": {
        "TaskbarAlignment": 0,
        "SearchBoxMode": 1,
        "HideFileExt": 0,
        "LaunchTo": 1,
        "RemoveProvisionedApps": ["Microsoft.BingNews", "Microsoft.GamingApp"]
    }
}

A companion Settings.schema.json gives you validation and autocomplete in VS Code as you type.

If you’d rather not hand-edit JSON, there’s a point-and-click configurator (tools\Configure-Settings.ps1). It reads the catalog and presents every available setting with its description and a drop-down of valid choices, then writes a valid Settings.json for you. It also has a Browse… button that validates and copies the asset files (branding images, default app associations, and the Start/taskbar layout) into the right place.

What it can customize

The catalog covers the things admins commonly want to standardize on a new Windows 11 device, including:

Branding - desktop wallpaper, lock screen image, and turning off Windows Spotlight so the branding actually shows.
Default apps - import a default file/protocol association set via DISM.
Taskbar & Start - taskbar and Start pins, search box mode, Task View and Widgets buttons.
Explorer & desktop UX - show file extensions and hidden files, desktop icons, app/system theme, the classic right-click context menu, and removing the Edge desktop shortcut.
Debloat / privacy / first-run - remove provisioned apps and consumer stubs, turn off suggested content and ads, advertising ID, tailored experiences, and various first-run prompts.
System behavior & accessibility - dynamic time zone, Fast Startup, clipboard history, the Sticky Keys shortcut prompt.

The complete list, including which mechanism each setting uses and whether it’s a changeable default or one of the few that lock, is in docs/Customizations.md.

Deploying it

The solution is packaged as an Intune Win32 app (.intunewin) and assigned to devices, so it runs as SYSTEM during the Autopilot device ESP, before any user profile exists. That timing is what lets it seed the Default User hive for every future user.

The build tooling (tools\New-Package.ps1) stamps a version into both the engine and a detection script, then produces the .intunewin. In Intune you create a Win32 app with:

Install: powershell.exe -NoProfile -ExecutionPolicy Bypass -File Set-WindowsCustomizations.ps1
Uninstall: powershell.exe -NoProfile -ExecutionPolicy Bypass -File Remove-WindowsCustomizations.ps1
Detection: the version-stamped detection script emitted by the build.

The engine writes a CMTrace-format log to the Intune Management Extension log folder, so it shows up in Intune diagnostics, and on success it writes a version stamp that the detection rule checks. Bumping the package version re-triggers the app on already-deployed devices.

Defaults, not policies#

How it works#

What it can customize#

Deploying it#

Further reading#

Defaults, not policies

How it works

What it can customize

Deploying it

Further reading