Triage and rollout strategy after a Wi-Fi 6E pilot
Northline Retail has 120 stores and 600 access points managed in ExtremeCloud IQ. A pilot added 40 Wi-Fi 6E APs to 12 stores; the rest remain on older firmware. Store 114 reports 38 percent client retries, average SNR of 18 dB on 5 GHz, and a DHCP pool at 92 percent utilization. The store has one AP per 1,200 square feet, a metal shelving wall, and a new 80-seat click-and-collect area. The XIQ alert rules were left at defaults, so the store manager only hears from the help desk. The company wants a repeatable rollout for 300 more APs and a single configuration template, but store layouts vary. The change freeze starts in 10 days.
1. How would you use ExtremeCloud IQ to separate RF coverage problems from DHCP exhaustion and client-device issues? Name specific evidence you would collect.
Read the worked answer
Use store 114 as a layered investigation rather than assuming the APs are at fault.
First, review the client timeline and AP health in XIQ for the affected clients. Look for retry and SNR trends over time, which AP and band the client used, and whether the client roamed. Check the AP neighbor report and channel utilization to see whether the metal shelving wall and the new click-and-collect area are creating coverage holes or co-channel interference. An average SNR of 18 dB is usable but not strong, so look for clients at the edge of coverage.
Second, separate DHCP from RF. A 92 percent pool utilization means new clients may fail to get an address even with good RF. Check DHCP pool utilization, lease duration, and whether failures cluster at busy times. Look at the client timeline for DHCP failures versus association failures. If clients associate but never get an address, that is DHCP; if they retry association or show low SNR, that is RF.
Third, check the wired side and client device mix. Look for AP uplink errors, PoE issues, and whether a particular device type fails. Use packet capture only after the simpler evidence points to a specific client or AP.
2. Recommend a configuration and firmware strategy for the 300-AP rollout without forcing one rigid template on all stores.
Read the worked answer
Use a layered configuration model. Create a base template for corporate SSIDs, security, monitoring, and firmware policy. Add site or store-type profiles for RF settings, channel plans, and AP placement differences. Use configuration groups or site overrides for exceptions such as the click-and-collect area instead of cloning one store exactly.
For firmware, define a compliance policy and a canary group. Upgrade a small set of non-critical stores first, watch AP health, client retries, and DHCP behavior, then move in waves. Keep a known-good firmware baseline and a rollback plan. Do not mix a mass firmware push with the 300-AP hardware rollout in the same window.
For provisioning, use auto-provisioning or zero-touch onboarding where supported, but require a pre-staging check of AP model, license, and site assignment. The single template should define standards, not eliminate legitimate local RF variation.
3. What alert and operational changes would you make so store 114 does not rely on user complaints?
Read the worked answer
Move from default alerts to a small set of actionable rules. Create thresholds for client retry rate, SNR or RF quality degradation, AP down or reboot, DHCP pool utilization above 80 percent, and uplink errors. Route critical alerts to the service desk through email or a webhook to ServiceNow, and route store-level summaries to the store manager.
Add a daily health report for pilot stores and a weekly comparison across stores so store 114 stands out before customers complain. Use XIQ monitoring views to review the worst clients and APs each morning during the pilot. Define an escalation path: store manager reports symptoms, service desk checks XIQ, network team investigates RF or DHCP with evidence.
Do not enable every possible alert; noisy defaults get ignored. Tune thresholds after two weeks of baseline data.