Features that are not included in your edition are still visible. They show a lock icon and Not available in Free version, so you can see everything the product offers. When you click a locked feature, a message links to the plans.

Feature	Free	Pro
Number of packages	10	Unlimited
Tags per package	5	Unlimited
PSADT packages: create, edit, test, export as ZIP
Import PSADT v3/v4 packages (with v3 → v4 translation)
Test Run and Test in Sandbox
Detect Command, cmdlet autocomplete (all cmdlets)
Function Builder: Process and MSI/MSP
Function Builder: all other categories	—
PSADT Templates
Installed Apps, Activity Log, Tags
App Catalog: browse
App Catalog: create packages and one-click updates	—
Conversion Assistant: analysis
MSIX, App Attach and IntuneWin packages (create, convert to, build)	—
Signing certificates	—
Connections: Intune, Azure Storage, MECM uploads and deployments	—
FSLogix App Masking rules	—
README.md in exported packages	—
Shared Package Storage	—
Package Configuration: edit Assets, Toolkit and UI sections	— (MSI only)

The post Free and Pro editions appeared first on XOAP.

Both editions. Settings → PSADT Templates stores your organisation’s PSADT customisations as reusable templates. Templates are stored outside the toolkit folder, so they survive PSADT toolkit downloads and updates.

What a template contains

• Support Files: copied to SupportFiles/
• Files: copied to Files/. A package’s own uploaded files win when the names are the same.
• Assets: copied to Assets/, for example your own AppIcon.png. These win over the toolkit’s files.
• Extensions Code: PowerShell added to PSAppDeployToolkit.Extensions.psm1
• Script Functions: PowerShell functions added to the generated script, before the initialization section

Managing templates

The list shows each template’s name (a star marks the default), description, contents and the date it was last modified.

Review imported templates. Template code runs with full rights in every package that uses it. An imported template is therefore never made the default automatically, and the app warns you when an imported template contains code.

Using a template in a package

Choose the template on the Session Config step of a PSADT package, or choose None (stock toolkit). The template is applied in the script preview, in test runs, in every export (ZIP, IntuneWin, MSIX, App Attach) and in uploads.

The post PSADT templates appeared first on XOAP.

Pro edition. The FSLogix Rules page builds FSLogix App Masking rule sets and exports them as .fxr / .fxa file pairs. The files are compatible with Microsoft’s FSLogix Rule Editor.

What App Masking does

App Masking hides, redirects or changes files, folders, registry keys, fonts and printers per user or group on shared session hosts (AVD, multi-session Windows). The rules are installed on the host, and the assignments decide who they apply to.

Creating a rule set

Rules tab

For each rule:

1. Choose the Action:
   • Hide
   • Redirect
   • Set registry value
2. Choose the Item type:
   • folder or registry key
   • file or registry value
   • font
   • printer
3. Enter the Source path, for example C:\Program Files\MyApp\config.ini or HKLM\SOFTWARE\Contoso\App.
   • Use Insert macro for FSLogix path macros such as %ProgramFilesFolder64%.
   • A * wildcard matches one complete path part only. C:\Users\*\AppData works, C:\App*\ does not.
4. Fill in the extra fields for the action:
   • Redirect: the destination path, and optionally Copy original first.
   • Set registry value: the value type (String, ExpandableString, DWord, QWord or MultiString) and the data.
5. Optionally add a Comment.

Bulk add: paste many paths, one per line, to create a hiding rule for each at once.

Errors such as an empty path prevent saving. Warnings point out risky entries, for example hiding important Windows folders.

Assignments tab

Assignments decide who the rule set applies to. They are read from top to bottom, and the last matching entry wins.

A new rule set starts as Everyone / Doesn’t apply, which means it applies to nobody. The editor warns you until you add an assignment that applies.

• Who: Everyone, User, Group (by SID), Process, Network, Computer, OU or Environment variable.
• Applies / Doesn’t apply for each entry.
• Use the arrows to change the order.
• Presets:
  • Apply to everyone
  • Apply to group, exempt administrators

User and group assignments need identities synchronised from Active Directory. Cloud-only Entra ID accounts are not supported.

Preview tab

Shows the exact .fxr and .fxa file contents and updates as you edit.

Exporting and deploying

Click Download on a rule set:

• In the app: the files are saved to your Default Output Folder.
• In a browser: you get a ZIP with both files.

To deploy the rules:

1. Copy both files to C:\Program Files\FSLogix\Apps\Rules on each session host, for example via your golden image, Intune, Group Policy or a PSADT package.
2. FSLogix picks them up immediately. No restart is needed.
3. To remove the rules, delete the file pair.

Renaming a rule set only affects future exports. Files you exported earlier are not renamed.

The post FSLogix App Masking rules appeared first on XOAP.

Pro edition. Connections let you send packages straight to Microsoft Intune, Azure Storage or Microsoft Configuration Manager (MECM).

The Connections page

Open Connections in the sidebar. The table shows Name, Type, Target, Authentication and Last test (Passed / Failed / Not tested). Each row has Test connection, Edit and Delete. Click New Connection to add one.

All connection details stay on your computer:

• Secrets are encrypted with Windows DPAPI for your user account.
• Secrets are never shown again after you save them.

Microsoft Intune

Before you start, you need:

• An app registration in Microsoft Entra ID.
• The API permission DeviceManagementApps.ReadWrite.All, with admin consent granted.
• For interactive sign-in: the redirect URI http://localhost (platform Mobile and desktop applications).
• For app-only sign-in: a client secret.

Fields:

Azure Storage

MECM / Configuration Manager

Before you start, you need:

• The Configuration Manager console installed on this computer.
• A Windows account with ConfigMgr administrative rights. The app always connects as the signed-in Windows user, so no password is stored.
• A content share where:
  • your account has write access
  • the site server’s computer account has read access

Testing a connection

Click Test connection, either in the editor before you save or on a saved row. The test checks:

• Intune: that sign-in works and the permission is granted
• Azure Storage: that the container or share can be accessed
• MECM: that the console and module are present, the content share is writable and the site responds. The result shows the site name and version. The first test takes about 20 seconds.

Uploading a package

1. On a PSADT, MSIX or IntuneWin package card, click the upload (cloud) icon.
2. Choose the Destination and a Connection:DestinationPackage typesWhat happensMicrosoft IntunePSADT, IntuneWinPublished as a Win32 app. A PSADT package is wrapped as .intunewin automatically.Azure StoragePSADT, MSIX, IntuneWinThe package file is uploaded to the container or file shareMECMPSADTOpens the Deploy to MECM panel (see below)
3. Click Start Upload. You can click Hide (upload continues) and keep working. A notification appears when the upload finishes, even if you have moved to another page.

After an Intune upload, review assignments and details in the Intune admin center. It can take a few minutes until the app is fully available there.

Uploading several packages

Select packages on the workspace and click the toolbar upload icon. Choose Microsoft Intune or Azure Storage. Each package shows its own status (Waiting / Building / Published / Uploaded), and a summary appears at the end. MECM is not available for bulk uploads.

Deploying to MECM

The Deploy to MECM panel walks you through the following:

1. MECM connection. Collections and distribution points are loaded from the site. The first load takes about 20 seconds; the list is kept for 5 minutes, and Refresh reloads it.
2. Application. Name, publisher, version and description are pre-filled from the package.
3. Detection rules. Choose MSI product code, file exists, registry key exists, or a PowerShell script.
   • If the package contains an MSI, its product code is filled in for you.
   • A script rule must be the only rule.
4. Target collection. Pick an existing device collection, or create a new one:
   • Give it a name and a limiting collection.
   • The new collection is created empty. Add members in the console.
5. Content distribution. Choose distribution point groups and/or individual distribution points.
6. Deployment. Choose the purpose:
   • Available (self-service in Software Center)
   • Required (installs automatically, with an optional deadline)
   Also choose the user notification setting.
7. Optionally open Preview the deployment script.
8. Click Deploy.

The package content is copied to {content share}\Applications\{Publisher}\{Name}\{Version}. The application, the PSADT deployment type, the collection, the content distribution and the deployment are created, and progress is shown live. Content distribution to the distribution points then finishes in the background.

Possible conflicts:

• An application with the same name already exists. The deploy stops before anything is created.
• The content folder already exists. Turn on Overwrite the content folder, or increase the version.

The post Connections & uploads appeared first on XOAP.

Browsing: all editions. Creating packages: Pro.

The App Catalog lists applications from two sources:

• about 600 apps from the Evergreen project
• about 14,000 apps from the Windows Package Manager (winget) community repository

You can create a ready-to-review PSADT package for any of them.

The App Catalog needs an internet connection. The list is cached for 24 hours. If no source can be reached, the last cached list is shown with a stale data badge.

Browsing

• Search by name, publisher or package ID. Sort by the columns and page through the results.
• Use the source filter (All / Evergreen / winget) to show one source. A badge on each row shows its source.
• The link icon opens the vendor’s web page (Evergreen apps).
• Click a row to open the configuration panel.

For winget apps, the list first shows the publisher part of the package ID (for example Microsoft). The full publisher name is read when the package is created.

Configuring the release

The panel only offers the choices that exist for that app, with sensible defaults:

• Version: newest preselected
• Architecture: x64 preferred, then ARM64, then x86
• Channel: Stable preferred
• Installer type: MSI preferred over EXE
• Language: English preferred

A summary shows the installer file, its size, the download host and whether a checksum is available.

Create package (Pro)

When you click Create package, the wizard does the following:

1. Downloads the installer into the new package (with progress; you can cancel).
2. Checks the download. It verifies the SHA-256 checksum when one is published (always for winget) and checks that the file really is an installer.
3. Determines the silent switches:
   • MSI installers always use /qn /norestart.
   • For EXE installers it uses the first match from: the curated list, the winget manifest, a scan of the installer, the winget installer type, and finally the file name.
   • If nothing matches, the package is flagged needs review, and the generated install phase stops with an error instead of starting an interactive setup.
   • winget apps that install per user only get a hint, because PSADT installs machine-wide.
4. Creates the PSADT package with:
   • application details
   • a silent install phase
   • a registry-based uninstall phase
   • a repair phase
   The package then opens on Session Config for review.

Review and adjust the generated package like any other package before you export it. Catalog packages count towards the Free edition limit.

Update badges

Packages created from the catalog remember the app and release they came from.

• When the check runs. When you open the Packages Workspace, they are checked against the catalog. This happens at most every 6 hours and is skipped silently when offline.
• The badge. If a newer version exists, the card shows an amber UPDATE badge with the new version.
• The update button (Pro) creates a new package at the new version. The existing package is kept.
  • Tags and the PSADT template are carried over.
  • Manual edits to the phases are not carried over. Re-apply them before you export.
• Same variant only. Updates are only shown for the same architecture, channel and installer type that you originally picked.

Packages created before version 2.1.0, and converted copies, do not show update badges. Create them again from the catalog to get update badges.

The post App Catalog appeared first on XOAP.

Use the Conversion Assistant to turn a package into another type, for example PSADT → MSIX, MSIX → App Attach, or PSADT → IntuneWin.

1. On the Packages Workspace, click Convert… on a package card.
2. The assistant analyses the package and shows a card for each target type.

Each target card shows:

• Readiness: Ready to build, N details needed, or Not possible from this payload
• Carries over automatically: values taken from the source, such as name, version, publisher, install and uninstall commands, and silent switches
• Needs your input: only the fields the assistant cannot derive, with pickers for your uploaded files
• Checks: a preview of the build validation
• This machine: notes about your computer, for example that App Attach needs administrator rights

Conversion always creates a new package. The original is not changed. Name, version, publisher, architecture, uploaded files and tags are carried over. The analysis is available in both editions; creating MSIX, App Attach or IntuneWin packages needs Pro.

When the package contains an installer

MSIX and App Attach need the installed application, not its setup program. If the source package contains an installer, the assistant offers three options:

• Repackage the installer (recommended). The wizard unpacks the installer without running it on your machine:
  • MSI: an administrative extraction rebuilds files, registry and shortcuts.
  • Inno Setup, NSIS and self-extracting archives: unpacked with an extraction tool when one is available.
  • Other installers (WiX Burn, InstallShield, unknown): are passed to Install & capture, with the reason shown.
  Repackaging runs in the background with progress and Cancel. Afterwards a pre-filled package opens in the wizard, and a report shows what was rebuilt and what was skipped.
• Install & capture. The installer runs silently and the wizard records what changed in the file system and registry. Things to know:
  • The app must run as administrator.
  • Use a disposable virtual machine for this.
  • Your own user profile data is never captured.
• Keep as-is. Builds a package that contains the raw installer. You get a warning that the result will probably not work as expected.

Viability check

Before any work is done, the assistant checks whether the app can work as MSIX or App Attach at all:

• Blockers (not possible): kernel drivers, credential providers, in-process shell extensions (for example Explorer context menus), and hardware license dongles. The evidence is named.
• Conditional: Windows services work with MSIX but not with App Attach.
• Warnings: writes to the install folder, scheduled tasks, machine environment variables.

Other conversions

• PSADT → IntuneWin offers two options:
  • Deploy this PSADT package via Intune: the whole PSADT package is wrapped.
  • Repackage the raw installer: install and uninstall commands are derived from the installer.
• Conversions to PSADT create real install and uninstall code from the source:
  • An .msi becomes Start-ADTMsiProcess.
  • An MSIX is built, signed and provisioned machine-wide, and its certificate is trusted.

The post Converting packages appeared first on XOAP.

Test Run (PSADT)

On the Preview step of a PSADT package:

1. Choose Deployment Type (Install / Uninstall / Repair) and Deploy Mode.
2. Optionally turn on Run as Admin. Most installations need it, and Windows shows a UAC prompt.
3. Click Test Run.

The script runs on this computer with exactly the files, toolkit and template that the exported package would contain. Its output appears in the PowerShell Output panel. A test run stops after 120 seconds.

Test Run installs software on your own machine. To keep your machine clean, use Test in Sandbox.

Test in Sandbox (PSADT)

Test in Sandbox runs the package on a clean, disposable Windows machine (Windows Sandbox), without leaving the app. It shows you how the package behaves on a fresh client.

1. Enable Windows Sandbox once: Settings → General → Windows Sandbox → Enable Windows Sandbox. Windows shows an administrator prompt, and a restart is needed afterwards. Windows Sandbox is not available on Windows Home editions.
2. On the Preview step, choose Deployment Type and Deploy Mode:
   • Silent or NonInteractive for a fully automatic test
   • Interactive if you want to click through the PSADT dialogs in the sandbox window yourself
3. Click Test in Sandbox.

A progress panel follows the run. When it finishes, it shows:

• the result based on the exit code
• the PSADT deployment log

Further notes:

• Cancel stops the test and closes the sandbox.
• Close Sandbox closes the sandbox window after the test.
• Only one sandbox can run at a time.
• Everything inside the sandbox is discarded when it closes.

Verifying with Installed Apps snapshots

Use the snapshot feature on the Installed Apps page to check what a package really installed and whether the uninstall removed it again.

The post Testing packages appeared first on XOAP.

Pro edition. Creates a Microsoft Intune Win32 app package.

Step 1: Source Files

Upload the setup files, for example the MSI, EXE, scripts and configuration files.

Step 2: App Information

Enter Name (required), Publisher, Version and Description. These are shown in the Intune admin center.

Step 3: Program

For MSI installers, the product information and a product-code detection rule are filled in automatically.

Step 4: Detection Rules

Intune uses detection rules to find out whether the app is installed.

• Add as many rules as you need with + Add detection rule. All rules must match.
• Rule types:
  • msi: the MSI product code
  • file: the full path of a file
  • registry: a registry key, for example HKLM\SOFTWARE\…
  • script: a detection PowerShell script
• At least one rule is required to publish the app in Intune.

Step 5: Requirements

Step 6: Preview & Build

Review the build plan and click Finish.

Result:

• {name}.intunewin: the encrypted package
• {name}.intune.json: all app details, commands and detection rules, ready for automated publishing

To deliver a PSADT package through Intune, you don’t need an IntuneWin package. Upload the PSADT package to Intune directly (see Connections & uploads). It is wrapped as .intunewin automatically.

The post Creating an IntuneWin package appeared first on XOAP.

Pro edition. App Attach delivers an MSIX app to Azure Virtual Desktop or Windows 365 session hosts by mounting it from a disk image instead of installing it.

Step 1: MSIX Source

Upload one of the following:

• a ready-made .msix or .msixbundle, or
• the application files. The wizard then builds and signs the MSIX for you.

Step 2: Image Format

About CIM images:

• A CIM image consists of several files: {name}.cim plus objectid_* and region_* files. Always copy all of them together.
• The generated scripts need the CimDiskImage PowerShell module on the session host. AVD’s built-in App Attach mounts CIM images without this module.
• Use VHDX for Windows Server 2019 and 2022 hosts.

A ready-made .msix that you upload is checked before it is used:

• Unsigned packages are rejected.
• Packages whose publisher does not match their signature are rejected.
• If the signer is not trusted on this machine, you get a warning.

Step 3: Signing

This step offers the same certificate and timestamp settings as the MSIX wizard. It applies when the wizard builds the MSIX itself. The public certificate (.cer) is saved next to the image, and the Stage script trusts it automatically on the session host.

Step 4: Lifecycle Scripts

App Attach uses four scripts:

Working default scripts are generated for you. To change one, click Customize:

• You can use Insert snippet… for logging or error handling.
• Reset to generated default undoes your changes.

For AVD host pools, Microsoft recommends the built-in App Attach feature in the Azure portal. In that case you only need the image.

Step 5: Metadata

Enter the Display name (required) and the Version.

Step 6: Preview & Build

The step shows the validation results and the image plan, and checks this machine:

• If the msixmgr tool is missing, the build is blocked and the reason is explained.
• Creating a disk image needs administrator rights. If the app is not running as administrator, the Request admin rights (UAC) switch appears (on by default). Windows shows an administrator prompt when the build starts. Choose Yes in that prompt.

Click Build App Attach Image.

Result:

• the image (.vhdx, .vhd, or the .cim file set)
• the four lifecycle scripts
• {name}.cer

App Attach images are built to disk and cannot be uploaded from the app. Copy them to your file share yourself.

The post Creating an App Attach package appeared first on XOAP.

Pro edition. An MSIX package contains the installed application files (not an installer), together with a manifest that describes the app to Windows.

If you only have an installer (setup.exe or .msi), create a PSADT package with it and convert it to MSIX. The Conversion Assistant can repackage the installer for you.

Step 1: Source Files

Upload the application files, for example the folder with the application’s EXE and DLL files.

Step 2: Package Identity

The step also shows the resulting Package Family Name.

Step 3: Dependencies (Dependencies & Capabilities)

• Capabilities. Pick from the standard values or type your own. runFullTrust is required for classic Win32 applications.
• Framework dependencies. For example the Visual C++ runtime (VCLibs), WinUI or the Windows App Runtime. Pick a preset or enter Name or Name|MinVersion.

Step 4: Applications

Choose the Primary executable from your uploaded .exe files. This is the program that the Start menu entry launches.

Step 5: Signing

Windows only installs signed MSIX packages.

If no certificate exists, a long-lived self-signed certificate is created automatically on the first build. Its public certificate (.cer) is saved next to the package so you can trust it on target machines.

Step 6: Preview & Build

• Shows the validation results and the generated AppxManifest.
• When the status reads All checks passed — ready to build, click Finish to build, sign and save the .msix.

Result: {name}.msix and {name}.cer.

The post Creating an MSIX package appeared first on XOAP.