Question for the masses. I’ve had some issues in the past as we were initially experimenting with Google Compute Engine (various changes to hardware ended up resetting ZendID) so I’ve had to have the nice folks at FPBX reset it (since we ate our 3 resets). During my conversations with them about that, I specifically said how frustrating it was that I couldn’t use the DEACTIVATE button to “check back in” the licenses so they could be reactivated on a different box, and I was told that’s just kinda how it was. I specifically stated that if that’s true, it kinda makes the deactivate button pointless.
I’m looking at that button right now, and it specifically says what I had hoped it would represent (the ability to check-in for moving to another box).
“You only need to use this button if you want to move this deployment to another, different, server.”. I recalled trying it once and although it deactivated the current box, it did not allow reactivation on another box.
So, here’s my question. We have a customer who is currently running FPBX13 on VMWare, but we now want to load it on it’s own box (as the other VMs have been migrated off that VM Host). When we do this, we’ll obviously be wiping the drive, but more importantly, moving FPBX from a virtual to physical machine, the hardware IDs will certainly change and it will be considered a different installation instance. IF I deactivate before wiping, and then reactivate after I’m done with the reinstall, should I be able to activate without a Zend Reset? We’re out of Zend Resets on that instance (because of the previously-mentioned migration/moving, etc (we also had such an issue when initially loading this in VMWare when we installed it). What I don’t want to have happen is we deactivate it, then try to activate it after it’s been rebuilt and can’t, but then have no way to contact support to have it reactivated until the following week. I really want to understand the DEACTIVATE button’s true function, as I’ve got an email thread that seems to conflict with the button’s own labeling.
There’s a process for changing the hardware out from under an existing system. In fact, Lorne just posted a link to the instructions for changing the site code on the fly.
If you need another ZEND reset, just post a request for support in the Support tab - the Sangoma folks have been pretty good about resetting those for everyone I’ve ever heard about.
Right - that was my complaint all along. If I’m actually selecting on the system to DEACTIVATE, that should NOT affect my zend hardware reset count - I’m essentially de-authorizing that deployment in order to move it. A zend reset from the purchasing portal should only be for if the existing deployment is unrecoverable and you can’t use DEACTIVATE to move/migrate it. But when I hit DEACTIVATE, it should “check back in” my licenses allowing me to move them to the replacement machine.
The problem is (and yes, we already exhausted those 2 resets), opening the support ticket in off-hours (when a customer would want this work done), likely won’t be answered until the next business day, and the inability to check-in the license manually impedes off-hours work from being done. (sigh).
So, basically, with no zend resets remaining, there’s no way to migrate this in the off-hours (I can’t have the reset done early or the system will go unlicensed at some point when it trues up its licensing - doesn’t it check every so often?)…
I have to agree with this. If one is either moving the deployment to a new machine (either because the old one isn’t fast enough or is failing), there should be zero penalty for explicitly deactivating the licenses on the first machine before activating them on the replacement machine. Penalizing your customer for doing performing what is a common maintenance procedure just is NOT COOL.
The only time I should have to beg Sangoma for the ability to activate a paid-for license on a new server is if the machine the deployment is licensed for was burnt so badly that it cannot cleanly communicate with them and cleanly release the licenses in preparation for the move. That’s where “zend resets” should be a limited “resource”, and only there.
At this point I haven’t even rolled out a new PBX to my church, and for some reason I’m already at 1 reset remaining. For various reasons learned in the process of setting up the system in the first place, I’m now planning on moving the deployment to a VM, which to my understanding will leave me with ZERO resets. If that VM becomes damaged in any way and requires a rebuild, I will be completely screwed until Sangoma deigns to give me another reset, which is not acceptable. More immediately, if I determine during the process of building the VM up that for one reason or another it ends up not actually being a good idea, I’ll be screwed again unless Sangoma takes pity on me. I must activate the VM deployment, because in order to even consider placing this PBX in the “cloud” I must have VPN functionality, which is a licensed feature. I also must be able to validate EPM functionality in relation to the VPN.
EVERY other “seat”-based licensing system out there (I’m specifically referring to things like $1M software packages used for e.g. chip design, etc.) has a continuous check-in/check-out mechanism, with zero penalties for moving the license. FreePBX should be exactly the same.
We have no ability to know the license has been removed as we don’t have phone home stuff so even though we remove the license file on the machine we have no way to keep you from just putting it back from a backup and since we don’t force a phone home license update we have no way of truly taking back the license from the machine once it has it which is why we give you 2 resets but as we know their are plenty of abusers who run that same license on 2-3 machines using resets it does not make us want to give even more resets. If we move everything to 1 year license than it becomes a moot point.
Tony, I really think this needs to be fixed. Right now, my FreePBX has some issues, and I’d really like to migrate to a clean install but I don’t want to waste one of my 2 moves. And when I upgrade to new major versions, I’d rather migrate to a fresh VM. Like you said, if FreePBX would do some basic phoning home for license purposes, then it would eliminate the majority of simple cheaters and we could get rid of that 2-times limit. For the more advanced cheaters, please understand that all software gets cracked so any restrictions only affect your good customers who pay, while the crack users enjoy a better experience than us. Please let us follow best practices without fear of downtime.
In r14, it looks like there’s actually a daily CRON job to confirm the licensing is still valid on a given box (I don’t know if that was also on r13).
Now, I’m not sure if there are still ways for the crafty thieves to work around it, but it looks like, with that, there’s the potential to actually make a checkout/checkin licensing mechanism and have a decommissioned system check within a day to shut down…
The problem is in the license file itself. When you buy a 25 year module from us the license is set for 25 years. We don’t ever verify after the 25 years as people screamed at us when we use to that if I have something for 25 years it should not phone home.
We can’t just say hey when you phone home deactivate the licnese as you can just not phone home and have the license work for 25 years.
You will be amazed the number of cheats we have that try and cheat the system already.
Just thinking of possible solutions: You could just require the phoning home and explain that it’s for good reason. Or, to make everyone happy, you could make the phoning home an opt-in thing so that people can choose either a two-transfer limit or an unlimited limit with phoning home.
Like I said though, advanced cheaters can simply crack whatever protection you build in, so please prioritize the needs of your paying customers over the never-ending effort of blocking the cheaters. I’m afraid to do a clean install because of the current limits. When I play video games, I never use my potions or single-use scrolls since I don’t want to waste them.
All you have to do is message support and they will take care of you. Even past the 2 limit. It’s the same for Microsoft. You have a limit of a certain number of activations (was 2) if you go past that just call them and explain and they give you another one.
Scanning through this thread it appears you haven’t even asked support about the issue you are going to face. Which means they could have just reset the limit for you to proceed with this. This is why you should ask them instead of speculating.
To be honest. This isn’t a priority. Instead we are slowing upgrading our backend licensing system to work with PHP 7+ which zend doesnt support. So perhaps Zend resets won’t exist at all. But that is speculating as well.
So, when I proceed with deployment of my FreePBX to a VM (AWS), and in the process I exhaust my final “reset” (I have no idea why I only have 1 left anyway), I plan to immediately file a support ticket requesting that I gain another “reset” back. I will NOT deploy a system that can put me in a position where a failure at an inopportune time forces me to wait until the vendor gets back to me before I can proceed with a reinstall and reactivation. That “reset” must be in the bank waiting for such a scenario, not begged for in the middle of disaster recovery.
Is that going to be a problem? If so, then I’ll have to insist on a refund for the modules we purchased, because we won’t be using them and I’ll have to find another solution that doesn’t involve such licensing shenanigans.
I have 2 FreePBX instances that I rent from FreePBXhosting. We wanted to move to a larger instance.
These instances come with already installed commercial modules, System Admin and End point manager. We want to move 3 additional modules from one of the PBXs that we recently shut down to the new one. We have no further access to this particular PBX.
I have followed all the directions I can find and am unsuccessful at this.
I have deactivated all the licensing on the retired PBX using the freePBX portal. This appears to have no effect.
I attempted to deactivate the licensing on the new PBX so that I could assign the old deployment number with the understanding that this would provide the new licensing. I was not allowed to do this either.
I’m wondering if this issue is particular to units that are pre-provisioned by Sangoma for FreePBXhosting?
It seems like the new instance is locked needing to retain the assigned preloaded System Admin and End point manager.
Is there anyone with any related experience or any suggestions.
This sounds like a ticket for Support. I don’t think any of us is going to be able to help you, and it sounds like kind of a unique set of steps. I’m sure someone can help you through the Issues/Support tickets.
Need to Transfer Commerical Module to New Deployment has some good information about transferring commercial modules. You may need to get a “Zend Reset” through a request (information in the forum is still good for that).