SDS alarms/SDS Form Comparison

[fishhead64]

We're having what looks like a routing issue and I found those neat SDS tools, which look awesome, but we can't see all the records, as it's truncated. Is there a buffer we can open up to see it, or can it be exported?

We think the real issue we have is that ARS entries aren't being properly populated across our devices. That's beyond our skillset and we're letting our partner sort it out. But we like the tool for troubleshooting.

Record (Digits Dialed:5123, Number of Digits to Follow:0, Termination Type:List) only exists on controllerA
Record (Digits Dialed:5125, Number of Digits to Follow:
The output is too large and is truncated.

Seems a steep learning curve for Mitel, we learn something new every day. This forum and MitelForums have been a huge help, thanks to all who reply to our requests for assistance!

 

[kokolino23]

You can have a look in the logs, this should tell you where is failing. You can then compare the forms between the controller where you have SDS errors and the other ones in the cluster.

 

[fishhead64]

right, thanks, and how do I get to see the missing data from the SDS Form Comparison report?

 

[AH64Armament]

When you have an SDS error on a MiVB, go to the SDS Distribution Errors - All form. Select the entry. Scroll down to the GUID and double click on it. It'll show you the entry that caused the issue.
Most of the ones I see these days is that the on-site admin edited a user and failed to add an email address to the account.
A majority of the sites we manage were installed prior to the mandatory email requirement. And teaching on-site admins that this is required is akin to teaching 10-second Tom from 50 First Dates anything.

You don't have to put a valid email address, only a valid email address format address - some of these sites don't use voicemail to email, so they don't want their users to have their email address in the form. So if their extension number is 1001, I'll put the email address as 1001@MiCollab.CompanyName.com (usually match this to that of the MiCollab server's name).
I say that you only have to appease the email gods to make it work.. but not necessarily a valid email address.

Where are you located? Do you have a Mitel Vendor that's helping out? If not, let me know, I'm sure we can set something up for a direct call.

 

[fishhead64]

Our users all have valid email addresses. Are you also talking about phone devices without users (ex. guestroom phones, elevator phone, lobby courtesy phone, etc?) In that case, none of those have emails. Are you saying we need to populate a fake email in every phone? We have 1000's.


We do have a partner and they do help. We're upgrading in the next week, so some of our issues may disappear, but we have some immediate needs so we're digging deeper on our own.

 

[AH64Armament]

If those phones have an account on the MiCollab, they must have an email address.

What does the SDS error form show as problems? These should be cleared before you do any upgrade or you risk dragging invalid data into the upgrade and possibly orphan data.

 

[kokolino23]

The error you've got has nothing to do with an email address, it's related to ARS!
When you do a sync and fails, the error log should tell you which controller is that. You can also compare the ARS form to each cluster element and see which one is failing. I presume the ARS is shared across the cluster, that's why you're getting this particular SDS error.

 

[Billz66]

"ARS entries aren't being properly populated across our devices"

very little is shared regarding ARS
- from memory cor groups and ARS digit mod can be shared
routes arent shared
route lists arent shared
ars digits dialled isnt shared

this is due to a number of reasons , one is that you cant put the CEID digits of your own mivb into its ars digits dialled table
and normally each mivb will have different trunks on it so it doesnt make sense to push any ars data for routes that aerent directly connected to the mivb

 

[AH64Armament]

I missed the part that it appeared to be an ARS entry that was failing.
One of the first sites we set up SDS for, they had shared as many forms as possible - including ARS digits dialed (and others). This wreaked havoc on SDS errors for similar issues.

As pointed out, the Route List entry referenced does not appear on Controller B - "Record (Digits Dialed:5123, Number of Digits to Follow:0, Termination Type:List) only exists on controllerA".

Stop sharing ARS Dialed Digits (and other ARS forms) and only share items that would be useful to be shared -
COS, System Speedcalls, TELDIR, etc. The Mitel defaults are pretty spot on.

 

[fishhead64]

Thanks, not saying you're wrong, but we have 20 AX controllers and some do need to share ARS entries and others don't. We have hotel properties, so guest rooms on that cluster probably should share, but not across clusters. Since we don't share across the clusters, that's probably the reason for the mismatches, although I'm still green on this platform, so I don't actually know for sure.

It would be helpful though if the Comparison Report showed everything instead of truncating. We're probably missing actual, correctible errors.