M4300-48x failed switch replacement

Hmm, interesting to read an update if you can share what actually whent wrong and what was the outcome / end result.

I have extended stacks online, but I have at first once been bitten quite hard which ended up in a big fat warning in our internal deployment guidelines for new switches: If no stack priority is defined and a failover happens, you may not exactly know who is going to take over. Since then our configurations always contain a defined stack priority for all members of a stack (switch priority command) and also who is pre-selected as standby master (using the standby command).

What happened is (likely) back then, is that we had a switch that was operating for at least 1y before a second member was bought and added to this stack. It had a much newer production date and thus higher MAC address. This new switch erroneously took over the role of the stack stack master. Since it had no configuration copied from the master (yet), all ports ended up unconfigured by and not management IP was set, so the stack was basically down. We had to power down the secondary unit, reboot the original stack member, set the its stack priority to 15 and then the new switch was able to join the stack without becoming the stack master.

If no priorities are defined, I guess that similar to the M5300 the M4300 will use their MAC address to decide the election of who becomes the new stack master, as explained here: https://kb.netgear.com/21879/What-is-a-stack-master-and-how-does-it-work-with-my-managed-switch