It’s been a month since our last update to the client and quite some time since we’ve seen a security update. This update brings one fix. Kb 4461487 takes the Office 2013-based client from 15.0.5071.1000 to 15.0.5085.1000.
Whilst browsing the UCS 5.8 release notes I couldn’t help but notice the addition of support for Wi-Fi connectivity, added to all phones in the range that possess a USB port (except the VVX1500 apparently). This is delivered via an Obihai USB dongle, the “OBiWiFi5G” – which I was able to pick up for $AUD45 at the Bays Du e. So now we have the makings of a wireless VVX…
Well, it’s only kinda wireless – it’s still tethered to power, and that hardly makes it wireless. I wondered what we could do about that… but I’ll address that in my next post.
It’s been a month since our last update to the client and our fresh Spring update [here in the southern hemisphere] brings one fix. Kb4092457 takes the Office 2013-based client from 15.0.5059.1000 to “15.0.5067.1000” (according to the KB).
It’s not an uncommon requirement to provide a “courtesy” phone in a public area. In a hotel it might be a “house phone”. In many deployments all the visitor does is lift the handset from its cradle and the phone autodials or “hotlines” to the required destination.
If you go looking for the details of the wallpaper or background image sizes for the VVX family of phones you might fall into the same trap I did.
You might have seen this table in the documentation:
Optimal background image size (in pixels)
VVX 300 and 310
208 x 104 pixels
VVX 400 and 410
320 x 240 pixels
320 x 240 pixels
480 x 272 pixels
800 x 480 pixels
What isn’t immediately apparent is that this is the FULL screen size, not the USEABLE size. Place a logo too close to the top or bottom and it will be cut off by the “title bar” with the time display and line details at the top, or the softkeys at the bottom.
It also became clear in the process of testing this that despite the 400- and 500-series having the same absolute size, their useable size differ slightly, potentially requiring a different background image for each.
Coming not a fortnight after our last update to the client, this one reeks of a “whoops” – and yes it does look like it could fix some amusing/embarrassing issues. The Office 2013-based client jumps 10 builds to 15.0.5059.1000 courtesy of Kb4032250.
Kb4346579 User’s display name that has special characters is shown with an emoticon in Skype for Business
Kb4346578 Can’t input messages until clicking participants list after taking control in screen sharing in Skype for Business 2015 (Lync 2013)
Kb4346577 The display name with an ampersand (&) is incorrectly shown in IM conversation window in Skype for Business 2015 (Lync 2013)
If you click the Sonus category here you’ll quickly notice that I’ve written about the Sonus/Ribbon REST interface on and off for years now, as it’s such a handy way of peeking and poking into the SBC without interacting with the browser.
And so it came to pass last week that when presented with a challenge, I’ve again resorted to REST and PowerShell to deliver the fix.
The challenge – refresh the AD Cache
My customer is planning on migrating a couple of thousand users to Skype for Business quite gradually, and for that we’ve proposed the fairly standard upstream model, with the SBC doing AD lookups to determine if a user is enabled for SfB and thus decide where to send the call. If you’re not familiar with it I drew a picture and added an explanation at the top of this post back in 2014.
The catch is that the SBC’s minimum refresh period is an hour, and the customer doesn’t want to be potentially waiting that long for it to kick in after a user’s been migrated. They’re also big users of automation, and so logging into the SBC to clear the cache by hand isn’t really an option.
Thankfully Sonus added the option to clear the cache to their REST interface, and it didn’t take me a lot of effort to “save-as” a script I’m working on (more on that soon) to come up with “Update-RibbonADCache.ps1”.