Solved Server move

[skytrack]

Hello,

I am trying to move our 3CX Enterprise installation to a different cloud server.
The issue I'm facing is that the deskphones do not provision after server movement.

My steps are:
1) Backup "old" server with FQDN/license, also without
2) Turn off "old" server, turn on new one and initiate 3CX installation (Debian)
3) On first install screen via web browser, I upload the backup (have tried with both backups), complete installation and access the instance via web browser.

My question is, do I need a different approach? The two servers have different IPs, how does the FQDN update to point the new server's IP?
Do I need to manually reprovision (after factory reset) each deskphone? Shouldn't they work immediately if the FQDN points to the correct new server?
Thank you in advance

 

[Saqqara]

Restore using license key and fqdn,

As you have Ent license, it should take 6 mins for the fqdn to update to the new wan IP address of your cloud server

You should not have to factory default the phones, as there will using fqdn to connect. May required a phone reboot to clear any dns cache

 

[epodworksnet]

To be honest some model phones won't reprovision correctly with this kind of change. Depending on your exact model of phone you might have to "reset" each desk phone. This can easily be tested by reseting one!

I just moved from Windows v16 to Linux V18 with different FQDN but the same IP Address which made life easy. I also am using SBC between office and PBX. If you are using 3CX FQDN then the DNS TLL is like 6 Hours so if the IP Changes it might take a while. You can also check the FQDN via nslookup or dig to determine if the IP Address matches.

I always recommend getting a FREE STD 8 SC license for testing this kind of migration.

 

[skytrack]

Restore using license key and fqdn,

As you have Ent license, it should take 6 mins for the fqdn to update to the new wan IP address of your cloud server

You should not have to factory default the phones, as there will using fqdn to connect

That is what I thought, but unfortunately this does not seem to work.
Our phones are provisioned via STUN-remote, if that makes any difference (should not, though).
I read that FQDN update time is around 300 seconds.
Is there anything else that could affect the provisioning of the deskphones, that I may be missing?

 

[skytrack]

To be honest some model phones won't reprovision correctly with this kind of change. Depending on your exact model of phone you might have to "reset" each desk phone. This can easily be tested by reseting one!

I just moved from Windows v16 to Linux V18 with different FQDN but the same IP Address which made life easy. I also am using SBC between office and PBX. If you are using 3CX FQDN then the DNS TLL is like 6 Hours so if the IP Changes it might take a while. You can also check the FQDN via nslookup or dig to determine if the IP Address matches.

I always recommend getting a FREE STD 8 SC license for testing this kind of migration.

I am using SNOM D765 phones, that are supported.
Also Enterprise edition 3CX that has shorter FQDN TTL.
The FQDN seems to update, and I can access the instance via web browser using the FQDN url instead of IP, but the phones do not provision.

 

[Saqqara]

Check 3CX Blacklist

 

[skytrack]

Check 3CX Blacklist

The IP of the deskphones remains the same, will check if the blacklist is not transferred upon backup restoration on the new server.
Should I release the FQDN from the old instance?

 

[Saqqara]

Should I release the FQDN from the old instance?

No, as you are using the same license and fqdn.

If you do an nslookup command does the fqdn resolve to the wan ip address of the new server

 

[epodworksnet]

If phones do not provision, then check your provision link via any web browser. Get provision URL from any extension then add "/cfg<mac> (not sure if that is right for SNOM -- <mac>.cfg works on Yealink). Then you can do two things -- visually check the content of the provision data and you then know the download from the PBX Web Server works. Finally, check DHCP option 66 as that is what is generally used for auto-provision URL path for most handsets.

 

[skytrack]

If phones do not provision, then check your provision link via any web browser. Get provision URL from any extension then add "/cfg<mac> (not sure if that is right for SNOM -- <mac>.cfg works on Yealink). Then you can do two things -- visually check the content of the provision data and you then know the download from the PBX Web Server works. Finally, check DHCP option 66 as that is what is generally used for auto-provision URL path for most handsets.

Hey, thanks for your input.
I am restoring the full backup on the new server at the moment.
How I go about checking the DHCP option? Is this done via the console?
There has been no other change on our office network, only the 3cx server IP change.

 

[epodworksnet]

Did you have an FQDN change (URL of the 3CX Web Management UI)? If not, then you might be OK.

If you have a FQDN change then that could be the problem. You need to point the OLD FQDN to same IP of the new FQDN if you want to Phones to migrate over to the new FQDN. The provision config is self defining and contains details about the new IP and FQDN.

I use Yealink so I don't know the behavior on this point for SNOM. Obviously, if the phone tries the OLD Provision URL and the server does not answer then the phone won't re-prevision or worse get the wrong config file from the OLD 3CX.

The other concern is what is the phone's behavior for updating the Provision URL from OLD to NEW FQDN.

One way to check is inside the Phone via the Web Manage UI to see what the Phone things the Provision URL string is.

DHCP is controlled by a Router or Server on the LAN that the phones are connected. This is network infrastructure and has nothing to do with 3CX per se. If you have automatic phone provision, then when the Phone boots the TCP/IP Stack gets an IP Address and other settings during the DHCP Request process. One of those settings is DCHP Option 66 which is used by the 3CX/Network Admin to pass to the phone the base URL string that is used to grab the provision file. You can see the base Provision URL string inside the 3CX Web Manage UI from any Extension -- go to the Provisioning tab.

Some phones won't change their Provision URL once the phone has retrieved it the first time from Option 66. The only choice is to reset to factory. You can test this idea simply by taking one of your phones and perform a reset. If Option 66 is set correctly then the phone will automatically connect to the correct 3CX. If not, then you have your answer.

 

[skytrack]

Hello folks.
Thank you for all the great tips and help.

It turned out to be a local network issue, the phones could not point to the new server IP.
Opening the Local SIP ports of phones did the trick, although reprovisioning was necessary for some reason.

All is good now, thank you again.

 

[JohnS_3CX]

LAN Phones / IP interface: They will fail if you move to a server with a different IP. They will need to be factory reset and reprovisioned after your migration.

LAN Phone / FQDN Interface: If you use split DNS and updated the internal DNS entry to point to the new IP, you should have no problems. Simply reboot them once and they will work.

SBC or STUN Phones: They will not be affected at all, especially if the migration stays behind the same WAN IP and you port forwarded correctly. If the WAN IP changed simply reboot them once and they will work.