Campus AP Onboarding with Partial Discovery
Brightline Health is onboarding 120 new APs across a five-building campus. The APs are already racked and powered, and the network team has a CSV with serial numbers and MAC addresses. DHCP is handled by a central server; option 43 is not configured because the previous vendor used it for a different controller. After 30 minutes, 78 APs appear in ExtremeCloud IQ under Unassigned, 22 appear in a device group called Default, and 20 never appear. The campus edge firewall permits outbound DNS and HTTPS, but one building uses a NAT gateway that rewrites source addresses. The team wants to use the fastest repeatable method and avoid manually typing serial numbers. They also need to ensure the APs receive the correct network policy before going live.
1. Recommend an onboarding workflow for the 120 APs that avoids manual serial entry and reduces the risk of putting devices into production too early.
Read the worked answer
Pre-provision the APs by importing the CSV into ExtremeCloud IQ and assigning the devices to a staging device group with a bootstrap network policy. That way the APs authenticate to the cloud by serial and pull a controlled configuration without someone typing serials at each site. Use the ExtremeCloud IQ Connect app only for exceptions or replacements. Keep the staging policy minimal, then move devices to the production device group after validation. This is faster and more repeatable than discovery-only onboarding because the desired group and policy already exist before the AP connects. Confirm that DHCP, DNS, outbound HTTPS, and NTP are working, since certificate validation and cloud reachability depend on correct time and name resolution. NAT is normally acceptable because the AP initiates the outbound session, but the gateway must not block return traffic.
2. Twenty APs never appear in ExtremeCloud IQ, while 78 are Unassigned and 22 are in Default. What troubleshooting sequence would you use?
Read the worked answer
Start at the physical and Layer 2/3 layers for the missing 20: check switch port status, PoE, AP LED, DHCP lease, and the VLAN assigned to the AP port. Then verify DNS resolution and outbound HTTPS from that subnet. The NAT building is a suspect because a rewriting gateway can break return traffic or hide source addresses from monitoring; confirm that outbound sessions persist and that the firewall is not inspecting or blocking the cloud endpoint. Check whether the APs have correct time, because certificate validation fails with a large clock skew. For the 78 Unassigned devices, the onboarding succeeded but no device group or policy assignment was applied; assign them to the staging group in bulk. For the 22 in Default, confirm whether auto-onboarding placed them there and move them to staging so they do not inherit an unintended policy.
3. How would you validate the APs before moving them into the production network policy?
Read the worked answer
Use the staging policy to verify cloud management and basic wireless operation without exposing production SSIDs. In Device 360, confirm the AP is online, the firmware is at the approved version, the network policy and VLAN are correct, and the radios are up. Associate a test client and confirm DHCP, gateway reachability, and the intended SSID behavior. Check alarms for configuration failures, certificate issues, or radio faults. Then move a small batch to the production device group, confirm the configuration push succeeds, and repeat in waves. This staged approach catches a bad VLAN or policy mapping before it affects all 120 APs and keeps rollback simple.