Two Sites, One Co-Termination Date, Nine Days to Go-Live
Helio Logistics is standing up a second distribution center. The bill of materials is one MX68 with a second MX68 arriving next month as a warm spare, three MS120-8 switches, six MR36 access points, and a five-year Enterprise license per device, all bought on one order. Site one went live eight months ago with individually configured hardware and no template; it has since drifted from what the team intended, and support calls there are frequent. Go-live is in nine days and the VAR needs to claim and pre-stage the hardware before the circuit is installed, because the carrier lead time is unpredictable. The organization's current co-termination date is 14 months away. The IT team has one part-time network person and no formal change-management process.
1. How do you get the hardware into the organization and pre-staged before the circuit exists, and what problem does the five-year license create on day one?
Read the worked answer
Claiming is easy and does not require the devices to be online: claim by order number or by serial from Organization > Inventory, then create the network and assign the devices. Pre-staging works because Meraki configuration is cloud-side - devices pull their config when they first reach the internet. The one thing you cannot pre-stage is what the device learns from the link itself, so document the WAN addressing assumption and confirm it against the carrier handoff before the install appointment.
The licensing problem is the real question. Meraki licensing is co-terminated: adding a five-year license to an organization whose co-term date is 14 months out does not extend each device by five years. It pools the value and pushes the entire organization's co-termination date forward, which means you have effectively pre-paid for a long tail and your renewal date is now far away and lumpy. Two defensible responses:
- Accept it, and record the new co-term date as a known financial fact with a renewal calendar entry.
- Buy licenses sized in days to land on the existing co-term date, then renew everything together on a clean cycle.
Either is fine. What is not fine is discovering the co-term shift after the PO is cut. Check the projected date in Organization > License info before claiming.
2. Should the new site be built from a template derived from site one, built from scratch as a template, or configured individually like site one? Justify the call given the staffing and timeline.
Read the worked answer
Build the new site as a template, and do not derive it from site one without auditing site one first.
Deriving a template from a drifted network imports the drift as the standard. You would be automating the support calls. Site one is the evidence of what not to copy.
So: create a clean template capturing only the parts you are confident about - VLAN scheme, DHCP scope shape, firewall baseline, wireless SSIDs and RF profile, switch port profiles. Bind the new site to it. This costs a few hours now and pays back every time a change is needed at both sites, which for a two-site company with one part-time network person is the whole point: they cannot afford to make the same change twice, correctly, under time pressure.
Bind site one later, after a maintenance window, with a diff reviewed line by line. Do not bind it during the go-live week - you would be changing the working site and the new site in the same week with the same untested template, and if something breaks you will not know which change did it. Sequence matters as much as the decision.
3. The warm spare MX68 arrives after go-live. What has to be true for it to actually provide redundancy, and what would you do in the meantime?
Read the worked answer
A warm spare is not a spare until it is claimed, assigned as the spare for the primary MX, physically cabled in parallel (both WAN links and a LAN link), and its licensing and configuration state are correct. It also needs the same config, which is why the template decision matters - a spare that boots with drifted config is a liability, not a safety net.
Before it arrives, the honest position is that this site has a single point of failure and should be described to the business that way, not as 'redundant'. Mitigations in the interim:
- Confirm the primary MX's WAN failover behavior is configured deliberately rather than left at defaults, so a single carrier outage does not take the site down for hours.
- Make sure the part-time admin knows how to reach the local status page on site; when the cloud is unreachable, that is the only door in.
- Write down the swap procedure now, while nobody is under pressure: what to unplug, in what order, and who to call. A spare arriving without a rehearsed procedure buys you hardware and no recovery time.
When it lands, test failover during a window - pull the primary's power and verify the LAN keeps working. An untested HA pair is an assumption.