• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

Hello,

 

We have a couple VVXs running 5.6.0.17325 that we're starting to use with Skype for Business. Troubleshooting a situation where BToE appears to be locking out AD accounts has me spending time in the logs. No matter which firmware version we've been on, and whether they are configured for on-premises, or Cloud PBX accounts, we periodically get a bunch of log entries like this:

1017134630|cfg  |5|00|Prm|Parameter log.level.change.ice requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.tickt requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.sip requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.ec requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.app1 requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.so requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.afe requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.pps requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.btoe requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.auth requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.dpair requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.proxy requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.wad requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.nisvc requested type 2 but is of type 0
1017134630|cfg  |5|00|Prm|Parameter log.level.change.rssvc requested type 2 but is of type 0

 

I did review this seemingly related post:

http://community.polycom.com/t5/VoIP/Requested-type-2-but-is-of-type-0/m-p/43415#M6544

and this one:

http://community.polycom.com/t5/VoIP/quot-Parameter-lt-param-gt-requested-type-X-but-is-of-type-Y/m-...

 

But they don't really address the issue, other than to say that these may be spurious. The config files show no Pre-3.3.0 entries, no errors, and no duplicates. Which leaves me with two questions:

1. Is there any way to get a better handle on what these mean? If they are legit, we would like to make sure they get resolved.

2. If they are truly spurious, is there any way to stop getting them, since they just muddy up the logs making finding useful information more challenging?

 

Thanks!

 

3 REPLIES 3
HP Recommended

Hello AcousTech,


welcome back to the Polycom Community.

I have moved this to the Skype for Business section as this is more a Skype related question.

 

Usually our official advise is that End Customers should not really try and start looking at logs as the Logs are only for Polycom support to be looked at.

 

You may easily misunderstand them or they imply there is a Problem when there is not.

 

Again the messages you have found are there in error and do not really mean anything. Usually in regards to logging levels this is something we get pushed inbound by Skype for Business in later versions (5.5.0 or later).

 

In regards to your actual issue of accounts logging out please check this entry => here <=

 

In regards of fixing these type of messages you would need to raise this with support.


In order to raise a support ticket you need to work with your Polycom reseller as they need to do this for you. End Customers are usually unable to open a ticket directly with Polycom support.

If this is some sort of an Internet discounter please post either your phone's MAC address or your Polycom devices serial so I can look up who would be able to support you. This may not be who you purchased the Polycom device from.

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

Thanks Steffen.

 

The errors, if they are to be ignored, are unfortunate noise. We've had them with the 5.x series of firmware whether we were using on-premises Lync Server 2013, or Cloud PBX(Phone System). Hopefully they can be stopped eventually.

 

Regarding account lockouts, we are very familiar with how to find these. The interesting thing is that when it's the VVX that causes it, we see this in the Windows Event Log, event ID 4740, on the Domain Controllers:

 

Caller Computer Name: (none)

 

It's that (none) that's particularly interesting. When it's a PC, we see the name of the PC. We also know it's the VVX because when we sign out on the phone, the lockouts stop. Conversely, if the BToE connected PC is not logged in, the lockouts continue. Furthermore, they throw an error saying:

 

"Authentication failed. Re-enter the password to access Exchange services."

 

Anyway, I understand that opening a ticket is the thing to do. We'll pursue that. If we find anything useful out, I'll report back. Also, if anyone else has ideas we're all ears. 

 

Thanks.

HP Recommended

OK. I _think_ we may figured this one out. This article provided a clue: I think S4B was forcing BToE to off, but Exchange Calendaring was enabled. Our on-premises configuration was that we were setting BToE to on/auto pairing. So, since Calendaring was enabled, it would try to use BToE credentials to authenticate, and eventually cause lockouts. Changing the appropriate settings is covered here, and here. Basically, the default settings are:

 

EnableBetterTogetherOverEthernet      : False
BetterTogetherOverEthernetPairingMode : Manual

 

So we configured our tenant like this:

 

EnableBetterTogetherOverEthernet      : True
BetterTogetherOverEthernetPairingMode : Auto

 

Hopefully this will fix the issue. Interestingly, we had to do a 1-3-5 reset to get this to work, because when the inband provisioning came down to the phone it started core dumping until we made sure there was no override file in place, and did the config reset. Now, we wait and see...

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.