Is posibble to Factory Reset a provisioned AP (cnPilot) from cnMaestro on Premises?

Hi!

I have some APs provisioned in a "cnMaestro-on Premises-1" VM, and I want to move them to another new VM, lest's call it "cnMaestro-on Premises-2". Both VMs are in Cloud and have a Public Ip Address.

It should be as easy as "delete from 1" and "Onboard in 2". The problem is that the APs were forced to connect to the IP-Address-1 (it was necessary when provisioned so they could locate the Controller). So, when I try to remove them from Controller-1, they appear again as "Approval Pending" in a few seconds.

They have set in their CONFIGURATION--> MANAGEMENT page the cnMaestro Remote URL.

The APs are installed on site (on a pole) and I can't make a Factory restore phusically. Is there any possibility to send a Factory Restore command to a provisioned AP, so it loses the configuration that forces to connect to the VM-1? Any other ideas?

Here is the  config file:

!
management cambium-remote
management http
management cambium-remote url https://IP-cnMaestro-1
management http port 80
management cambium-remote validate-server-cert
management https

Thanks in advance!

There are two way we can achieve this, 

Either by changing the IP address of cnMaestro to "second" in the AP. 

 

!
management cambium-remote
management http
management cambium-remote url https://IP-cnMaestro-2
management http port 80
management cambium-remote validate-server-cert
management https

 

or 

Access the AP configuration Page on cnMaestro controller and scroll down to "factory Reset" 

attaching the screenshot for your reference. 

Hi,

Thanks a lot for the fast answer.

The problem is I cannot find the "Factory Restore Button in my cnMaestro 2.2.0-r60. Find atacched a snapshot:

Can I Upload a configuration file to an AP using cnMaestro? Take into account that I cannot connect locally using HTTPS, I only can access the APs using the curren cnMaestro controller.

Thanks in advance.

This configuration can be pushed from current cnMaestro using "User-Defined Overrides" option in AP group.  

Please find the format for the same below 

 

!

 management cambium-remote url  ${URL="https://IP-cnMaestro-2/"}

!

rest of the configuration can be added as needed. 

Thanks again.

I a realizing that maybe this is not working because there is a problem with the Sync... Any clue? Find the screeshots below

Captura de pantalla 2019-10-17 a las 12.21.43.pngCaptura de pantalla 2019-10-17 a las 12.21.49.png

this could be some issue in the configuration. Can you please delete the AP from the onboarding queue. 

Please share the user-override option being pushed, i'll have a look at it. 

Hi,

The user-override section is empty, and the error stil persists. 

I delete the AP from the APs page and from the Onboardign page, but as the AP has the cnMaestro remote IP configured manually, after a few minutes it appears again in the Onboarding page, pending to be approved. And when I select "Approve", it says "Onboarded with errors".

I'm into a strange loop... :(

Extra Note: The error while onboarding happens when I select an AP Group for the AP and I "Approve" it.

If I approve the AP without selecting any AP Group, there is no error.

I have tried with many AP groups, with any special configuration, including the "Defaul Enterprise" group.

Hi again.

I have created another group from zero, eliminated almost all option (no radio, no snmp, no name... nothing, almost empty) and the AP accepts it, so I have been able to add the Override command so the AP points to the new Controller.

I don´t know why the AP was not accepting Ap Group configurations that where working in another APs. Strange.

Anyway, you can consider this solved, as I finally get to move the AP to another controller. Thanks for your help.

(It's a pitty the button of "Factory Restore" does not appear now in the AP --> Configuration section, it was useful.)

Hello,

For others reading this and getting the same error.  The "key not in the table" error exists with certain versions of cnPilot Enterprise firmware.  This was fixed in version 3.11.2.  If you're getting this error, please upgrade to 3.11.2 or later.