ceterion Packaging Framework (cPF)

Enterprise-ready PowerShell framework for standardized, automated, and platform-agnostic software packaging and deployment integration.

---

🚀 Quick Start

Import-Module PackagingFramework
Initialize-Script
New-Package -Path C:\Temp -Name 'MyApp_1.0'

---

What a package looks like

A cPF package is a PowerShell script plus a JSON file next to it. The script holds the installation logic — nothing else:

# Installation
If ($deploymentType -ieq 'Install') {

    Start-MSI -Action 'Install' -Path "$Files\7z1604-x64.msi"
    Remove-File -Path "$CommonStartMenuPrograms\7-Zip File Manager.lnk"
    Remove-Folder -Path "$CommonStartMenuPrograms\7-Zip"

}

Everything around it is declared, not coded — shortcuts, firewall rules, permissions, AppLocker rules, detection methods, dependencies:

{
  "Package": {
    "PackageDescription": "7-Zip x64 16.04",
    "PackageDisplayName": "7-Zip",
    "PackageGUID": "09366b72-9466-416c-8245-65f0419320d9"
  },
  "Applications": [
    {
      "AppName": "7-Zip",
      "AppCommandLineExecutable": "$ProgramFiles\\7-Zip\\7zFM.exe",
      "AppWorkingDirectory": "$ProgramFiles\\7-Zip",
      "AppFolder": "Utilities",
      "AppIconSource": "$ProgramFiles\\7-Zip\\7zFM.exe"
    }
  ],
  "DetectionMethods": [ ],
  "FirewallRules": [ ],
  "Permissions": [ ]
}

The package GUID is written to the registry at install time and serves as a detection method for MECM, Intune and others. Package header, footer and error handling are generated by New-Package and are identical across every package — which is what makes a package estate reviewable.

Ten complete example packages ship with the module and are installed to %MyDocuments%\Packaging Framework Examples — including a reference package that demonstrates every cmdlet in context.

---

💡 Why cPF?

You have hundreds of packages and a platform migration ahead. Automated converters turn existing Matrix42 Empirum, Ivanti DSM, WISE and NSIS packages into maintainable PowerShell packages — instead of repackaging them by hand.

You need packages that are consistent, not just working. Enforced naming schema, validation rules and 450+ templates make every package look the same, no matter who built it.

You have to prove what you shipped. Package integrity sealing hashes every payload file and validates it at install time — a modified, missing or added file aborts the package before anything runs.

Your packages must reach more than one platform. The same package deploys through Intune, MECM, Workspace ONE, Recast Application Workspace or XOAP — no rebuild per platform, no vendor lock-in.

You would rather not build all of this yourself. Since 2017, 29 public releases — plus assessment, migration, training, packaging as a service and support from the team that builds it.

---

Who is this for?

• Enterprises with grown package estates facing migration or standardization
• Teams packaging for several endpoint management platforms in parallel
• Regulated environments that need reproducible, auditable packages
• Service providers packaging at scale for multiple customers

Less suited for: a handful of individually maintained packages with no standardization or migration requirement.

---

Overview

The ceterion Packaging Framework (cPF) is a modular PowerShell-based framework for standardized, automated, and enterprise-ready software packaging.

Since 2017, the framework has been continuously evolved and architecturally expanded across more than 40 internal iterations, consolidated into 29 public releases. It is actively maintained, with several releases per year.

It enables organizations to build, manage, and deploy application packages in a consistent, scalable, and maintainable way across modern endpoint management platforms.

Key Features

• Modular PowerShell architecture (fully refactored from script-based approach)
• Standardized packaging methodology for enterprise environments
• Integration-ready for modern deployment solutions (e.g. MECM, Intune, Workspace ONE)
• Seamless integration with the ceterion Deployment Framework (cDF, separate product) enabling end-to-end automation from packaging to deployment
• Native integration with Recast Application Workspace for enhanced application management and user experience
• Package integrity sealing with automatic install-time validation (New-PackageSeal / Test-PackageSeal)
• Built-in logging, error handling, and user interaction handling
• Highly customizable via central configuration (PackagingFramework.json)
• Designed for automation and CI/CD scenarios

Packaging Lifecycle

The framework supports a structured end-to-end packaging and deployment lifecycle:

Create → Configure → Package → Test → Deploy → Maintain

Roles & Technologies:

• Create / Configure / Package / Test

  • cPF (ceterion Packaging Framework) – Standardized packaging, configuration, validation, and testing

• Deploy

  • Any deployment mechanism (including custom scripts such as CMD/PowerShell)
  • Tools (Endpoint Management)
    • Microsoft Intune – Endpoint management platform
    • Microsoft MECM (SCCM) – Endpoint management platform
    • Omnissa Workspace ONE – Endpoint management platform
    • Recast Application Workspace – Application delivery and endpoint management platform
  • Frameworks
    • cDF (ceterion Deployment Framework) – Optional deployment orchestration and automation (separate ceterion product)
  • Platforms / Experience Layer
    • XOAP – Integration, package management, and Infrastructure-as-a-Service (IaaS) enablement

• Maintain

  • cPF / cDF – Lifecycle updates, versioning, and operational management

This ensures a seamless transition from packaging to enterprise deployment workflows.

Technology Base

cPF originated from the PowerShell App Deployment Toolkit. Its engine components were refactored, extended and stabilized, then embedded into a modular architecture built for real-world enterprise requirements.

Since 2017, the framework has followed its own development line — with its own API, its own release, signing and support process, and roughly 55 functions that have no counterpart upstream.

cPF and PSAppDeployToolkit

The two operate on different levels.

PSAppDeployToolkit provides an installation engine — install logic, user dialogs, logging, process handling.

cPF provides the packaging platform around it — standardization, validation, integrity, migration of existing package estates, and publishing to endpoint management platforms.

If you need an installation engine, PSAppDeployToolkit is a solid choice. If you need to industrialize a package estate — migrate it, standardize it, and keep it maintainable across platforms — that is what cPF is built for.

cPF and cDF

The ceterion Deployment Framework (cDF) is a separate ceterion product, not a component of cPF. cPF is fully functional without it.

cDF automates deployment and infrastructure beyond the individual package: provisioning, rollout strategies including blue/green, canary and rollback, orchestration through a management console or command tool, and centralized status, logging and compliance reporting. It ships its own REST API, install agent and job providers for VMware, Hyper-V, XenServer and WDS/PXE.

cPF packages integrate with cDF when it is present — Get-Parameter, Set-Parameter and Add-InstallationLogEntry use the cDF REST API — and run unchanged when it is not.

→ ceterion Deployment Framework

What's New in 2608 (26.8.1.0)

• Special character support in cDF API related cmdlets. Get-Parameter, Set-Parameter and Add-InstallationLogEntry now handle special characters such as German umlauts correctly in cDF REST API requests; the JSON request body is UTF-8 encoded (GitHub issue #4).
• Bugfix. Add-InstallationLogEntry populated the Command property with the value of the Status parameter (GitHub issue #3).

Previously in 2606 (26.6.1.0)

• Package integrity sealing — seal a package's Files folder with per-file MD5 hashes and a top-level aggregate manifest hash via New-PackageSeal, embedded as a collapsible #region block inside the package script. The seal is validated automatically at install time (Test-PackageSeal, invoked by Invoke-PackageStart); a changed, missing, or added file aborts the package before any payload runs. Sealing removes any existing Authenticode signature so packages can be re-signed afterwards (seal, then sign).

Previously in 2604 (26.4.0.0)

• Localization extended to 25 supported languages (23 newly added):
  • Newly added: Arabic, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch (Netherlands), Finnish, French, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian (Bokmål), Polish, Portuguese, Portuguese (Brazil), Russian, Slovak, Spanish, Swedish, Turkish, Ukrainian
  • Previously supported: German, English
• Added XOAP support for integration, deployment, and management of Packaging Framework packages in XOAP environments
• Updated internal parameter handling (ServiceURL replaces WebserverURL)

Optional Extensions & Toolsets

The following capabilities are not part of the Community Edition. They are available as part of a ceterion project engagement:

• Migration Converters

  • Matrix42 Empirum → PowerShell
  • Ivanti / DSM / NetInstall / HEAT / FrontRange → PowerShell
  • Wise Script → PowerShell
  • NSIS → PowerShell

• Intune Toolset

  Packaging for Intune is part of the Community Edition, including .intunewin creation. The toolset adds full Win32 app lifecycle management via New-IntuneApplication:

  • Configure nearly every Intune Win32 app property directly from the package JSON manifest — metadata, detection rules, assignments, dependencies and icons
  • Detection rules from the manifest: registry, file and MSI
  • Resolve and create assignment groups, post assignments
  • Update existing apps, overwriting metadata and content versions
  • Bulk run: recursively process every package folder under a parent directory and upload each package individually

• SCCM / MECM Toolset

  Packages already carry what MECM needs — GUID-based detection, dependencies and supersedence are declared in the package manifest. The toolset turns that into MECM objects via New-MECMApplication:

  • Import cPF packages as MECM applications, with command line and deployment type generated automatically
  • Create applications, device and user collections, and deployments in a single step
  • Detection rules from the package manifest: directory, file, registry key, registry value and Windows Installer — including version, size and date comparisons
  • Dependencies and supersedence resolved through package GUIDs
  • Environment settings (server, site, share, distribution point groups) and naming patterns for every MECM object held centrally in PackagingFrameworkMECMExtension.json
  • Bulk import of every package in a folder

• Workspace ONE UEM Extension

  Import cPF packages into Omnissa Workspace ONE UEM via New-WorkspaceOneUemPackage, with install and uninstall command lines and the detection method derived from the package:

  • Import a single package or bulk-import an entire folder structure
  • Packages in EXE and ZIP format
  • Query applications, groups and devices via Get-WorkspaceOneUemApp, Get-WorkspaceOneUemGroup and Get-WorkspaceOneUemDevice
  • REST API endpoint, key, credentials and group ID held centrally in PackagingFrameworkWorkspaceOneUEMExtension.json, with the password stored as an encrypted SecureString

• Citrix Extension

  The Applications section of the package manifest — the same one that defines local shortcuts — also drives publishing to Citrix Virtual Apps and Desktops:

  • Publish applications to a delivery group straight from the package manifest
  • Create nested application folders from the manifest folder path
  • Assign icons extracted from the application executable
  • Grant user and group access from the manifest
  • Discover site configuration and the delivery group of the current machine from the delivery controller
  • Clean up published applications and empty folders

• Template Libraries (in addition to the example packages included with the module)

  • 450+ Application package templates
  • 100+ OS configuration templates
  • Citrix templates (PVS, XenApp, XenDesktop)

• Winget Repository Integration

  • Automated integration of Winget package repositories
  • Enterprise-ready consumption of public repositories with standardized packaging integration

• Packaging as a Service (PaaS)

  • Outsourced and scalable application packaging services by ceterion
  • Standardized, high-quality package delivery aligned with enterprise requirements

• Professional & Support Services

  • Implementation and customization
  • Integration into existing environments
  • Trainings and workshops
  • Technical support
  • SLA-based enterprise support

Installation

Run:

PackagingFrameworkSetup.exe

Usage

Requirements

• PowerShell with administrative privileges
• Execution policy allowing script execution:

Set-ExecutionPolicy RemoteSigned

Import Module

Import-Module PackagingFramework

Initialize Runtime

Initialize-Script

Discover Commands

Get-Command -Module PackagingFramework

Help

Get-Help [Command]
Get-Command -Module PackagingFramework | Get-Help
Show-HelpConsole

Runtime Variables

Get-Variable | Out-GridView

Create a Package (Example)

New-Package -Path C:\Temp -Name 'Microsoft_Office_16.0_EN_01.00'

Configuration

Central configuration file:

%ProgramFiles%\WindowsPowerShell\Modules\PackagingFramework\PackagingFramework.json

Example Packages

%MyDocuments%\Packaging Framework Examples

Support & Contact

• Email: packagingframework@ceterion.com
• GitHub Issues: https://github.com/ceterion/PackagingFramework/issues

License

Licensed under the GNU General Public License v3.0.

See /LICENSE.txt for details.