Zero-Touch Onboarding of 12 EX3400 Switches Across Three Sites
RetailWorks is replacing 12 standalone EX3400-48P switches across three stores: Austin (4), Denver (4), and Portland (4). The switches run Junos 18.4R3, have static management IP addresses on VLAN 99, no DHCP helper, and no DNS or NTP configured. Each store has unique data, voice, and guest VLAN IDs, plus local port descriptions for POS terminals and a few PoE settings. The company has purchased Mist Wired Assurance and wants to onboard all switches during two-hour maintenance windows, one store at a time. The security team requires outbound traffic to be limited to HTTPS 443 to Mist and DNS/NTP. The network team wants to preserve the existing port descriptions and PoE settings but avoid copying full Junos configs into Mist. They also need a rollback plan if a store loses switch management after template push.
1. List the prerequisites and onboarding sequence for getting these switches into Mist Wired Assurance given static management IPs and no DHCP, DNS, or NTP. What must be done before the maintenance window?
Read the worked answer
Before the window, confirm the EX3400 Junos version is supported for Mist management, collect serial numbers or claim codes, create the org and the three sites, and confirm outbound HTTPS 443 to Mist plus working DNS and NTP. Because the switches use static management addresses and there is no DHCP, zero-touch onboarding will not happen by itself. Either create a temporary management VLAN with DHCP, DNS, NTP, and the supported Mist redirect method for EX ZTP, or use console/CLI during the window to set name-server, NTP, and the Mist cloud connection before claiming the switch. Claim the serials and assign each switch to the correct site before the window so the template is ready. Stage the org-level switch template with site variables for VLAN IDs and management parameters. During the window, back up the running config with show configuration | display set, apply the template, commit, and verify the switch appears online in Mist with management reachability, uplink ports, PoE, and clients. Do not zeroize until the backup is stored off-box.
2. How should the team preserve existing port descriptions and PoE settings while still using an org-level switch template? What should be variable, port profile, or per-switch override?
Read the worked answer
Use the org template for common policy: DNS, NTP, syslog, uplink definitions, VLAN creation, and standard port settings. Make site-specific values variables: VLAN IDs, management subnet, NTP server if it differs, and site name. Put repeated wall-port standards into port profiles, such as POS, AP, phone, and printer profiles, including description patterns, PoE priority, and VLAN membership. Apply port profiles by port range instead of pasting per-port config into the template. Preserve true exceptions, such as a single odd POS terminal or a locally required PoE setting, as per-switch overrides and document them. Do not copy the full Junos config into Mist; that defeats template consistency and makes drift likely. Before the window, render the template for each site and compare the intended VLANs, descriptions, and PoE settings against the saved config. If Mist shows a config diff, review it before commit rather than accepting it blindly.
3. What validation and rollback steps should be used inside the two-hour window?
Read the worked answer
Before the push, record uplink ports, management addressing, and console access, and save the full config off-box. After the push, validate in this order: switch online in Mist, management reachable from the NOC, uplinks up and passing VLANs, LLDP neighbors correct, access ports up, PoE delivered to APs and phones, client counts normal, and no critical alarms. Compare the running config against the saved backup and check for unexpected VLAN or port changes. If management is lost, use console access to restore the saved config or revert to the previous template version. Keep the window scoped to one store so a failure does not affect all 12 switches. Do not move to the next store until the first store has run through a business-cycle check, including POS transactions and phone calls. The rollback plan must include who has console access and where the backup is stored.