The words MAS uses in the UI and in every other chapter. Read this once — the rest of the docs assume it.
The four workflow steps #
MAS' main window is organised as a four-step workflow. Each step is a page; each page owns one phase of the pipeline.
| Step | What happens | Ends when |
|---|---|---|
| Capture | The installer file (or setup folder) is analysed. Product name, version, vendor, upgrade code, installer technology, silent-install switches are extracted. The MAS Catalog is consulted to prefill known-good defaults. | The Capture summary card is green and the Continue button is enabled. |
| Build | The PSADT v4 template is instantiated with the captured metadata. Cmdlets are inserted from the Cmdlet Library. The Deploy-Application.ps1 (v3-style) or Invoke-AppDeployToolkit.ps1 (v4-style) is written to the workspace, along with the payload subfolder and any custom scripts. |
The workspace folder validates against the template contract and the Build succeeded toast appears. |
| Pre-Ship | The built workspace is renamed to its final SCCM/Intune package name, detection rules are chosen or authored, and any signing pass runs. This is the last human checkpoint before the package leaves the workstation. | The Ship-drawer preflight is green and the Ship button is armed. |
| Rollout | The package is queued for one or more targets: SCCM Application create + distribute + deploy, and/or Intune .intunewin upload + assignment. Each target runs as a separate job in the Ship queue with its own state, toast and log. |
Every target job reaches Completed or Failed. Both terminal states leave the workspace untouched so the run can be retried. |
The workflow is unidirectional — Capture feeds Build feeds Pre-Ship feeds Rollout — but every step can be re-opened as long as the package record still exists in the Memory Database.
Profile #
A profile bundles connection details for one deployment target:
either a SCCM site (Site Server FQDN, Site Code, optional Distribution
Point Group) or an Intune tenant (Tenant ID, Client ID, optional
default assignments). Profiles live under
%LOCALAPPDATA%\MilochApplicationStudio\profiles\<id>.json and are
selected in Settings → Profiles.
Since MAS 2.0 there is exactly one active profile at a time
(ActiveProfileId). A profile can hold both SCCM and Intune
configuration simultaneously — the two-tab UI on the Rollout page
lights up whichever tabs the active profile actually has fields for.
MAS Catalog #
The MAS Catalog is an embedded SQLite database
(Catalog/installer-catalog.db) that ships with the application. It
holds roughly 303,000 rows harvested from the public Winget manifest
repository — product name, publisher, version, silent-install switch,
detection rule, custom exit codes. During Capture, MAS looks up the
installer's identifying fields (UpgradeCode first, then vendor plus
name, then hash) and prefills the workspace with the Catalog's known
values whenever a row matches. A Catalog hit is a hint, not a lock —
every field remains editable.
Memory Database #
The Software Memory Database (SQLite, WAL journal) at
%LOCALAPPDATA%\MilochApplicationStudio\memory.db remembers every
package MAS has touched on this workstation: the identity (name,
vendor, upgrade code), the build snapshots, the distribute records,
the audit log. It is the source of truth behind Recent projects,
the Reopen this package action, and the GDPR export. It never
leaves the workstation.
Cmdlet Library #
The Cmdlet Library is MAS' catalogue of PSADT commands the user
can drop into a build. It includes every cmdlet in the current PSADT
v4 template plus any custom cmdlets the packager has authored via the
in-app editor. The library is filesystem-backed
(%LOCALAPPDATA%\MilochApplicationStudio\cmdlets\), so custom
entries survive updates.
PSADT #
PowerShell Application Deployment Toolkit — the open-source scripting framework MAS wraps every package in. MAS 2.0 embeds PSADT v4.1.8; the exact version shipped with the running MAS build appears under Settings → About.
Audit chain #
Every write to the Memory Database is entered into an append-only
audit chain with a prevHash / rowHash linkage — the SHA-256
of each row includes the previous row's hash, so any tampering with
older rows breaks the chain. The chain is verifiable from the app
(Settings → Database → Verify audit chain) or via the reference
Python verifier in the Appendices cluster.
Ship queue #
The Ship queue is the background job pool that runs the Rollout
step. Each job has a state (Queued → Running → Completed | Failed | Cancelled), a toast in the notification tray, and an entry in the
Ship drawer. Multiple targets on a single package produce one job
per target — running an SCCM create and an Intune upload for the
same package produces two independent jobs.
Related chapters #
- Installation — before any of the above matters.
- Your first package — the vocabulary applied to a real seven-minute run.
- Workflow steps — the Capture / Build / Pre-Ship / Rollout steps in operational detail.