We have had 5-6 customers using Class of Service. When we get “Maintenance Expired” in the dashboard, we have to disable class of service to get outbound calls?! Which means we have to use extension routing, without access
Class of service disabled “Maintenance Expired”. CALLS ARE NOT GOING OUT BECAUSE OF THIS. As we understand maintenance expired does not effect calls, however unless we disable Class of Service the customer cannot dial out because of this. This should not happen. We have a customer who cannot work without class of service. What’s happening with this?
Please review recent blog/forum posts on the topic and provide some more details on your module versions e.g. screen shots of relevant parts of Module Admin, fwconsole ma list output, fwconsole setting MODULE_REPO settings/changes, images of the exact error messages, recent system update history, etc. (You can also separately DM over the affected Deployment IDs.)
When you go into Class of Service, it says there is no maintenance contract (expired) and the module has been disabled. No outbound calls are allowed, until we disable COS module and go into the outbound routes, go into extension routing and add in the extensions to be allowed to dial out.
Also based on the reply, maintenance on specific modules if they expire will just cease to work or update? As our supplier who we purchase the licenses etc through said it should not effect calls. However class of service is specifically used to handle outgoing if it expires, are outgoing calls going to be blocked as we are experiencing, then having to disable COS to get service back or purchase extension on maintenance?
Oh the joys of creating a solution to solve an issue that is so low impact that the solution creates more problems than it solves. This is a good roadmap to keep on.
Optimal for Sangoma maybe but hey changing something like this after over a decade should be fine. It won’t have any backlash at all. Breaking peoples systems because they didn’t renewal their annual support is a bit too much over the line. You’re taking fully licensed software and making it stop working because someone won’t pay for updates.
@penguinpbx the 25 year license is sold as an option that includes 1 year of upgrades and 24 more years of additional use without upgrades. Optionally, buy an upgrade license after the first year.
Are you saying this is not how it works now? If so - stop selling 25 year licenses. It’s misleading.
I’ve followed these threads for awhile now, and still wonder if a formal announcement was sent out well in advance for the affected customers. Not meaning a post in this essentially-techie forum, but I would presume that Sangoma has contact details for each registered customer who has purchased a commercial module. A quick e-mail or snail mail letter informing these affected parties well in advance would’ve saved everyone grief on both sides of the fence.
Not saying this is in any way analogous, but when our company was blindsided by Broadcom’s VMware “strategy” it felt like we were being held hostage. Until we moved to another virtualization platform in that case.
Again, probably a poor analogy, but imagine WinRAR’s meme-worthy trial suddenly ending without any notice. And archive files were locked where they couldn’t be accessed by any archive app. In any event, a major paradigm shift deserves formal notification in advance.
At least Broadcom sent out post-facto formal notification to us. After we left VMware, with snail mail and e-mail demanding we prove that VMware wasn’t running in any environment to avoid legal action being taken against us. lol.
That is still the process, but this one particular module needed further adjustment.
There were forum topics, blog posts, webinar mentions, and emails – some of the latter with specific details sent from the internal Sangoma portal to billing account contacts as well as recently updated system notifications sent direct to individual PBX administrators. If you didn’t receive such an email, well, then that probably means your support and maintenance (if any) was up-to-date.
But you are shutting off GUI access as well. So this is not the original process since it never shut down access to the module just because a support renewal wasn’t done. Sure it supposed to keep working with the current config but it makes the module unusable since you can’t fix any problems or make changes with the module you have licensed to use completely for 25 years.
Sangoma is now forcing people to maintain support renewals if they want to keep their modules functioning as is. Don’t pay, your module stops functioning as expected.
Notwithstanding OP’s current module situation – since corrected – GUI access is blocked on a module-by-module basis only for forbidden licenses i.e. those versions which did not exist until after your support maintenance expired.
Notwithstanding OP’s current module situation – since corrected – you may continue to use the version of the module that was available during your support maintenance period for the duration of the original license length in question.
Notwithstanding OP’s current module situation – since corrected – we are not using the force in this way at all. It would be more accurate to say:
Don’t pay, your module stopskeeps functioning as expectedshipped. But until you pay, you won’t be able to upgrade to the latest versions with exciting new features, compatibility improvements and/or important security updates.
For more background, please review some recent blog posts on the module expiry matter that were aggregated in to this forum topic a fortnight ago:
…as well as the below more historically distant forum topic – which largely still accurately represents official Sangoma mirror policy:
If formal notification well in advance was sent out as described, then point taken. In our case at the time we hadn’t purchased any commercial modules, hence my relative ignorance of that.
So it sounds like this is status quo except for the CoS module which had a bug causing it to erroneously disable itself even though there was a long-term “can continue to use but not upgrade” license in place.
And there will be more of such notifications! Please continue to stay subscribed to Sangoma emails, FreePBX blog post RSS feeds, and Watch (subscribe) to the relevant forum categories to get notified directly from the Discourse mechanisms.
Thank you for contributing to the forums!
…and except for disabling of the per-module GUI when forbidden licenses are encountered, and except for Softphone access is changing as module licenses expire (although that is not a module exactly but a separate app) – anyhow, those are both new things in the license/maintenance project space in mid-2026.
So with all of this being said, for our company I did purchase SysAdmin Pro for our new v17 FPBX instance that I spun up. This was last June. So this is how things look.
We have only used the official mirror going back to previous instances going back to v15. So on this new v17 instance, here below is that being queried. This was the first time we purchased any commercial module, after the battening down of licensing enforcement.
If what I’ve read appears to be the case, then the expected behavior come 6/14/2027 should be:
If we renew annual maintenance, then SysAdmin Pro will continue to fully function.
If we do not renew annual maintenance, then SysAdmin Pro will continue to fully function at its current version. Any module version updates should be automatically blocked from being listed as available and/or would be blocked from being installed from the official mirrors.
Not trying to deliberate this topic, just trying to fully understand what is the expected behavior. I would think/hope that the official mirrors wouldn’t allow me to update a commercial module if it’s out of maintenance contract. If that is still possible and then the module is disabled as a result, that’s a gap to me.
Fair enough. But let’s say the commercial module is another one that’s applicable to this scenario. Say it’s Parking Pro. If maintenance has expired then I’m assuming that either the official mirrors will block a new version from being pulled down, or else if the new version is downloaded the install routine will fail due to detecting the expired maintenance? Properly enforcing license controls should help prevent customers from accidentally shooting themselves in the foot if they see a notification about newer versions being available for update in the admin dashboard and want to keep patched.
