Template basics

MAS instantiates the PSADT template on every Build. This chapter covers the template's shape, which files the packager typically customises, and where custom scripts are supposed to live so they survive both a MAS update and a template refresh.

The embedded template version is fixed at PSADT v4.1.8 for MAS 2.0. The version shipped with the running build is shown under Settings → About.

Template layout #

Every Build produces a workspace with this layout:

<workspace>/
├── Invoke-AppDeployToolkit.ps1        ← the entry script MAS generates
├── Invoke-AppDeployToolkit.exe        ← PSADT v4 launcher (unchanged from upstream)
├── config.psd1                        ← runtime configuration (see below)
├── AppDeployToolkit/                  ← PSADT v4 runtime (unchanged from upstream)
│   ├── AppDeployToolkitMain.ps1
│   ├── AppDeployToolkitConfig.xml
│   └── ...
├── Files/                             ← installer payload (MSI, EXE, etc.)
│   └── <the installer>.msi
├── SupportFiles/                      ← anything else the install needs
│   └── (custom .ps1 scripts, config templates, ...)
├── _capture.json                      ← MAS-only, the Capture record snapshot
└── _psadt-version.txt                 ← MAS-only, records the template version used

The three top-level PowerShell/EXE files plus the AppDeployToolkit/ folder come verbatim from the PSADT v4 distribution. MAS never modifies them. That means an upstream PSADT bug fix can be picked up by refreshing the embedded template — everything under AppDeployToolkit/ is replaced wholesale.

config.psd1 and Invoke-AppDeployToolkit.ps1 are the two files that MAS generates — details below.

Files/ and SupportFiles/ are the packager's territory. MAS copies the installer into Files/ on Build; anything under SupportFiles/ is preserved verbatim across rebuilds.

_capture.json and _psadt-version.txt are MAS metadata sidecars so a workspace can be re-opened months later without losing the context it was built in.

What MAS puts in Invoke-AppDeployToolkit.ps1 #

The generated script has fixed structure — three named regions per phase (Pre-Install, Install, Post-Install, and the same for Uninstall and Repair). MAS fills:

• Pre-Install — no default content. Cmdlets dropped in from the Cmdlet Library land here first.
• Install — always one step derived from the Capture: Start-ADTMsiProcess for MSI, Start-ADTProcess for EXE installers, Start-ADTMspProcess for patches.
• Post-Install — no default content. Common inserts: shortcut creation, registry adjustments, license file copies.
• Uninstall / Repair phases — same skeleton, empty by default. Uninstall is populated if the Capture derived an uninstall command from the MAS Catalog or from the MSI properties.

Any cmdlet the packager drops in via the Cmdlet Library (Build page → Add cmdlet) is inserted into the current phase at the caret position.

What MAS puts in config.psd1 #

config.psd1 is the runtime configuration PSADT reads on execution. MAS generates it per package with:

• The application name / version / vendor from the Capture record.
• The log-file path convention configured under Settings → PSADT config.
• Any PSADT toggles set on the Build page (deferral policy, close-apps list, reboot pass-through).

The file is regenerated on every Build. If a packager needs a per-package tweak that isn't exposed in the UI, the recommended path is to author a small .ps1 under SupportFiles/ that dot-sources or overwrites the value at runtime — that survives rebuilds. Direct edits to config.psd1 do not.

Where custom scripts belong #

Any bespoke code — pre-install checks, custom uninstall logic, special-case detection — belongs in a .ps1 file under SupportFiles/. MAS never touches SupportFiles/ on rebuild. Reference the script from the generated Invoke-AppDeployToolkit.ps1 via the Cmdlet Library's Invoke SupportFile script cmdlet, or via a hand-written . "$dirSupportFiles\my-custom.ps1" at the appropriate phase.

Rebuilding a package overwrites Invoke-AppDeployToolkit.ps1, so inserted-in-place edits to that file are lost. That's why the SupportFiles/ script + Cmdlet-Library reference is the recommended pattern.

Template refresh #

Upgrading the embedded PSADT template (e.g. once PSADT v4.1.9 or v4.2 lands upstream) is a MAS release event, not a packager task:

1. A future MAS release replaces the shipped AppDeployToolkit/ folder + launcher EXE with the new version.
2. On next launch, MAS refreshes its Cmdlet Library from the new template. New cmdlets appear in the Library; removed cmdlets are flagged in the Library editor as deprecated.
3. Existing workspaces continue to work — their _psadt-version.txt records the template they were built against, so a re-open shows a hint if the workspace's template pre-dates the current one.

Re-building a workspace refreshes its PSADT runtime automatically. Existing customisations in Invoke-AppDeployToolkit.ps1 are not carried over — that's why the Cmdlet Library + SupportFiles/ pattern is the resilient choice.

Related chapters #

• Workflow steps — Build produces exactly this workspace layout.
• Vocabulary — the Cmdlet Library term used above.
• What the Memory DB remembers — the workspace also gets a row in the Memory DB with the template version used, so a re-open lands in the right context.