Verify Checkmk extension activation separately on each target site

Bottom line: Distinguish stored, enabled-inactive and active MKPs at the actual Checkmk version, with central extension replication and push configuration treated as separate distribution prerequisites.

Source fact: what the authority says

The Checkmk MKP guide limits its GUI package manager to commercial editions. An added MKP is initially available but inactive, and activation installs its files before a separate activation of changes makes the functionality available. A package enabled for an incompatible Checkmk version can remain in the Enabled inactive state rather than becoming active on that site. Central extension distribution requires Replicate extensions and the Push configuration to this site replication setting.

What the source does not establish

This article checks documented package and distribution states, not third-party code quality or universal compatibility. It does not recommend overriding version restrictions or promise that a package-upload result proves its checks are functioning.

Applicability questions

• Which exact package and Checkmk version apply on each target site?
• Is the observed package stored, enabled but inactive, or active there?
• Which remote sites receive extension replication and pushed configuration?
• What harmless extension function will be checked independently of upload success?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a package-to-site matrix before distributing an extension. Record the package identity, required version information, installed Checkmk version and intended state for each site. Keep the package’s availability on the central site separate from its acceptance and operation on a remote target.

Review compatibility against the actual package metadata and installed release. Treat an inactive state as a specific condition to resolve rather than evidence that the extension’s functionality is ready. Keep forced version overrides outside the ordinary rollout; require an appropriately reviewed development or compatibility assessment instead of bypassing the check to obtain a different status.

Inspect both relevant replication settings for each intended remote site. Identify sites deliberately excluded from propagation and preserve that distinction in the rollout plan. Review the wider local-customization population with the site owner rather than assuming the proposed synchronization transfers only the package currently under discussion.

Use a test site and a harmless representative extension before production promotion. Define the exact function and observation the owner needs, with a separate recovery or removal decision for failure. Preserve the previous package inventory and configuration, and keep publisher trust and code review independent of a displayed active state.

Verification and evidence

Proposed verification: add and activate the approved test package through the applicable supported interface, recording the state after each reviewed checkpoint. Inspect the actual target version and activation-of-changes result. Compare a legitimate incompatible-package case only in a disposable scope without forcing it to install.

For approved distribution, inspect each remote site’s resulting package state and exercise the named harmless function there. Retain the package identity, replication settings, site/version map and actual outcomes. Report an inactive or missing function explicitly; neither a completed upload nor central activation alone closes the per-site acceptance.

Official references

• Checkmk — Checkmk extension packages (MKPs) — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.