Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MiVoice 6920 SET LOCKED OUT! CONTACT ADMIN

Status
Not open for further replies.

IT-Rob

IS-IT--Management
Apr 9, 2021
5
US
Hi, just signed up to ask this question as we can't get it sorted out...
((*** I've seen the post from 3-Mar-16 ***))
--------------------------------------------
That post may be the answer; however, I'm not a phone guy and so I need some hand-holding on how to check the steps.
I made a new thread because that one is quite old, not sure that it would be seen if I added to it, and we have different Mitel equipment.
Hopefully I have pre-qualified my thought process here... :)

Our phone vendor says they've never seen this problem before and that they have spoken with Mitel support and they haven't either...

We have a Mitel MIVB virtual server which has been working fine up until a few weeks ago when we rebooted it.
After the reboot we are not able to add new phones...in this case it's a 6920 IP Phone... We boot it up, it goes through the process and gets to the point where you need to enter the PIN, which we have been using a sequence of *'s and #'s...I can post it if it's not something that I shouldn't post...and once we hit enter it comes back with the message, "Set Locked Out! Contact Admin". The phone set I'm using right now is straight out of the box 6920. We have tried a couple others, and have reset them, cleared IP settings, etc... seems to make no difference.

Our vendor says they have programmed plenty of "base extensions" and so it should be able to connect and that there has to be some other networking problem.
So hoping there are some Mitel folks out here that have seen it and can offer some things to try. We've looked at the licensing and extension configurations and compared with working ones and just can't see what the problem is.

Maybe it is a network problem, but we've got a couple hundred other extensions that work...and I can't believe that no one has ever seen this message before, including Mitel support...
Thank you - Rob
 
the *** method relies on there being a pool of numbers - it could be that the pool is full ( regardless of what the vendor says)
check system options - down towards the bottom there should be a range of auto assigned numbers

if your entering more than just *** ( or ###) then your trying to set the device to a specific extension
- set locked out would happen if the extension your trying to login to is assigned as a different type
its not really a security issue so it would help to tell us exactly what is being entered


If I never did anything I'd never done before , I'd never do anything.....

 
Billz66,
Thanks for the response, I appreciate it!!

So we're using "#**#" to do the initial registration of the phone for a hot desk user. I get the feeling that the pool is full too, or something related to that, but how do you check what is used and what is available in the pool?

I'm attaching a screenshot of that part of System Options that you mentioned.
Thank you - Rob
System_Options_-_Auto_DN_Pool_nvgfpo.jpg
 
Unusual codes

- pool is 1000 devices so probably not full

try Maintenance command locate auto_dn # 1000 1999

you could also do an export of all ip users and devices
if you have extensions #1000~ #1999 assigned then the pool is all used

- from memory you can delete any without mac addresses as they arent in use , it should start again from the start to find a spare
- i think you can also change range to greater number without any side effects ( could change end to 2100)

Could be a license issue - are there any alarms on the system?
can it sync with the AMC.
might be an issue with the cluster config

is that the exact error shown on the screen

if it just says LOCKED then its working and you have auto assigned a device only- its now waiting for a hotdesk user to be logged into it .

on the post you mentioned , they were assigning a fixed extension that wasnt correctly configured
thread1329-1762671


If I never did anything I'd never done before , I'd never do anything.....

 
Billz66,
I believe you are zeroing in on this!
I messed with that locate command yesterday but couldn't figure out the proper syntax...if I have typed it correctly using what you posted then it's saying there are no free DN's...
=======
LOCATE AUTO_DN # 1000 1999
=======
LOCATE: Warning! file *.LOCATE.AUTO_DN will be overwritten.
Quantity of free DNs in the given range: 0
Set Registration - Auto DN Select last free DN is:
A free DN within the given range cannot be found.

** Dialing conflict with one or more FAC or ARS string. **
=======

How do you delete mac addresses? I was looking into that yesterday. The test set I have on my desk was showing up in the "IP Telephones - All" with no number assigned and a state of "UnProgrammed". I unplugged it yesterday and it seems to have fallen out of the list now, so will they clear on their own? I could not find a way to delete anything on this screen.

I did an export from that same screen and when sorting it I see extensions labeled with the "#" that go from 1004-1008, 1010, 1014-1016, 1019-1021, 1024, 1026, 1030, 1042, 1046, 1048, 1071-1072, 1999....so randomly sequential and definitely not using up even the slightest percent of the total pool. I also see numbers that are 1103, 1104, 1120, etc... that do not have the "#" and I know these are valid extensions, but is there a possibility of a conflict, or does the "#" differentiate them?

We might be able to increase the pool beyond 1999, but I'll need to check with my boss to see if there are any existing numbers/extension in that range. She has a dial plan, for the most part, and I don't know what it is. I think the error I got from the command you gave me is more likely what the problem is though.

Licensing...I *think* we're OK, we went through that during the initial upgrade/installation of the Mitel VM's and I don't see any errors or alerts about it on the top right. We opted for the "DMZ install" rather than using the Mitel boxes as "firewalls", so our vendor supplied us with a Mitel engineering document that listed all the ports they needed to work. We have opened everything up according to the document on our firewall and I recall working through the licensing. At that time it was verified to be talking to the Mitel license servers on the Internet.

On that note, I do think there are cluster problems. We have (4) 3300's and this new MIVB system was supposed to be added in; however, I know my boss has complained that if she adjusts an extension, such as the directory name, in the MIVB that it does not sync to the 3300's. She has to go into the 3300's individually and adjust the entry there as well otherwise the people on those systems won't see the updated information. Also, I keep seeing alerts on the top right...it blinks between Major, Warning, and Minor. Our vendor keeps telling us to ignore it and that it's not a problem; however, I believe it is. In looking into the Auto_DN assignment, I read something in the Mitel help that said the cluster had to sync otherwise it wouldn't work...it also said something about the, I don't remember the term, trigger key (my term...) of "#" had to be consistent between all the devices in the cluster. I don't really know how to check this.

Yes, the exact error on the phone set that appears when we enter in the "#**#" sequence is "Set Locked Out! Contact Admin"

So it's clear we have bigger problems, but at this point if we can sort out the auto_dn registration/set locked out thing, or if it is reasonably possible to conclude it's not working because of cluster errors, or the likes, then that would be enough for me to go to my boss and make a case. I know you're doing this for free, and I appreciate that, so also not going to expect you to resolve every one of my issues that our vendor, who is getting paid, should be doing...
Thanks - Rob

Here's a screenshot, not sure if this is relevant or not...
SDS_Distribution_Errors_yaci12.jpg
 
Billz66,
So I sent the output from the locate auto_dn command you gave me to our vendor, and their tech got back to me a little while ago.
I don't want to wholesale paste his response, but he basically says the Call Pickup - Directed feature access code for us is #1, which conflicts with the #1xx base range and so he recommends changing it. He says that when two directory numbers have the same leading characters that the system will wait 3 seconds for an additional digit to be entered before dialing the number.
I mean, they are the ones that set this whole thing up so I just have to wonder why they would have created a conflict, but I guess that's water under the bridge now.

We've now had a few more of the 53xx series phones fall off the system, and are expecting a bit of impending disaster...our workaround is to configure the extension as a teleworker, which get them back on. I have to wonder if the TW option works because it just doesn't require a base dn for the phone to register...

So do you think that having the conflict between the base range and the feature codes would prevent a phone set from obtaining a base extension issued by the auto_dn?
Thanks - Rob
 
Quite possibly

get them to change the pickup code or change the prefix for the auto dn in shared system - make it a 9

then auto dn would be 91000-91999



If I never did anything I'd never done before , I'd never do anything.....

 
Billz66,
OK, so our vendor finally changed the auto_dn pool to a range that's not conflicting...and imagine this...it started working!!

We've been arguing with them for a solid two months about this "Set Locked Out!" issue and they've insisted that it is a "network problem".
We've also been arguing with them for the same amount of time about our 53xx sets erroring out downloading firmware and rebooting...they've insisted it is a "network problem" too.

Well, the resolution to tftp/reboot problem was that they were getting a version of the firmware that has a known bug with the version of the MIVB we're running.
I bring this up because once I was able to prove to them the auto_dn issue, then they suddenly realized the firmware version problem...once both of these items were fixed, no more "Set Locked Out!"...and it wasn't a "network problem"

So, I just want to give you a hearty THANKS!!! Billz66, you pretty much zeroed in on the problem in two posts of the forum and absolutely helped me force our vendor to open their eyes.
I learned from this, and I really appreciate your assistance!!!!
Thanks - Rob
 
No problems glad to help . Lots of good help here on tektips

If I never did anything I'd never done before , I'd never do anything.....

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top