Connect. Secure. Manage.
Meraki Configuration Recovery
Recover lost or incorrect Meraki settings using available records and configuration rebuilding, with clear limits on what can be restored.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Meraki configuration recovery restores the intended settings after a bad change or failed move. We first work out what changed and which records can be trusted. Recovery then proceeds through agreed checks and controlled changes. A factory reset is not a general undo tool, and not every Dashboard setting has a saved version to restore.
Dashboard clarity
Structure organisations, networks and permissions around real operational ownership.
Consistent sites
Use repeatable standards without ignoring the differences between locations.
Practical operations
Keep cloud management connected to physical links, users and business services.
Stabilise the incident before attempting restoration
The first priority is to understand the service impact and stop further conflicting changes. We establish which sites and apps are affected, who is currently making changes and whether management access remains available. A clear incident owner helps avoid several engineers independently trying different fixes and making the original state harder to reconstruct.
We preserve relevant change records, setup information and timestamps before resetting equipment or moving it between networks. This evidence can distinguish a mistaken setting from a provider failure or hardware fault that happened at a similar time. Recovery is faster when the team works from a specific explanation rather than assuming that the latest visible change must be responsible for every symptom.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Define the state that needs to be restored
A recovery target should describe the required service, not simply an approximate date when users remember everything working. We find the affected VLANs, policies, routes, wireless settings or admin permissions and compare them with available records. Where several legitimate changes followed the last baseline, blindly restoring an old setup could remove improvements that the business still needs.
Evidence may include approved change plans, dashboard change history, API-derived records, diagrams and device-specific documentation. These sources differ in completeness. We identify gaps clearly and confirm uncertain settings with the responsible app or network owner. A setup export is only useful for restoration when its coverage and the supported method of reapplying it are understood.
A useful starting point
Tell us what is happening.
A short description of the problem is enough for an initial discussion.
Distinguish local reset from configuration recovery
A factory reset can clear local state. But a device that remains assigned may get its configured settings again when it reconnects. That behaviour is different from restoring a previous approved network design. Reset procedures also vary by platform. So we check the exact hardware and the purpose of the action before recommending it.
Removing a device or changing its network assignment may introduce extra consequences. We avoid these steps unless they are part of a supported recovery plan. The customer should know whether the proposed action addresses corrupted local state, management network access, incorrect dashboard setup or a failed hardware component. These problems can look similar to a user but require different remedies.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Reconstruct only the affected configuration where possible
A focused correction often carries less risk than rebuilding the entire network. We prepare the required settings, identify dependencies and choose an order that preserves management access. For example, restoring a trunk allowance without checking the corresponding VLAN and gateway may leave a service unavailable even though the original command has been reversed.
Where a wider rebuild is necessary, we establish a controlled baseline and document the assumptions behind it. Secrets and certificates are handled separately from ordinary records of the settings. We do not copy an old credential into a new setup simply because it appears in an archived note. Recovery should restore service without reintroducing an access problem that the business had already addressed.
Test the recovery against business symptoms
Verification begins with the original failure: the app, endpoint group or management task that stopped working. We test representative users and the forward and return traffic paths. We also check nearby services that could have been affected by the repair, because a broad policy change can solve one complaint while weakening isolation or interrupting another app.
The acceptance record separates restored functions from remaining issues. Monitoring and alerting should reflect the recovered state, and the support team should know whether any temporary workaround remains. Where production constraints prevent a particular failover or isolation test, we record that limitation instead of describing the network as fully proven from a single successful connection.
Reduce the effort required next time
After recovery, we review why the previous state was difficult to establish. Useful improvements may include clearer change descriptions, periodic setup inventories, documented exceptions and testing of the recovery process itself. Meraki dashboard change audit can help turn those findings into an operating standard rather than another unused incident document.
MCI can assist with a defined recovery incident or prepare a recovery-readiness review before a migration. The initial information we need is the affected service, approximate timeline and actions already attempted. Share sensitive setup through an agreed secure channel. We will distinguish what can be recovered from available evidence, what needs rebuilding and which dependencies require cooperation from Cisco or another service owner.
Technical references
- Resetting Meraki devices to factory defaults — Cisco / Cisco Meraki
- Cloning networks and organisations in dashboard — Cisco / Cisco Meraki
Talk to a specialist
Need a specialist view?
Tell us what is affected, what changed and what your team has already checked. A short outline is enough to start.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.