Global Retail Rollout: Policy and Device Group Boundaries
Northwind Retail is migrating 400 Extreme APs across 40 stores from an on-premises controller to ExtremeCloud IQ. Stores are grouped into three regions (EMEA, APAC, Americas), each with 10-15 sites. Every site needs a corporate SSID mapped to a local VLAN and a guest SSID with captive portal. Central IT wants one consistent policy, but regional engineers need to add a temporary event SSID at short notice. Two stores have outbound firewall rules that only allow DNS and HTTPS to approved SaaS domains, and one store has a backup LTE link that frequently fails over. The project team is debating whether to create one global network policy, one policy per region, or one per store, and how to structure device groups so that a bad change does not hit all 400 APs at once. They also need to explain to store managers what happens to Wi-Fi if the cloud is unreachable.
1. Recommend a device group and network policy structure for the 400-AP rollout, and justify the trade-offs between global, regional, and per-store policies.
Read the worked answer
Use a regional baseline plus store-level exception groups. In ExtremeCloud IQ, SSIDs live inside a network policy and the policy is assigned through device groups, so one global policy would make every SSID edit affect all 400 APs. Create one device group per region and per-store groups for staging and exceptions. Build a regional network policy containing the common corporate and guest SSIDs and assign it to the region's store groups. For a temporary event SSID, clone the regional policy into a store-specific policy assigned only to that store's group, then remove it after the event. This limits blast radius: a bad corporate change can be piloted on one store group before the region. One policy per store multiplies drift and administrative effort, so reserve it for genuine exceptions. The design also gives regional engineers a scoped object to edit without tenant-wide rights.
2. During an ISP outage, store staff report that Wi-Fi still works but the APs show offline in ExtremeCloud IQ. Explain what is happening and what the store managers should expect.
Read the worked answer
Separate the control plane from the data plane. The APs can keep broadcasting cached SSIDs and serving already-associated clients, but ExtremeCloud IQ marks them offline because heartbeats cannot reach the cloud. New cloud-side changes, live monitoring, and cloud-hosted guest portal authentication may fail. Check Device 360 history and local AP LEDs rather than assuming the APs are down. Tell store managers that existing Wi-Fi may continue, but guest login and central visibility can be degraded. If guest access is business-critical, validate whether the captive portal is cloud-hosted and consider a local survivability option or backup WAN. After restore, confirm the APs rejoin and the configuration syncs, and check alarms for config mismatch. Also avoid designing every store behind one WAN or DNS dependency.
3. A regional engineer needs to add a temporary event SSID for one store. How should the administrator delegate this without giving tenant-wide admin rights?
Read the worked answer
Do not grant a tenant-wide Admin role. Create a user group scoped to the region's device groups with permission to manage network policies but not tenant settings, firmware, or user management. For the event, clone the regional policy into a store-specific policy, assign it only to that store's device group, and let the engineer edit that policy. If the available role granularity does not allow policy-only edits, use a change request workflow: the engineer submits SSID and VLAN details, and central Tier 3 applies them in a maintenance window. Require audit log review and a defined rollback time. This preserves least privilege, prevents the temporary SSID from leaking into other stores, and keeps a clear record of who changed what.