How to Standardize 3CX Config Across Every Customer PBX

The consistency problem at MSP scale

One 3CX server is easy. You open the admin console, find the setting under Advanced → Parameters, change it, and move on. Twenty customer servers is a different job entirely. The same parameter — a feature flag, a timeout, a regional default, a behavior toggle your team relies on — lives on every one of them, and over months of independent edits, onboarding by different technicians, and one-off "just for this customer" tweaks, the values quietly diverge.

This is configuration drift, and it's insidious precisely because nothing is broken. Every PBX works. Every customer is happy. Then one day a setting that was correct on 19 servers turns out to be wrong on the 20th — the one that just took a traffic spike, or upgraded, or hit an edge case — and you're troubleshooting a ghost at 2am because you assumed the fleet was uniform when it wasn't.

The usual "fix" is a runbook: a wiki page that says set parameter X to value Y on every customer. Runbooks document the intent, but they don't enforce it. Enforcing it means logging into every console, navigating to the same screen, and making the same edit by hand — which is exactly the kind of repetitive, error-prone work that drift was born from in the first place. Miss one server, fat-finger one value, and you've created the next ghost.

What MSPs actually want is simpler than orchestration: a way to declare this setting should have this value on every customer PBX, and have that be true across the fleet without touching each console. That's what Standardization (Sikurd's fleet-parameters feature) is for.

How the push works

Standardization is built around a single, deliberate idea: push one 3CX custom parameter across many instances at once. From the Parameters screen you browse the parameters on a reference instance, then open the push panel and provide three things:

• Name

  The 3CX custom parameter name (letters, digits, and underscores) — the exact key as it appears under Advanced → Parameters.
• Value

  The value you want that parameter to hold everywhere you push it. This is the baseline you're enforcing.
• Description (optional)

  A short note for context, set when you're creating the parameter for the first time.

Then you choose where it lands. Tick individual customers, or select your entire fleet in one click, and push. Sikurd connects to each selected PBX and upsertsthe parameter: if the parameter already exists on that server, it updates the value; if it doesn't exist yet, it creates it. Either way, when the push finishes, that parameter holds the value you specified on every instance you selected — no console-hopping, no per-server navigation.

It's a synchronous, on-demand fan-out. You click push, Sikurd writes to the instances in parallel, and you wait the few seconds it takes — these are fast configuration calls, with no backup or service restart involved (unlike a firmware update). The moment it completes you get a per-instance report: X of Y succeeded, with a green check next to each PBX that took the change and a clear error next to any that didn't. If one customer's server was unreachable, you see exactly which one and why — instead of assuming the whole fleet is consistent when one server silently missed the update.

Because the operation changes live behavior on production phone systems, it's owner-scoped and shows a confirmation when you're writing to more than one PBX, spelling out the parameter and how many servers it's about to touch. The point isn't to make bulk changes casual — it's to make a deliberate, fleet-wide baseline change take one screen instead of twenty.

The audit trail: every change, recorded

A bulk write to production phone systems is only as trustworthy as its paper trail. Every parameter push in Sikurd is audited per instance. For each PBX, the log records what the parameter was set to, whether it was created or updated, and — critically — the previous valuealongside the new one, so "what did this used to be?" is always answerable. It also captures who ran the push, so there's a clear actor on every change.

That matters for three reasons MSPs feel every week. First, troubleshooting: when a customer's behavior changes, the first question is "what changed?" — and the before/after value is right there. Second, accountability: bulk changes to many customers at once are exactly the kind of action you want a defensible record of. Third, reversibility: because the old value is captured, undoing a push is a matter of pushing the previous value back, not reconstructing what it must have been from memory.

What Standardization is — and isn't

It's worth being precise, because the name invites assumptions. Standardization is a one-parameter, on-demand push. It is not a scheduler: there are no cron rules, no "apply nightly," no background orchestration that keeps servers in sync over time. It is not a multi-setting profile engine: you push one parameter per operation, not a bundle of twenty settings as a named template.

That narrow scope is the feature, not a limitation. The job it does — and does completely — is taking a single setting and making its value consistent across every customer PBX you choose, in one action, with a full record of what changed. When you need a baseline value to be true everywhere, you push it, you confirm from the report that it landed everywhere, and you're done. For ongoing fleet hygiene, you simply re-push the baseline whenever you onboard a new customer or want to re-assert it.

Configuration drift is one of those problems that stays invisible right up until it isn't. The fix isn't a heavier process or a thicker runbook — it's the ability to assert a consistent baseline value across every customer PBX in one action, and to prove afterward exactly what changed. That's what Standardization gives you. If you're managing more than a handful of 3CX servers, see also our guide to the best tools for managing multiple 3CX servers.