Das Wichtigste in Kürze
- Ein an ein Template gebundenes Netz wird zum „Kind“ dieses Templates und übernimmt dessen Konfiguration. Änderungen für alle gebundenen Netze müssen am Template erfolgen, nicht am einzelnen Standort.
- Ausnahmen je Standort sind vorgesehen — aber nicht jede Einstellung lässt sich an einem gebundenen Netz ändern. Welche das sind, hängt an der Produktlinie und gehört vor den Rollout geklärt.
- Das Claiming per Meraki-Bestellnummer ist abgekündigt. Gearbeitet wird mit dem Order Claim Key aus den Product-Claim-Mails — und sobald ein Teil einer Bestellung einzeln eingelöst wurde, lässt sich die Bestellung nicht mehr als Ganzes einlösen.
- Die Grenzen der Organisation stehen fest: 50.000 Geräte je Organisation, 5.000 je Netz. Wer darüber hinauswächst, plant über mehrere Organisationen.
Der Reiz von Meraki im Filialbetrieb ist schnell erzählt: ein Dashboard, ein Standard, ein Karton, den vor Ort jemand einsteckt. Das stimmt auch — aber nur, wenn die Struktur davor stimmt. Die Entscheidungen, die einen Rollout tragen oder teuer machen, fallen alle vor dem ersten Standort.
Was ein Template ist — und was es mit einem Netz macht
Ein Configuration Template ist ein Netz, dessen Konfiguration andere Netze erben. Meraki beschreibt das direkt: Wird ein Netz an ein Template gebunden, wird es zum „Kind“ dieses Templates und erbt dessen Konfigurationseinstellungen. Was am einzelnen Standort vorher eingestellt war, ist damit nicht mehr das, was der Standort fährt.
Ausnahmen: vorgesehen, aber nicht überall
Standorte innerhalb eines Templates können Ausnahmen von der Konfiguration haben; Geräte, die anders behandelt werden müssen, lassen sich entsprechend einbinden. Die Einschränkung steht daneben und ist die wichtigere: Nicht alle Einstellungen lassen sich an einem gebundenen Netz ändern. Welche das im konkreten Fall sind, hängt an der Produktlinie — MX, MS, MR und MG bringen jeweils eigene Template-Regeln mit.
Ein Template je Standorttyp, nicht je Standort
Templates lohnen sich, wo viele Standorte ein gemeinsames Netzdesign teilen — Filialketten sind der Musterfall. Meraki formuliert die Empfehlung ungewöhnlich deutlich: Templates sollten bei Rollouts immer eine primäre Überlegung sein, weil sie viel Zeit sparen und viele mögliche Fehler vermeiden.
Die praktische Frage ist deshalb nicht ob, sondern wie viele. Die Antwort ergibt sich aus den Standorttypen, nicht aus der Standortzahl: Eine Filiale mit einer Leitung, eine Filiale mit zwei, ein Lager, die Zentrale — das sind vier Typen, nicht vierzig Standorte. Für den identischen Aufbau vieler Netze nennt Meraki zusätzlich das Klonen: erst ein „golden configuration network“ bauen, dann daraus klonen.
- Tags sind das Ordnungsmittel, nicht der Netzname: Meraki beschreibt Tagging als Weg, Geräte, Netze oder Ports für bestimmte Zwecke zu gruppieren — Beispiele reichen von Ortsangaben wie „1stFloor“ bis zu Montageangaben wie „CeilingMount“.
- Ein Namensschema vor dem ersten Netz festlegen. Es steht später in jedem Alert, jedem Report und jeder Suche. Nachträglich umzubenennen ist möglich und trotzdem lästig.
- Ausnahmen benennen statt sammeln. Jede Abweichung, die niemand aufgeschrieben hat, ist beim nächsten Template-Change eine Überraschung.
Claiming: der Schritt, bei dem sich die Wege trennen
Geräte kommen über das Claiming in die Organisation. Einzeln geht das über die zwölfstellige Seriennummer (Cloud ID), in Menge über den Order Claim Key. Wichtig für alle, die ältere Anleitungen im Kopf oder im Wiki haben: Das Claiming über die Meraki-Bestellnummer ist abgekündigt. Meraki verweist ausdrücklich auf den Order Claim Key aus den Product-Claim-Mails.
Wo die Organisation an ihre Grenzen kommt
| Grenze | Wert |
|---|---|
| Geräte je Organisation | 50.000 |
| Geräte je Netz (standalone und combined) | 5.000 |
Für die allermeisten Filialnetze sind das keine relevanten Zahlen. Sie werden relevant, wenn ein Konzern die Grenze absehbar reißt: Meraki empfiehlt dann ausdrücklich, mit dem Account-Team eine Strategie über mehrere Organisationen zu entwerfen. Das ist eine Architekturentscheidung, keine Konfigurationsfrage — und sie fällt am besten, bevor die erste Organisation voll ist.
Die Reihenfolge, die trägt
Standorttypen schneiden
Nicht die Standorte zählen, sondern die Bauformen. Je Typ ein Template — und für jeden Typ die Frage beantworten, welche Einstellungen lokal abweichen dürfen.
Namen und Tags festlegen
Vor dem ersten Netz, nicht nach dem zehnten. Beides steht später in jedem Alert und jedem Report.
Bestellungen sauber einlösen
Order Claim Key für die ganze Bestellung, bevor irgendjemand ein Einzelgerät herauslöst. Danach ist der Sammelweg zu.
Einen Standort pilotieren und messen
Ein Typ, ein echter Standort, ein gemessenes Ergebnis — erst danach in Wellen. Der Pilot ist der Ort, an dem sich Template-Fehler billig zeigen.
Abweichungen protokollieren, nicht dulden
Jede lokale Ausnahme bekommt eine Zeile mit Grund. Was nicht aufgeschrieben ist, fällt beim nächsten Template-Change auf.
Wie wir Standards, Pilot und Wellen-Rollout in Meraki-Projekten führen, steht unter Cisco Meraki. Welches Lizenzmodell dazu passt und warum diese Entscheidung an den Anfang gehört, behandelt der Beitrag zu den Meraki-Lizenzmodellen.
Quellen
Jede belegte Aussage dieses Beitrags ist hier nachvollziehbar. Das Abrufdatum sagt, wie frisch die Prüfung ist.
- Managing Multiple Networks with Configuration Templatesöffnet in neuem Tab
Cisco Meraki Documentation · abgerufen am 26. August 2026
- Using the Organization Inventoryöffnet in neuem Tab
Cisco Meraki Documentation · abgerufen am 26. August 2026
- Building a Scalable Meraki Solutionöffnet in neuem Tab
Cisco Meraki Documentation · abgerufen am 26. August 2026