EasyCC
For admins

Deploy

Install EasyCC across your fleet — installers, MDM wiring, updates, and detection.

Everything between "I have the installer" and "EasyCC is live on the fleet, staying current."

For a guided walkthrough on one test machine, start at the admin quick start — about 30 minutes.

Installers

EasyCC ships one signed installer per platform.

PlatformArtifactInstall scopeSigning
WindowsEasyCC-Setup.exe (NSIS)Per-user — installs to %LOCALAPPDATA%\EasyCC. No UAC required for install or auto-update.EV-signed (Authenticode)
macOSEasyCC.dmg (interactive drag-to-Applications)/Applications/EasyCC.appApple Developer ID signed + notarized + stapled

macOS unattended install is not yet supported. EasyCC ships a .dmg today, which requires the user to drag the app into /Applications/. A signed-and-notarized .pkg for sudo installer -pkg EasyCC.pkg -target / is on the roadmap. In the meantime, host the .dmg on a managed share and have users install it themselves — managed policy and service-provider bundles work either way. For a per-user MDM script workaround, extract EasyCC.app from the .app.tar.gz updater artifact into /Applications/.

Windows perMachine is on the roadmap. A separate EasyCC-Enterprise-Setup.exe artifact for true machine-wide deploys is planned. Until then, push the per-user installer in user context (Intune user-context apps, Jamf user-level policies).

Silent install (Windows)

EasyCC-Setup.exe /S
EasyCC-Setup.exe /S /D=C:\custom\path

/D= must be the last argument and unquoted (NSIS quirk).

Runtime flags

FlagWhat it does
--silent-first-runSkip the interactive onboarding when a service-provider bundle or managed policy already satisfies setup. If setup isn't satisfied the wizard runs anyway.
--autostart-hiddenLaunch with no window — used by the OS-login autostart hook.
& "$env:LOCALAPPDATA\EasyCC\EasyCC.exe" --silent-first-run
/Applications/EasyCC.app/Contents/MacOS/EasyCC --silent-first-run &

File and registry footprint (Windows)

ArtifactPath
Binary%LOCALAPPDATA%\EasyCC\EasyCC.exe
Uninstaller%LOCALAPPDATA%\EasyCC\uninstall.exe
Start menu shortcut%APPDATA%\Microsoft\Windows\Start Menu\Programs\EasyCC.lnk
Add/Remove ProgramsHKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\EasyCC
Per-user app data%LOCALAPPDATA%\com.easycc.app\ (config, history, logs)
Per-user agents%USERPROFILE%\Documents\EasyCC\ (default; agents_root policy overrides)

File footprint (macOS)

ArtifactPath
App bundle/Applications/EasyCC.app
Per-user app data~/Library/Application Support/com.easycc.app/
Per-user logs~/Library/Logs/com.easycc.app/
Per-user agents~/Documents/EasyCC/ (default; agents_root policy overrides)

MDM wiring

Every MDM follows the same three-piece pattern: package the installer, push managed policy, optionally drop a bootstrap bundle. Per-MDM, here's the form each piece takes.

Microsoft Intune (Windows)

The most common deploy path.

  1. Package the installer. Wrap EasyCC-Setup.exe with IntuneWinAppUtil.exe -c <folder> -s EasyCC-Setup.exe -o <out> to produce EasyCC-Setup.intunewin.
  2. Create a Win32 app in Intune admin center → Apps → Windows → Add → Win32. Install command: EasyCC-Setup.exe /S. Uninstall: "%LOCALAPPDATA%\EasyCC\uninstall.exe" /S. Install behavior: User (per-user installer).
  3. Detection rule: file exists at %LOCALAPPDATA%\EasyCC\EasyCC.exe, or registry HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\EasyCC\DisplayVersion ≥ <floor>.
  4. Managed policy: create a Settings Catalog profile (or a custom OMA-URI / PowerShell script policy) that writes to HKLM\Software\Policies\EasyCC (enforced) and HKLM\Software\Policies\EasyCC\Recommended (defaults). See Configuration.
  5. (Optional) Secrets: push to Windows Credential Manager via a PowerShell script policy using cmdkey /add:com.easycc.app /user:<slot> /pass:<value>. See Secrets.
  6. (Optional) Bundle: drop the bootstrap JSON at %PROGRAMDATA%\EasyCC\bootstrap.json via a PowerShell script policy. See Bundles.

Jamf Pro (macOS)

Most common Mac MDM. Today's flow assumes the user installs from the .dmg; the per-MDM PKG path lands when the signed .pkg ships.

  1. Distribute the .dmg via a Self-Service policy, or host it on a managed share.
  2. Push managed policy with a configuration profile that writes a plist to /Library/Managed Preferences/com.easycc.app.plist. Top-level keys are enforced; keys nested under a recommended dict are defaults.
  3. Detection: bundle exists at /Applications/EasyCC.app. For version checks: defaults read /Applications/EasyCC.app/Contents/Info CFBundleShortVersionString.
  4. (Optional) Secrets: push to Keychain via security add-generic-password in a Jamf script. Service name com.easycc.app.
  5. (Optional) Bundle: drop at /Library/Application Support/EasyCC/bootstrap.json.

SCCM / Configuration Manager (Windows)

Same Win32 app pattern as Intune. Use the Application model (not Package) so SCCM evaluates the detection rule and reports compliance. Same install/uninstall/detection commands. For policy, run a Compliance Settings configuration item that writes HKLM\Software\Policies\EasyCC, or run the PowerShell snippet from Configuration as a deployment script.

Active Directory Group Policy

Two pieces:

  • Software install: publish EasyCC-Setup.exe via a Software Installation GPO or run a Computer Startup Script that calls EasyCC-Setup.exe /S. (NSIS installers can't be deployed as MSIs; the script approach is more reliable.)
  • Managed policy: import EasyCC's EasyCC.admx + EasyCC.adml (see Reference → ADMX/ADML) into your Central Store, then enable settings under Computer Configuration → Administrative Templates → EasyCC.

Kandji, Mosyle, Workspace ONE

All three follow the Jamf pattern: managed configuration profile + (in time) a .pkg upload. Until the .pkg ships, distribute the .dmg via your platform's "available in Self-Service" flow.

Updates

EasyCC checks for updates daily, on launch, and on demand (Settings → About → Check for updates). The update flow:

  1. GET latest.json from the update endpoint (default: GitHub-hosted; override with the update_endpoint policy).
  2. Compare manifest version to installed version.
  3. Download the platform archive.
  4. Verify the minisign signature against the public key baked into the app at build time. A tampered binary fails verification and is rejected, even if the mirror is compromised.
  5. Run the installer (NSIS on Windows / replace .app on macOS).

Because Windows installs are per-user under %LOCALAPPDATA%, auto-updates require no UAC and run silently.

Channels

ChannelCadenceManifest
stable (default)Roughly monthlylatest.json
betaWeeklylatest-beta.json
alphaMultiple times a weeklatest-alpha.json

Pin a channel via the release_channel policy field.

Self-hosted update mirror

You can serve the manifest and binaries from your own server with no signing changes:

  1. Download the manifest + archives byte-for-byte from EasyCC's release feed.
  2. Rewrite the platforms.*.url values in your copy of the manifest to point at your server. Don't change any other field — signatures verify the archive contents, not the URL.
  3. Set the update_endpoint policy to your mirror.

The signing key never leaves EasyCC. You're a mirror, not a signing authority. Push only approved versions to your mirror to gate updates through change management.

Air-gapped fleets

For zero update traffic outside your perimeter, combine the mirror above with a .dmg/.app.tar.gz you've already vetted, and lock auto-update off if you only want manual pushes:

{
  "policy": {
    "auto_update_enabled":  { "kind": "enforced", "value": false },
    "update_endpoint":      { "kind": "enforced", "value": "https://updates.your-org.example/easycc" },
    "release_channel":      { "kind": "enforced", "value": "stable" }
  }
}

Deferral and force install

Policy fieldWhat it does
max_update_deferral_hoursCaps how long a user can postpone an update — past this, install on next launch. Default: no cap.
auto_install_at_quitInstall pending updates when the user quits EasyCC instead of prompting on launch.

Set both to give users some flexibility while enforcing a ceiling.

Disable auto-update

For change-controlled fleets that want to push every update manually:

{
  "policy": {
    "auto_update_enabled":  { "kind": "enforced", "value": false }
  }
}

EasyCC then never checks the update endpoint. You push new binaries the same way you pushed the first install.

Uninstall and rollback

Windows

Silent uninstall:

& "$env:LOCALAPPDATA\EasyCC\uninstall.exe" /S

This removes the binary, shortcuts, and Add/Remove Programs entry. Per-user data is not deleted%LOCALAPPDATA%\com.easycc.app\ and %USERPROFILE%\Documents\EasyCC\ survive. Wipe them in a follow-up script if your policy requires.

macOS

sudo rm -rf /Applications/EasyCC.app

Per-user data lives in ~/Library/Application Support/com.easycc.app/ and ~/Documents/EasyCC/. Same survival rule.

Rollback

EasyCC doesn't ship a version downgrade path. To roll back to an older version, uninstall and re-install from the older installer artifact. If you mirror updates (above), pin your mirror to the prior version and let auto-update bring devices back down.

Verifying the deploy

After install, on a target device:

  • Settings → About shows the version and the (default or overridden) update endpoint.
  • Settings → Advanced shows lock icons next to enforced policy fields.

Per-MDM, the admin console should show the app status as Installed and the configuration profile status as Succeeded.

If something looks off, the Support page covers the common cases (policy not applying, bundle not loading, update loop, secret resolution failures).

How is this guide?

On this page