which ones did not exist?
partition, downgrade and bootloader
Those features existed previously and if you used them, they are still working. Only new configuration requires approval by button press, for remotely connected user, to protect against remote intruder.
I discovered the same issue. 7.17B2 will not provision wireless capsman controlled AC CAPs (mipsbe) access points. It shows the interfaces but shows no remote CAPs. I upgraded one CAP to 7.17B but it still does not work. Also, as you report, 7.16 capsman does not work with 7.17B2 access points.
Normis, do you want a use case? Here you go. There’s a war in my country. The equipment is located in a place where bombs are currently falling. Right now, I don’t need the notorious traffic-gen there. I updated the firmware, and suddenly I needed that very traffic-gen. I think the best solution would be to send one of the MikroTik employees (for example, you) over there to press the button or turn the power off/on. After the first nearby explosion, that employee will stop asking silly questions.
What will you be using traffic gen for, in this remote router? There is no need for theoretic, like I said
To check the quality of the connection after a bombing, for example. I’ll repeat what I’ve already written — please, don’t touch professional equipment. The industry already has the opinion about MikroTik: “Try not to update firmware — they’re bound to break something in the process.”
I think that you (Mikrotik) think wrong… There are countless devices inside company networks that are not exposed to The Internet in any way, but also not easily reachable/available for power-off or button press during day/normal working time. Some even require special permissions to enter the room at any time, not to mention more special permission and at least two people to get in during the night (I personaly have only a few, but most of my clients are not that paranoid). Luckily, I don’t have any devices left on hotel roofs, stadium light poles or similar hard to reach places, I was lucky to have them replaced with optical cables a few years ago 
To paraphrase your last sentence: I think there are beter ways to protect a device against unauthorised access, especially if it is not reachable from The Internet (btw, I don’t understand why people assume that every router will be connected to The Internet?).
So I still think that there should be a “I-know-what-I’m-doing” device mode, and YES, I would set ALL of devices I control to that without thinking a second, just as you said… Just don’t make me go push a button on every OLD device already in production.
Thank you for reading and understanding this.
Premise: if you have a 7.16 backup partition, it means that it’s there for a reason → switch over it if new doens’t work as you expect.
If you upgrade your primary part to 7.17 ..then the router boots and works but some service is misbehaving (let’s say OpenVPN is broken ..or PPPoE Server has issues..); yow want at this point switch over the backup partition or to downgrade.
You can’t because both are now blocked by this new lock in 7.17. The device is remote (maybe you have plenty of them) and you have to go there and push the bloody button?
If you don’t understand it, please have some rest (ehi, it’s friday) and think again about it on monday. 
I do understand these theoretical situations. There are several types of posts here:
- People who want to know what exactly will happen, and who have not yet read the previous posts. I try to answer them.
- People who have theoretical “what if …” concerns for highly improbable scenarios. Sure, they are true, but how critical is this really in real life.
- People with very specific use cases that MikroTik did not imagine before.
I am trying to help the first people and to better understand the other two. If you post your specific use cases, we can understand it better and try and find other kind of solutions to the original security issues.
Instead of talking about the consequences of new device-mode settings in 7.17.
Mikrotik, dear Normis: could you disclose your reasons for applying the changes?
!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
A reason for each one. Why bootloader? Why downgrade? Why active partitions? How did you come up with this decision/change? Was there a specific finding or incident?
Maybe acceptance is growing - at least a little - when people know the reasons for this drastic changes.
You don’t need to “understand” or “explain”, you simply just need to set a timer on 7.17 .. after a week the system is running it will enforce the new policy ..during the first week (grace), admins are allowed to (re-)enable the “partition, downgrade and bootloader” functions.
It’s fair: you introduce a new policy, let users the possibility to adapt. Otherwise you HAVE TO give the users a way to prepare BEFORE (a special procedure to proprly set those parameters beforehand).
People who did not read changelog will be shocked in 8 days then
People that manage many devices and remote ones ..they will read, those that don’t plan their work are not interested in this topic (IMHO).
I think MikroTik will achieve the opposite result. Now everyone will enable everything right from the initial setup stage because that’s easier than thinking, “Will I need this or not, and will I have to climb onto the roof in the middle of the night?” Well done.
Sure .. but you can’t enable NOW for future version/policy. So double damage, they enable all features and those who need them can’t do that
I see that people are giving very specific situations from real life, there is nothing “theoretical” here: devices that are not easily accessible, on which they WANT to enable downgrade or other features they already had before (for whatever reason, my is that I want to be sure that I’ll be able to downgrade in case some problem appears days or weeks after an upgrade, in spite all the testing I did in advance - would not be the first time I need this!).
Then again, why would YOU care what how I want to manage MY devices? I actually think that all this “device mode” stuff was totally unnecessary from the beginning and never used it (of course, I read all the docs about it when first heard about it and found that I don’t need it for my usage patterns). I was OK with “enterprise” mode because it did not limit my access to MY devices. I am NOT OK with “advanced” mode which is limiting me. I don’t want to spend more $ than the equipment is worth to go out there and visit every device just to press a button, also don’t want to buy/test/install/maintain more hardware just to be able to power cycle remote devices…
@normis - you still don’t get it and redirecting the discussion in a nonsense area. Now it looks like you’re the father of this new device-mode and will keep defend it till the death. Many examples above gave us a full spectrum of real life situations where your idea is wrong. Don’t be such arrogant and think it over before your next response…
And this is the problem. There are plenty of us who manually switch between them for various reasons. In particular, the newly loaded version may “work” just fine, but have enough bugs in it that we don’t want to stay on that version. I want to be able to manually switch back to my backup version if the new version under test has OSPF/BGP/ISIS/L3HW stability issues, for example.
How about when device is both physically inaccessible and situated in a really complicated location?
We have cases where Mikrotik devices are installed inside the appliances and only way to access them is (partial) disassembly of appliance itself. One example was Mikrotik device providing connection to our IoT “mothership” and it was a part of a smoking oven… which ended up at EXPO in Dubai. I wouldn’t evem mind to make a trip from northern part of Europe to see things over there, but I am not sure who would be interested in paying for that trip…