Stop asking the customer to Register their FreePBX after it's already registered!

(Greg Snover) #1

Ok - I have been moving all my boxes around and twice now, this has happened - the first time it happened, the customer was smart enough to call when they did it - this morning, the customer only called saying their system was “down” because they could no longer get into the GUI.

In case anybody doesn’t know, for a while after a box is registered and set up, it will prompt you to register the box - away from the reseller (me) - I understand why Sangoma is trying to bypass me and establish a direct relationship with the end-user, but in the process of doing this (both times) it creates a new deployment and nukes all the licensing for any paid modules.

It also tries to force you to connect in the Web Interface to the non-https port on the box to update - in the case of our machines, we do not expose that interface to the outside world - yet another problem.

Look, if Sangoma wants to find out about the actual end-customers for Marketing, I am OK (but not thrilled) with that - but asking them to register the box which then disconnects all the commercial licensing it stupid and customer-hostile.

As a reseller, it’s downright aggressive!

(R. Stindl) #2

Aren’t you the guy who used a script to set up a new freePBX server? Couldn’t it be an issue with your method? Sounds weird to me…

(Greg Snover) #3

No - perhaps you haven’t set up a new server in a while - it’s a thing. Set up a few more servers and have one of your customers screw it up on you and you will see what I am talking about.

(Simon Telephonics) #4

Are you sure you have the reasoning right on this? It sounds more like a bug to me. If you are a partner, why not reach out to your contacts at Sangoma rather than air your gripes on the user forum.

(Greg Snover) #5

Wow - what a bunch of odd responses to this E-Mail - do you think you have to defend Sangoma?

“air your gripes on the user forum”

That actually made me laugh out loud! :slight_smile: - If you look though my posts here you will find me over and over again, either trying to help others with what I know, or asking about things that don’t seem to work.


(R. Stindl) #6

Did you change the MAC of your network hw by any chance?

(Greg Snover) #7

You didn’t read the post - nothing changed except when the customer logged in, they were prompted to register the machine - they did, and it changed it away from me to them.

(Simon Telephonics) #8

I’m not talking about your other posts (which I agree are insightful, informative, and helpful). I’m talking about this one. I think you have it wrong and this is a fairly hostile post. I would reach out to your contacts in the org first.

(R. Stindl) #9

Where did the credentials of the customer come from? Didn’t you test it first and logged in with the credentials of the customer?

(Lorne Gaetz) #10


Please open a support ticket for this so we can exactly determine how best to make this work for you and your customers. The registration claim process is intended to allow the final PBX user access to support and deployment details, it is not intended to make them re-register with a new deployment ID.

(Greg Snover) #11

Fair enough - I have another 30 machines to move/recreate before the end of the month, so I know it will happen again - if it took the licensing along with the re-registration that would be fine - I have a direct relationship with my customers, so it’s not a problem to let Sangoma have their info also - it’s the fact that when they do it, all their commercial modules become deactivated and (because of the way we currently firewall them) they can’t access the GUI anymore.

(Greg Snover) #12

Perhaps a little angry - ANY outage at our customers (Even if they caused it!) is a ding against us! It’s Human Nature - not a facet I appreciate, but there it is.

Both of the customers, thinking they were doing what they were supposed to do, did something that then impacted their phones - in one case, because they were using Sangoma Connect, it quit working. In the other customers case, she came in early to record IVR’s, registered the box, and then could no longer access the GUI and coming in early was wasted.

It’s “death by a thousand cuts” - we just switched back-end providers so we have touched our whole customer base in the last two months - The trunking customers hardly noticed the change, but all of the Hosted customers, it was a fairly significant change - and change (at least for the people I work for…) = broken in their minds. Eventually it adds up, they think we are not worth messing with and they move on - I am trying to avoid that.

(Simon Telephonics) #13

Thanks, I understand. It does seem like the flow of things is really confusing.

(Lorne Gaetz) #14

Thanks @GSnover for walking me thru what you’re seeing. Something is not right there so I will get a ticket open on it.

(Lisa Purchasing) #15

As a customer, I assure you this is very frustrating but in no way blame our reseller. Our brand new PBXact is currently useless for this very reason. On Sangoma’s portal, it now shows the new hardware but under a different deployment than what Sangoma had us set up. I even tried to open a ticket but have not had any reply whatsoever. I unlocked the licenses on Sangoma’s portal but still cannot activate them onto the other deployment.

(Lorne Gaetz) #16

We have an internal ticket on this to fix the issue, but it will take time until the fix is implemented.

In the near term, please ensure that customers are selecting “Existing Deployment” when going thru the co-claim process.

@Taquine the fix is to run

fwconsole sa activate xxxxx

where the x’s are the original deployment ID.

(Lisa Purchasing) #17

Thank you! We’ll try that and I’ll post back if they are successful in activating it.

(Lisa Purchasing) #18

Mission accomplished! The fix worked like a charm after a few minutes. Thank you!

(system) closed #19

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.