AC firmware v3.0.1.x BToE button greyed out

Scenario

BToE is pretty nice.  But let’s face it.  Not always easy to work with.  Especially when a service provider insists that a buried setting be configured so as to disable the manual concepts and default to automatic.

So, let’s figure out how to get an AudioCodes 450HD with the latest firmware (3.0.1.9.367) to play BToE with us like WE want, not how somebody else wants. 

OOBE for a phone that is going to be qualified for SfBO is with the BToE pairing forced to “automatic.”  This results in the button being greyed out when you go to MENU on the phone.  In this mode, BToE pass-though mode works just fine.  Web login to SfBO works as expected.

But what if you want to do something like, pair a wireless laptop with the handset device always CAT5 so you can just grab the laptop and go?  Like a laptop is designed to work? 

The Fix

What we need to do is light up the BToE button so we can get a pairing code (essentially a representation of the device IP).  Not exactly easy to find for those who don’t typically read 200+ pages of setup. Like me.

Hmmm… (page 113 of LTRT-14820 450HD IP Phone for Microsoft Skype for Business User’s manual ver.3.0.1.pdf) says

Going to the admin manual…. ( page 157 of LTRT-09943 400HD Series IP Phone for Microsoft Skype for Business Administrator's Manual Ver. 3.0.1)

And that does work to enable the BToE button.

The cfg file is available here – there is the semi-standard “download the file, modify the file with text editor, upload the file to phone routine.”

Here is how the phone cfg file looks by default…

And here is how it needs to look.  After uploading the cfg file, the phone will restart and you can then manually pair.  Remember that the manual pair code is case sensitive.

SfBO policy

Make sure that your Office 365 admins, if that role is not you, changes your online policy for ip phones to enable BToE, and further more to not change the pairing setting.  For more information see this.

https://webcache.googleusercontent.com/search?q=cache:hYptjYU9T9AJ:https://technet.microsoft.com/en-us/library/mt629497.aspx+&cd=1&hl=en&ct=clnk&gl=us

Summary

BToE button greyed out, but automatic pass-through BToE works.  You want control of that button so manual pairing is possible for wireless connections.  Modification of the cfg file is required.

As always,

YMMV

Restricted Office 365 OWA–Skype on-premises Integration

Scenario

Office 365 tenant established.  Exchange Online (EOL) for the user mailbox.  Skype for Business on-premises for IM/P.  Users are mixed – some have full Office suite, others are just a browser.  Security is tight.  No federation is desired or allowed with partners, vendors, spammers, or public (consumer) Skype. In addition, the requirement also stipulates that no authorized user can use the system remotely without going through a VPN. 

This last requirement means that remote users via the Edge server must be disallowed – but….won’t the Office 365 users be remote?  Great question.  We will cover that down below.

Because of the user software mix, we need the pure browser user to have OWA (EOL) integrate with the SfB on-premises.  Not the most attractive (visually and functionally) solution from the user perspective, but it does work.  Specifically, the function requirement was for OWA users to have presence information and be able to IM.

This article will not attempt to show the end user how to muddle through using SfB with EOL OWA.  The focus is just providing the service.

So, here is a visual of what we want… presence going both directions between the on-premises SfB users, and at least one of the users is using EOL OWA.

OWA User

On-premises user

How to

Obviously, we need an on-premise pool of some sort, and an edge server.  And then get your hybrid working.  In this case, the tenant (and the EOL work) was up and running before the SfB project started, so all we had to do was make sure that the Azure AD Connect was done right. 

  Danger Will Robinson!  

Because the AAD Connect was done prior to to SfB schema extension, the AAD connect will need to be FORCED to reread schema and synchronize.  You can read about this in a somewhat related post here. 

Moving on…

Having taken care of the obvious install and configuration items, the next thing is to establish hybrid posture.  If you have not already done so, you can read up on it here, here, and here.  Pay particular attention to this last reference.  Failure to do this will result in a no-go..  If you want all the fancy-schmancy integration, then you will need to do this here also. 

Now that you have all that done, we are done.  Right?

Well, no.  Remember that we needed to have no federation with anyone other than an Office 365 user, and no remote user access?  That seems to be a bit conflicting, yes?  But no.  A remote user is someone using a full client.  A bit of testing showed that Office 365 connecting to the on-premises SfB was a federation user not a remote user.

As a final bit of constraint, we did not want to be changing the external firewall.  So what to do?  Maybe we need to do a little something with Edge configuration and policy, eh?

Here is our Access Edge Configuration:

From the top down, we need to federate – Office 365 is a federation.  Per security requirement, no partner domain discovery, which closes out contacting anyone other than our own domain.  No need to send an archiving disclaimer to people we cannot talk to.  Per security, no remote user access.  Lastly, no outside access to web conferencing, so no need for those pesky anonymous attendees.  Just to confirm your deepest doubts, here is the SIP Federated Domains list:

Here is the External Access Policy:

Again, from the top, and note that we only have one thing checked…federated users is the requirement.  Nothing else needed… XMPP is pretty much dead nowadays anyhow; no remote users, ergo, no need for that, and without public user federation, no need for that either.

Conclusion

We had a set of requirements:  OWA integration between EOL and on-premises SfB.  Security concerns were that no other domains be contacted, and none of our domain users can be remote.  EOL users were not using Outlook, just OWA and we needed presence and IM.  We did not do the full OAuth as those features were not part of the specification.

YMMV

AudioCodes Updated 4xx firmware

Audiocodes has released an updated 3.0.1 version for all 400HD models. Comparing to the 3.0.1 GA, this version includes mainly bug fixes. Please refer to the new release notes document to see the list of fixes. For customers that still did not move to 3.0.1 GA and plan to move to 3.0.1, it is recommended to use this version (instead the 3.0.1 GA).

Version name:

• UC405HD_3.0.1.276.img
• UC420HD_3.0.1.276.img
• UC430HD_3.0.1.276.img
• UC440HD_3.0.1.276.img
• UC450HD_3.0.1.89.367.img

According to my source, these new firmwares are anticipated to be posted to the AudioCodes website (www.audiocodes.com) sometime early next week.  In the meantime, my phones (420, 440, 450) seem to get along right well with the new code.

As an interesting side note…my web login/BToE combination now works as expected.  Previously this was not working, and I know our corporate IT recently changed the Office 365 BToE status, and it could have been the firmware.  If you are having issues, maybe this firmware will help you.

I have a zip file with updated documentation and firmware files here.

YMMV