We have been moving all our Wi-Fi APs, bridges and PTP products over from the cloud to on-prem without losing any configurations. When it comes to the cnMatrix switches, what steps has everyone been taking to on-board the switch to the on-prem controller and maintain the port configurations? When I apply the switch group it wipes the port settings and when I create a template and import the switch config, it works but then is out of sync. The switch functions correctly and has all the port settings but we lose the ability to sync global changes. Looking to have help figuring out the correct process to on-board and maintain port config if possible. Thanks for your help!
I am having the same problem.
When I apply the switchgroup which will overwrite the template that was exported from Cloud the switch loses connection for a while then reverts back, which is nice. But I want in sync + template also so I can change my switch group configuration.
I’m guessing that you, like us, have configured your switches in the Cloud side using “per-device port overrides” (I’ll say PDPO for short), which is what you get when you click the “Edit Ports” link from the Configuration tab in cnMaestro.
As you’ve found, those PDPO are not actually stored as part of the Switch Profile / Switch Group (“SG”), and so they don’t get exported. (Side note: it’s confusing, but cnMaestro uses two different names for the same feature in different places. At the main “Settings” gear on the left side you see “Switch Profiles,” but within that actual page, they are called “Switch Groups”. 
)
It is possible to configure switch port settings at the Switch Group level so they do get exported… it’s just counter-intuitive how you do it. A lot of how you proceed hinges on how many switches you have in a given SG, and how many of them are “special snowflakes” that need their own config, vs. identical clones of everything else in the group.
Most of our sites have one or two different types of switches, and one is in the MDF or is the main “uplink” switch that connects to a router or a PtP link that eventually hits a router. That main switch usually has some different settings from the rest. In those cases, I find it works better to put the “main” switch into its own switch group for migration, and that way you can migrate all of its unique settings to a new SG.
When you have a site with multiple switches with similar/identical config it’s a lot easier. I start on the cloud side, and basically “convert” all of the PDPO settings into a proper SG-level port config. You do this by going into the SG, going into “Ports” on the left side. If your setup is PDPO-centric like ours has been, you’ll see the “Port Overrides” section expanded… but up above it is a collapsed “Model Configuration” section.
You need to expand “Model Configuration,” and then you may need to “Enable Ports for Models,” and select the switch types you want to use in the SG:
Make sure to scroll through this list because there are other models not displayed on one screen, and you might not want them enabled but they might be on by default (why they couldn’t dynamically size the popup to the tab/window you have open, IDK, the whole list would fit on my screen if the popup was bigger). For example, in the screenshot above, the TX2020R-P was also enabled for some reason… I shut it off. You can also delete a Model Config in the screen below by hitting the trash can next to it, but it’s easier to just not add one to begin with.
After you click Update, now you’ll have a screen with tabs across the top, one for each model of switch, and a whole extra set of port configuration settings. This works just like the Port Overrides do, but it works at the SG level. I have been manually going through and basically “copying” what I have from the “Port Overrides” section up to the “Model Configuration.”
The “nice” part is that if you have a PDPO in place for a given switch and port, whatever you do on the “Model Config” should “lose” to the PDPO. So you can setup the SG-level config, and even should be able to sync it to the switches, and nothing should actually change, because the PDPOs “win” over the Model Config. The only thing to be careful of is if you put something into the Model Config that previously was NOT Overridden for a specific switch, and then you sync, you might lose access to that switch (say something with the uplink port and what VLANs are allowed in Hybrid mode or whatever). The good part is that after 15-30 minutes of not talking to cnMaestro, the switch will auto-rollback the change and it should eventually “come back to you” through Cloud cnM, but it will reboot itself during that process so it is disruptive to end users.
I’ve been using this process this to “migrate” my PDPOs to SG level config (which does get exported). Then I make a final tweak to the SG to add the cnMaestro override URL to point the switch to my onprem server. Finally, I export the SG from Cloud, and I import it to Onprem.
When the switch shows up in the Onboarding section onprem, I set the name, Location, and then I go over to Configuration, and pick the SG that I just imported. If the switch had a static IP, you have to go down to “Advanced” below Configuration and re-set the static IP in there again as well.
Because I already “copied” all of the PDPOs down to the SG “model config” level, when I apply/sync that config, it matches what is already on the switch and nothing really changes. The PDPOs are all “gone” and the switch is reset back to the SG “model config,” but since I made the model config match what I had done as PDPOs in the past, everything is happy.
I save the Onboarding section, then go back over to Cloud and Delete the device, and wait 15-30 seconds for it to ACTUALLY disappear from Cloud, before going back to OnPrem and hitting “Approve.” (If you don’t wait long enough, when you Approve onprem it will fail and say the device is in a different controller and you basically have to delete it and redo your work at the onprem side.)
If you have a site with 4 switches of the same model all with wildly different config, then this probably won’t work as well for you. In that case, I think you would need to apply PDPO during the Onboarding process, which is not something that I have tried to do (but I believe it is possible). Alternatively, make a separate SG for each of the switches, and put all of the port config back to the SG level instead of using PDPO.
I hope all of my rambling was at least somewhat helpful. If anything doesn’t make sense feel free to ask and I’ll try to explain better. I’ve migrated 36 cnMatrix switches at this point with another 15 to go, thankfully those 15 are broken up into 3 separate SGs already with basically matching config in each group though.
Thank you for the detailed response Braden! Yes, you were exactly correct on how I had these switches set up. We only have under 10 of them at the moment and I think I will create a new Switch Group for each and setup the ports, as a lot of our switches have special setups for ports. I appreciate your reply and the guidance. Thx Aaron
I’ve only got 4 switches. I’m tempted to just remove them from cnMaestro Cloud and leave them as “unmanaged” and just configure then individually directly on the switch. Any issues with that or missing features apart from quick view monitoring?