PSAppDeployToolkit 4.2 RC2: what a candidate changes before you pin it

The newest tags are candidates while 4.1.8 sits nine months back

The release page shows 4.2.0-rc2 tagged on 2026-10-01, 4.2.0-rc1 tagged on 2026-08-20, and then 4.1.8 tagged on 2026-01-14. So the newest complete release is from January, while two candidates for the next line have been on the release page for six weeks. The last push landed on 2026-10-02, a day after rc2.

That makes pinning a decision between a January stable and an October candidate, and nothing on the page gives a target date for 4.2.0 final. The six week gap between rc1 and rc2 also tells you the candidate's own changelog is still moving: the list of what 4.2 changes grew between the two candidates rather than settling. Anything you build against rc2 is built against a document that has already been rewritten once.

Renamed parameters keep their old names as aliases

The 4.2 RC2 notes for `Show-ADTInstallationRestartPrompt` say that some parameters have been renamed to make their behaviour clearer, with the previous names retained as aliases. `-SilentRestart` is now `-AllowSilentRestart`. Nothing in that note says when the old names are removed, and no deprecation table appears on the page.

The same release changes a return type rather than a name. `Show-ADTInstallationPrompt` with `-SecureInput` now returns the entered text as a `SecureString`, which breaks any package that treated that output as a plain string and did its own comparisons on it. Aliases keep old call sites compiling; they do not keep an old return type working. Between the two changes, the surface that a script touches is larger than the parameter list suggests, and the changelog entry for each is one line.

Group Policy keys are now versioned by release line

Group Policy supports version-specific policy keys under `HKLM\SOFTWARE\Policies\PSAppDeployToolkit\4.2`, so that 4.2-only settings such as Base64 assets do not break 4.0 and 4.1 deployments on the same device. Two things follow. Before 4.2, every version shared one unversioned key, and a value written by 4.2 into it was readable by older clients. And the versioned key prevents new collisions without moving anything already sitting in the old key, so a device managed with the old templates still needs its policy replaced.

The ADMX and ADML templates were updated to match, which means the registry layout and the admin templates have to change together or the policy editor and the runtime disagree. The same release also lets an empty policy value clear a value set in a deployment's config, which makes the registry layer win over `config.psd1` whenever it is set to something. That precedence rule exists only as one clause in a release note.

PathsBasedOnSystemContext switches on the account, not on admin rights

A new config option, `PathsBasedOnSystemContext`, makes the toolkit use its `NoAdminRights` paths whenever the caller is not the LocalSystem account, rather than whenever the caller is not an administrator. The distinction is the whole point of the switch: the previous rule asked what rights the caller had, the new one asks which account the caller is.

For an interactive administrator running a package from a console, the two rules disagree, and the toolkit will now take the non-elevated path set even though the caller holds administrator rights. Packages written against the admin path tree will therefore see a different layout under this option, which makes it a switch to read about before you enable it rather than a safe default. The option name is the extent of the documentation: no section on the page says what the NoAdminRights tree contains or how it differs from the elevated one.

The default restart path still force-closes open applications

`-NoForceCloseApps` is a new switch on `Show-ADTInstallationRestartPrompt` that omits the `/f` switch when calling `shutdown.exe`, which the notes describe as a more graceful restart. The force flag is therefore still the default in 4.2, and the opt-out arrived in the candidate.

Three other changes land on the same cmdlet. `-Force` was added so the prompt can appear in Silent and NonInteractive mode. The parameter sets were fixed so that all UI options remain available when `-AllowSilentRestart` is supplied, which means code that reached for those options before could not reach them in that path. And default countdown durations moved into `config.psd1`, so the wait before a restart is a deployment setting rather than a value passed in code. Four behavioural changes on one function, three of which affect what a headless run does without a user present.

The feature list is five adjectives and the screenshot tables are empty

The key features are five bullets, each of them a claim rather than a mechanism: it works with all major deployment solutions, it offers a customizable interface with both Fluent and Classic looks, it handles complex deployment scenarios, it is described as reliable and battle-tested in enterprise environments, and it is extensible. None carries a number, and the opening paragraph's promise of consistently high deployment success rates has no measurement behind it anywhere on the page.

The screenshot section promises Light Mode, Dark Mode, Custom Accent Light and Custom Accent Dark in a table whose cells are all empty, so the theming claim is unillustrated. The consequence is that the most concrete content on the page is not the feature list but the 4.2 candidate changelog further down, which is where every actual behaviour change is described. The document also opens with an empty top-level heading before the tagline, and the repository's own description field reads Project Homepage & Forums, a pointer to the website rather than a description of the software.

A v3 compatibility layer is still absorbing fixes

The changelog lists numerous fixes to the v3 compatibility layer, `AppDeployToolkitMain.ps1`, to better match v3 behaviour. A shim for a two-major-old PowerShell codebase still taking corrections means two sets of behaviours are maintained inside one repository, and any bug report has to be classified against both.

The tree is arranged for that split: `support/`, `modules/`, `vendor/` and `src/`, two solution files named `PSADT.slnx` and `PSADT.Invoke.slnx`, and two test stacks, the Pester entry points `pester.cmd` and `pester.ps1` alongside the C# unit tests the changelog calls extensive with no figure attached. `BannedSymbols.txt` sits at the root, which points at symbol policing for the PowerShell sources, though the page never reproduces the list. The `examples/` directory holds four folders, Launching, Multi-session Installation, VLC and WinSCP, a thin sample set for a framework of this size.

Prerequisites stop at .NET Framework 4.7.2 while the build is set up for modern .NET

The stated prerequisites are Windows 10/11, PowerShell 5.1 or later, and .NET Framework 4.7.2 or later. The root of the repository meanwhile carries `global.json`, `Directory.Packages.props`, `Directory.Build.props`, `Directory.Build.targets`, `nuget.config` and `CodeCoverage.runsettings`, with `build.cmd` and `build.ps1` as the build entry points.

So the runtime floor is a .NET Framework release while the build and test harness is laid out in current .NET tooling conventions, and the page does not reconcile the two anywhere. Acquisition is offered three ways with no statement of what each contains: a getting started guidance page, the PowerShell Gallery, or GitHub Releases. If you script acquisition for a fleet, check which of the three you actually need first, because the page treats them as interchangeable and only one of them carries the build entry points and the tests.

Editorial conclusion

PSAppDeployToolkit is worth adopting for Windows package authoring when you already run Intune, ConfigMgr, Tanium or BigFix and want your own branded interface and full-fidelity logging instead of the host's. Pin deliberately, because the newest complete release is 4.1.8 from 2026-01-14 and everything since is a candidate. Before you deploy, confirm three things: which generation of Group Policy keys your devices already carry, whether you want PathsBasedOnSystemContext in a session that is not LocalSystem, and whether your build runs the C# unit tests or only the Pester scripts. And read the candidate changelog rather than the feature list, because the renamed parameters, the SecureString return type and the shutdown.exe call are the parts that break existing packages.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. PSAppDeployToolkit/PSAppDeployToolkit on GitHub
4. README
5. Releases