How to downgrade V20 to V18

[lazuruz]

Have a V20 that needs to be downgraded to V18 as a absolutely astonishing amount of issues have popped up.

Hosted at 3CX.

Thanks

Austin

 

[Charles_3CX]

Please be advised that there is no downgrade path with 3cx hosted instances. If you would like to post your issues a few at a time, we could try to work through them and also provide other community members with some useful information.

 

[UAC]

The v20 issues we're having are seriously bad... We upgraded our version of Debian and it switched us to v20

 

[Charles_3CX]

When you say seriously bad, can you let us know what is not working for you?

 

[SteveITS]

Are both of you on the release candidate 3 version released this week?

 

[lazuruz]

@UAC im glad im not the only one having issues.

@Charles_3CX I think you guys should rethink this stance on patches/updates. It almost guarantee's I will update very seldomly in the future. User complaints are 30x for various problems over v18. Half of them are intermittent so its hard to find the exact issue.

@SteveITS no I am not. Minus well at this point. You guys really need a downgrade path.

 

[SteveITS]

OK well RC3 added several missing features: https://www.3cx.com/blog/releases/v20-release-candidate-3/

And it's not "me" as I don't work for 3CX. We haven't upgraded any of our clients yet.

The problem with not updating at all, is the scenario like last summer where only 18 u8b or later would activate. Users on u7 or earlier got stuck if their license expired, because they could no longer upgrade, or renew.

 

[UAC]

When you say seriously bad, can you let us know what is not working for you?

It appears when our failover is active, the Call Flows we had and later the digital receptionists, intermittently failed to transfers calls. That resulted in our customers not being able to contact us. Shutting down the failover server seemed to correct the problem. Later we were able to manipulate our local DNS so we could login to the "passive" server and discovered that both were in an "active" state. Manually helping the failover server go into the passive state seemed to correct the problem, but I haven't had a chance to test if the failover process still works at all in v20.

We only discovered this issue because in attempts to fix the problem, we switched from using Call Flows Apps to the Digital Receptionist and we heard recordings old recordings on a server that did not match the dashboard's IP address. Apparently our phones were connecting to the wrong server.

None of the troubled calls were showing in the Call Log. Today, we have no idea if calls come in and an issue occurs unless someone is constantly testing the lines or emailing the office to indicate a problem. Being able to see every incoming call is something that we need. People are claiming they called and I can't easily see if that actually happened.

The Activity Log was an extremely helpful tool and it appears that is gone in v20. Besides easily having access to great debugging information in v18, you could browse individual log files and download what you needed. Downloading a support file, unzipping it, and going through the files is clunky and not something we can quickly review. The logging features in v18 were far easier to use and offered clear snapshots of how things were running, where v20 is lacking the polish and tools of previous versions.

We've trusted the upgrade process 3CX has had in the past and unfortunately we upgraded our debian version which came with v20. If we knew how early it was in development, I think we would have held off much longer.

 

[SteveITS]

The Activity Log was an extremely helpful tool and it appears that is gone in v20

I’ve used that log several times this week diagnosing various issues.Change to Medium, replicate, done (change back).

 

[SteveITS]

we upgraded our debian version which came with v20

Q on this because I’ve seen it a couple times recently I think…are you running updates at the command line? If so, 3CX has a note explaining the update to v20 and Debian in the console. In the console manual updates to 3CX don’t install OS security updates. Command line updates may install updates 3CX hasn’t tested so are not recommended. The “correct” approach to control updates is to change 3CX to automatic, and change back again after.

 

[UAC]

Q on this because I’ve seen it a couple times recently I think…are you running updates at the command line? If so, 3CX has a note explaining the update to v20 and Debian in the console. In the console manual updates to 3CX don’t install OS security updates. Command line updates may install updates 3CX hasn’t tested so are not recommended. The “correct” approach to control updates is to change 3CX to automatic, and change back again after.

We ran the update from the link in the v18 web dashboard. We noticed it didn't trigger an update for the passive server, so we did have to run that after the active server completed. It did say in the web console that it was going to include v20 and to my own fault, I didn't really look into any issues about it. I figured I had let it sit long enough to work out any issues... I never install the alpha releases and generally I haven't had any serious issues until this pre-RC3 release. I'm going to hold off updating baring any major security issues until v20 matures a little.

I'm not saying v20 is a failure or anything close. It's still the same 3CX product that many of us love, but it's not entirely ready for prime time. v18 had issues, like a separate semi-disconnected admin area under the webclient, but it was pretty solid and trouble free for me.