Create and Deploy Windows Provisioning Packages (.ppkg) on Windows 10 and 11

Windows Configuration Designer supports this workflow on Windows 10 and Windows 11. Microsoft positions it primarily for business and education deployments, but it is equally useful for a small office, lab, repair bench, classroom, or a fleet of similarly configured home PCs.

What a provisioning package can do​

With the Provision desktop devices wizard, a package can configure common settings including:

• A standardized PC name
• A Wi-Fi connection
• A local administrator account
• Shared-PC options
• Removal of preinstalled software
• Active Directory or Microsoft Entra enrollment
• Selected applications and certificates

For this guide, keep the first package deliberately modest: computer naming, Wi-Fi, and one emergency local administrator account. Add apps, certificates, domain enrollment, or removal of preinstalled software only after the basic package works exactly as intended.

Important: Microsoft’s simple desktop wizard is documented for Windows desktop editions other than Home. Do not assume every setting will behave identically across editions or Windows builds. Test on the same edition and configuration that you intend to deploy.

Click to expand...

Before you build anything​

You will need:

1. A Windows 10 or Windows 11 PC on which to build the package.
2. Windows Configuration Designer, available from the Microsoft Store.
3. A test PC or virtual machine running the intended Windows edition.
4. A removable USB drive if you plan to apply the package during first-run setup.
5. The exact Wi-Fi SSID and, for WPA2-Personal networks, its passphrase.
6. A secure place to store project files and the finished package.

The last item is not housekeeping theatre. A project may contain Wi-Fi credentials, local-account passwords, certificates, and other sensitive deployment data. Microsoft notes that while a .ppkg can be protected, the project files themselves are not encrypted. Treat the project folder like a password-bearing administrative asset, not like a holiday-photo archive.

Create the package​

Open Windows Configuration Designer from Start, then select Provision desktop devices.

1. Name the project
   Use a name that tells future-you what it is for, such as BranchOffice-Baseline or Lab-PC-Setup. Avoid vague labels such as newfinal2, which have historically caused more IT incidents than malware with better branding.
2. Configure device setup
   Enable Set up device if you want to set a naming pattern.
   Windows device names must be unique and limited to 15 characters. Rather than hard-coding one name, use a supported variable pattern such as:
   LAB-%SERIAL%
   This creates a more useful, unique name based on each device’s serial number.
   Leave edition upgrade, shared-device settings, and preinstalled-app removal alone unless they are explicitly part of your tested configuration standard.
3. Configure Wi-Fi
   Select Set up network and turn it on.
   Enter:
   • Network SSID: the Wi-Fi network name exactly as broadcast
   • Network type: Open or WPA2-Personal
   • Password: if using WPA2-Personal
   Confirm the SSID carefully. A typo in a package does not merely produce an awkward spreadsheet entry—it can leave every newly provisioned PC stranded without the connectivity needed for the rest of its setup.
4. Create a local administrator account
   Under Account Management, choose Local administrator and specify a dedicated username and strong password.
   Use a purpose-specific administrative account, not an employee’s ordinary sign-in account. Keep its credentials in your approved password-management system, and establish a process for changing the password. Microsoft documents that local accounts created through this wizard must have their passwords changed through Settings every 42 days or they may become locked out.
   If your organization uses Active Directory or Microsoft Entra ID, do not casually add enrollment credentials to a broadly shared package. Domain join credentials should be least-privileged, while Entra bulk enrollment requires organization-side preparation and has token-expiry considerations.
5. Skip optional apps and certificates for the first run
   Windows Configuration Designer can include Win32 and UWP apps plus certificates, but every added payload expands the testing matrix. Start with configuration only. Once it works, create a separate version with applications or certificates and test that package independently.
6. Protect and create the package
   At Finish, choose to password-protect the package if it contains credentials or other sensitive settings. Record that password securely.
   Select Create. The tool builds the .ppkg and displays its output location. Copy only the completed package to your deployment USB drive; retain the project folder in a restricted administrative location.

Test before rolling it out​

Never make a production fleet your beta program.

Use a spare PC or virtual machine that matches the target environment as closely as possible. Test these points:

• The device name follows the expected format and remains unique.
• The Wi-Fi profile appears and the PC connects successfully.
• The local administrator account can sign in.
• The account has administrator privileges, but no unintended accounts or policies were created.
• The package does not disrupt existing network, management, or security configurations.
• A reboot does not expose a delayed failure.

If you included applications or certificates, test them separately as well. Windows Configuration Designer imports associated deployment assets, and Microsoft recommends keeping source files local to the PC building the package rather than relying on removable media or network shares during construction.

Apply the .ppkg during or after setup​

You have two practical deployment paths.

During Windows first-run setup​

At the Windows out-of-box experience screen:

1. Insert the USB drive containing the package.
2. If Windows does not detect it automatically, press the Windows key five times.
3. If prompted, choose Install provisioning package.
4. Select the intended .ppkg.
5. Confirm that you trust the package.
6. Wait for Windows to indicate that removable media can be removed.

This is the cleanest route for new PCs: settings are applied before the device becomes someone’s daily workstation.

On an already configured PC​

For a runtime deployment, open:

Settings > Accounts > Access work or school > Add or remove a provisioning package > Add a package

Choose the package source, select the .ppkg, then approve the User Account Control and trust prompts.

You can also double-click a .ppkg from a local folder, USB drive, or approved network location. Windows requires administrative approval because a provisioning package can modify policies and execute system-level configuration tasks. In plain English: never install one sent by “[email protected].”

Verify and troubleshoot with PowerShell​

For repeatable administration, Windows includes provisioning PowerShell cmdlets. Run PowerShell as an administrator.

To view installed packages:

Get-ProvisioningPackage -AllInstalledPackages

To apply a package from a known local path:

Add-ProvisioningPackage -Path "C:\Packages\BranchOffice-Baseline.ppkg"

For scripted deployments, use the logging option so there is evidence to inspect if something goes sideways:

Add-ProvisioningPackage -Path "C:\Packages\BranchOffice-Baseline.ppkg" -LogsFolder "C:\ProvisioningLogs"

Windows generates provisioning traces and reports in the selected log folder. Those logs are far more useful than guessing whether an SSID was mistyped or a setting was unsupported on the target device.

One security caveat deserves bold letters: Microsoft documents that PowerShell package application suppresses the usual prompt for an unsigned package by default. Restrict write access to package locations, verify the package path in scripts, and do not use unattended deployment commands against files you have not controlled.

Removing a package is not the same as undoing everything​

To remove a specific installed package through Settings, return to:

Settings > Accounts > Access work or school > Add or remove a provisioning package

Select the installed package and remove it with administrative approval.

PowerShell offers a more controlled option:

Get-ProvisioningPackage -AllInstalledPackages

Identify the correct package, then remove it by its package ID:

Remove-ProvisioningPackage -PackageId "PackageIdHere"

Do not reach for -AllInstalledPackages unless removing every installed provisioning package is genuinely the intention.

More importantly, package removal is not a time machine. Microsoft states that only certain settings are revertible. Some Wi-Fi, certificate, VPN, app-management, browser, power, and other policy-related settings may be reverted, but not every action performed by a package will be undone. A local account, installed software, renamed device, or other configuration change may require separate cleanup.

That is why a restrained baseline package is safer than a “configure everything we have ever heard of” monster. Version your packages, document their contents, test upgrades and removal on representative hardware, and keep a small change log beside each .ppkg.

A well-built Windows provisioning package will not replace full endpoint management for a large organization. It does, however, make repeatable PC setup dramatically faster—and it avoids the ancient ritual of configuring twelve laptops by hand while wondering whether coffee qualifies as a deployment dependency.