Hardened Environments

How the Agent Runs

• The agent is the Windows service PckgrAgent, running as Local System from C:\Program Files\Pckgr\Agent\pckgr-agent.exe.
• Every script runs through Windows PowerShell 5.1 (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe). From agent 1.1.38 it is started as powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -Command "& '<script>' <arguments>; if ($?) { exit 0 }; if ($null -eq $LASTEXITCODE) { exit 1 }; exit $LASTEXITCODE"; User-context script jobs and collectors wrap that line in cmd.exe /c ... 1> <stdout file> 2> <stderr file>. Agents before 1.1.38 use powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -File <script> (see the language mode section for why that changed). If you validate process chains, or have EDR or AppLocker rules keyed on the -File form, re-validate them against the -Command form before updating the agent. PowerShell 7 is not used.
• Apps and scripts set to the System context run as Local System. Those set to the User context run as the signed-in user, from the same folders. For a User-context job the agent grants the built-in Users group read and execute on that job's folder only. Users are never granted write access to anything the agent runs.
• The agent starts every Windows tool it needs (msiexec.exe, schtasks.exe, shutdown.exe, cmd.exe, powershell.exe) by its full path under C:\Windows\System32. It never uses WMI or PsExec to create processes.
• Every package is checked against a SHA-256 hash from the API before it is extracted, and every script is checked the same way before it is written to disk. A mismatch fails the job.

Programs

The Self-Service Portal is a single-file application. On first launch it unpacks its WebView2 loader into %LOCALAPPDATA%\Temp\.net\pckgr-self-service\ and keeps its browser data in %LOCALAPPDATA%\Pckgr\SelfServicePortal\WebView2\. The agent and the toast helper unpack nothing at run time.

Data Folder: C:\ProgramData\Pckgr

The agent creates this folder at enrollment with an access list of Local System and Administrators (Full Control) only. Standard users cannot read, create or change anything in it unless a row below says otherwise. The folder is shared with Pckgr for Intune, which writes its own PckgrPrivate_*.txt transcripts there.

Inside a deployment job folder, Work\<JobId>\:

When an app runs in Interactive mode, PSADT starts a client process from the package's PSAppDeployToolkit folder in the signed-in user's session to show its dialogs (close-apps prompts, deferrals, progress).

Temp and Log Locations Outside the Data Folder

Registry

The agent also creates the Start menu shortcut C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Pckgr\Self-Service Portal.lnk, the named pipes PckgrSelfService (Self-Service Portal) and PckgrScreenCapture-<id> (remote desktop), and the scheduled task PckgrAgentUpdateWatchdog for the duration of a self-update.

Code Signing

Publisher rules need a signature on the file that actually runs. This is the state today:

The path rules below are safe because none of the folders they cover can be written to by a standard user (see the access column above). That is the property AppLocker and WDAC path rules depend on.

Signing your own scripts

Scripts, collectors, pre-install and post-install scripts and custom detection scripts reach the device exactly as you saved them in the portal, and each runs from its own file. Sign them with your organization's code-signing certificate before pasting them in (for example with Set-AuthenticodeSignature), add a publisher rule for that certificate, and they run without a path rule. From agent 1.1.28 a collector keeps its signature too, because the Set-PckgrField helper comes from the signed runner installed with the agent rather than being added to your file; earlier agents modify the collector file and break its signature, so those still need the Work path rule. Two things still need the path rules on Work and Scripts: the catalog's own detection scripts, and the package configuration and extension files until they are signed.

AppLocker

Deploy these in Audit only mode first, enroll a pilot device, and switch to Enforce once the event log is clean.

If your policy keeps the default rule that lets the Administrators group run anything, System-context deployments and scripts are already allowed, because Local System holds that group. You then only need the rules below for User-context apps and scripts, and for the toast helper and Self-Service Portal, which run as the user.

Executable rules

Publisher rules can replace the second row: one for the PSAppDeployToolkit publisher, plus one per software vendor whose installers you deploy. The path rule is simpler and no less safe, because the Work folder is not writable by users.

Script rules

Windows Installer rules

A publisher rule for Pckgr Pty Ltd. covers the agent update MSI on its own; MSI-based applications still need the path rule or a rule per vendor.

DLL rules

Only if you enforce them: %OSDRIVE%\ProgramData\Pckgr\Work\* for the PSADT lib\ assemblies, and a publisher rule for Microsoft Corporation for the WebView2 loader the Self-Service Portal unpacks into the user's temp folder.

Finding what was blocked

Open Event Viewer and go to Applications and Services Logs, Microsoft, Windows, AppLocker. EXE and DLL logs events 8003 (would have been blocked, audit) and 8004 (blocked). MSI and Script logs 8006 and 8007. A blocked script also shows in the job's log bundle in the portal as a PowerShell error saying the file cannot be loaded because its operation is blocked by policy.

App Control for Business (WDAC)

• Allow the publishers Pckgr Pty Ltd., the PSAppDeployToolkit publisher and Microsoft for the signed files in the table above.
• Add file path rules for C:\Program Files\Pckgr\*, C:\ProgramData\Pckgr\Work\* and C:\ProgramData\Pckgr\Scripts\*. WDAC accepts a path rule only for a location standard users cannot write to; all three qualify.
• With script enforcement on, PowerShell runs a script that no rule allows in Constrained Language Mode instead of blocking it. PSADT and most collector scripts do not work in that mode, so the Work rule is required for deployments and collectors to run at all.
• Agents before 1.1.28 run System-context detection scripts from C:\Windows\Temp, which a WDAC path rule cannot cover, so on those agents they run in Constrained Language Mode until the agent updates. Registry and file checks work there; a detection script that calls .NET methods or uses Add-Type does not.

PowerShell Execution Policy and Language Mode

• For script execution, the agent passes -ExecutionPolicy Bypass. A machine-scope Group Policy (Turn on Script Execution) overrides that switch. Allow only signed scripts (AllSigned) stops every unsigned file in the tables above, which includes every detection, collector and pre-install and post-install script. Use Allow local scripts and remote signed scripts (RemoteSigned), or leave the policy unconfigured.
• When an authorized admin opens Remote Shell, the service starts interactive powershell.exe -NoLogo -NoProfile or cmd.exe /D through ConPTY, as SYSTEM in Session 0 or, when the admin chooses, in the signed-in user's session under that user's token. It does not pass an execution-policy override. Validate this process chain against your approved AppLocker, WDAC and EDR policies before enabling remote shell.
• Files the agent downloads carry no Mark of the Web, so RemoteSigned treats them as local and runs them.
• Constrained Language Mode breaks PSADT. Scripts that an AppLocker or WDAC rule allows run in Full Language mode, so the rules above are what keep deployments working. Forcing Constrained Language Mode on the whole device through the __PSLockdownPolicy environment variable is not supported.
• From agent 1.1.38 the agent starts every script file (script jobs, detection scripts, collectors through the runner, and a package's PSADT entry script when it runs as a .ps1) by calling it, not with PowerShell's -File switch. That matters on these devices: when the session starts in Constrained Language Mode, Windows PowerShell refuses to run a script that uses [CmdletBinding()] through -File even though a rule allows it, and the run ends before the script starts with Cannot dot-source this command because it was defined in a different language mode. Earlier agents hit that for every User-context run of such a script under AppLocker, the collector runner included, so User-context collectors there need agent 1.1.38; under WDAC script enforcement, where the session starts constrained for SYSTEM as well, it affected both contexts.
• The restart and shutdown notifications the agent shows before a device command use an inline PowerShell command in the user's session. Under Constrained Language Mode that notification does not appear; the command itself still runs.

Attack Surface Reduction Rules

ASR exclusions are set per folder or file in Intune under Endpoint security, Attack surface reduction, and apply to every rule. Controlled folder access does not affect the agent unless you add its folders to the protected list.

Microsoft Defender Antivirus and SmartScreen

No antivirus exclusion is required. If real-time scanning slows the extraction of large packages, C:\ProgramData\Pckgr\Work\ is the folder to exclude; every package in it has already been verified against the catalog's hash. SmartScreen never prompts: the agent downloads packages itself, so no file carries a Mark of the Web.

Network

The agent has no proxy settings of its own. Connections are made by the Local System account, so a proxy must apply to that account or be transparent on the network. If you inspect TLS, the inspecting certificate authority must be trusted in the device's machine store.

Rolling It Out

1. Put AppLocker or WDAC in audit mode with the rules above, and set any ASR exclusions.
2. Enroll one pilot device. Deploy one System-context app and one User-context app, run one script and one collector, and open a remote desktop session if you use it.
3. Review the AppLocker or WDAC event log and the job log bundles in the portal for anything blocked.
4. Switch to enforce and roll out.

Related

• Installing the Agent for the data folder overview and uninstall behavior
• Platform Security for how packages, scripts and device identity are protected in transit and at rest
• Scripts and Custom Fields for what runs from the work folder