Überblick über den Mist-Onboarding-Arbeitsablauf

1. Lernziele

Onboarding von Claim, Site Assignment und Provisionierung abgrenzen
Organisation, Site, Subscription und Inventory korrekt einordnen
Claim-Code, QR-Code, Activation Code und Adoption auswählen
Gerätetypen und deren unterschiedliche Workflows unterscheiden
Konfigurationsvorbereitung vor der Gerätezuweisung durchführen
Cloudverbindung, Configstatus und Servicefunktion getrennt prüfen
Auto-Provisioning nur im dokumentierten Scope einsetzen
Stop-, Rollback- und Release-Kriterien anwenden
Onboarding sicher und auditierbar gestalten
ein wiederholbares Step-by-Step-Runbook verwenden

Leitfrage: Ist das Gerät lediglich beansprucht, bereits einer Site zugeordnet, cloudverbunden, konfiguriert oder tatsächlich fachlich abgenommen?

2. Was „Onboarding“ umfasst

Administrative Aufnahme

Gerät und Subscription werden der richtigen Mist-Organisation zugeordnet.

Technische Einbindung

Gerät erreicht die richtige Mist-Cloudinstanz und baut eine sichere Managementsession auf.

Fachliche Aktivierung

Site, Template/Profile, Konfiguration, Dienste und Experience werden abgenommen.

Claimed ≠ Assigned ≠ Connected ≠ Configured ≠ Accepted

3. Zustandsmodell

Status	Bedeutung	Beweis
Purchased/Installed Base	Gerät ist bestellt beziehungsweise Juniper-Konto zugeordnet	PO/Installed Base
Claimed/Adopted	Gerät gehört zur Mist-Organisation	Inventoryeintrag
Unassigned	noch keiner Site zugeordnet	Inventorystatus
Assigned	Sitekontext vorhanden	Site im Gerätedatensatz
Connected	aktive Cloudkommunikation	Portalstatus/Gerätesession
Configured	beabsichtigte Konfiguration angewendet	Configstatus/Commit
Operational	Geräte- und Netzwerkfunktionen arbeiten	Metrics, SLEs und Tests
Accepted	fachliche Abnahme und Übergabe erfolgt	Abnahmeprotokoll

4. Schritt 1 – Deployment planen

Entscheidung	Beispiele
Gerätetyp	AP, Switch, WAN Edge, Mist Edge
Ausgangslage	Greenfield, Brownfield, Ersatz, Migration
Zielmodus	Cloud-managed, beobachtet, Fabric-/Cluster-Mitglied
Site	Adresse, Zeitzone, Gebäude, Standortcode
Konfigurationsquelle	Org Template, Site, Device Profile, Gerätekonfiguration
Netzpfad	DHCP/statisch, DNS, NTP, Gateway, Firewall, Proxy
Change	Impact, Wartungsfenster, Rollback, Verantwortliche

Gerätetyp und Ausgangslage bestimmen den Pfad. Ein bestehender Switch benötigt andere Sicherungs- und Ownershipschritte als ein neuer AP mit QR-Code.

5. Schritt 2 – Organisation vorbereiten

richtige Mist-Cloudregion und Organisation bestätigen
Organisationsname, Land, Zeitzone und Kontaktinformationen prüfen
SSO/MFA und Adminzugänge konfigurieren
Namens-, Standort- und Taggingkonvention definieren
Templates, RF-/WLAN-/Switch-/WAN-Standards vorbereiten
API-/Webhook-Nutzung und Tokenmodell dokumentieren
Audit-, Datenschutz- und Aufbewahrungsanforderungen festlegen

Ownership: Ein Claim bindet ein Gerät an eine Organisation. Vor dem Scannen wird deshalb die aktive Organisation in Portal oder Mobile App geprüft.

6. Schritt 3 – Rollen und Berechtigungen

Rolle/Aufgabe	Prinzip
Super User	organisationsweite hochwirksame Aktionen wie Claim, Templates und Release
Network Admin	Konfiguration und Betrieb im erlaubten Siteumfang
Helpdesk	Diagnose und Einsicht mit begrenzter Änderungskompetenz
Observer	read-only beziehungsweise überwiegende Sichtbarkeit
Installer/Mobile Workflow	physische Installation, QR-Erfassung und Sitezuordnung nach Freigabe

Die genaue Berechtigungsmatrix ist geräte- und rollenabhängig. Vor der Durchführung wird die aktuelle Juniper-Rollendokumentation geprüft; technische Berechtigung ersetzt keine Changefreigabe.

7. Schritt 4 – Subscriptions aktivieren

Organization→Admin→Subscriptions→Apply Activation Code

Ein Activation Code kann mehrere gekaufte Geräte und Subscriptions gemeinsam aktivieren beziehungsweise claimen. Subscriptions gelten laut Juniper grundsätzlich auf Organisationsebene; passende Geräte konsumieren den verfügbaren Umfang.

Prüfung	Frage
Status	aktiv, abgelaufen oder überschritten?
Service	Wireless, Wired, WAN, Marvis oder Location passend?
Menge	ausreichend für die geplanten Geräte?
Site Enablement	falls für Subscription unterstützt, richtige Sites aktiviert?
Laufzeit	Ablauf und Renewalprozess überwacht?

Bei Ablauf bleiben Geräte nach Juniper-Angabe operativ, der Portalzugriff für Monitoring und Konfigurationsänderungen kann jedoch entfallen. Das ist ein Betriebsrisiko und kein sofortiger Data-Plane-Ausfall.

8. Schritt 5 – Sites anlegen

Feld	Warum wichtig?
Site Name	eindeutiger betrieblicher Kontext
Time Zone	Events, Schedules, Reports und Korrelation
Adresse/Koordinaten	Karte, Standortdienste und Supportkontext
Site Group	delegierte Administration und Gruppierung
Variablen	standortspezifische Server, Netze und Werte
Templates	Switch-, WLAN- oder WAN-Intent

„Primary Site“ ist nur der initiale Standardname und besitzt laut Juniper keine besondere technische Bedeutung.

9. Schritt 6 – Intent vor Claim vorbereiten

Wired

Switch Template, Networks, Port Profiles, RADIUS, Rollen und Site Variables.

Wireless

WLANs, RF Template, Site Settings, Device Profiles, AP-Name und Floorplan.

WAN

WAN Edge Template, Provider-/Interfacevariablen, Policies, Hub-/Spoke-Rollen.

Mist Edge

Cluster-/Sitekontext, Tunnel-, VLAN-, IP- und Redundanzplanung.

Ein der Site zugeordnetes Gerät kann Konfiguration unmittelbar erben. Falsche Variablen oder Templates werden daher vor der Zuweisung korrigiert.

10. Schritt 7 – Day-0-Netzwerk bereitstellen

Parameter	Funktion	Fehlerbild
IP/Mask	lokale Erreichbarkeit	keine Lease/Adresskonflikt
Default Gateway	Cloudpfad	nur lokales Netz erreichbar
DNS	Mist-Endpunkte auflösen	IP-Konnektivität, aber kein Cloudaufbau
NTP/Time	Zertifikate und Ereigniskorrelation	TLS-/Zeitprobleme
Firewall	ausgehender Managementtransport	Timeout/Disconnected
Proxy	optionaler kontrollierter Cloudzugang	Auth-/Option-/Routingfehler
VLAN/Native	korrekter Management-L2-Pfad	DHCP oder Gateway nicht erreichbar

Freigaben werden anhand der aktuellen Cloudregion und gerätespezifischen Dokumentation erstellt. AP, Switch, WAN Edge und Mist Edge dürfen nicht pauschal mit identischen Ports und Zielen angenommen werden.

11. Schritt 8 – Inventory verstehen

Organization → Admin → Inventory trennt Gerätetypen in eigene Register. Von hier aus werden Geräte gesucht, claimed/adopted, benannt, Sites zugewiesen oder released.

Objektzustand	Bedeutung
Installed Base	Juniper-Kontobestand, noch nicht zwingend in Mist adoptiert
Claimed/Adopted	Organisation besitzt das Gerät in Mist
Unassigned	noch ohne Site
Assigned	einer Site zugeordnet
Connected/Disconnected	aktuelle Cloudkommunikation

Nicht verwechseln: „Unassigned“ beschreibt fehlenden Sitekontext, nicht zwingend fehlendes Eigentum oder fehlende Cloudfähigkeit.

12. Schritt 9A – Claim

Methode	Geeignet für	Wirkung
QR-Code	ein physisches cloud-ready Gerät	schnelle mobile Erfassung
Claim Code	ein Gerät über Portal oder App	Gerät der Organisation zuordnen
Activation Code	Bestellung mit mehreren Geräten/Subscriptions	Batch-Claim und Aktivierung

1. Organisation prüfen
Aktiver Mandant muss dem Auftrag entsprechen.

2. Identität erfassen
QR, Claim- oder Activation Code sicher eingeben.

3. Optionen prüfen
Site, Namensgenerierung, Profile, Management und Firmware – abhängig vom Gerätetyp.

4. Ergebnis prüfen
MAC, Seriennummer, Modell und Stückzahl kontrollieren.

13. Schritt 9B – Adoption

Adoption wird für unterstützte Bestandsgeräte ohne Claim-Code, für Geräte aus der Installed Base und je nach Typ für virtuelle/ältere Geräte verwendet.

Phase	Kontrolle
Bestand	Konfiguration, Version, Identität und Serviceabhängigkeiten sichern
Portal	Adopt-Workflow und gerätespezifische Befehle erzeugen
Gerät	Befehle prüfen, anwenden und committen
Cloud	Session und Inventoryeintrag bestätigen
Ownership	Monitoring oder vollständiges Cloudmanagement bewusst wählen

Bei EX-Brownfield kann aktiviertes Mist Configuration Management die bestehende Konfiguration ersetzen. Deshalb wird Adoption nicht automatisch mit sofortiger Konfigurationsübernahme gleichgesetzt.

14. Schritt 10 – Mobile-App-Workflow

Die Mist AI Mobile App kann Switches, APs, WAN Edges und Mist Edges claimen und Sites zuweisen.

Startpunkt	Wirkung
Home → Claim Devices to Org	claimt in Organisation; Site später zuweisen
Device Inventory → Gerätetyp → +	claimt in Organisation; Site später zuweisen
Site → Gerätetyp → +	claimt und weist direkt dieser Site zu

QR-Code kann gescannt oder Claim-Code manuell eingegeben werden. Vor-Ort-Personal kontrolliert Organisation, Site und Geräteidentität; es entscheidet nicht eigenmächtig über produktionswirksame Templates.

15. Schritt 11 – Site Assignment

Inventory→Geräte wählen→More→Assign to Site→Bestätigen

Vor Zuweisung	Prüfung
Site	Name, Zeitzone, Adresse und Site Group korrekt
Template/Profile	erwartete Konfiguration statt Test-/Defaultintent
Subscription	benötigter Service verfügbar
Gerätename	eindeutige betriebliche Konvention
Floorplan/Rack	physischer Standort vorbereitet
Managementwirkung	automatische Provisionierung verstanden

16. Gerätetypen im Vergleich

Gerät	Claim	Adoption	Site-Intent
Mist AP	QR/Claim/Activation	typisch Claim	WLAN, RF, Site-/Device Profile
EX/QFX Switch	cloud-ready Claim	Brownfield/Installed Base	Switch Template, Site, Switch Config
WAN Edge	modellabhängig Claim	Installed Base/Workflow	WAN Edge Template/Hub/Device
Mist Edge	App/Portal nach Modell	produktspezifisch	Cluster-/Tunnel-/Sitekonfiguration

Die Tabelle ist ein Überblick. Konkrete Plattform, Release, Ports, Secrets, ZTP und Rollback folgen immer der jeweiligen Produktdokumentation.

17. Schritt 12A – Switch-Pfad

Claim/Adopt→Site→Manage?→Template→Commit→Wired SLE

Standard-Junos und unterstütztes Modell
Greenfield-ZTP oder Brownfield-Backup
Configuration Management als separates Gate
Networks, Port Profiles, Rollen und Variablen
gerenderte Junos-Konfiguration und Commitstatus
Uplink, VLAN, LACP/STP, Routing und PoE
802.1X/MAB, DHCP und Testclient
Virtual-Chassis-Workflow gegebenenfalls separat

18. Schritt 12B – AP-Pfad

Claim→Site→Name/Profile→Cloud→RF/WLAN→Clienttest

AP-Modell, Country/Regulatory Domain und Subscription
PoE, LLDP, Native VLAN, DHCP, DNS und Firewall
Site, Floorplan und physische Position
WLAN-, RF- und Sitekonfiguration geprüft
Device Profile nur bei bewusstem Bedarf
2,4-/5-/6-GHz-Radios und Kanal/Power plausibel
Clientauth, DHCP, DNS und Anwendungstest
Wireless SLEs und AP Insights als Baseline

19. Schritt 12C – WAN-Edge-Pfad

Claim/Adopt→Site→WAN Template→Config→Sessions

Underlay-/Providerparameter und Managementpfad
Site dem richtigen WAN Edge Template zuweisen
nur ein WAN Edge Template pro Site
Interface-, Provider-, DHCP-/statische Variablen
Policies, Application Steering und Hub/Spoke
automatisches Rollbackverhalten des konkreten WAN-Workflows prüfen
WAN SLE, Tunnel, Sessions und Failover testen

Abgrenzung: Die in der WAN-Dokumentation beschriebenen Fünf-Minuten- und Auto-Rollback-Mechanismen dürfen nicht ungeprüft als identisches Verhalten für APs oder EX-Switches dargestellt werden.

20. Schritt 12D – Mist-Edge-Pfad

Use Case: Tunnelterminierung, Datenpfad oder Serviceintegration
Hardware/VM, Schnittstellen, VLANs und IPs
Cluster-, Node- und Sitezuordnung
Cloud- und Tunnelkommunikation freigeben
Redundanz und Split-Brain-Schutz planen
Zertifikate, Secrets und Zeitsynchronisation
Ende-zu-Ende-Tunnel und Datenverkehr testen
Upgrade- und Recoveryverfahren dokumentieren

Mist Edge wird nicht wie ein AP behandelt. Claim ist nur ein Teil; Datenpfad, Cluster und Integrationsziel benötigen eine eigene technische Abnahme.

21. Schritt 13 – Konfiguration anwenden

Ebene	Beispiel	Prüfung
Organisation	Templates und globale Standards	Zielmenge/Regeln
Site	lokale Werte und Services	Variablen/Overrides
Device Profile	AP-spezifische Gerätegruppe	Priorität und Match
Gerät	Name, Management-IP, Port oder Interface	Sonderfall begründet
Fabric/Cluster	Topologie- und Rollenobjekt	alle Knoten vorbereitet

Intent → Vererbung → Rendering → Push → Commit/Apply → Operational State

Ein Portalwert ist noch kein angewendeter Dienst. Übertragungs-, Commit- und Betriebszustand werden separat geprüft.

22. Schritt 14 – Validieren

Gate	Prüfung
Identity	MAC, Seriennummer, Modell, Name, Organisation
Assignment	Site, Profile, Template, Rolle
Connection	stabile Cloudkommunikation
Configuration	kein Push-/Commit-/Applyfehler
Physical	Strom, Link, Interfaces, Temperatur, Alarme
Network	VLAN, IP, Routing, Tunnel, DNS/NTP
Client/Service	realer Ende-zu-Ende-Test
Assurance	SLEs, Insights, Events und Baseline

Die Einbindung gilt erst nach einem gerätetypspezifischen Service-Test als erfolgreich – nicht bereits bei „Connected“.

23. Schritt 15 – Automatisierung skalieren

Methode	Nutzen	Grenze
Activation Code	Batch-Claim aus Bestellung	Ergebnisliste vollständig prüfen
Namensgenerierung	einheitliche Gerätenamen	Eindeutigkeit und Standortbezug
Templates/Variablen	skalierbarer Intent	Fehler skaliert ebenfalls
Bulk Configuration	viele gerätespezifische Werte	Schema- und Plausibilitätsprüfung
API	Integration und Idempotenz	Token, Rate Limit, Fehlerbehandlung
Auto-Provisioning	automatische Site-/Profilzuordnung	laut aktueller Doku insbesondere APs/Cellular Edge; nicht pauschal alle Geräte

Aktuelles Auto-Provisioning greift nur bei verbundenen Geräten und dokumentierten Gerätetypen. Bereits einer Site zugewiesene Geräte werden durch automatische Sitezuweisung nicht einfach umgehängt.

24. Schritt 16 – Fehler und Rollback

1. Organisation/Inventory
Falscher Tenant, bereits anderswo claimed oder falsche Identität?

2. Day 0
Power, Link, DHCP/IP, Gateway, DNS, NTP?

3. Cloudtransport
Firewall, NAT, Proxy und gerätespezifische Ziele?

4. Assignment
Unassigned, falsche Site, falsches Template/Profile?

5. Configuration
Render-, Push-, Commit- oder Applyfehler?

6. Service
VLAN, Routing, Auth, DHCP, RF, Tunnel oder Policy?

7. Rollback
gerätetypspezifische Recovery statt pauschalem Factory Reset.

Stop-Kriterium	Aktion
falsche Organisation	nicht weiter claimen; Ownership klären
Intent ungeprüft	keine Site-/Managementaktivierung
Brownfield ohne Backup/OOB	Cutover verschieben
Cloudsession instabil	Transport vor Konfiguration beheben
Serviceabnahme fehlschlägt	Go-live stoppen, kleinsten nachweisbaren Fix oder Rollback

25. Sicherheit und Governance

Organisation vor jedem Claim sichtbar bestätigen
Claim-, Activation- und Adopt-Informationen schützen
MFA/SSO und Least Privilege einsetzen
Installations- und Administrationsrollen trennen
Root-/Adminpasswörter und Secrets sicher verwalten
Cloud-Egress auf dokumentierte Ziele begrenzen
Templates und Batchaktionen nach Vier-Augen-Prinzip prüfen
API-Token minimal berechtigen und rotieren
Release, Unassign und Reassignment als Changes behandeln
Logs, PCAPs, Standort- und Clientdaten zweckgebunden verwalten

26. Schritt 17 – Betriebsübergabe

Nachweis	Inhalt
Inventory	Gerät, Seriennummer, MAC, Subscription, Site
Physical	Standort, Rack/Floorplan, Ports, Strom, Fotos
Intent	Template, Profile, Variablen, Overrides
Acceptance	Geräte-, Netzwerk-, Client- und Failovertests
Assurance	SLE-/Insights-/Metrics-Baseline
Operations	Alerts, Upgradegruppe, Runbook, Ansprechpartner
Recovery	Rollback, OOB/Console, Ersatz- und Eskalationsweg

27. Master-Runbook Step by Step

Gerätetyp, Ausgangslage, Zielzustand und Change definieren.
richtige Cloudregion, Organisation und Rollen prüfen.
Subscriptions aktivieren und Kapazität kontrollieren.
Site mit Name, Zeitzone, Standort und Gruppen vorbereiten.
Templates, Profile, Variablen und gerätespezifischen Intent reviewen.
Day-0-IP, DNS, NTP, Gateway, Firewall und Proxy bereitstellen.
Geräteidentität, Modell, Version und Ownership prüfen.
Greenfield per QR/Claim/Activation claimen oder Brownfield adoptieren.
Inventoryergebnis und Stückzahl kontrollieren.
Site, Namen, Profile und Managementoptionen bewusst zuweisen.
Cloudverbindung und korrekten Transport bestätigen.
Rendering, Push und Commit/Apply überwachen.
physische und Netzwerkfunktionen prüfen.
realen Client-/Service-Ende-zu-Ende-Test durchführen.
SLEs, Insights, Events und Metrics als Baseline erfassen.
Fehler beheben oder gerätetypspezifisch zurückrollen.
Dokumentation und Betriebsübergabe abschließen.

Häufige Fehlannahmen

Behauptung	Bewertung	Einordnung
„Claimed bedeutet einsatzbereit.“	Falsch	Site, Verbindung, Konfiguration und Abnahme fehlen möglicherweise.
„Activation Code ist nur Lizenz.“	Falsch	Er kann Subscriptions aktivieren und Geräte der Bestellung claimen.
„Primary Site ist technisch besonders.“	Falsch	Es ist nur der initiale Standardname.
„Alle Geräte onboarden identisch.“	Falsch	AP, Switch, WAN Edge und Mist Edge besitzen unterschiedliche Intent- und Recoverymodelle.
„Connected beweist den Dienst.“	Falsch	Es beweist primär Cloudkommunikation.
„Auto-Provisioning gilt für alles.“	Falsch	Der dokumentierte Scope ist gerätetyp- und funktionsabhängig.
„Ein Rollback funktioniert überall gleich.“	Falsch	Mechanismen sind produkt- und plattformspezifisch.

Merksätze

Onboarding beginnt vor dem Claim.
Die Organisation ist die Eigentumsgrenze.
Die Site gibt dem Gerät seinen betrieblichen Kontext.
Subscriptions gelten auf Organisationsebene.
Intent wird vor der Zuweisung geprüft.
Claim und Adoption lösen unterschiedliche Ausgangslagen.
Connected ist kein Ende-zu-Ende-Test.
Gerätetypen besitzen unterschiedliche Provisionierungsmodelle.
Automatisierung skaliert Standards und Fehler.
Abgeschlossen ist Onboarding erst nach Übergabe.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. Claimoptionen, Rollen, Gerätetypen, Auto-Provisioning, Cloudtransport, Subscriptions und Rollbackmechanismen können sich ändern. Für produktive Einbindungen gelten die aktuelle gerätespezifische Juniper-Dokumentation, die konkrete Mist-Cloudregion und ein freigegebener Change.