Consistency is the real challenge
A single-site Aruba Central deployment is a couple of afternoons. The difficulty appears at scale, when the goal is not "make this site work" but "make eighty sites behave identically, provision new ones without a visit, and change policy everywhere at once without breaking anything". That is a configuration-model problem, and getting the model right at the start is what separates an estate you manage from one that manages you.
This is a practitioner's guide to how the AOS-10 configuration model in HPE Aruba Networking Central is meant to be used for multi-site deployments.
The AOS-10 configuration model
In AOS-10, configuration is organised around groups. A group is a container of devices that share a configuration. Devices in a group inherit that group's settings, which is what makes consistency achievable: you configure the group, not each device. Sites, labels, and the device inventory then let you organise and filter the estate, but the group is the unit of configuration.
The design decision that follows is how to structure groups. Too few and you cannot express legitimate differences between sites. too many and you lose the consistency the model exists to provide. The art is grouping by shared configuration intent, for example "standard retail site", "flagship site", "warehouse", rather than one group per physical location.
Group by intent, not by geography
The instinct is one group per site. Resist it. Group sites that should be configured identically, and let variables handle the small per-site differences. A handful of well-chosen groups covering an estate of dozens of sites is the shape you are aiming for.
Groups vs templates
Central supports two ways of managing configuration within groups, and choosing between them is one of the more consequential early decisions.
UI (configuration model) groups
Configuration is managed through the Central interface, using the structured configuration model. This is approachable, validated, and well suited to standardised deployments where the UI expresses everything you need. For most wireless-led multi-site estates, this is the sensible default.
Template groups
Configuration is managed as CLI templates with variables substituted per device. This suits estates that need fine-grained control, non-standard configuration, or that are migrating existing CLI-based configuration and want to preserve it. Templates are more powerful and less forgiving: they assume you are comfortable with the underlying CLI and with managing variable sets.
The trade-off is control versus simplicity. Template groups give you everything the CLI can express, at the cost of the guardrails the UI model provides. Many estates use UI groups for the bulk of the deployment and reserve templates for the specific cases that demand them.
"The template-versus-UI decision is not about which is better. It is about how much bespoke configuration your estate actually needs. Choosing templates for control you never use just adds fragility. choosing the UI when you need real CLI depth just moves the problem."
Edge7 Networks, Networking PracticeVariables and per-site difference
No two sites are perfectly identical. there is always a hostname, a VLAN, an uplink, or a local parameter that differs. The model handles this through variables: the group defines the shared configuration, and per-device or per-site variables fill in the differences. Done well, this keeps the shared configuration truly shared while expressing legitimate local variation cleanly. Done poorly, variables proliferate until the "shared" configuration is riddled with exceptions and the consistency benefit erodes. Keeping the variable set small and disciplined is part of keeping the estate manageable.
Zero-touch provisioning
Zero-touch provisioning is what makes adding sites scale. A device can be shipped to a location, cabled and powered on by someone with no networking knowledge, and adopt its configuration from Central automatically based on its group assignment. No on-site CLI, no engineer visit for standard bring-up.
For a growing estate this changes the economics of expansion: onboarding a new site becomes a repeatable, low-touch process rather than a project each time. The prerequisite is that the group and variable model is sound, because zero-touch provisioning simply applies whatever the group defines. it makes a good configuration model effortless to roll out, and a poor one effortless to replicate.
Patterns that scale
A few patterns consistently pay off across large Central estates:
- A small set of intent-based groups covering your standard site types, rather than per-site groups.
- A disciplined, minimal variable set for genuine per-site differences only.
- Consistent naming and labelling from day one, so devices, sites, and groups are filterable and the telemetry stays legible.
- A defined change process: test a change in one group or pilot site before applying it estate-wide, because the same model that pushes good config everywhere pushes mistakes everywhere too.
- Zero-touch as the default onboarding path, with the group model doing the work.
This connects directly to managed WiFi at scale: the configuration model is what turns an estate of many sites into a single managed system rather than many separate ones.
Where to start
If you are standing up a multi-site Central estate, or an existing one has grown into a tangle of per-site configuration, the starting point is the group and variable design. Getting that structure right (before the estate scales) is far cheaper than untangling it afterwards. An architecture review of how your sites should map to groups, what belongs in variables, and where templates are justified, is the highest-value early step.
Edge7 Networks designs and runs multi-site HPE Aruba Networking estates for organisations across Ireland and the UK. If your Central deployment is growing faster than its configuration model, an architecture review is the right place to begin.