v18 / v20 licensing

[grussell]

I have a production v18U9a system (64SC PRO license), and have established a separate v20 4SC PRO instance, using a different FQDN than my production system. I used an simple express-config to get the v20 machine up and running. Both are on-prem installs. I have poked around in V20, getting a feel for the new system. Now, I would like to restore the config from my v18 production machine into my v20 machine. I am most concerned about doing this without jeopardizing my production v18 license (having the license upgrade to v20 before I am ready to fully upgrade my production pbx). Am I safe to copy a backup file from my v18 machine (choosing the option to NOT include license info during the backup) into the v20 machine and restore from within the running v20 machine? If this is not viable, can I do a clean v20 install from the iso and choose my v18 backup file (with no license info included), and using the FQDN of my v20 4SC license, and have a functional v20 4SC machine with a configuration that is the same as my v18 production machine? Again, I am most concerned about not jeopardizing my v18 production license at this time, but want/need to validate my production environment in v20 before upgrading production.

Thanks

 

[Guillaume Bourgeois]

Hi,
The 3CX PBX won’t allow you to restore a backup that contains a different license (and FQDN) from the one currently installed.

In any scenario, if you want to change the machine on which 3CX is running, you’ll need to restore a backup from a fresh v20 installation without any configuration.

Otherwise, if v18 is running on Linux, you can upgrade to v20 without needing to reinstall.

 

[Guillaume Bourgeois]

I am most concerned about doing this without jeopardizing my production v18 license (having the license upgrade to v20 before I am ready to fully upgrade my production pbx). Am I safe to copy a backup file from my v18 machine (choosing the option to NOT include license info during the backup) into the v20 machine and restore from within the running v20 machine?

If you create a backup without the 3CX license and FQDN, it should work without compromising your 3CX license/FQDN.

However, be aware that there are other details you need to consider when restoring a backup:

- Are your SIP trunks set to "REGISTER" mode? If so, this could cause issues with your SIP provider, and calls might not route to the correct system.
- Users will likely receive welcome emails automatically after the restore (unless this was disabled before the backup). This email will contain your temporary FQDN, which could confuse several people.

And there might be other factors I’m forgetting.

Honestly, avoid restoring a backup from one system onto a temporary system. It’s likely to cause more headaches than benefits.

 

[grussell]

Thanks Guillaume -- My 3cx environment is probably not typical these days. The pbx is entirely LAN based , as are the SIP trunks and hardware handsets. I have no softphones, and the pbx is not public facing. It can egress to the internet to talk to the 3cx licensing mother ship, that's it.
The sip trunks only use IP based authentication. There are 2 primary SIP trunks to the PSTN, and a few FXO trunks.
The handsets are not provisioned through 3cx. We provision them with a separate http server. There are 450 of those.
I do have off-hours to test handset/trunk functionality on a temporary system.

When I go to v20 I need to be sure everything works, or need to be able to roll back to v18 and resolve problems. If on-prem licenses CAN be reverted from v20 to v18, I would have less concern about upgrade/test/revert, and would like to know how one may accomplish such a task.

I appreciate the heads up about welcome emails, that would just be an annoyance to my users.

 

[Guillaume Bourgeois]

Honestly, due to the potential impact of the upgrade on your business, I would recommend seeking assistance from a 3CX partner. Many 3CX partners are experienced in managing major clients with challenges like yours. We are accustomed to these situations, and over time, we’ve acquired the knowledge to resolve issues without jeopardizing everything.

However, if you're feeling brave , I have some advice for you. But to guide you properly, I need to know which OS you are running 3CX on.

 

[grussell]

I welcome any/all advice around this upgrade! I have not had good luck in finding a partner in the past. I am on linux.

Thanks -- Gordon

 

[Guillaume Bourgeois]

I welcome any/all advice around this upgrade! I have not had good luck in finding a partner in the past. I am on linux.

Thanks -- Gordon

I am delighted to share my advice with you.
You're on Linux, which is already great news.

Do you have a server at the office?
If so, are you using VMWare or Hyper-V?
If yes, I strongly recommend moving to a virtual environment in anticipation of future updates or for troubleshooting issues.

Otherwise, when upgrading from V18 to V20, would it be possible to migrate to a separate machine to avoid uninstalling V18 until V20 is fully operational? This would allow you to restart the V18 server if a major problem occurs. (This is an alternative to upgrading).

- Do you control the router? If so, what is the brand and model?
- Do you control the DNS server? If so, can you create a local DNS entry?
- Are the phones provisioned on a separate server, and do you have control over it?
Scenario: If you change the local IP address during the migration to V20, for example, would it be simple to modify the information in the phone settings, or would you need to manually update each of the 450 phones?

The users do not have softphones, so no mobile apps or WebClient, is that correct?

Here is one of my suggestions,
If I receive answers to my previous questions, I will be able to delve into details such as configuring a local DNS or Hairpin NAT, provisioning strategy, and configuration strategy in the router, if necessary.

Here are my recommendations:

Take advantage of the upgrade to V20 to migrate to a virtual machine; staying on Linux is ideal.

Meet the minimum specifications for better reliability:
Intel Xeon E5 v4 or equivalent
Minimum of 8 vCPUs
Minimum of 16 GB RAM
Minimum of 500 GB SSD storage
recommended-hardware-specifications-for-3cx

When you reach the step of the 3CX Wizard, use option 1.
IMAGE
There's no need to open the webpage. Keep the SSH console open, we will return to it.

(Before proceeding with a 3CX V18 backup);

- Ensure that email addresses are unique for all extensions WITHOUT EXCEPTION!
- Make sure that your extension number plays the role of "owner," that you are able to log in to the dashboard with its password AND that it is indeed your email address that is defined.
The "Super ADMIN" user will be removed; it no longer exists in V20.

Disable welcome emails in 3CX V18; Settings > Emails > Notifications > Uncheck: Notify user when an extension is added

- Enable Failover Mode (Active Server)
Backup & Restore > Failover > Check "Enable Failover" & Select Failover mode: Active

Perform the full backup with the FQDN, but without the call records, we can move them later separately.

Instead of creating a temporary server, why not opt for a two-step update?
Note: If you have VMWare or HyperV on a server, take this opportunity to virtualize your 3CX system. This could save you a lot of effort in the future.

The two-step update is actually a strategy I like to use for critical systems like yours. Make a backup of your V18 environment with the 3CX license. Export your backup.
Create your new machine (ideally virtual, if not physical), when you reach the step of the 3CX Wizard, choose option 1 but no need to access the webpage.

On your new server, create a folder, be careful not to use 3cxpbx:

sudo mkdir /var/lib/3CX && sudo chown -R phonesystem:phonesystem /var/lib/3CX && sudo chmod -R 750 /var/lib/3CX

Upload your V18 backup to the new server, into the folder you just created (/var/lib/3CX/)

Then, run this command to adjust the permissions on the backup file.

sudo find /var/lib/3CX -type f -exec chown phonesystem:phonesystem {} \; -exec chmod 640 {} \;

We're ready to restore the backup! To do this, we will use an SSH command documented here:

DIR_PATH="/var/lib/3CX"; FILE_NAME=$(ls $DIR_PATH | head -n 1); sudo -u phonesystem 3CXRestoreCmd --file="$DIR_PATH/$FILE_NAME" --log="$DIR_PATH/restore_cmd.log" --failover & tail -f "$DIR_PATH/restore_cmd.log"

This command aims to restore the backup, keep SIP services disabled, and remain in passive Failover mode. It will still allow you access to the environment (Dashboard).

Restoration is underway, the more powerful your machine, the faster it will be.

This procedure avoids any issues related to the license and FQDN.

Once finished, you can access the dashboard and explore V20.
During a quiet period, on the PBX V18, go to Backup and Restore > Failover > change Active to Passive.
Set the local IP address of the PBX v20 server.
Check all services to monitor
Apply the following number of seconds: 172800 (equivalent to about 120 days)
Check Failover when all selected tests fail
Press "OK" and press "OK" at the popup.
The production server (v18) has just switched to passive mode and will not reactivate for several days even if it fails to reach the v20 server
Normally, on the Dashboard page, click on Services, several services should be stopped, this is normal.

Access the V20 server, (You must use the FQDN to access it with https), use your extension number and the password of your extension set in v18, go to the Admin page at the bottom left, Backup (It's in the menu to the right of the black bar where "Admin" > FailOver, switch to active mode and press "OK".

The services of your new 3CX should start!
To see their status, go to Dashboard > click on Services (It's on the page, Troubleshooting section, it's not a tab), all services should be green.

You can perform your necessary tests.
Go to your FXO and don't forget to change the local IP of the PBX
Go to a few physical phones and modify the local IP of the PBX
If the SIP Trunk to PSTN (remote), don't forget to modify your rules in the router to direct traffic to the correct system.

When you're ready to switch back to v18, proceed with the reverse operations;
The V20 server becomes passive, Failover when all selected tests fail, check everything, set to 172800 (equivalent to about 120 days), and press OK and confirm by pressing OK again.
3CX (the interface) stops responding for a few seconds, wait, it will come back.
Upon return, check the services, several should be "Stopped".

Go to 3CX V18, switch to active mode.

You can do this an unlimited number of times but when switching from one mode to another (Passive or Active) wait for the process to finish before switching back to the opposite mode. Give the system time to proceed with the operations.

Finally, on the BIG day, all you need to do is redo the operation from "Upload your V18 backup to the new server"... and set your PBX v18 to PASSIVE and/or turn it off... and that's it!

PS: If there are call records, use the scp command on the pbx v18 to send them to the new pbx, here's an example:

scp -rp /my/recording/3cx/path/ [email protected]:/my/recording/3cx/path/

 

[Evolute IT]

I have not had good luck in finding a partner in the past.

That's surprising considering the license size you have. Feel free to reach out if you want to explore options!

 

[grussell]

Thanks for the detailed information, Guillaume. Leveraging the failover feature is interesting. I assumed that active/passive servers would need to be at the same version/software level, but from your description, that is not the case. I'm still a bit perplexed about how 3cx licensing works. When I look at my licenses in "My Systems" in the 3cx portal, they are clearly labeled as to what version they are. My production version says 3CX PRO (18.0) 64SC. My freeby says 3CX PRO (20.0) 4SC. This leads me to wonder whether or not licenses are locked to versions or not. Perhaps they are backwards compatible?

If I install a 2nd machine (version 20) using the FQDN/license of my production machine during install from iso, I assume it will talk to the 3CX licensing portal and upgrade this license to be 3CX PRO (20.0) 64SC, In the active/passive failover approach you describe, with one participant being v18 and the other being v20, it implies that v18 will continue to function at 64SC capability, even if the license is for version 20. That is the piece of information that I'm most interested in confirming. Is a v20 license for on-prem environments backwards compatible with a v18 pbx? Your failover approach with mixed versions of 3cx would require that.

If I can get clear confirmation about my license version concerns, the simplest approach for me is probably to build up a fresh install of v20 in a new debian 12 VM, using a fresh full backup from my v18 VM during initial install, and use a different LAN IP at first. My backups are written into a separate location via NFS., and the v20 instance can mount that same NFS share. IP address swap would take care of cutover, after some testing of handsets/trunks.
In the event that something unexpected were to take place after moving onto v20 (and the 3cx portal moves my license to v20.0), I can safely swap LAN IP's back and bring up the v18 server, and 3cx licensing should be happy. <<<< SEEKING CONFIRMATION OF THIS!

To answer your various questions, my server environment is fully virtualized, and I control all aspects of DNS/DHCP/routing/firewalling/etc. The provisioning server is automated, with two config files (common.cfg and MAC-based cfg), It is an in-house application that has worked well for many years. It gives us easy control over individual handset customizations.

Thanks -- I appreciate the feedback.

 

[Guillaume Bourgeois]

Yes, you're right, the activation server wouldn't let you proceed with the activation process for a new v18 installation (or a v18 restore) after have upgrade to v20, but if you don't uninstall your v18 setup, it shouldn't cause an issue, theoretically. It's a trick I've used several times before, for example, from v16 to v18.

That said, you're correct, it is risky.

Since you're not using a "register" trunks, you might try the strategy you were planning to use (with a temporary license), remembering to disable welcome emails, making sure you have access to your extension as the owner, and ensuring that the email addresses are unique. Make a backup without the license and then restore it on a freshly installed v20 virtual machine without any configuration, without touching your v18.

However, once you finish testing with v20, since it's on the same network as the v18 and contains the same data, I strongly recommend shutting it down to avoid having two active phone systems. Although this shouldn't cause any problems, I'm not familiar with your setup; for example, multicast? CallFlow? Your in-house provisioning application ? mobile app (PUSH)? Etc.

In the meantime, I have a v18 pro license that I can use to retest my failover strategy and let you know if it still works. I will also revert to version v18 and let several days pass to observe the behavior. I will even deliberately click on "refresh license" on the v18 to provoke an error and see if the PBX downgrades the number of Simultaneous Calls.

That said, you're right to minimize risks and to consider using temporary license / FQDN.

To answer your question about Failover; from what I recall, Failover (Fail detection) works even on different major versions as long as they are on the same FQDN, operating system, and network configuration (ports), but I might be mistaken. In any case, the worst scenario that could happen is the passive system thinking the active server is down. That's why in my strategy, we make sure that the verification only occurs every 120 days, consequently, it would take 120 days before the passive server initiates its protocol to become active. In other words, we do not want it to switch to active mode without your manual intervention, regardless of its compatibility or not.

In 3CX v20 , you must use the HTTPS port and the FQDN to access the Dashboard/WebClient.

To do this, you need to enable Hairpin. The goal is to instruct your firewall to route traffic intended for the public IP address to its LAN port, not its WAN port.

Alternatively, you could use split DNS (local DNS entry) but most web browsers and antivirus software detect this setup and may believe you are experiencing a hijacking, which could block your browsing to 3CX Dashboard/WebClient.

Do not hesitate to let me know if there is anything I can do to help.