For the complete documentation index, see llms.txt. This page is also available as Markdown.

Native Choco Runtime

The Native Choco Runtime is RealmJoin's own in-process package installation engine that replaces the outdated Chocolatey 0.10.3 binary while staying fully compatible with existing packages.

The Native Choco Runtime was introduced with RealmJoin Agent 4.21.6 (Beta). The feature is opt-in: existing clients keep using the classic Chocolatey engine until you explicitly enable the native runtime.

What it is

When the RealmJoin Agent installs software packages outside of Intune (see package installation), it has traditionally relied on Chocolatey as the underlying package engine. RealmJoin shipped a pinned, heavily patched build of the open-source Chocolatey CLI — version 0.10.3 — bundled as choco.exe under C:\ProgramData\chocolatey\.

The Native Choco Runtime replaces that bundled Chocolatey binary with RealmJoin's own, purpose-built implementation that runs in-process inside the RealmJoin service. It shims Chocolatey: it understands the same package format (.nupkg) and behaves the same way from a package author's and administrator's point of view, but it no longer depends on the ageing Chocolatey 0.10.3 codebase.

In other words, packages you already use keep working unchanged — only the engine underneath them changes.

How it works

  • In-process engine. Package installs run inside the RealmJoin service instead of shelling out to an external choco.exe. The chocolateyInstall.ps1 of each package is executed in an in-process PowerShell runspace.

  • Isolated storage. The native runtime installs to its own root, C:\ProgramData\RealmJoin\choco\ (with lib\, extensions\, and logs\ subfolders). It never writes to classic Chocolatey's state under C:\ProgramData\chocolatey\ and never changes the machine-wide ChocolateyInstall environment variable. This means the native runtime and a pre-existing classic Chocolatey can coexist on the same device.

  • Automatic dependency resolution. Package dependencies declared in the .nuspec (such as the RealmJoin Core Choco Extension) are resolved and installed automatically from your configured sources.

  • choco.exe shim. Some package scripts call choco.exe directly. To keep those working, the runtime deploys a small shim to %ProgramFiles%\RealmJoin\choco-shim\choco.exe that routes such calls back into the in-process engine instead of to classic Chocolatey. The shim is not added to the system PATH; it is only made available to package scripts while they run.

Compatibility

The Native Choco Runtime is designed as a drop-in replacement:

  • Existing RealmJoin packages (including everything from the Package Store) install and uninstall the same way.

  • Package arguments / params configured in the RealmJoin Portal continue to work.

  • The RealmJoin Core Choco Extension helper cmdlets used inside package scripts remain available.

  • RealmJoin ESP / Autopilot are supported: on a fresh device with the native runtime enabled, winchoco packages are installed natively during enrollment, with their dependencies resolved automatically.

How to use it

The runtime is selected through a RealmJoin setting, so you can control it centrally instead of touching individual clients. RealmJoin settings cascade, which means you can set a tenant-wide default and, where needed, override it for specific groups (and the objects within them).

Setting Key: Chocolatey.UseNativeRuntime

Setting Value: true / false

The following settings control the behaviour:

Setting
Default
Meaning

Chocolatey.Enabled

false

RealmJoin manages Chocolatey-typed packages on the device.

Chocolatey.UseNativeRuntime

false

Master switch. When false, installs still go through the classic choco.exe. When true, all winchoco installs go through the in-process native runtime.

Chocolatey.DisableShim

false

Only relevant when UseNativeRuntime = true. When true, any package script that calls an external choco.exe fails loudly instead of being routed through the shim — useful to surface scripts that still reach for an external binary.

1

Enable it for a pilot group first

Open the settings of a RealmJoin group that contains a small set of pilot devices and set Chocolatey.UseNativeRuntime to true there. Because group settings take precedence over the tenant-wide default, only those devices switch to the new engine.

2

Validate your packages

Let the pilot devices run their normal package assignments and upgrades. Confirm that installations succeed and check the logs if anything looks off (see Package Installation Issues).

3

Roll it out tenant-wide

Once you are confident, set Chocolatey.UseNativeRuntime to true as the tenant-wide default so that all clients use it. Individual groups can still opt out if you need to keep them on the classic engine temporarily.

Configuration follows the same tenant-setting / group-override model as the other agent settings described under General settings (for example the Client Configuration and LAPS Configuration tenant settings).

What is the default

Native Choco Runtime is disabled by default (Chocolatey.UseNativeRuntime = false). Clients continue to use the classic, bundled Chocolatey 0.10.3 engine until an administrator enables the native runtime — either tenant-wide or for a specific group. This lets you adopt the new runtime at your own pace and roll it back just as easily while the feature is in beta.

Migrating existing devices

The native runtime and classic Chocolatey coexist on a device for as long as needed. When you enable the native runtime on a device that already has classic Chocolatey-installed packages:

  • Existing RealmJoin-managed packages keep working and are not reinstalled just because the runtime changed — their installed state carries over across the switch, so there is no reinstall storm.

  • New installs and upgrades go through the native runtime; the classic installation stays on disk, untouched, until it is explicitly removed.

Fleet-wide removal of classic Chocolatey is planned as a separate, orchestrated step. Until then, the native runtime is happy to coexist with a leftover classic installation, so there is no hard deadline to clean it up.

For an individual device (for example during support or QA), an administrator can move a machine off classic Chocolatey with the shim's migrate verb from an elevated shell:

Logs & troubleshooting

Native runtime installs write a per-package log to:

(kept to the 10 most recent entries per package). This is separate from classic Chocolatey's C:\ProgramData\chocolatey\logs\. When collecting logs for a support request, include the C:\ProgramData\RealmJoin\ folder as described in Package Installation Issues.

File & path reference

Path
Purpose

C:\ProgramData\RealmJoin\choco\lib\<id>

Native runtime package install root.

C:\ProgramData\RealmJoin\choco\extensions\<id>

Auto-imported PowerShell helper modules.

C:\ProgramData\RealmJoin\choco\logs\<id>

Per-install logs (last 10 per package).

C:\Program Files\RealmJoin\choco-shim\choco.exe

The choco.exe shim.

Last updated

Was this helpful?