MikroTik Netinstall for Refurbishment: A Clean RouterOS Reimage Checklist

Short answer

Use Netinstall when an owned MikroTik router needs a clean RouterOS installation rather than only a configuration reset. Prepare an isolated installation segment, enter Etherboot, select packages for the device architecture, and install without preserving the former configuration. Netinstall reformats the system drive, but it does not reset RouterBOOT settings or remove the RouterOS license key.

Choose the intended end state first

Decide whether the asset should leave the bench with the standard factory configuration or an empty configuration for later provisioning. Those are different outcomes. A router with an empty configuration may offer no familiar IP management path; that does not automatically mean installation failed.

This guide applies to owner-authorized physical-device processing. Obtain permission before erasing anything. CHR virtual machines, third-party x86 installations, and unusual storage layouts need their own installation and sanitization plans.

Prepare the workstation and package set

• Record model, architecture, RouterOS version, and available recovery port.
• Download an approved Netinstall tool and matching RouterOS package set.
• Use a dedicated interface and a simple isolated Layer 2 segment.
• Prevent unrelated DHCP or BOOTP services from responding on that segment.
• Have the hardware-specific Etherboot entry sequence ready.
• Keep the power connection stable throughout the write.

Do not select packages by the appearance of the case. On the installation screen, verify that the discovered device is the intended asset. When several routers are waiting on a bench, connect only the one being processed.

Enter Etherboot and configure installation

Use the designated Ethernet recovery port and enter Etherboot with the supported button or console procedure. If detection fails, work through the separate Etherboot troubleshooting checklist before changing packages or repeating resets.

In the Windows tool, leave Keep Old Configuration unselected for clean-state processing. Review any configure script and branding options. A custom default script can persist and run after later resets, so a supposedly clean baseline should not inherit an unknown provisioning script.

Select the expected architecture packages, start installation, and wait for completion. Reboot as instructed by the tool and device. Some platforms require a manual reboot after installation; do not interrupt an active write to force one.

Verification note: a completed install is only the first checkpoint

Require normal boot, the intended RouterOS version, and the selected configuration baseline.

Use read-only inventory commands after authorized login:

/system resource print
/system package print
/system routerboard print
/file print

Inspect files and any attached storage separately. A system-drive reformat does not establish certified sanitization of every external device or storage area. Record RouterBOOT state independently instead of expecting the firmware recovery to reset it.

Pass, hold, and retry decisions

Result	Disposition
Expected version and clean baseline	Continue hardware grading
Previous users or provisioning return	Review preservation options and scripts
No IP access with empty configuration	Check intended management method
Repeated write or boot errors	Hold for storage or hardware diagnosis

After grading, record whether any temporary bench configuration remains. Do not ship undocumented users, routes, or management services created during testing.

CliDeck Workspace can capture the console startup and checklist. Attach the package versions, selected installation options, and final verification result to the private asset record so another operator can distinguish a reimage from a simple reset.

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.

Who this is for

This guide is for ITAD teams, refurbishment teams, network engineers, and operations teams who need to perform an owner-authorized reset, recovery, verification, or documented device-processing workflow on network devices that your team owns or is authorized to process.

When to use this

Use this guide when:

• Your team owns or is authorized to process the device.
• You need to reset, zeroize, recover, reimage, verify, or document a network device.
• The result must be attached to an asset, resale, reuse, refurbishment, or recycling workflow.

When not to use this

Do not use this guide when:

• You do not own or have authorization to work on the device.
• The device is outside your approved change, recovery, or processing scope.
• The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
• You need a certified data destruction procedure and your organization has not provided one.

Workflow

• Confirm ownership, processing scope, device identity, and approved procedure.
• Connect through the console or approved management path and capture the session context.
• Run the reset, zeroize, recovery, reimage, or verification steps required by the article and vendor documentation.
• Reboot or reconnect as needed and verify the expected clean, default, or recovered state.
• Attach logs, verification output, exceptions, and final pass/fail/exception status to the asset record.

Verification checklist

• Device identity matches the asset record.
• Console or session log is attached to the asset.
• The reset, zeroize, recovery, or reimage method is recorded.
• The post-reboot state matches the expected clean or recovered state.
• Verification commands and outputs are captured.
• Exceptions or failures are quarantined instead of marked ready.

Resale and evidence checklist

Before marking the device ready for resale, capture:

• Device model and serial number
• Console transcript or session log
• Reset, zeroize, reimage, or recovery method used
• Any confirmation prompts and operator decisions
• Post-reboot state
• Visible default or clean-state prompt
• Verification commands and outputs
• Hardware alarms or boot errors
• License, entitlement, or customer identifiers handled according to policy
• Exceptions, failures, or quarantine decisions
• Final pass/fail/exception status attached to the asset record

What not to publish

Do not publish raw transcripts that include customer names, public IP addresses, VPN settings, license keys, entitlement IDs, serial numbers that must remain private, passwords, tokens, certificates, or other sensitive identifiers. Keep sensitive evidence in the customer-approved internal system and publish only sanitized examples.

Common mistakes

• Processing a device without owner authorization or the correct asset record.
• Treating a factory reset as certified data destruction.
• Failing to capture confirmation prompts, reboot state, verification output, or exceptions.
• Publishing raw logs that contain customer identifiers, licenses, keys, passwords, or configuration remnants.

CliDeck workflow fit

CliDeck can help turn this procedure into a repeatable workflow. Console Server Go is useful for portable rack-side console access and shared remote support. Net Controller is better for ITAD, refurbishment, and batch processing where multiple devices need barcode tracking, approved scripts, logs, API updates, and evidence-style results.

Net Controller can help operators connect devices, scan assets, run approved workflows, capture console logs, require verification steps, and attach the result to the asset record.

FAQ

Is this a certified data destruction procedure?

No. This article describes a practical, owner-authorized workflow and verification approach. Certification depends on your organization’s process, evidence requirements, customer contract, and any formal certification program that applies.

Does CliDeck provide vendor OS images?

No. CliDeck does not distribute vendor operating system images. Recovery or reimage workflows can use images already present on the device or images provided by the customer where the customer has appropriate rights and licenses.

Should I publish the full console log?

Usually no. Keep complete evidence in the approved internal system and publish only sanitized examples. Console logs can contain serial numbers, license details, customer names, IP addresses, keys, passwords, or configuration remnants.

Can CliDeck help with this workflow?

Yes. Console Server Go helps with portable rack-side console access and shared remote support. Net Controller is better for batch ITAD, refurbishment, recovery, provisioning, barcode/API tracking, and evidence-style results.

Related guides

• MikroTik Not Detected by Netinstall: An Etherboot Troubleshooting Checklist - When Netinstall does not detect an owned MikroTik device, separate boot-mode entry from network discovery.
• MikroTik Backups, Exports, and Files Before Resale: What a Reset Leaves to Review - Treat a MikroTik binary backup, text export, diagnostic file, and active configuration as different artifacts.
• MikroTik supout.rif Before Wipe: Diagnostic Evidence Without a False Clean-State Claim - Create supout.rif before reset only when the owner authorizes diagnostic preservation.
• MikroTik Reset Configuration vs Netinstall: Which Path Fits Resale Preparation? - Choose a RouterOS configuration reset when the operating system is healthy and the approved task is to replace configuration.
• Aruba Instant AP Factory Reset: Isolate the Device and Verify the Fresh Baseline - For an owned Aruba Instant AOS-8 access point, use the supported factory-reset procedure for the exact model and software.