Upgrade Directly From V15.5 to V18!

[Keith Winhall_3CX]

We’ve made upgrading even easier! Administrators can now upgrade end-of-life version 15.5 instances directly to the latest V18 release.

No middle step​

Previously, when upgrading from version 15.5 to 18, admins needed to first backup and restore the configuration onto a v16 instance. Then carry out the same backup and restore ...

Continue reading the Original Blog Post.

 

[bguldibi]

Hi Mr. Keith

We are using 3cx "15.5.20000" Windows version
I have read your article and downloaded the V18 update 2 setup from the link. When I run the setup I get "Product: 3CX Phone System -- Another version of 3CX Phone System is already installed. Go to the Management Console to take a full backup and repeat the installation process."
How can I pass this error message?

Regards
Bayram

 

[NickD_3CX]

Hi Mr. Keith

We are using 3cx "15.5.20000" Windows version
I have read your article and downloaded the V18 update 2 setup from the link. When I run the setup I get "Product: 3CX Phone System -- Another version of 3CX Phone System is already installed. Go to the Management Console to take a full backup and repeat the installation process."
How can I pass this error message?

Regards
Bayram

Hi!

These are the instruction on how to upgrade from your V15.5 to V18 as you seem to have installed your 3CX on a Windows OS:
https://www.3cx.com/docs/upgrading-pbx/#h.c34e4qzgvobd

 

[GJT]

I have the same problem. But doing the process listed in the link above
https://www.3cx.com/docs/upgrading-pbx/#h.c34e4qzgvobd

does not constitute, in my opinion, as "direct upgrade from 15.5 to v18 with no middle stage"

Your blog states "Existing on-premise and private cloud installations can download 3CX v18 Update 2 on Windows and Linux on Debian 10 and benefit from a direct upgrade from 15.5 to v18 with no middle stage."

So first you state in the blog that v18 U2 on Windows can benefit from direct upgrade from 15.5 to v18 with no middle stage, yet when encountering an error you respond back that a backup, uninstall, install, and backup restore must be done for Windows version.

So basically, at the end, the Update2 is not a direct upgrade, it's a regular upgrade, and your initial blog post is absolutely useless.

 

[NickD_3CX]

I have the same problem. But doing the process listed in the link above
https://www.3cx.com/docs/upgrading-pbx/#h.c34e4qzgvobd

does not constitute, in my opinion, as "direct upgrade from 15.5 to v18 with no middle stage"

Your blog states "Existing on-premise and private cloud installations can download 3CX v18 Update 2 on Windows and Linux on Debian 10 and benefit from a direct upgrade from 15.5 to v18 with no middle stage."

So first you state in the blog that v18 U2 on Windows can benefit from direct upgrade from 15.5 to v18 with no middle stage, yet when encountering an error you respond back that a backup, uninstall, install, and backup restore must be done for Windows version.

So basically, at the end, the Update2 is not a direct upgrade, it's a regular upgrade, and your initial blog post is absolutely useless.

It is, when V16 had first come out and someone had a system that was 2 major updates behind, they needed to:

• Backup their 2 versions old update
• Uninstall
• Install the 1 version old 3CX
• Restore backup
• Backup up again
• Uninstall 1 version old 3CX
• Install V16
• Restore the backup from the 1 version old installation

Partners and users that have been using 3CX for some time know this and probably appreciate what it meant.

So, now that you know how it used to be, you can understand why we call it a "direct upgrade" and in what context.

 

[mcsphones]

It's not what Windows users might call an "in-place upgrade" but it does allow importing of the v15.5 backed up PBX file directly into v18, bypassing the need to "walk" it thru v16.

 

[NickD_3CX]

It's not what Windows users might call an "in-place upgrade" but it does allow importing of the v15.5 backed up PBX file directly into v18, bypassing the need to "walk" it thru v16.

As an extra piece of information, we are trying to find a way to make Windows installations also capable of an "in-place upgrade" removing the requirement to make a backup and then restore it onto the new version, but this will be for future Major Releases following V18.

The challenge is that on Windows, adding/removing services while at the same time maintaining data can be a bit tricky, because this must be done using an Installer and Installers don't give a lot of flexibility on what actions can be performed, because they are also restricted by Windows on some things, and at this point we need to make sure that nothing goes wrong, otherwise it could result in data loss without a good way of rolling back.

 

[mcsphones]

Nice, thanks NickD. That will be a timesaving feature for sure, understanding that Windows manipulation of files & services by an installer is pretty tough!

 

[schut]

I did an upgrade directly from V15.5 (Windows Server 2008 R2 - so latest version I could use on that OS) to the Linux/Debian 3CX ISO and noticed the following behavioural changes to the PBX System:

* Backup-schedule is not migrated to the new VM - so the new VM is not taking backups. That is easily set-up again

* Completed backups send an e-mail to the Administrator in the past, but no longer did. I had to re-activate that Notification.

* On my V15.5 on Windows 3CX would add the internal IP-address to the Contact-field of the SIP-header when using "Default Settings". On the V18 Linux that behaviour changed and the external IP-address was added, causing dropped calls - since the receiving SIP-server was trying to send ACK's to that external IP.. This I could fix in the Trunk-options, but the debugging took me the better part of a morning..

* Somehow old Forward-settings which had been used 'way in the past' for certain extensions where suddenly set to active. For example, I had an extension which, after 5 seconds of ringing would be forwarded to another ring-group. That need was removed roughly a year ago, and configured accordingly without that forward. Suddenly that forward is back on the Linux 3CX V18 despite using a very recent 1 day old backup during the installation.


All these "little" changes which can be covered deep in the configuration make me worry a bit: What else has been silently changed or not properly restored in this upgrade / migration to Linux.

Is there a list available of other quirks and oddities you found in this 'direct upgrade' path ?

 

[NickD_3CX]

Hi!

All these "little" changes which can be covered deep in the configuration make me worry a bit: What else has been silently changed or not properly restored in this upgrade / migration to Linux.

A lot has changed!

The product from December 2018 when I believe V16 was release until now, 3+ years later, has receive many fixes and improvement, so you can go through the change log to see all the changes:
https://www.3cx.com/blog/change-log/phone-system-change-log/

* Backup-schedule is not migrated to the new VM - so the new VM is not taking backups. That is easily set-up again

This is correct and expected, I believe this was always like this when restoring from a backup onto a clean install.

* Completed backups send an e-mail to the Administrator in the past, but no longer did. I had to re-activate that Notification.

This is correct and expected.

* On my V15.5 on Windows 3CX would add the internal IP-address to the Contact-field of the SIP-header when using "Default Settings". On the V18 Linux that behaviour changed and the external IP-address was added, causing dropped calls - since the receiving SIP-server was trying to send ACK's to that external IP.. This I could fix in the Trunk-options, but the debugging took me the better part of a morning..

I don't remember anything changing in this area specific to the presentation of the IP Address in the Contact header, then again over the past 3 years we have fixed many many bugs in the SIP Core. What I can say is that the behavior that exists now in V18 is what we want it to be, so I am glad to hear you managed to find a way to resolve this.

* Somehow old Forward-settings which had been used 'way in the past' for certain extensions where suddenly set to active. For example, I had an extension which, after 5 seconds of ringing would be forwarded to another ring-group. That need was removed roughly a year ago, and configured accordingly without that forward. Suddenly that forward is back on the Linux 3CX V18 despite using a very recent 1 day old backup during the installation.

This is strange, I don't recall seeing something like this, but especially with Forwarding Rules, the "general structure" has not changed much over the years so I can't think what could have happened here. Also as far as I am aware we haven't received other complaints about this.

Is there a list available of other quirks and oddities you found in this 'direct upgrade' path ?

There are no known "quirks" with restoring a V15.5 backup, only of course what has changed in the product as listed in the change log.

 

[schut]

I have also the requirement of a Static Route to a specific IP via another (non-default) gateway. This is necessary for Ziggo/Vodafone One Fixed Subscribers in the Netherlands (the public IP is their SIP-server which is only accessible via their own SBC which comes with the subscription into your own local LAN). I've tried various solutions:

1. Modifying /etc/network/interfaces by adding under the DNS-rules:
up ip route del 62.140.159.225/32 via 172.17.0.253 dev ens192
up ip route add 62.140.159.225/32 via 172.17.0.253 dev ens192

This did not seem to work, the route was after reboot not visible with the command ip route show

2. make a shell script in /etc/network/if-up.d/my_route
#!/bin/sh

if [ "$IFACE" = "ens192" ]; then
ip route add 62.140.159.225/32 via 172.17.0.253
fi

This did not seem to work, the route was after reboot not visible with the command ip route show


Eventually I was 'annoyed' working in overtime due to various other issues I encountered in the update (see previous post) that I just modified the existing /etc/rc.local by including the ip route command.
#!/bin/sh
ip route add 62.140.159.225/32 via 172.17.0.253
clear; sleep 1
if [ -x /usr/local/bin/post-install ]; then /bin/openvt -c 10 -s /usr/local/bin$
exit 0

This works, the route is added during (re)boot. However, does 3CX update/modify this script in updates? If so, do they remove my custom solution ?

 

[NickD_3CX]

I have also the requirement of a Static Route to a specific IP via another (non-default) gateway. This is necessary for Ziggo/Vodafone One Fixed Subscribers in the Netherlands (the public IP is their SIP-server which is only accessible via their own SBC which comes with the subscription into your own local LAN). I've tried various solutions:

1. Modifying /etc/network/interfaces by adding under the DNS-rules:
up ip route del 62.140.159.225/32 via 172.17.0.253 dev ens192
up ip route add 62.140.159.225/32 via 172.17.0.253 dev ens192

This did not seem to work, the route was after reboot not visible with the command ip route show

2. make a shell script in /etc/network/if-up.d/my_route
#!/bin/sh

if [ "$IFACE" = "ens192" ]; then
ip route add 62.140.159.225/32 via 172.17.0.253
fi

This did not seem to work, the route was after reboot not visible with the command ip route show


Eventually I was 'annoyed' working in overtime due to various other issues I encountered in the update (see previous post) that I just modified the existing /etc/rc.local by including the ip route command.
#!/bin/sh
ip route add 62.140.159.225/32 via 172.17.0.253
clear; sleep 1
if [ -x /usr/local/bin/post-install ]; then /bin/openvt -c 10 -s /usr/local/bin$
exit 0

This works, the route is added during (re)boot. However, does 3CX update/modify this script in updates? If so, do they remove my custom solution ?

I recall having tried it in the past and what I needed to do is what we describe in this guide:
https://www.3cx.com/docs/cypriot-sip-trunk-cyta/#h.66ylxkz8bf4y
It's for a different provider of course, but the logic is the same.
I admit the last time I tried it though was on Debian 9.
This is for the "interfaces" files if you want to give it another shot.


As for the /etc/rc.local file, I am pretty sure that this file is shipped with the 3CX Debian ISO and is not changed thereafter, at least not so far.