Replace License Key NFR not working

[oschobert]

Hi! We would like to replace our existing (commercial) license key with our new NFR key. Unfortunately this is not possible using the "usual" method in the GUI (License Settings - Replace License key): "NFR keys can not be specified as New license key".

So we talked to the support and they told us to do the following:

- take a backup of the old installation without FQDN, License, conferencing
- release FQDN
- deploy the new subscription and use the backup, select former FQDN

This is not working because:
- while deploying the new subscription there is an error that the backup has to contain FQDN, License, conferencing
- so the only way would be to setup the new subscription from scratch and when the PBX is running restore the existing backup

But: When i try to use our existing FQDN, the domain "my3cx.de" is not selectable anymore in the list of available domains?

After all: We cannot use our NFR-Key because the domain "my3cx.de" is not available anymore.

Why is it not possible to simply replace the key in the gui which normally is a matter of seconds? Instead we have a lot of work to do with uncetrain results / its not working at all?

Technically this should not be a problem at all because normally it can be done with a mouse click using the gui.

Does anybody know if replacing the key can be done using the shell? The PBX is hosted on Azure and we have SSH-Access.

Thanks a lot!

Otto

 

[NickD_3CX]

Hi Otto,

Indeed, the constraint of not being allowed to replace any key with an NFR for Free key has been around for some time, but that is not something that is going to change.

Also, you are right, the my3cx.de domain is currently locked due to the amount of subdomains that have been created on it. Your option of DE domains at the time of writing is "on3cx.de", so you can use that.
Unfortunately there isn't the possibility of "transferring" the FQDN from one key to another, by the time the domain you are using is currently locked, so DON'T release it from the old key, because if you do, you won't be able to rebind it again.

From you reading, I understand that you are trying to deploy via our deployment wizard to either "Hosted by 3CX" or your own Hosting Provider. To do this what you need to do is:

1. First I would make sure that the server you are taking the backup from is on the latest version of 3CX
2. Take a Backup without License key and FQDN option
3. Create a new installation using your NFR subscription with a new FQDN
4. Once you finish the installation, follow the instructions in the following link in order to see how you can now restore your backup

 

[oschobert]

Thanks for your reply - but:

The main problem is, that i cannot go on using the same FQDN which means that ALL clients and 3rd party integrations do not work anymore after that change and that we have to touch everything which menas a lot of work...

 

[NickD_3CX]

Thanks for your reply - but:

The main problem is, that i cannot go on using the same FQDN which means that ALL clients and 3rd party integrations do not work anymore after that change and that we have to touch everything which menas a lot of work...

I understand your point, but there is no easy way around this.

Generally if you as a Partner intend on using a system for your own use, or as a demo system, you should configure it using the NFR to begin with, to avoid these things.

 

[oschobert]

I understand. But when you start working with 3cx you are growing every month / year and you do not start from scratch beeing a bronze or silver partner. So from time to time its necessary to replace the key when you get one wirh more features / channels. Unfrtunately we were urgently waiting for this and now we cannot use it and might have to buy a license with more channels....

 

[oschobert]

Addition: Your wrote "there is no easy way around this" which is wrong. It seems that there is NO way at all around this.....

 

[NickD_3CX]

Addition: Your wrote "there is no easy way around this" which is wrong. It seems that there is NO way at all around this.....

What I meant by 'no easy way' is that you will need to make some changes to dependent systems that are referencing your PBX using the FQDN.

I understand. But when you start working with 3cx you are growing every month / year and you do not start from scratch beeing a bronze or silver partner. So from time to time its necessary to replace the key when you get one wirh more features / channels. Unfrtunately we were urgently waiting for this and now we cannot use it and might have to buy a license with more channels....

Understandable, unfortunately these constraints we have put in place are there for a reason, it is not that we want to make your life difficult.

 

[oschobert]

What I meant by 'no easy way' is that you will need to make some changes to dependent systems that are referencing your PBX using the FQDN.


Understandable, unfortunately these constraints we have put in place are there for a reason, it is not that we want to make your life difficult.

Can you tell the reason? I cannot see any sense in this...

 

[NickD_3CX]

Can you tell the reason? I cannot see any sense in this...

For the domain being locked, there is a cap on how many subdomains can be created under a domain. From that point onward, no new ones can be created, and moving them manually on our internal systems is not viable.
So this is a Technical limitation.

For why you can't replace a Key with an NFR key, let's just say that some Partners were doing things with their NFRs that they shouldn't have been doing, so we had to put in place some restrictions and heavily monitor actions of NFRs, and I'll leave this last point at that...

 

[oschobert]

OK, thanks. But it does not help us after all...
Isn´t there a way to "reserve" our FQDN? We won´t register a new one, it´s just a transfer of an existing one.

 

[NickD_3CX]

OK, thanks. But it does not help us after all...
Isn´t there a way to "reserve" our FQDN? We won´t register a new one, it´s just a transfer of an existing one.

Unfortunately no, as I mentioned, moving them manually on our internal systems is not viable.