Retail Template Push Breaks Instant APs
A retail chain has 60 stores, each with two Aruba Instant APs in a virtual controller and a store router. Aruba Central manages all APs in one template group with site-specific VLAN variables. Stores use a 20 Mbps MPLS primary link and LTE backup. On Friday, an engineer changes the WLAN template to add a new employee SSID and commits it to the group. By Saturday, 40 stores report Wi-Fi down. Central shows the APs online but configuration out of sync; some stores have one AP broadcasting the old SSID and one not. The affected stores span three regions, but stores in one region are fine. Store staff can reach the internet through wired POS. You must restore Wi-Fi quickly without visiting stores, and you must prevent the same failure next time.
1. What is the most likely cause, and what evidence in Central would you check first?
Read the worked answer
The APs are online, so this is not a total WAN outage. The most likely cause is the template commit: the new employee SSID references a VLAN variable that is undefined or wrong for the affected stores. The virtual controller applies the config to its members, which explains one AP broadcasting and one not while they converge; the region that is fine probably has the variable defined. Check Central's configuration audit/diff for the group and the per-store variable values first. Then check the AP configuration status and virtual-controller logs; confirm the store router actually has the intended VLAN. Do not start by replacing APs or rebooting all stores, because that destroys evidence and may widen the outage.
2. What rollback path minimizes risk, and why not simply push the fixed template to all stores at once?
Read the worked answer
Fix the variable or template first, then test on one affected store and one non-affected store. Use Central's configuration history/restore or roll back the group template to the prior version for the affected stores, but do it in batches so the 20 working stores are not put at risk. Do not push a corrected template to all 60 stores at once: a single bad variable would repeat the outage, and LTE backup links may be slow. After the pilot shows both APs in sync and the SSID broadcasting, roll out by region with a pause and a health check. Keep the old template version available until the new one is proven.
3. What governance change would prevent recurrence?
Read the worked answer
Treat template variables as code: require a default or validation for every variable, review the group diff before commit, and pilot every WLAN change in a canary store or region. Use Central's configuration audit and firmware/config compliance as gates, not as after-the-fact reports. Document which variables are per-store and who owns them, and keep a tested rollback procedure. Schedule changes outside store trading hours and monitor AP online/configuration-sync status after each batch. This prevents a single missing variable from becoming a 40-store outage.