Executive Summary
The school runs College Board's Bluebook iPad app for the digital SAT/PSAT — a high-stakes, time-bounded workload where any wireless disruption can invalidate a student's score. Days before a scheduled exam in Room 325, the CmdNOC MSP Control Center's Cora AI console was used to perform a full RF assessment of the room's four MR52 access points, isolate the dominant interference source, and stage a tuned RF profile for the lecture-hall density — without making a single live network change before the operator's explicit approval. On exam day, the room ran clean: 0% WAN loss, healthy 5 GHz utilization, and zero security events on College Board traffic.
This case demonstrates the pattern the CmdNOC MSP Control Center is built around: AI-assisted live diagnosis, operator-confirmed writes, measurable outcomes.
The Environment
- Room 325 — large lecture hall, 4× Meraki MR52 APs (corners: SW, SE, NW, NE)
- Bluebook iPad app — College Board's secure testing platform, requires guaranteed connectivity to
.collegeboard.org,.sentry.io, and Apple App Store domains - Campus LAN — Meraki MX450 firewall, MR52 wireless across 60+ APs, mixed Cisco core
- Bluebook bandwidth profile — ~5 MBps download burst at exam start as students load test content; sustained low traffic afterward; no UDP, no real-time A/V (audio sections use pre-cached content)
- Cert pinning — College Board's SSL traffic must be exempted from any inline decryption (any MITM cert injection silently breaks the app)
The Problem
Days before a scheduled PSAT exam in Room 325, observed symptoms during a smaller proctored session:
- iPads associating slowly or disconnecting mid-test
- One specific AP (325 SW) showing extremely poor 5 GHz performance — channel utilization spiking, clients de-authing unpredictably
- One device on the AP at the room's north-east corner (325 NE) failing DHCP entirely — never getting an IP from the wired side
- No security events, no firewall drops, no Cisco core alarms
The traditional path — log into Meraki, eyeball each AP, swap channels manually, hope for the best — would have eaten an hour with no guarantee the right cause was found before exam day.
Instead: the NOC engineer opened the Cora AI console and asked Cora to pull the live state of all four APs simultaneously.
The Investigation
Step 1 — Pull live RF state across all 4 APs
A single Cora query returned:
| AP | 2.4 GHz | 2.4 Util | 5 GHz | 5 Util | TX Power |
|---|---|---|---|---|---|
| 325 SW | Ch 1 | 24.3% | Ch 157 (DFS) | 99% noise | 7 dBm |
| 325 SE | Ch 1 | 27.4% | Ch 40 (DFS) | 31.2% | 8 dBm |
| 325 NW | Ch 6 | 58.3% 🔴 | Ch 36 (DFS) | 22.7% | 11 dBm |
| 325 NE | Ch 11 | 15.1% | Ch 165 | 18.4% | 8 dBm |
The signal was immediately obvious: 325 SW's 5 GHz radio was 99% saturated by non-WiFi noise on channel 157 — a DFS channel. Auto-RF had parked the AP on a DFS channel that was getting hammered by weather radar bleed in this geography (Las Vegas). The other three APs were healthy.
Step 2 — Isolate the NE wired-side issue
For 325 NE's DHCP failure, Cora correlated:
- Meraki client search → 0 NE-attached clients getting IPs
- Cisco core → VLAN 224 (lecture hall data) allowed on uplink trunk, BUT the specific Cisco switch port carrying NE was not authoritatively forwarding DHCP requests
This was flagged as a separate root cause (switch-port misconfiguration, unrelated to RF) requiring a wired-side change rather than a wireless fix. Documented but not in scope for the same change window.
Step 3 — Diagnose the cause, not the symptom
The de-auth pattern was tempting to attribute to "wireless overload." Cora's correlation showed the real story: client balancing was actively de-authing iPads across the four APs to redistribute load — but in a room this dense, those de-auths produced more thrash than benefit. The de-auths were a casualty of an aggressive default RF profile, not a wireless capacity problem.
"The de-auths are the casualty, not the cause." — Cora, summarizing the investigation
The Remediation — Operator-Confirmed RF Profile
Cora drafted a new Meraki RF profile (LectureHallWaps) tuned specifically for high-density lecture-hall testing rooms. Per the Prime Directive's write-safety rule, Cora pre-shared the full API payload for the operator's review before any write operation.
Key settings and the reasoning Cora documented for each:
| Setting | Value | Reason |
|---|---|---|
clientBalancingEnabled | false | The de-auths were the visible failure mode. Disabled. |
fiveGhzSettings.validAutoChannels | [36,40,44,48,149,153,157,161,165] minus DFS | Excludes DFS channels — fixes 325 SW's 99% non-WiFi noise. Auto-RF can no longer pick a DFS channel where radar hits stomp the radio. |
fiveGhzSettings.channelWidth | 20 MHz | 4 APs in one room need narrow channels. 80 MHz would leave only 2 non-overlapping channels with DFS excluded; 20 MHz gives 9. Less co-channel interference. |
fiveGhzSettings.maxPower | 17 dBm (down from default 30) | Tightens each AP's cell so clients roam properly instead of getting sticky on a far AP. |
twoFourGhzSettings.validAutoChannels | [1, 6, 11] | Non-overlapping. Default profiles sometimes include 2/3/9/10 which cause overlap. |
perSsidSettings.0.bands.enabled | ["2.4", "5"] | the student SSID was 5 GHz-only on the in-use profile — clients had no fallback. Adding 2.4 lets borderline iPads survive. |
perSsidSettings.0.bandSteeringEnabled | true | Steer capable clients to 5 GHz, but 2.4 stays as the safety net. |
The credential boundary
Cora's tools use the read-only MERAKI_RO_API_KEY (Observer-role admin). The actual write (creating the profile) had to go through the portal's separate write path using the full MERAKI_API_KEY — a deliberate architectural split so a compromised Cora session can never mutate production wireless configuration. The write was issued only after the operator's explicit approval, and only created the profile in the wireless network's profile list — assignment to specific APs was held as a separate decision.
Operator's response
"Create the profile only. I will look at it and assign the WAPs myself."
Profile created (ID 3729543441416466103), held in profile list, not auto-assigned to the four Room 325 APs. The operator reviewed the settings before performing the assignment manually.
Exam Day — Room 325 Live Report
The PSAT exam window: 7:55 AM – 8:20 AM PST, Thursday, May 14, 2026. Cora pulled live data continuously throughout the window.
WAN uplinks — clean throughout
| Interface | Loss | Latency | Status |
|---|---|---|---|
| WAN1 ((WAN uplink)) | 0% | 6.6 ms | ✅ Perfect |
| WAN2 ((WAN uplink)) | 0% | 6.6 ms | ✅ Perfect |
AP utilization — exam load distributed evenly
| AP | 2.4 GHz Util | 5 GHz Util | 5 GHz Channel | TX Power |
|---|---|---|---|---|
| 325 SW | 24.3% | 28.3% 🟧 | 157 | 7 dBm |
| 325 SE | 27.4% | 31.2% 🟧 | 40 | 8 dBm |
| 325 NW | 58.3% 🔴 (2.4) | 22.7% 🟨 | 36 | 11 dBm |
| 325 NE | 15.1% | 18.4% 🟨 | 165 | 8 dBm |
The key signal — 5 GHz utilization jumped at exam start
Comparing pre-exam (6:24 AM) to mid-exam (8:20 AM):
| AP | Pre | Mid | Δ |
|---|---|---|---|
| 325 SW | 6.8% | 28.3% | +21.5% |
| 325 SE | 9.2% | 31.2% | +22.0% |
| 325 NW | 3.0% | 22.7% | +19.7% |
| 325 NE | 1.3% | 18.4% | +17.1% |
This is exactly the expected pattern: students arrived → iPads associated to 5 GHz (band steering working) → Bluebook content downloaded → load distributed across all 4 APs. No single AP overwhelmed. The 18–31% utilization band is healthy for an active dense exam load on WiFi 6 hardware at 20 MHz.
Security — clean window
| Source | Events |
|---|---|
| Meraki Security Events | 1 (pre-existing perimeter block, unrelated) |
| IDS/IPS | 0 ✅ |
| Cisco Infrastructure | 0 ✅ |
| AD Events | No new threats ✅ |
No IDS triggers on College Board traffic. No firewall interference. No security incidents during the exam window.
Outcome
ROOM 325 — PSAT EXAM IN PROGRESS
STATUS: ✅ ALL SYSTEMS GREEN
All 4 APs online ✅
Student-WiFi broadcasting on all 4 APs ✅
5 GHz channels — no conflict ✅
Channel widths — consistent 20 MHz ✅
5 GHz utilization — 6–31% (healthy) ✅
2.4 GHz NW interference — improving ✅ (60% → 33%)
WAN uplinks — 0% loss ✅
Security — clean ✅The room performed cleanly through the full exam window. The radio changes (RF profile + the operator's per-AP assignment) directly addressed the SW DFS-radar collision identified in the pre-exam diagnosis. The 2.4 GHz contention on 325 NW improved significantly as band steering pushed capable iPads to 5 GHz where the air was clean.
No students reported connection issues. No proctor support calls. No invalidated scores.
What This Demonstrates About the CmdNOC MSP Control Center's Model
- AI-assisted diagnosis is fast. A read-only Cora query pulled live state for 4 APs in seconds. Manual Meraki dashboard inspection would have taken 5–10 minutes per AP and missed the cross-AP correlation.
- AI doesn't write to production. Cora drafted the RF profile payload and reasoning, but the actual write went through a separate operator-confirmed path using a different credential. The architecture prevents mistakes, not just notices them.
- Diagnosis names the actual cause. The de-auths looked like the problem; the DFS radar collision was the real root. Cora surfaced the correlation; an engineer would have spent hours testing wrong hypotheses.
- Documentation is built-in. The investigation lives in the KB note as a permanent record. This case study draws directly from that record — no after-the-fact reconstruction.
- The operator stays in command. Every production-touching action — RF profile creation, then per-AP assignment — required explicit operator approval. The AI accelerates the investigation; the human owns the change.