Tips4Tiks – Fleet Commander Best Practices

Fleet Commander Tips

Fleet Commander has been my favorite RemoteWinBox/Admiral feature since we released it back a few years ago! While I’m sure there are many people that use it regularly and have their processes down, I wanted to share some of the useful tips and tricks that I use to maximize the benefits of Fleet Commander.

Always run the command on one router first!

Unless I’m doing a print statement that I’ve executed a number of times, I always follow the same approach. I run my command on one test router. If that runs as expected, I’ll run it on one production router, then five, then a dozen. If all of those runs look good, I’ll run it on the whole network.

I follow the same practice when doing firmware updates!

Use the `execute` statement to skip interaction on certain commands

We’ve received a few support tickets in the past couple of months asking why doesn’t reboot work from Fleet Commander, or how to reboot multiple MikroTiks through the Admiral dashboard without having to click into each router and hit the Reboot button.

While I wouldn’t recommend mass rebooting routers, there is definitely a way to do it! Fleet Commander is a powerful tool, however, it doesn’t know how to expect a prompt and respond to it. This occurs in a few instances, `/system reboot` and `/system routerboard upgrade` come to mind. An easy workaround is to run an `execute` command instead of writing a desired script directly into your Fleet Commander:

Make your scripts (more) bulletproof

Sometimes I like to run multiple commands in a single Fleet Commander job, since my job is then done faster. The issue that I ran into in the past is “What to do if one of the commands errors out?”. If one of the commands throws an error, all of the rest will not execute. Commands before the error will run and all those after the error will fail (including the error command).

Even with Fleet Commander logs, it’s tedious work noting down which routers a command failed on. I thought, why not write the commands in a way where they don’t crash the script?

One of the ways to do this is to use the `do` statement. A good idea is to also print out a meaningful log, whether that’s a print statement or a note.

Another way of doing it (in some cases) is by using `find`, which I will also show in the example. However, this method only works in cases where a certain item could be missing out of the config – it does not work for any other type of error. It’s a much cleaner way of doing things compared to `do` statements, but a lot less powerful when it comes to error-handling and logging.

Below are 3 examples of scripts that all accomplish the same work:

1. add an ip address 10.10.10.10 attached to ether3
2. remove a user named “test123”
3. disable a wlan2 wireless interface
4. and set the DNS to 1.1.1.1. 

Let’s assume that the user “test123” exists on 80% of the routers. Let’s also assume that about 90% of the routers have both interfaces wlan1 and wlan2, but 10% of them only have wlan1 (so wlan2 doesn’t exist on those).

Case 1. is just a simple script that expects the “in a perfect world” scenario.

Case 2. is a script that utilizes `do` functionality.

Case 3. is a script that utilizes `find` functionality. 

Case 1.

/ip address add address=10.10.10.10 interface=ether3;

/user remove test123;

/interface wireless disable wlan2;

/ip dns set servers=1.1.1.1;

Case 2.

do command={/ip address add address=10.10.10.10 interface=ether3;} on-error={:put “Error adding an address”};

do command={/user remove test123;} on-error={:put “There is no user test123”};

do command={/interface wireless disable wlan2;} on-error={:put (“Routerboard is $([/system routerboard get board-name;]) and it does not have wlan2”)};

do command={/ip dns set servers=1.1.1.1;} on-error={:put “Error setting dns servers”};

Case 3.

/ip address add address=10.10.10.10 interface=ether3;

/user remove [find name=”test123”];

/interface wireless disable [find where name=”wlan2”];

/ip dns set servers=1.1.1.1;

In Case 1. You would have 20% of routers fail to execute anything other than the `/ip address add` due to “no such item” error on the `/user remove`. 10% of the routers would not get their dns servers set due to “no such item” error on the `/interface wireless disable` command.

Case 2. and Case 3. would both execute properly, however, there are a few things to notice.

One pro of Case 3. is that it’s much cleaner and easier to read. Unfortunately, that comes with a few cons. One of them is that there aren’t any logs in Case 3. that you could see in your Fleet Commander logs compared to Case 2.

In Case 2. You would get meaningful error messages on failed commands, AND your commands would execute all the way through. If you take a look at the `/interface wireless disable` command in Case 2. you’ll notice that we can even print in our log what type of routerboard it is. It may show that it’s a hAP lite, and everything is in order, or it may say it’s a hAP ac^2, and now you’ll be able to tell that you may have a one-off configuration on that particular router.

It’s worth mentioning that `do` will take care of, to my knowledge, any type of errors, even some of the syntax ones (that may or may not be desirable behavior in your case), while `find` will only handle the “no such item” error.

Personally, I often use `do` and `find` combined to handle errors AND act based on a search other than the name or id of the item.

4. “But I have about 20 commands, and I don’t want to manually add 20 `do` and `on-error` statements!”

There are many tools that help reduce the time spent on re-typing or copy-pasting the same piece of text. Personally, I use Sublime to do multi-line edits, but many other tools have the same functionality.

I hope these tips help you bulletproof, as well as save time on some of the Fleet Commander tasks you deal with!