What a venue copy carries
Not every part of a venue’s configuration copies, and what copies depends on whether you are cloning within a tenant, copying across tenants, or building a template. This page is the reference; the Venue config copy page is the workflow.
Call venue_copy_support for the authoritative answer. It takes no
arguments, is read-only, and is derived from the planner’s own write registry —
so it tracks what a copy actually does. The table below is that matrix in prose
form.
The matrix
Section titled “The matrix”| Domain | Same-tenant | Cross-tenant | Template | Notes |
|---|---|---|---|---|
| Venue metadata + address | Created | Created | Created | Async (202); the new id threads into every later write. Created only when you plan into target.newVenue (or build a template); an existing target.venueId is diffed, never recreated |
| Venue settings singletons (radio, mesh, LED, …) | Updated | Updated | Updated | 17 domains: switch, AAA, radio, AP mesh, AP management-traffic VLAN, load balancing, directed multicast, DoS protection, mDNS fencing, BSS coloring, client admission control, AP LAN-port, LED, rogue AP, RADIUS options, syslog, SNMP agent. Syslog, SNMP-agent, and AP LAN-port settings have no template equivalent; mesh has a narrower template enum |
| AAA / RADIUS servers | Created | Created | Created | Shared secret and bind password are write-only — readable copies verbatim, masked becomes an operator-input binding. A server with purpose: "DEFAULT" is not created |
| AP groups + per-group radio | Created | Created | Created | AP serial membership is stripped — it’s physical. The default AP group is auto-provisioned, not copied |
| WLAN activations | Re-activate the existing id | Create → resolve → bind dependencies → activate | WLAN template create → resolve → activate | The dependency binds that carry across are listed below |
| Portal service profiles (guest captive portal) | Reuse existing id | Create → resolve → bind to the WLAN | No portal object — the guest portal travels inline on the WLAN template | Base64 images ride inline in the create body. In a template, the guest-portal config travels as wlan.guestPortal and only the profile’s branding images are lost |
| DPSK service pools | Reuse existing id | Create → resolve → bind to the WLAN | Created and bound | In template mode the pool is created without an identity group, and has no passphrases |
| DPSK passphrases | Ride the pool | Created under the recreated pool | Not supported | Readable copies verbatim; masked becomes an operator-input binding |
| Identity groups | Reuse existing id | Create → resolve | Not supported | Container only — member identities are not copied |
| RADIUS server profiles (Cloudpath / 802.1X) | Reuse existing id | Create → resolve → bind to the ethernet-port profile and/or WLAN | Created and bound to the template WLAN | Shared secret is write-only. Ethernet-port profiles aren’t carried into a template at all, so there is no template ethernet-port RADIUS binding |
| AP LAN-port (ethernet-port) profiles | Re-activate existing | Create → resolve → activate per AP model and port | Not supported | Per-AP-serial overrides are not copied |
| Switch profiles (+ VLANs / ACLs) | Re-associate the existing id | Create → resolve → associate | Profile template create → resolve → associate | Children — VLANs, ACLs, trusted ports, voice VLANs, CLI template — embed inline in the create body |
| VLAN pool profiles | Reuse existing id | Create → bind to the WLAN | Created and bound | A per-AP-group bind widens to the whole WLAN. A WLAN whose pool didn’t copy still activates, without VLAN pooling |
| Wi-Fi calling service profiles (ePDG) | Reuse existing id | Create → resolve by name → bind to the WLAN | Created and bound | Cross-tenant, its create returns no id, so it resolves by exact name (switch profiles do the same) |
| Access control profiles | Reuse existing id | Children created first → profile created → bound to the WLAN | Created and bound | Carries its four child policies by id in its own create body |
| L2 / L3 ACL policies | Reuse existing id | Created before the profile that references them | Created | Reached only through an access-control profile. A policy captured with no rules is skipped (see warnings) |
| Device policies | Reuse existing id | Created before the profile that references them | Created | OS / device-type rules |
| Application policies | Reuse existing id | Created before the profile that references them | Created | DPI signature rules copy verbatim; USER_DEFINED rules are rejected by R1 |
| Switch inventory | Not copied | Not copied | Not copied | Physical devices; re-onboard them at the target |
The headline rules
Section titled “The headline rules”Physical devices are never copied. Switch inventory is not part of a copy in any mode, and AP serial membership is stripped from AP groups. Hardware is re-onboarded at the target.
Cross-tenant copies recreate shared objects and bind their dependencies. A guest-passphrase WLAN gets its portal service profile recreated and bound; a DPSK network gets its service pool, identity group, and passphrases recreated and bound; a Cloudpath / 802.1X WLAN and a RADIUS ethernet-port profile get their RADIUS server profiles recreated and bound. Each of those bindings is what makes the copied WLAN actually activatable in the target tenant.
Not every missing binding blocks activation, and the difference matters. If a
portal, DPSK pool, or RADIUS profile can’t be copied, the WLAN is created but
left un-activated — it would come up broken, so it doesn’t come up. If a VLAN
pool, Wi-Fi calling profile, or access-control profile can’t be copied, the WLAN
is created and activated, just without that capability: no VLAN pooling, no
ePDG, or — in the access-control case — unfiltered, with no ACLs, no device or
application policy, and no rate limiting. Every one of those is named in
warnings; none is a silent drop.
Reverse linkages are discovered, not read off the WLAN. Portals, RADIUS profiles, VLAN pools, Wi-Fi calling profiles, and access-control profiles are all bound to a WLAN from the profile’s side — the WLAN body carries no reference to them — so the copy finds them by querying each profile family for the WLANs it lists. A policy bound directly to a WLAN rather than through an access-control profile is on a separate linkage path that is not copied and is invisible to this discovery.
Template mode is the most restricted, and its exclusions are a property of R1’s template surface rather than of the copy engine:
| Skipped in template mode | Why |
|---|---|
| Portal service profiles | No /rec/templates portal object — the guest-portal config travels inline on the WLAN template instead; only the profile’s branding images stay behind |
| DPSK passphrases | No passphrases sub-collection under a template pool |
| Identity groups | No standalone template create surface — which is why a template DPSK pool is created group-less |
| AP LAN-port profile activations | The template surface can’t carry them |
| Syslog settings | A template expresses syslog as a server-profile activation, not the settings PUT the copy engine writes |
| SNMP-agent settings, AP LAN-port settings | No venue-level template equivalent |
| AP mesh settings, conditionally | A template accepts only 2.4-GHz / 5-GHz for radioType. A source venue holding anything else has the whole domain skipped rather than written with a different radio — harmless when mesh is off, which is the common case |
Warnings you should expect to read
Section titled “Warnings you should expect to read”venue_copy_plan returns a warnings array. These are the cases where the copy
could not resolve something on its own:
| Warning case | What it means |
|---|---|
| Guest-passphrase WLAN with no captured portal | The WLAN is created but may be left un-activated |
| DPSK network whose pool could not be copied | Typically its identity group was not captured; the WLAN is created but left un-activated |
| RADIUS / 802.1X profile not captured or copied | 802.1X will not function until a profile is created and bound |
| AP-group-scoped source activation | Widened to all AP groups — the source’s AP-group ids don’t map across tenants |
| AP-group-scoped VLAN pool bind | Widened to the whole WLAN, for the same reason. Re-scope per AP group at the target if it matters |
| VLAN pool or Wi-Fi calling profile not copied | The WLAN activates anyway, without that capability |
| Access-control profile not copied | The WLAN activates unfiltered — no ACLs, no device or application policy, no rate limiting |
| A child policy could not be copied | Blocks its access-control profile rather than creating one that is only partly wired |
| A policy captured with no rules (L2/L3 ACL, device, application) | Skipped — R1 refuses a rule-less policy — which blocks its access-control profile, so the WLAN activates unfiltered. R1’s detail read of L3 ACL and application policies can drop their rules (an R1 bug); the warning says whether rules were confirmed lost (re-run venue_extract) or the policy is genuinely empty at the source |
| A tenant-default object (default DPSK pool, identity group, and similar) | Skipped: R1 auto-provisions its own in the target tenant, which may differ from the source’s. Nothing was written, so verify does not check it |
An application policy with USER_DEFINED rules | R1 rejects these server-side (202, then an async failure). Signature rules are unaffected — this is an R1 defect, not a copy defect |
| A shared object of the same name already exists | Adopted, overwritten, or skipped per sharedCollision; every affected object is named |
| WLAN / switch profile / ethernet-port profile with no captured definition | The extract fan-out didn’t finish. Re-run venue_extract to completion, then re-plan |
| Write-only secret masked at the source | Listed in operatorInputRequired; the run refuses with missing_capture until you supply it |
| Template: a domain the template surface can’t carry | Skipped at plan time, per the table above |