Meraki Templates: When One Edit Beats API Cloning, and When It Doesn’t

Meraki configuration templates let network teams manage one base configuration that pushes changes to many bound networks, turning repetitive multi-site setup into a single editing task. They suit estates with several similar sites that need consistent SSIDs, VLANs and firewall policy. Heavier automation or service-provider scale, by contrast, often calls for cloning through the Meraki Dashboard API instead.

TL;DR:

• Choose Unique VLAN subnets when sites need Auto VPN connectivity; Same subnets overlap across bound networks and disable site to site VPN between them.
• Export an existing network’s configuration before binding, because the template overwrites prior settings and removes local tuning that was not recorded.
• Verify device support and licence compatibility before binding, since unsupported settings may be ignored and mismatched licence coverage can stall deployment.
• Test changes on a representative network before production; published template edits propagate immediately to every bound site, where some settings may be ignored.
• Use Dashboard API cloning when high volume provisioning requires per site variability beyond supported template overrides, particularly when the team can script provisioning.

Table of Contents

• Creating a configuration template in the Meraki dashboard
• How template changes propagate to bound networks
• MR wireless templates: SSIDs, RF profiles and licensing
• MX templates: VLAN subnets, firewall rules and SD-WAN behaviour
• MS switch templates and port profile management
• Binding networks and auditing which sites use a template
• Moving networks between templates and unbinding safely
• Local overrides and known template limitations
• Planning templates: one template per site role and change control
• When to clone via the Dashboard API instead of using templates
• Firmware scheduling and appliance replacement under templates
• How a Cisco partner typically supports template projects
• How we support Meraki template rollouts
• FAQ
• Sources

Creating a configuration template in the Meraki dashboard

Templates live under Organization > Configuration templates in the Meraki dashboard. From there, administrators either create a new template from scratch or copy settings from an existing network, which is useful when one site already represents the standard build.

The creation flow asks for a few decisions that shape everything that follows:

• Name and time zone: choose a naming convention that identifies the site role, not just a location, since templates often outlive the first site they were built for.
• Product types: select which Meraki product lines (MX, MR, MS, MG) the template will govern, since this determines which configuration pages appear.
• Source: start blank for a genuinely new design, or copy from a proven network to inherit settings that already work.

Before creating anything, it pays to plan the variables that cannot be shared across sites: subnet ranges, RADIUS server addresses, time zones and any per-site licence requirements. Mixing licence types or missing a licence tier for a product line is one of the most common reasons a bulk rollout stalls part-way through.

A short checklist before creating or binding helps avoid rework:

• Confirm which sites share an identical role (retail branch, warehouse, teleworker) and therefore belong on the same template.
• Check that every device model in scope is supported by the product types selected for the template.
• Verify licence counts and expiry dates across the organisation before binding additional networks.
• Decide the subnetting scheme up front, since retrofitting unique subnets after binding many sites is disruptive.

Getting this groundwork right before the first bind saves far more time than it costs, particularly across estates with many near-identical sites.

How template changes propagate to bound networks

Templates are edited centrally, and the dashboard pushes those changes to every network bound to that template. This is the entire operational point of using one: a single VLAN edit or firewall rule change reaches every site without visiting each dashboard individually.

Some settings on specific hardware may be ignored if a bound network’s devices do not support a given template setting, so it is worth previewing changes against representative sites before a wide rollout. A sensible rollout sequence looks like this:

1. Make the change on a staging template bound only to a test network, never directly on a production template with live sites attached.
2. Validate the change against representative networks for the product types and site roles present in the estate.
3. Schedule the production template change for a low-impact window, since propagation applies immediately once published.
4. Keep a record or export of the prior configuration so a rollback is straightforward if something behaves unexpectedly.

One point is easy to overlook: binding an existing, already-configured network to a template overwrites that network’s previous settings with the template’s configuration, so any site-specific tuning done before the bind is lost unless it was recorded first.

MR wireless templates: SSIDs, RF profiles and licensing

Wireless settings in a template, including SSID names, security settings and RF profiles, apply uniformly to every bound network unless the specific setting permits a local override. Broadcast SSIDs and their authentication method typically come from the template, while a smaller set of radio and power settings can sometimes be tuned per site.

Before mass deployment of newer access point models, it is worth confirming licence compatibility rather than assuming coverage, since licence SKUs and co-term behaviour vary by model generation and community guidance frequently flags this as a stumbling block for teams scaling quickly.

Where sites genuinely need different SSID counts or different security postures (a guest network at retail sites that does not exist at warehouses, for example), it is cleaner to run separate templates rather than bolting exceptions onto one shared design. Our Meraki Wi-Fi design guidance covers SSID and RF planning decisions that feed directly into this template structure.

Pro Tip: Push SSID or RF profile changes to one bound child network first and confirm client behaviour before letting the change propagate across the rest of the estate.

MX templates: VLAN subnets, firewall rules and SD-WAN behaviour

MX templates govern VLAN addressing, firewall policy and SD-WAN behaviour across every bound security appliance, and the VLAN choice made at template creation has the biggest downstream impact of any decision in the design.

When configuring VLANs, Meraki’s own documentation requires a choice between ‘Same’ and ‘Unique’ subnets for each VLAN. Choosing ‘Same’ assigns identical subnets to every bound network, which disables site-to-site VPN between those sites, since overlapping address space cannot be routed. Choosing ‘Unique’ assigns a distinct subnet per site, which is what Auto VPN connectivity between sites actually requires, but it demands a properly planned subnet pool before binding begins.

Firewall rules in MX templates should reference VLAN objects rather than hard-coded subnets wherever possible, so that each site’s unique subnet translates correctly into the rule without manual editing per network.

A few further points matter for WAN design:

• DHCP settings generally support local overrides, so a site can run its own DHCP reservations without breaking the shared template.
• Static route local overrides are not supported on MX template-bound networks, so routing exceptions typically require a separate template or a planned workaround.
• SD-WAN policies and uplink preferences are set at the template level and apply across bound sites, which keeps uplink failover behaviour consistent estate-wide.

MS switch templates and port profile management

Switch templates add a second layer on top of the network template: switch templates, also called port configuration profiles, define reusable port configurations that get assigned to physical switches as they join a bound network.

Autobind has its own constraints. A switch template generally needs enough profiles to cover each switch model in use, and Meraki’s guidance effectively treats this as one profile per model rather than one profile trying to fit several hardware types.

• Split switch templates by switch model where port counts or capabilities differ significantly, rather than forcing a single profile to cover mismatched hardware.
• Treat stacks as a unit when assigning profiles, since stack members typically need coordinated port scheduling.
• Review port schedules centrally, since they are part of the template and will apply uniformly unless deliberately separated.

Binding networks and auditing which sites use a template

Binding a network attaches it to a template so it inherits that template’s configuration going forward. The typical sequence runs as follows:

1. Open Organization > Configuration templates and select the target template.
2. Choose to bind an existing network or create new networks bound directly to the template using the dashboard’s bulk creation tool, which is the faster route for rolling out several identical sites at once.
3. Confirm the bind, understanding that most local Configure menu options disappear from the bound network’s own dashboard view once binding completes, since those settings now live at the template level.
4. Repeat for additional sites, or use bulk creation to provision many bound networks from one action rather than binding them individually.

To audit which networks currently inherit a given template, the Organization > Configuration templates view lists every bound network against its template, which is the quickest way to confirm scope before making a change.

It is worth repeating the warning from earlier: binding an existing, already-configured network replaces that network’s configuration with the template’s settings, so any pre-bind configuration should be captured first if it might be needed again.

Moving networks between templates and unbinding safely

Moving a bound network to a different template is supported, but the destination template’s configuration replaces whatever the network previously had, in the same way the initial bind does.

• When unbinding a network from a template, choose whether to retain the current (inherited) configuration as a standalone local configuration, or revert to whatever configuration existed before the original bind.
• Take a configuration export or screenshot record before any move or unbind, since the retain-versus-revert choice is made at the point of unbinding and is not easily reversed afterwards.
• Schedule template moves for a maintenance window and validate against one network before moving the rest of a group, following the same staged approach used for routine template edits.

Local overrides and known template limitations

Templates carry a handful of hard incompatibilities that are worth checking before committing to a design, since working around them after binding dozens of sites is far more disruptive than planning for them up front.

• Systems Manager incompatibility: configuration templates cannot be applied to any network containing Systems Manager devices, confirmed in Meraki’s own documentation.
• VLAN Profiles: this feature is not available on template networks or on networks bound to one.
• Static route overrides: MX template-bound networks do not support local overrides for static routes, so routing exceptions generally need a separate template.
• MG cellular gateways: some MG networks bound to templates do not support DHCP reserved ranges or fixed IP assignments, a narrower limitation worth checking against any cellular gateway deployment plan.

Where a design genuinely cannot avoid one of these constraints, splitting the affected sites into their own template, or provisioning them via the Dashboard API instead, is generally more sustainable than forcing an exception into a shared template.

Planning templates: one template per site role and change control

The strongest planning principle for templates is straightforward: build one template per distinct site role rather than one template trying to serve every type of site. A retail branch, a warehouse and a teleworker hub each have different VLAN, security and SSID needs, and best-practice guidance is explicit that a ‘one-size-fits-all’ template makes troubleshooting and bulk updates harder, not easier.

• Plan the subnet pool for the whole estate before binding any site, choosing ‘Same’ or ‘Unique’ VLANs per site role based on whether Auto VPN between those sites is required.
• Adopt a naming convention that encodes site role and template version, so an administrator can tell at a glance which template a network should be on.
• Maintain a staging template as part of change control, testing every production change there first.
• Split templates by hardware generation, security policy or compliance requirement whenever one of those factors genuinely differs between groups of sites.

Pro Tip: Version your template names (for example “Retail-v3”) so a rollback target is always obvious when a change needs reverting.

When to clone via the Dashboard API instead of using templates

The Meraki Dashboard API is a RESTful interface for provisioning, bulk configuration and monitoring, supporting operations such as creating organisations, networks and VLANs programmatically once an API key is in place. For service providers and heavily automated environments, cloning networks via the API is often preferred to templates because cloning gives more granular, scriptable control over each site’s configuration than a shared template model allows.

A simple decision checklist helps choose between the two approaches:

1. If most sites share the same role and only a handful of variables differ, a template with planned local overrides is usually the simpler path.
2. If provisioning needs to happen at volume, with per-site variability that exceeds what template overrides support, cloning via the API with scripted parameterisation is generally the better fit.
3. If the team has existing scripting capability (Python, for instance, against the Meraki API), a clone-parameterise-provision workflow, where a reference network is cloned, site-specific variables are injected via script, and the result is provisioned automatically, scales further than manual template binding.

Firmware scheduling and appliance replacement under templates

Firmware upgrade scheduling set at the template level applies to every bound child network, using each site’s own local time zone, which keeps maintenance windows sensible across geographically spread estates without per-site scheduling.

When a device bound to a template fails and needs replacing, the configuration lives at the template level, so reassigning a new appliance to the same bound network restores its configuration rather than requiring it to be rebuilt from scratch.

• Stage firmware upgrades across a small subset of bound networks before scheduling the full estate, limiting the blast radius of any unexpected regression.
• Keep a rollback plan for firmware changes, since a staged approach makes reverting one site far simpler than reverting dozens simultaneously.
• Record serial numbers and licence assignments for bound devices, so hardware replacement is a quick reassignment rather than a rebuild.

How a Cisco partner typically supports template projects

A practised partner typically adds the most value in the planning stages that are easy to rush: inventory validation across sites, licence review before binding begins, and building a staging template before anything touches production. For larger estates, a partner can also script the clone-and-provision workflow so sites inherit a tested configuration rather than a hand-built one. With Cisco-focused experience across education, manufacturing and logistics environments, Re-Solution brings that planning discipline to multi-site Meraki rollouts.

How we support Meraki template rollouts

We help IT teams get templates right from the first site rather than fixing issues after many sites are already bound. Our Professional Services cover design and planning, our Managed Services keep a template estate running once it is live, and our Network As A Service option suits organisations that want an ongoing subscription model for multi-site provisioning. Our Network Audits and Wireless Surveys give you the inventory and RF data a sound template design depends on.

If you are planning a large rollout, migrating licences, or building automation around template cloning, get in touch through our Professional Services page to discuss your estate.

FAQ

What is replacing Cisco Meraki?

Nothing is replacing Cisco Meraki; it remains an active, actively developed product line within Cisco’s networking portfolio. Organisations choosing between cloud-managed and on-premises controller architectures typically compare Meraki against Cisco’s DNA Center-managed catalyst estate rather than looking for a replacement product.

Is Meraki still owned by Cisco?

Yes, Meraki has been part of Cisco since Cisco’s acquisition of the company, and it continues to operate as a Cisco cloud-managed networking line. Meraki’s dashboard, licensing and hardware are sold and supported under Cisco.

Is there a PDF version of the Cisco Meraki configuration guide available?

Cisco Meraki’s configuration guidance is maintained as living documentation on the Meraki documentation site rather than as a single downloadable PDF, since the content changes as dashboard features are updated. Individual documentation pages can generally be exported or printed to PDF directly from a browser if an offline copy is needed.

Can I use a Meraki access point without a licence?

Meraki access points require an active licence to operate within the dashboard, since Meraki’s cloud-managed model ties device functionality to licence status rather than running fully standalone. Licence requirements and SKU compatibility vary by access point generation, so it is worth confirming the correct licence type before deployment.

Sources

• Managing Multiple Networks with Configuration Templates – Cisco Meraki Documentation
• How to Use the Cisco Meraki Dashboard API – Cisco Meraki Documentation
• Controlmonkey

Recommended

• Meraki Wi‑Fi Design: 5 Field Tested Decisions for UK Enterprise Engineers
• Meraki licensing explained: which model to choose
• Meraki licensing explained: which model to choose
• SASE & Meraki