Navigate the core functions of Orchestrator for configuration, monitoring, and reporting.
Explain zero-touch provisioning (ZTP) and template/preconfig-based deployment end to end.
Use Orchestrator dashboards and reports to monitor fabric health and application performance.
Pre-Reading Check — Orchestrator Overview
1. Why is Orchestrator described as a "single pane of glass" for the EdgeConnect fabric?
Because it replaces the appliances entirely, so there is no per-site hardware to manage
Because administrators express policy and manage all appliances centrally rather than configuring each box by CLI
Because it can only be viewed on a single physical monitor at a time
Because every appliance runs an identical configuration with no variation
2. An enterprise has strict data-residency rules and must keep its management plane inside its own data center. Which Orchestrator deployment model fits best?
On-premises self-hosted virtual appliance
Vendor-hosted SaaS via the Global Cloud Portal
A different product, since Orchestrator only runs as SaaS
Each appliance manages itself, with no central server
3. In Orchestrator RBAC, a role controls two independent dimensions. What are they?
Which firmware version runs and which hardware model is allowed
Which WAN circuit is used and which QoS class is applied
Which functions a user may perform and which objects they may touch
Which time zone a user logs in from and which language the UI uses
4. How is an appliance's effective configuration produced in Orchestrator's hierarchical model?
The appliance picks whichever of global, group, or override is most recent
Global objects plus group settings plus per-appliance overrides, validated on each device
Only the per-appliance override is ever used; global and group are documentation
The Cloud Portal merges configs from all tenants into one shared profile
5. What does the "apply groups" operation accomplish at scale?
It instantly reboots every appliance in a group
It recomputes each member's effective config and pushes staged changes, optionally to a subset first
It deletes per-appliance overrides so all members become identical
It exports the group configuration to a CSV file for offline editing
1. Orchestrator Overview
Key Points
Single pane of glass: appliances connect to Orchestrator over a secure out-of-band TLS channel; admins express policy-based intent instead of typing CLI on each box.
Three deployment models: on-premises virtual appliance, customer-hosted cloud VM, and vendor-hosted SaaS (tied to the Global Cloud Portal) — same product, different operator.
RBAC + multi-tenancy: roles are scoped by function and object; MSP mode fully isolates each tenant's appliances, configs, reports, and alarms.
Layered config: Effective config = Global + Group + Appliance override, rolled out via apply groups with staged and selective rollout.
Orchestrator (originally Unity Orchestrator, now Aruba Orchestrator under HPE/Aruba) is the centralized management and orchestration plane for EdgeConnect SD-WAN appliances. It provides policy-driven configuration, device grouping, real-time monitoring, alarms, and granular access control from one console. Each appliance establishes a secure HTTPS/TLS control connection to Orchestrator, which stores three categories of information: configuration objects (WAN labels, overlays, QoS/routing policies, templates), live appliance state (tunnels, interfaces, routes, flows, statistics), and events/alarms/historical statistics.
The payoff is policy-based intent instead of per-box command-line work. Rather than typing routing and QoS commands into 200 routers, you express an intent once — "all voice traffic should use the best-quality path" — and Orchestrator computes and pushes the device-specific configuration everywhere, validating it through consistency checks before it reaches the appliances.
Analogy: Orchestrator is the conductor of an orchestra. The musicians (appliances) each play their instrument, but the conductor reads from one score (the policy), cues each section, and keeps the performance in sync.
Deployment Options: On-Prem, Cloud, and SaaS
Deployment Model
Where it Runs
Typical Use Case
Trade-offs
On-premises (self-hosted)
Customer data center / private cloud, as a VM (ESXi, KVM, Hyper-V)
Strict data-residency or air-gap requirements
Full control; customer owns sizing, patching, HA, backups
Customer-hosted cloud
Customer's own public-cloud account (AWS, Azure)
Organizations standardizing on public cloud
Elastic infra; customer still owns the VM lifecycle
SaaS / cloud-hosted
Aruba/HPE-hosted service, incl. Global Cloud Portal
MSPs and enterprises wanting no management-plane infra
Vendor handles uptime, scaling, upgrades; less low-level control
Role-Based Access Control and Multi-Tenancy
RBAC governs who can see and change what. Authentication can be local, or delegated via RADIUS, TACACS+, or SAML/SSO. A role controls two independent things: which functions a user may perform (admin, config-only, monitor-only, read-only) and which objects they may touch (all appliances, or a subset scoped by group, region, or tenant). Common archetypes are Super Admin, Network Engineer/Designer, NOC Operator, and Read-Only/Auditor.
Multi-tenancy (MSP mode) extends RBAC into full logical isolation. A global admin creates tenants, assigns appliances, and allocates per-tenant templates. Each tenant sees only its own appliances, groups, overlays, reports, and alarms — letting an MSP run dozens of customers from one Orchestrator while guaranteeing Customer A never sees Customer B's data.
Configuration Templates and Apply Groups
Every appliance's effective configuration is the sum of three layers:
Global objects: application definitions, Business Intent Overlays (BIOs), QoS/optimization policies, underlay/path definitions, default routing/security.
Group-level configuration: interfaces/VLANs, routing defaults (OSPF/BGP), WAN labels and tunnels, system parameters (DNS, NTP, SNMP, logging).
Effective configuration = Global + Group + Appliance override, validated on each device before it takes effect. The apply groups operation pushes staged changes: edits live only in Orchestrator until you explicitly apply them, with inheritance with override (per-appliance overrides preserved), staged review, and selective apply to pilot a subset first.
Config Inheritance & Fleet Push (animated)
Global objects flow into appliance groups, group settings flow into individual appliances, and per-device overrides sit on top — the effective config Orchestrator pushes to each box.
Templates are reusable configuration blocks (interfaces/VLANs, routing, WAN circuits, firewall rules) attached to groups or appliances. Best practice: maintain a small number of strong templates (one per site type) that cover 90–95% of every device's config, reserving per-appliance overrides for genuinely unique values.
Key Takeaway
Orchestrator is the single pane of glass: appliances connect over TLS, admins express policy centrally, and RBAC + multi-tenancy control exactly who configures or views each slice. Configuration is layered and rolled out through apply-groups; templates standardize the bulk so adding a site means assigning a template plus a few variables, not hand-building a router.
Post-Reading Check — Orchestrator Overview
1. Why is Orchestrator described as a "single pane of glass" for the EdgeConnect fabric?
Because it replaces the appliances entirely, so there is no per-site hardware to manage
Because administrators express policy and manage all appliances centrally rather than configuring each box by CLI
Because it can only be viewed on a single physical monitor at a time
Because every appliance runs an identical configuration with no variation
2. An enterprise has strict data-residency rules and must keep its management plane inside its own data center. Which Orchestrator deployment model fits best?
On-premises self-hosted virtual appliance
Vendor-hosted SaaS via the Global Cloud Portal
A different product, since Orchestrator only runs as SaaS
Each appliance manages itself, with no central server
3. In Orchestrator RBAC, a role controls two independent dimensions. What are they?
Which firmware version runs and which hardware model is allowed
Which WAN circuit is used and which QoS class is applied
Which functions a user may perform and which objects they may touch
Which time zone a user logs in from and which language the UI uses
4. How is an appliance's effective configuration produced in Orchestrator's hierarchical model?
The appliance picks whichever of global, group, or override is most recent
Global objects plus group settings plus per-appliance overrides, validated on each device
Only the per-appliance override is ever used; global and group are documentation
The Cloud Portal merges configs from all tenants into one shared profile
5. What does the "apply groups" operation accomplish at scale?
It instantly reboots every appliance in a group
It recomputes each member's effective config and pushes staged changes, optionally to a subset first
It deletes per-appliance overrides so all members become identical
It exports the group configuration to a CSV file for offline editing
Pre-Reading Check — Provisioning Workflows
1. What is the core promise of zero-touch provisioning (ZTP)?
An engineer must visit each site once to enter the bootstrap CLI
A factory-default appliance can be plugged in by non-technical staff and come up fully configured automatically
Appliances ship pre-cabled and require no power
All configuration is typed locally before the box reaches the branch
2. During ZTP, what role does the Global Cloud Portal play when an appliance phones home?
It pushes the full BIO and QoS policy directly to the appliance
It matches the serial to a customer account and returns the correct Orchestrator address (and any preconfig)
It permanently manages the appliance instead of Orchestrator
It assigns the appliance a DHCP lease and DNS servers
3. What distinguishes a preconfig file from a template?
The preconfig carries overlay and QoS policy; the template carries IP addresses
The preconfig carries only site-specific identity/addressing; overlays, QoS, and routing intent come from the template
They are identical; "preconfig" is just an older name for a template
The template is per-appliance and the preconfig is fabric-wide
4. A claimed appliance boots, gets DHCP, and phones home, but is never managed (or goes to the wrong Orchestrator). Where is the fix most likely made?
In the appliance's local CLI, by an on-site technician
In the Cloud Portal — correct the claim/account and the Orchestrator registration/certificate FQDN
By replacing the hardware, since ZTP cannot be corrected
By disabling DHCP at the branch
5. A site has no initial internet reachability and strict outbound restrictions. Which staging strategy best fits?
Standard cloud ZTP, since reachability is not required
USB/console pre-staging (or hybrid staging) so the box arrives configured without phone-home
Skip Orchestrator and configure routing protocols by hand forever
Claim the appliance under a different customer to bypass the portal
2. Provisioning Workflows
Key Points
ZTP rendezvous: a factory-default appliance boots, gets DHCP/DNS, phones home to the Global Cloud Portal, is redirected to the correct Orchestrator, applies a preconfig, then receives its full template.
Cloud Portal job: answers "this serial belongs to which customer, which Orchestrator should it talk to, and does it have a preconfig?"
Preconfig vs template: preconfig = minimal site-specific identity/addressing (often YAML); template = the common overlays, QoS, and routing intent.
Staging & automation: USB/console pre-staging and hybrid staging handle offline sites; REST APIs drive "network as code" onboarding from IPAM/CMDB/CI-CD.
Zero-touch provisioning (ZTP) solves the initial-deployment problem: a factory-default EdgeConnect appliance can be shipped to a branch, plugged in by non-technical staff, and automatically come up fully configured — no CLI, no local GUI, no expert truck-roll. It works through a rendezvous between the appliance, the Global Cloud Portal, and your Orchestrator.
Zero-Touch Provisioning Sequence (animated)
A new appliance powers on, gets DHCP/DNS, phones home to the Cloud Portal, is redirected to Orchestrator, receives its template, and joins the fabric — each step lights up in turn.
Zero-Touch Provisioning End to End
Stage
Where
What Happens
1. Preparation
Cloud Portal
Orchestrator registered (FQDN/IP, port, cert); appliances claimed by serial; each linked to a preconfig and deployment template
2. Boot
At the branch
Appliance powers on in factory-default mode; gets IP and DNS via DHCP (or static)
3. Phone-home
Appliance → Portal
Using its built-in certificate, the appliance contacts the portal over outbound HTTPS
4. Rendezvous
Portal → Appliance
Portal matches serial to account, returns Orchestrator address (and preconfig); appliance applies preconfig locally
5. Configuration
Appliance → Orchestrator
Orchestrator identifies the appliance and (in automated ZTP) applies the assigned template/profile
Prerequisites that prevent most ZTP failures: internet reachability with working DNS and outbound HTTPS allowed; Orchestrator correctly registered; certificate names matching; and roughly correct clocks (large time skew breaks TLS validation).
Preconfiguration Files and YAML
A preconfig is a minimal, device-specific stub delivered during ZTP that gives the appliance just enough site-specific identity to reach Orchestrator before the full template is applied. It typically carries identity (hostname, site, region), network basics (mgmt IP/gateway, DNS, NTP, time zone), interface roles (LAN/WAN, VLANs, WAN-link labels), and bootstrap (Orchestrator FQDN, token). Notably absent: overlays, QoS classes, and routing intent — those come from the template. Preconfigs are commonly authored in YAML and generated from a golden reference, a template wizard, or a bulk CSV/spreadsheet, then uploaded to the portal and associated with a serial or deployment profile.
Bulk Deployment and Staging
For a 50-branch rollout: design templates in Orchestrator (parameterizing LAN subnets and WAN bandwidths); generate preconfigs in bulk from a spreadsheet; set up the portal (register Orchestrator, claim all serials, upload/associate preconfigs, attach the deployment profile); rack and power on at each site; then ZTP runs per appliance. Two staging strategies cover sites that cannot reach the cloud: USB/console pre-staging (full config loaded in the lab, no phone-home) and a hybrid approach (core config staged, branch-specific values filled as Orchestrator variables). Orchestrator also exposes REST APIs for automated onboarding from IPAM/CMDB or CI/CD pipelines.
Key Takeaway
ZTP separates what is unique per site (a small preconfig of identity and IPs) from what is common (templates and overlays in Orchestrator), letting non-technical staff bring up dozens of sites by plugging them in — while staging and APIs cover offline and automated scenarios.
Post-Reading Check — Provisioning Workflows
1. What is the core promise of zero-touch provisioning (ZTP)?
An engineer must visit each site once to enter the bootstrap CLI
A factory-default appliance can be plugged in by non-technical staff and come up fully configured automatically
Appliances ship pre-cabled and require no power
All configuration is typed locally before the box reaches the branch
2. During ZTP, what role does the Global Cloud Portal play when an appliance phones home?
It pushes the full BIO and QoS policy directly to the appliance
It matches the serial to a customer account and returns the correct Orchestrator address (and any preconfig)
It permanently manages the appliance instead of Orchestrator
It assigns the appliance a DHCP lease and DNS servers
3. What distinguishes a preconfig file from a template?
The preconfig carries overlay and QoS policy; the template carries IP addresses
The preconfig carries only site-specific identity/addressing; overlays, QoS, and routing intent come from the template
They are identical; "preconfig" is just an older name for a template
The template is per-appliance and the preconfig is fabric-wide
4. A claimed appliance boots, gets DHCP, and phones home, but is never managed (or goes to the wrong Orchestrator). Where is the fix most likely made?
In the appliance's local CLI, by an on-site technician
In the Cloud Portal — correct the claim/account and the Orchestrator registration/certificate FQDN
By replacing the hardware, since ZTP cannot be corrected
By disabling DHCP at the branch
5. A site has no initial internet reachability and strict outbound restrictions. Which staging strategy best fits?
Standard cloud ZTP, since reachability is not required
USB/console pre-staging (or hybrid staging) so the box arrives configured without phone-home
Skip Orchestrator and configure routing protocols by hand forever
Claim the appliance under a different customer to bypass the portal
Pre-Reading Check — Monitoring, Reporting, and Visibility
1. A tunnel is flapping and an appliance has lost connectivity to Orchestrator. Which alarm family covers these?
Performance / SLA
Availability / state
System health
Security / config
2. Why does Orchestrator forward alarms to email, SNMP traps, and syslog/SIEM?
So SD-WAN events flow into the same operations tooling and ticketing used for the rest of the environment
Because Orchestrator cannot display alarms in its own dashboard
To replace the need for any health dashboard
Because appliances cannot generate alarms on their own
3. A ticket says "ERP is slow at Dallas." Orchestrator shows 4% loss and high jitter on the MPLS underlay while the internet underlay is clean, and the overlay failed traffic over correctly. What does this evidence indicate?
The ERP servers are overloaded and need scaling
A carrier/circuit problem on MPLS — route the ticket to the WAN provider, not the app team
The overlay failed and must be rebuilt from scratch
Orchestrator lost connectivity to the Dallas appliance
4. What makes Orchestrator's application visibility different from plain interface counters?
It only reports total bytes per port, not per application
Because EdgeConnect is application-aware, it breaks traffic down by application — volume, sessions, QoS class, plus latency/loss/jitter per path
It requires logging into each appliance to see any per-app data
It shows only historical data, never live
5. What do Boost reports let a team quantify?
The number of RBAC roles defined in Orchestrator
The return on a Boost license — optimized vs unoptimized bytes, compression/dedup ratios, and per-site/per-app savings
Which appliances have not yet phoned home
The number of tenants in MSP mode
3. Monitoring, Reporting, and Visibility
Key Points
Health dashboard + topology view: at-a-glance appliance/tunnel/link/CPU/SLA status with a color-coded overlay map and drill-down into any appliance.
Four alarm families: availability/state, performance/SLA, system health, and security/config — forwardable to email, SNMP traps, and syslog/SIEM.
Application visibility: EdgeConnect is application-aware, so traffic breaks down by app (volume, sessions, QoS) plus performance (latency/loss/jitter) to isolate network vs application problems.
Bandwidth & Boost reports: per-site/link/tunnel utilization and Boost benefit (optimized vs unoptimized bytes, compression/dedup ratios); historical time-series support capacity planning and SLA reporting.
Once deployed, Orchestrator becomes the central telemetry and analytics hub, collecting state and statistics from every appliance and presenting them through dashboards, topology views, alarms, and historical reports — end-to-end visibility without logging into individual boxes.
Health Dashboards and Alarms
The top-level view is a fabric health dashboard summarizing appliance status, tunnel health, link state, CPU/memory, and SLA compliance. A topology view renders the logical overlay as a map of sites, hubs, and data centers with color-coded health per tunnel and per SLA, so a degraded path is visible instantly. Alarms surface problems proactively:
Alarm Family
Examples
Typical Trigger
Availability / state
Tunnel down/flapping, underlay link down, lost connectivity to Orchestrator
A central alarm dashboard lets operators view active and cleared alarms, filter by site/severity/type, and acknowledge or clear with notes. Alarms and events forward to email, to an NMS via SNMP traps, and to syslog/SIEM — so SD-WAN events flow into the same operations tooling and ticketing used for the rest of the environment.
Application and Flow Visibility
Because EdgeConnect is application-aware, Orchestrator breaks traffic down by application rather than just by interface: per-application volume, bandwidth, session counts, and QoS class across the fabric, plus top applications, top talkers, and distribution by app/site/user/WAN link. Alongside volume, application performance indicators — latency, loss, jitter along the chosen path — help distinguish a network problem from an application problem.
Example: A "Dallas ERP is slow" ticket — Orchestrator shows the ERP path with 4% loss and elevated jitter on the MPLS underlay while the internet underlay is clean, and confirms the overlay failed traffic over correctly. The data points to a carrier issue on the MPLS circuit, so the ticket goes to the WAN provider with evidence attached.
Boost and Bandwidth Utilization Reports
Bandwidth and circuit utilization reports show Tx/Rx rates, volume, and peak/average utilization per site, appliance, WAN link, and tunnel over selectable windows, with drill-down from the global view to an individual link. For sites that license Boost (WAN optimization), Orchestrator shows where Boost is enabled, optimized vs unoptimized bytes, compression/dedup ratios, and per-app/per-site savings in bandwidth and round-trip time — letting a team quantify the return on a Boost license rather than taking savings on faith. All of this is available as historical reporting: time-series graphs support capacity planning and before/after comparisons, can be scheduled or run on demand, and exported (PDF/CSV). In the cloud-hosted model the Cloud Portal aggregates reports across tenants.
Key Takeaway
Orchestrator turns raw appliance telemetry into actionable visibility — health dashboards and alarms for proactive operations, application and flow views to isolate problems by app rather than interface, and bandwidth/Boost reports (live and historical) for troubleshooting, capacity planning, and SLA reporting.
Post-Reading Check — Monitoring, Reporting, and Visibility
1. A tunnel is flapping and an appliance has lost connectivity to Orchestrator. Which alarm family covers these?
Performance / SLA
Availability / state
System health
Security / config
2. Why does Orchestrator forward alarms to email, SNMP traps, and syslog/SIEM?
So SD-WAN events flow into the same operations tooling and ticketing used for the rest of the environment
Because Orchestrator cannot display alarms in its own dashboard
To replace the need for any health dashboard
Because appliances cannot generate alarms on their own
3. A ticket says "ERP is slow at Dallas." Orchestrator shows 4% loss and high jitter on the MPLS underlay while the internet underlay is clean, and the overlay failed traffic over correctly. What does this evidence indicate?
The ERP servers are overloaded and need scaling
A carrier/circuit problem on MPLS — route the ticket to the WAN provider, not the app team
The overlay failed and must be rebuilt from scratch
Orchestrator lost connectivity to the Dallas appliance
4. What makes Orchestrator's application visibility different from plain interface counters?
It only reports total bytes per port, not per application
Because EdgeConnect is application-aware, it breaks traffic down by application — volume, sessions, QoS class, plus latency/loss/jitter per path
It requires logging into each appliance to see any per-app data
It shows only historical data, never live
5. What do Boost reports let a team quantify?
The number of RBAC roles defined in Orchestrator
The return on a Boost license — optimized vs unoptimized bytes, compression/dedup ratios, and per-site/per-app savings