Before you claim — what onboarding really means
Think of a new Mist AP like a brand-new phone. The phone is useless until you link it to your account. The little code on the box is how you say "this one is mine." Once it's linked, your settings flow down to it automatically — no cable, no laptop, no typing config. That linking step is called claiming, and the auto-settings part is zero-touch provisioning.
Here's the one idea that unlocks everything: a Mist AP carries no local config out of the box — its brain lives in the Mist cloud. To manage it, you must first claim it into your organization, then place it on a site. Claiming proves ownership; the cloud then pushes the right config down automatically. You never SSH into the AP to configure it.
Architecturally, onboarding separates ownership from configuration. The claim/activation code binds a device serial to your Mist org. ZTP then handles the config: the AP gets DHCP, resolves the cloud terminator FQDN, opens an outbound HTTPS session, and inherits org → site → device-profile → AP-level settings in that precedence. Get the claim, the site assignment, and the outbound path right, and a hundred APs come up identically with zero on-site touch.
A per-device code (also a QR) on the rear of the AP. Claims one AP into your org. Perfect for a single AP or a small site.
One code that claims many APs at once. Juniper sends it with your purchase-order (PO) info. The bulk-deploy default.
A physical location in Mist. A claimed AP must be assigned to a site to inherit that site's templates and go live.
A reusable config bundle (radios, LEDs, WLAN templates) you push to a group of like APs — assignable right inside the claim modal.
① Claim vs Activate — one AP or a hundred?
Two codes, one job: telling Mist "these are mine." If you bought a single AP, use the little code on the back. If a big box of APs arrived, your order email has one master code that grabs them all in a single step.
To manage any AP you must claim it. You use either a claim code or an activation code. A claim code (and matching QR) is printed on the rear of each AP and claims that single unit. An activation code arrives alongside your PO and claims all the APs on that order at once. Rule of thumb: one AP → claim code, a shipment → activation code.
Both codes resolve, on Juniper's back end, to a set of device serials registered to your Mist org. The activation code is really just a phone-home token tied to the order; when an AP from that order boots and reaches the cloud, the org adoption happens automatically (true ZTP). The claim code is the manual equivalent for ad-hoc units. Either way, the trust anchor is the device serial — not the network it's plugged into.
Pause & predict: a colleague has one spare AP from a drawer (no PO) to add to a live site. Claim code or activation code?
Where is the per-device claim code (and its QR code) physically located on a Juniper Mist AP?
② Onboard the AP — mobile QR or web browser
Two ways to do it: point your phone's Mist app at the QR code on the AP, or open the website on a laptop and paste the code. Both end the same way — the AP shows up on your screen and you drop it onto a floor plan.
Mist gives you two onboarding paths. Mobile: the Mist AI app scans the AP's QR, claims it, assigns the site, lets you rename it, and place it on the floor plan — great for one or a handful while you're physically on site. Web: in the dashboard go to Organization → Inventory → Claim APs, paste a claim or activation code, tick Assign claimed APs to site, and optionally tick Assign claimed APs to device profile. The web path is the bulk path.
The two paths converge on the same inventory record. The decision is operational, not technical: mobile gives you on-the-spot physical placement (you scan the AP you're literally holding, so floor-plan accuracy is high), while web lets you pre-stage the whole org before any hardware lands. Mature shops claim in bulk by activation code via web, pre-assign sites and device profiles, and let ZTP finish the job when each AP powers on.
Codes (one per line): ABC12-DEF34-GH567 # rear-panel claim code, AP #1 JKL89-MNP01-QR234 # rear-panel claim code, AP #2 TC-ACTIVATE-PUNE-2026 # activation code from the PO (claims the rest) [x] Assign claimed APs to site: Pune-HQ-Floor3 [x] Assign claimed APs to device profile: AP-Office-Standard
3 codes accepted · 14 APs claimed Status: Claimed → Assigned (site: Pune-HQ-Floor3) Profile: AP-Office-Standard applied to 14 APs Next: APs show "Disconnected" until they power on and reach the cloud
What you see: the AP is in Inventory but never appears on any site's AP list, and no config reaches it. Cause: claiming proves ownership only — it does not place the AP on a site. An AP with no site assignment inherits no templates and stays inert. Fix: select the AP in Inventory and Assign to Site (or tick the assign-to-site box during claim). Always claim and assign.
▶ Watch a single AP get onboarded
Click Play. Each stage lights up as the AP moves from "boxed" to "Connected" on the cloud.
Rahul at a TCS branch claims 12 APs by activation code on the web dashboard but forgets to tick "Assign claimed APs to site." The APs power on and reach the cloud. What does he see, and why?
③ Device profiles + ZTP — config that arrives before you do
A device profile is a "starter pack" of settings. Instead of setting up every AP by hand, you make the pack once and stamp it on a whole group. New AP joins, gets stamped, ready to go.
A device profile sends one consistent config to a group of like APs across sites — radio settings, LED behaviour, and one or more WLAN templates. Because you can tick "assign to device profile" right in the claim modal, an AP can be fully configured the moment it phones home. That's the heart of ZTP: power on → DHCP → resolve cloud → pull profile → live. No staging bench, no console cable.
Mist config is a precedence hierarchy: Org → Site → Device Profile → per-AP override. RRM/RF can come from an RF template, a device profile, or per-AP; if you set none, you must configure radios on each AP individually — which defeats scale. The design pattern is to encode the 80% common case in a device profile (e.g. AP-Office-Standard), keep exceptions as per-AP overrides, and let ZTP apply the profile automatically at first contact. One profile change then re-provisions every AP in scope.
▶ Zero-Touch Provisioning — greenfield AP boot
A factory-fresh AP, already claimed by activation code, powers on and provisions itself. No human on the keyboard.
Pause & predict: you change one radio-band setting in the AP-Office-Standard device profile. How many APs re-provision, and do you touch any of them?
A greenfield AP is claimed by activation code and powers on, but you set no device profile, no site template, and no per-AP radio config. What happens to its radio settings?
④ Troubleshoot — "AP won't connect" playbook
If the AP won't come online, the little light on it is basically Morse code for the problem. Count the yellow blinks and you instantly know whether it's a power, IP, gateway or cloud issue.
The AP has a single status LED that blinks out error codes. Read it first, then walk the path. 2 yellow blinks = a layer-2 issue on the switch/AP link. 3 yellow = no IP from DHCP. 5 yellow = got a gateway but can't reach it. A steady green/yellow connect pattern means it's reaching the cloud. If the LED is healthy but it still won't connect, suspect DNS or the firewall — the AP must resolve and reach ep-terminator.<region>.mist.com outbound.
Diagnose by isolating the ZTP stages. Power (PoE), L2 link, DHCP (IP+DNS+GW), DNS resolution of the terminator FQDN, then outbound HTTPS. Because the cloud terminator IPs change, firewall rules must be FQDN-based, not IP-pinned. APs need outbound TCP 443 as the primary channel; Juniper also recommends opening UDP 443 and TCP 80. No inbound rule is required — the AP always initiates the session. If L2/DHCP are clean but the cloud is unreachable, it's almost always DNS or a firewall blocking 443 to the terminator.
Layer-2 problem on the switch or AP link. Check the switchport config, VLAN, cabling and PoE before anything else.
No DHCP IP. The AP couldn't fetch an address from DHCP (or its static config). Check the scope, VLAN and DHCP helper.
Gateway unreachable. A default gateway was learned but the AP can't reach it. Check routing, gateway IP and subnet mask.
L2/DHCP healthy but still disconnected → DNS or firewall. The AP must resolve and reach ep-terminator on outbound TCP 443.
$ nslookup ep-terminator.gc1.mist.com 10.20.5.2 $ curl -sv https://ep-terminator.gc1.mist.com 2>&1 | head -n 4
Server: 10.20.5.2 Name: ep-terminator.gc1.mist.com Address: 34.x.x.x (IP varies — use FQDN firewall rules, not this) * Trying 34.x.x.x:443... * Connected to ep-terminator.gc1.mist.com (34.x.x.x) port 443 * TLS handshake, TLSv1.2/1.3 * SSL connection using TLS_AES_256_GCM_SHA384 # path to cloud is open
1. Open outbound TCP 443 from the AP VLAN to the Mist terminators (also recommended: UDP 443 + TCP 80). No inbound rule needed — the AP initiates. 2. Use FQDN-based firewall rules for the terminators — their IPs change, so IP-pinned rules silently break after a cloud move. 3. Confirm DNS works on the AP's VLAN; if the AP gets an IP (LED healthy) but can't resolve ep-terminator.<region>.mist.com, fix the DHCP-provided DNS server first.
*.mist.com terminator FQDN and the eighth AP connects in seconds. Pin FQDNs, not IPs.
Pause & predict: an AP blinks 3 yellow. Before you blame the cloud or the firewall, what is the actual problem?
What you see: the AP reaches Connected, downloads firmware, reboots, and the cycle repeats. Cause is usually power, not cloud: an underpowered PoE port (wrong PoE class/budget) can't sustain the AP through a firmware upgrade, so it brown-outs and reboots. Verify the switchport supplies the AP's rated PoE class on a Mist-supported switch, then let the upgrade complete.
▶ Diagnosis ladder — isolate the failed stage
Walk the same path the AP walks. Stop at the first stage that fails — that's your root cause.
Onboarding is an internet-facing-by-design flow, so firmware hygiene matters. Juniper has shipped serious advisories across the platform — for example the WAN Assurance / Session Smart API authentication-bypass (CVE-2025-21589) and the AP-relevant FragAttacks (CVE-2020-24588) frame-injection class. The takeaway for onboarding: let the cloud push current firmware as part of ZTP, subscribe to Mist security alerts, and never expose management to unsolicited inbound — the AP should only ever initiate outbound to the cloud.
A branch AP has a healthy connect-blink LED, a valid DHCP lease and a reachable gateway, yet stays Disconnected on the cloud. Which single firewall change is most likely to fix it without new hardware?
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from Juniper Mist docs + community Q&A. For a live prod issue, share the AP's LED pattern + your DHCP/DNS/firewall facts at chat.techclick.in.
📝 Wrap-up — six more
You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 Self-explanation — lock it in
In one or two sentences, explain to yourself: "For a single drawer AP vs a 60-AP shipment, which code do I use, and what's the one extra step after claiming so config actually flows?" Writing it in your own words is the single biggest retention booster.
👩🏫 Teach a friend
Explain claim-vs-activate and device-profile-ZTP to a teammate in under 60 seconds, using the "ownership flows up, config flows down" framing. If you can teach it, you own it.
🔔 Spaced-recall reminder (optional)
Want a 3-question recap mailed to you in 3 days? Spaced repetition is how this sticks for the exam. Enter your email — we only use it for this nudge.
📕 Glossary
- Claim code
- A per-device code (and QR) on the rear of an AP; claims a single AP into your Mist org.
- Activation code
- One code that claims many APs at once; delivered with your purchase-order (PO) information.
- Site
- A physical location in Mist; a claimed AP must be assigned to a site to inherit templates and go live.
- Device profile
- A reusable config bundle (radios, LEDs, WLAN templates) pushed to a group of like APs across sites.
- ZTP (Zero-Touch Provisioning)
- Power on → DHCP → DNS → outbound HTTPS to cloud → pull config — no manual staging.
- ep-terminator
- The Mist cloud endpoint FQDN an AP connects to (e.g. ep-terminator.<region>.mist.com); use FQDN firewall rules.
- Mist AI mobile app
- Phone app to scan an AP's QR, claim it, assign a site, name it, and place it on a floor plan.
📚 Sources
- Juniper Mist Docs — Claim a Juniper AP & Cloud-Ready Mist Access Points Quick Start (Step 1: Begin / Step 2: Up and Running). juniper.net/documentation & mist.com/documentation/claiming-aps.
- Juniper Mist Docs — Device Profiles Overview, Create a Device Profile, Using WLAN Templates in a Device Profile, RRM Configuration Options. juniper.net/documentation.
- Juniper Mist Docs — Onboarding ZTP/Greenfield Devices & AI-Driven Wired/Wireless Network Deployment Guide. mist.com/documentation.
- Community / practitioner — Mist & Juniper community: AP Unable to Reach the Mist Cloud?, What is the LED telling me?, Troubleshooting AP Disconnect Issues; r/networking ZTP threads. mist.com/documentation & community discussions.
- Juniper Security — API Authentication Bypass (CVE-2025-21589, WAN Assurance / Session Smart) & Mist Security Advisory — FragAttacks (CVE-2020-24588). supportportal.juniper.net & mist.com/documentation security alerts.
- Juniper Certification — Mist AI, Associate (JNCIA-MistAI, JN0-253) & Mist AI Specialist (JNCIS-MistAI, JN0-451) blueprints: AP provisioning & configuration, ZTP and onboarding. juniper.net/training/certification.
What's next?
Your APs are claimed, profiled and on air — now make the radios smart. Next we tune the RF: how Mist's auto-RF plans channels and power, the coverage-vs-capacity trade-off, and how RF templates push consistent radio policy across sites.