Bulk onboarding over WinBox: bringing the devices SSH can't reach into management

Ask an ISP how many MikroTik devices they have in the field and you'll get a number. Ask how many are under centralized management, and the number shrinks. The gap isn't neglect. It's the devices installed years ago, at end-customer sites, where SSH was never turned on or was closed off at some point, and today answer only to WinBox.

These devices work. They cause no problems, until they do. And when they do, there's no configuration backup, nobody knows which RouterOS version they're running, and troubleshooting means connecting to each one by hand.

The cost of that gap

Onboarding a device the manual way means opening WinBox, authenticating, running the onboarding script, checking the result, moving to the next one. Five minutes per device on a good day. Over two hundred devices, that's more than two working days of a technician who could be doing something else. On a larger fleet, the math stops working entirely: the project gets postponed, and the devices stay off the platform.

The paradox is that automation has existed for years, but it assumes SSH. Every provisioning tool, ours included, opens an SSH session and works from there. No SSH, no automation, and you're back to doing it by hand.

WinBox is not just a GUI

Port 8291, the WinBox port, doesn't only serve the graphical interface. It also exposes a full RouterOS terminal session, the same one you get from "New Terminal" inside WinBox, encrypted, with its own authentication.

That changes the problem. If you can run commands over that port, then any device reachable over WinBox is a device you can automate. You don't need to enable SSH first, and you don't need someone on site to do it by hand.

How it works in practice

You upload a CSV with the list of devices: address, credentials, and a name if you have one — if you don't, it's read straight from the device's own system identity.

From there, the system does three things per row, in parallel:

It picks the channel on its own. It tries SSH first. If SSH doesn't answer, it falls back to WinBox. Nobody has to decide device by device, and the report shows which channel was used for each one. If you already know a device has SSH closed, you can flag it in the CSV so the useless attempt is skipped entirely — on large fleets, where SSH is often filtered rather than closed outright, that wasted attempt costs a timeout per device.

It checks before writing anything. It reads identity, version and device-mode for every device and tells you upfront which ones are onboardable and which aren't. This matters because there's a category of devices where onboarding simply isn't possible by design: those running in home device-mode have fetch and scheduler disabled, and re-enabling them requires physical access to the device. There's no remote workaround, on any channel. Better to know that before the campaign starts than to discover it halfway through.

It runs the job and reports back. It creates the device on the platform, fetches the onboarding script, and runs it on the device. If something fails, the message tells you exactly what went wrong on that specific device, so you can retry just that one.

RouterOS 6 and 7

Real-world fleets aren't uniform. Alongside recent devices there are always ones installed years ago, still on RouterOS 6, that nobody has upgraded because they work fine.

Between the two major versions, things that matter change: the slash-based command syntax doesn't exist on 6, the terminal behaves differently, and some menus available on 7 aren't there at all. These are differences you only find by testing against real devices. Support for 6.x has been verified on RouterOS 6.49, not assumed from the documentation.

Credentials stay where they are

One detail matters more than it looks: the tool runs inside the network of whoever is using it, as a container on the technician's own machine.

That's not only about reachability, though end-customer devices are often only reachable from there. It's also why device credentials never leave that network: they stay in the container, encrypted, and are never uploaded to the platform. On a fleet made up of third-party customers' equipment, the difference between "I keep the credentials" and "I upload them to a service" is not a technicality.

If something goes wrong

Every onboarding is reversible. The tool knows how to undo what it wrote: it removes the objects it created from the router, restores services to how they were, and deletes the device from the platform.

Before touching anything, it shows you the exact list of what it would remove, device by device, and only acts after you confirm. This isn't a box-ticking safeguard: it removes only the objects it recognizes as its own, never by wiping indiscriminately, because on a production device guessing means erasing the customer's configuration.

What actually changes

This isn't a feature that does something new. It's a feature that removes an assumption: that automating a MikroTik device requires SSH.

The practical result is that "let's bring the legacy fleet under management" stops being a quote for days of technician time and becomes a CSV you upload.