Group Policy / SCCM / Intune deployment

Roll out CriticalPDF to many machines with silent install, license keys at deploy time, and update-channel pinning.

The CriticalPDF MSI is built for managed deployment. It supports silent install, accepts configuration via MSI properties, and exposes the right markers for inventory and detection.

Silent install

msiexec /i CriticalPDF-Suite-2026.517.37.msi /qn `
  LICENSE_KEY="CPDF-XXXX-XXXX-XXXX-XXXX" `
  UPDATE_CHANNEL="public" `
  AUTO_UPDATE="1"

Properties:

Group Policy (GPO)

The MSI is signed and can be assigned via standard Software Installation GPOs.

To pass MSI properties through GPO, use an .mst transform — the suite ships with a template at C:\Program Files\CriticalPDF\deploy\CriticalPDF.mst. Open it in Orca or a similar MSI editor and set the properties to match your deployment.

SCCM / Intune

The MSI installs as per-machine (not per-user), so deploy it as an Application with detection method:

• MSI product code: see release notes for the exact GUID per version.
• MSI version: the suite version on the Downloads page (date-based, e.g. 2026.517.37.0).

Both Configuration Manager and Intune can read the MSI metadata directly to auto-fill these fields.

For Intune, the Win32 app wrapper is the right format if you need to pass properties or run pre/post-install scripts. The Line-of-business app type works if you’re deploying with the default settings.

Pre-deploying templates

You can ship a curated set of templates to a fleet by dropping an exported .cpdf file into the install location and including it in your deployment:

1. On a reference machine, build the templates you want.
2. Settings → Templates → Export… to write a .cpdf file.
3. Include the file in your SCCM / Intune package.
4. Post-install script: copy the .cpdf to a known location and trigger the import on first user launch (e.g., via a run-once registry value).

Secrets (SMTP passwords, OAuth tokens, PDF encryption passwords) are not included in .cpdf exports — each user will enter or re-authenticate them on first run.

Multi-user Server / RDP deployments

CriticalPDF is supported on Windows Server 2016, 2019, 2022, and 2025 running RDP / RDS. The architecture handles multi-user hosts natively:

• The CriticalPDF Service runs once per machine as LocalSystem and watches the single shared print spooler.
• For each captured print job, the service uses CreateProcessAsUser to launch the desktop app as the Windows user who submitted the job — so a capture is always attributed to, and processed for, the person who printed it.
• The GUI config is per-user: each Windows account gets its own config.json under C:\ProgramData\CriticalPDF\users\<username>\. One user’s templates and email settings don’t disturb anyone else’s on the host.
• Stats, logs, error reports, the dead-letter queue, and the service config are shared machine-wide.

Practical deployment notes:

• Pre-deploy the license key via the LICENSE_KEY MSI property so each user activates transparently on first launch — no per-user license dialog.
• Pre-deploy templates by including a .cpdf file in your deployment and importing it for each user on first launch (see Pre-deploying templates above). Because config is per-user, each account gets its own copy of the template set.
• The virtual printer queue is shared — all users see and print to the same CriticalPDF printer (unless you restrict it — see below).
• The dead-letter queue is machine-wide — failed deliveries replay against the originating user when they next sign in. A capture from User A won’t deliver into User B’s session.

How seats are consumed on RDP hosts

On RDP / RDS, seats are only consumed and checked at print time. A user who is signed into the Server host but never prints to CriticalPDF does not consume a seat. So:

• A Server 2022 host with 100 signed-in users but only 12 who actually print needs 12 seats, not 100.
• A user who prints once during a session continues to occupy that seat for the rest of the session — they aren’t re-counted on each print.

Recommended: restrict who can see the printer. Because every user on the host can see the CriticalPDF printer by default, a curious user who picks it from a print dialog can accidentally consume a seat. Adjust the printer’s Security permissions so only users who need it can see or use the queue:

1. On the Server, open Devices and Printers, right-click CriticalPDF, Printer properties → Security.
2. Remove Everyone from the access list.
3. Add the specific Active Directory group of users who should be licensed (e.g., CriticalPDF Users). Grant Print permission.
4. Users not in that group will no longer see the printer in their print dialogs.

For larger fleets, deploy the same restriction via Group Policy Preferences → Printers → Security, or via PowerShell:

# Remove Everyone from CriticalPDF's printer permissions
$acl = (Get-Printer CriticalPDF | Get-PrinterPermission)
# Then apply your AD group via Set-PrinterPermission or the GPO equivalent.

This keeps your seat count aligned with the people who actually need the product, instead of every user who happens to log into the host.

Version pinning

Releases pin three version markers:

For a given Suite version, the UI and service versions are guaranteed compatible. Mix-and-matching across suite versions is not supported.

The current Suite version on each installed machine is visible in Settings → Help / Support → Versions and updates.

Verifying a deployment

After install, every machine should report:

Get-Service "CriticalPDF Service" | Select Status, StartType
# Expected: Running, Automatic

Get-Printer CriticalPDF | Select Name, PrinterStatus
# Expected: CriticalPDF, Normal

To inventory the installed Suite version across a fleet, query the MSI product registry or pull the value from the desktop app’s local API.

License seat release

When you decommission a machine — or move a user to a new one — release the seat from the old install:

1. Open the desktop app on the old machine.
2. Settings → Licensing → Release license.
3. Confirm. The seat returns to your license pool immediately.

If the old machine is already gone, contact sales@criticalpdf.com — we can release seats from the license server side.

Pinning the dead-letter encryption key

The MSI generates a random EncryptionPassword in serviceconfig.json per install. If you’d like all machines in a fleet to share a key (so a captured dead-letter file is readable by any machine), set it post-install via a configuration management tool and restart the service:

$cfg = "C:\ProgramData\CriticalPDF\serviceconfig.json"
$json = Get-Content $cfg -Raw | ConvertFrom-Json
$json.CriticalPdf.EncryptionPassword = "<your-shared-strong-password>"
$json | ConvertTo-Json -Depth 20 | Set-Content $cfg -Encoding UTF8
Restart-Service "CriticalPDF Service"

Most deployments don’t need this — random per-install keys are the safer default.

Was this page helpful? Let us know.