Managing Multiple PBX Sites: A Unified Management Approach

A unified management system for multiple PBX sites earns its place by collapsing the repetitive part of site administration into one console: device inventory, firmware versions, configuration state, backup status, and remote reach into the branch. It will not replace the site-specific knowledge of what each location does, and it will not repair a SIP design that was already poor. Judge it on those two lines.

Definition: A unified management system for multi-site IP telephony is a single platform that maintains the device inventory across every site, applies operational tasks such as firmware upgrade and configuration deployment, and returns status and alarms to one place — replacing a separate login per device and a separate person at each location.

What Breaks When You Run Five PBX Sites

Most multi-site estates did not fail on capacity. They failed on administration. A single site can be managed by one person who remembers what was changed last month and who knows why the branch manager asked for a different ring order. Extend that to a second and third location and the same informal process starts to lose information at every step.

The failure modes are consistent, and they appear in a predictable order.

• Configuration drift. Each site's configuration reflects its last local change, not the last intended state. Two branches with the same nominal extension plan diverge on route tables, ring groups, and voicemail prompts, and nobody can say which version is correct.
• Firmware spread. Boxes sit on different versions for months because upgrading one at a time feels risky and nobody owns the schedule. That spread is what turns a single vendor defect into a multi-site incident.
• No shared status view. You learn a site is down when a user calls, not when the device stops answering a poll. A console sitting in the rack room is not an alerting system.
• Backup habits that vary by site. The office with a full-time IT person has current configuration backups. The branch with a locked cupboard does not. Recovery there means rebuilding from a support ticket rather than from a file.
• Site knowledge held in one person's head. The information that a branch trunk needs a specific dial prefix, or that a failover route was deliberately removed, is not written anywhere a second technician can use.

Where multi-site operations actually break

The pattern behind those symptoms matters, because it decides what you buy. The problem is not that each device is hard to operate — a single IP-PBX has a manageable configuration surface. The problem is that the same task has to be repeated across devices that are not physically near each other, and every repetition is an opportunity for divergence.

This is also why "head office already has a phone system" is not an answer. Head office holds one device, one dial plan context, and one location's status. Running several sites is a coordination problem, and coordination needs tooling aimed at coordination.

Centralised Management: What It Should Cover

Unified management is often sold as a visibility layer. Visibility is useful, and it is the cheaper half. The expensive half is whether the platform can perform work across the estate — pushing a configuration, rolling firmware, verifying the result per device, and reporting which devices did not comply.

Four areas a unified management system should cover

1. Inventory. One register of every device in every site, with model, role, firmware version, and site. This is the base layer. A platform that cannot enumerate your estate reliably cannot operate it.
2. Configuration and firmware control. The ability to stage a change, apply it to a defined group of devices, and see the result per device. Targeting groups matters, because "upgrade everything" and "upgrade the two branches still on the old build" are different operations.
3. Status and alarms. A single view of which devices are reachable, which are registering successfully, and which have stopped reporting. Routing matters more than count: five relevant alarms delivered to a named owner beat fifty alerts nobody triages.
4. Backup and restore visibility. Not necessarily the backup mechanism itself, but dependable evidence that a current configuration backup exists for each site and that it has been checked. An unverified backup is an assumption.

These four areas are the test. If a platform claims unified management but only aggregates status, you have bought a dashboard and still carry the operational load site by site.

Where UMS Fits, and Where It Stops

New Rock's UMS unified management system is built for that estate-level job. New Rock describes it as providing unified management and remote operation for OM series IP-PBX systems and MX series VoIP gateways. In practical terms, it gives one console holding the devices across all sites and applies operational tasks to them.

UMS scope: what it covers and what it leaves alone

It is worth being precise about the boundary, because a management platform presented as universal is usually misunderstood by the people who end up owning it.

• Covered: the OM and MX estate. UMS manages OM series IP-PBX systems and MX series VoIP gateways. Devices outside that family sit outside its device management scope.
• Covered: site-level administration over distance. The purpose of the platform is that a change to a branch device is executed from a central position rather than by a local hands-on visit.
• Not covered: the SIP design. UMS operates the equipment you already have. Trunk numbering, route choice, and inter-site call flow are decisions encoded in the device configuration. The platform will propagate your decision faithfully, including a wrong one.
• Not covered: recording and call detail work. Centralised recording and call detail handling are separate products in the range — RMS manages recordings and CDR Software collects call detail records — rather than functions of the management console.
• Not covered: usage questions. Who calls whom, and why a group rings to a particular destination, is a question about call data, not about device management.

The honest framing: UMS replaces the mechanics of administering devices across sites. It does not replace the design work, and it does not remove the need for someone who understands the call flow.

Remote Access to Sites Behind NAT

Remote management is where multi-site estates usually stall. Branch hardware sits behind a consumer router or a cellular connection with no inbound path, so the choices are a VPN per site, a port forward per site, or a relay in the middle. Each one consumes router attention and network documentation that nobody enjoys maintaining.

New Rock addresses this at two product levels. The OM20G supports New Rock Cloud remote access alongside TR-069 and SNMP management, so a branch IP-PBX can be reached without opening an inbound path into the site. TR-069 gives a standard remote configuration channel across devices on your own management network, and SNMP suits monitoring rather than control.

At the edge, where the branch also terminates media and signalling conversion, the OM1000-TE media gateway carries a built-in cloud service client for NAT and firewall traversal, so the device initiates the outbound path rather than waiting to be reached. The same gateway is built with the redundancy a branch link needs: dual network ports and dual power supplies, 6000 MIPS of DSP processing capacity, 512 SIP trunk account registrations, and 500 routing and number transformation rules, with a maximum of 120 concurrent calls across its SIP/IMS and ISDN PRI sides.

Two design points matter more than any single headline feature.

• Outbound-initiated paths age better than inbound tunnels. A branch whose router address changes still reaches the management console, because the session is established from the device side.
• Local survivability protects the call, not the console. When a WAN link fails, the question is whether local calling continues. The MA50-LS local survival branch exchange answers that for the endpoints it serves: with FXO ports from 2 to 8 and SIP user registration from 50 to 200, it keeps calls alive locally when the head office or cloud server is unreachable, and switches back once the connection returns.

Firmware, Configuration and Backup Discipline

Centralised management earns its keep in these three areas, because all three fail quietly and all three compound across sites.

Configuration drift and backup discipline in practice

Firmware. Write down which build each model is expected to run, then check the estate against that document rather than against memory. Version spread stays invisible until the day a vendor corrects a defect and only one site carries the fix. Where devices are managed remotely, schedule the upgrade in a window that suits each site — a branch that closes at the end of the trading day and a site that runs overnight are different windows.

Configuration. Keep a reference configuration per site type, and treat the difference between a live site and the reference as a finding rather than as an exception to tolerate. A small number of intentional variations per site is manageable. Unbounded variation is what makes a fleet unmaintainable, because every future change has to be reasoned about against a different baseline on each site. When a configuration is changed centrally, capture the result on the way through, so the new state is also the documented state.

Backups. A configuration backup that is written but never verified is not a backup. Verify by restoring, or at minimum by a documented check that the stored file matches the running configuration. Schedule backups per site on a fixed cadence and keep the copies centrally, so a branch's recovery material does not sit on the branch's disk where a disk failure or a theft removes the system and its recovery data together.

Devices with local survivability reduce the urgency of a backup but do not replace it. Survivability keeps a call going during an outage; the backup determines how quickly the site returns to its intended state once the fault is resolved.

A Multi-Site Operations Checklist

This is the routine to run against an estate monthly. The first three items usually expose problems fastest.

1. Confirm the inventory against reality. Every device reported by the management platform should exist, sit at the site it claims, and do the job it claims. Unknown and orphaned devices are usually the first finding in an audit.
2. Compare firmware against the agreed build. Record every device that differs, then decide per site whether it moves now or waits for the next window.
3. Verify a configuration backup for each site, and test one restore. Pick one site and restore its configuration to a spare or an offline environment. The restore validates the backup; the backup's existence does not.
4. Test remote reach into every site. A management path unused since the last router replacement is untested. Exercise it deliberately and record the outcome per site.
5. Review alarm routing, not alarm volume. Confirm that each alarm type reaches a named person who will act, and that no site is silently excluded because its alarm channel was never configured.
6. Write down site-specific exceptions. The custom dial prefix, the deliberately removed failover route, the extension numbering that differs from head office policy. Keep them in the same document as the configuration reference, not in someone's mailbox.
7. Confirm local survivability where it matters. For branches where a WAN outage would otherwise block local calling, verify that the local-survival path is active and that the switch-back happens when the link recovers.
8. Match the model to the site's actual load. Sizing has to follow each site's own profile rather than the estate average. The table below gives the published limits for the OM range; a site with heavy internal call flow is constrained by concurrent calls, not by registered extensions.

Two sites with the same extension count can need different models, because concurrent calls reflect how a site is used rather than how many people are registered. A branch running a queue-driven intake function behaves nothing like a branch that mostly receives inbound transfers. Size on behaviour, and keep the reference visible in the management console so the assumption is visible to whoever inherits it.

Unified Management for Multiple PBX Sites FAQ

Does a unified management system replace logging into each device individually?

It replaces the routine logins — inventory checks, firmware upgrades, configuration changes, and status gathering. It does not remove the need for direct access during unusual events, such as tracing a specific call path or diagnosing a device the platform reports as unreachable. Treat the platform as the normal operating path and direct access as the exception path.

Can UMS reach a branch IP-PBX that has no inbound connectivity?

Yes, for the device families UMS manages. The OM20G supports New Rock Cloud remote access, TR-069, and SNMP management, which lets a branch unit be administered without opening an inbound path through the site's router. The OM1000-TE includes a built-in cloud service client for NAT and firewall traversal, so the outbound session is established from the device. Both approaches avoid the per-site port forward.

Does UMS manage phones, gateways, and recording systems as well as IP-PBX systems?

Its stated scope covers OM series IP-PBX systems and MX series VoIP gateways. Recording management and call detail collection are separate products — RMS and CDR Software — and endpoint phones are administered on their own. When you write the requirement, list device families explicitly, because a management platform's usefulness is bounded by what it enumerates.

How many sites can one UMS deployment handle?

New Rock specifies UMS for unified management and remote operation across OM IP-PBX and MX gateway devices, without publishing a per-deployment site count as a headline specification. Treat the trial as the deciding step rather than assuming a limit: bring the actual device list, the intended grouping of sites, and the alarm routing you need, then check the console handles that shape of estate.

If a branch loses its WAN link, do local calls still connect?

That depends on what you installed at the branch, not on the management platform. The MA50-LS local survival branch exchange keeps calls alive locally when the head office or cloud server is disconnected, with FXO ports from 2 to 8 and SIP user registration from 50 to 200, and returns to the server path once the connection recovers. A branch with no local-survival device depends entirely on its own internet link.

Should firmware be upgraded across all sites at once?

Usually not. Use the management platform to stage the change and apply it to a defined group, starting with sites whose configuration is closest to the reference and whose window you can protect. Leaving a subset on an older build is a deliberate, documented decision; leaving it that way by accident is what turns a vendor defect into a multi-site incident.

Conclusion

A unified management system is worth deploying when your site count has outgrown per-site administration, and it is worth evaluating against a boundary as much as against a feature list. UMS covers the OM and MX estate, applies operational work across sites, and pairs with New Rock Cloud access, TR-069, and SNMP on the device side, plus local-survival options for branches that cannot lose local calling.

Start with the first three items of the checklist: reconcile the inventory, compare firmware against one agreed build, and verify one backup by restoring it. Those three results tell you more about the value of centralising than any console screenshot, and they produce a list of real gaps you can size against a specific management platform.