Skype for Business Mobile Client Coming Soon

You may have recently seen an update to the Lync 2013 Windows Phone Mobile client where upon starting the app it informed you a new version was coming soon. A recent blog post explains the same – teasing us Windows Phone users but no date has been offered. Unfortunately at this time we only get to see the screenshots in the blog post and the notice in the app. However, it is nice to see that the Windows Phone is getting the application upgrade first with the others following.

 

Product

Version

KBs

Download

Lync 2013 for Windows Phone

5.9.1371.0

MS Download

 

http://blogs.bricomp.com/image.axd?picture=/Skype4B_WP_Mobile/Skype_Upgrade_for_WP.jpg

 

Additional Notes:
Lync Server 2013 build number is 5.0.8308.887

Lync 2013 Client build number is 15.0.4727.1001

Skype for Business Server 2015 build number is 6.0.9319.55

Lync Group Chat build number is 4.0.7577. 4409

Lync Group Chat Server build number 4.0.7577.4409

Lync Group Chat Admin build number 4.0.7577.4409

Lync Attendee build number is 4.0.7577.4461

Lync Attendant build number is 4.0.7577.4098

Lync Phone Editions build number is 4.0.7577.4463
Lync Phone Edition (Tanjay) build number is 4.0.7577.4463
Lync for Mac 2011 build number is 14.0.11

Lync 2013 for Windows Phone build number 5.9.1371.0

Lync 2013 for iPad build number 5.7.563

Lync 2013 for iPhone build number 5.7.563

Lync 2013 for Android build number 5.6.3.1
Lync 2013 for Android tablet build number 5.5.3.8919
Lync Windows Store App build number is March 2014

Lync Basic 2013 build number is 15.0.4420.1017
Lync VDI 2013 build number is 15.0.4420.1017


The truth about Call via Work in Skype for Business 2015

This year at Ignite I had the privilege of being asked to speak - this time the topic was "Planning and Deploying Call via Work for Enterprise PBX Users". As always, I had a great time preparing and presenting the topic however there are some that did not receive the message as well as I had hoped. For the record, we speakers are not paid to create and deliver our presentations. I present because I love to speak, especially when it is about a product I am passionate about and LCS/OCS/Lync/Skype4B definitely falls into that category!

It is true that Call via Work (CvW) is not a new "feature" of Lync/Skype4; but, it is also true that it is now being implemented in a new way. The key to the "little different" is where the feature is being exposed. The best example of what the feature is and where it was previously can be seen in the Lync 2010 Mobile app. For all intents and purposes, the 2010 Mobile feature is the Skype via Work feature, simply now in the desktop client.

So with all that said - why was I viewed as a hater of the feature? To clarify - I do not hate the feature, I simply do not agree with the concept of using it for Enterprise PBX users (my topic). :) My warnings of blind implementation were taken a little too direct. I was hoping to present the message that CvW was now an option but to plan and prepare prior to any implementation. Just because the feature is there doesn't mean we should/need to use it.

Without rehashing what I said regarding the feature and its limitations as a PBX feature, simply stated I believe attempting to use this feature as a replacement to RCC is a mistake - and 9 out of 10 Microsoft engineers agree (no, that is not a real statistic but everyone loves math). The feature parity is not there so that should be a given.

In addition, the users must understand the process. This understanding is something more than just making a call (as we often say, dial-tone should just simply work and users expect that). IMHO, in order for the feature to be used correctly, the user must understand the call flow concepts so intelligent decisions may be made (by the user).

Last point was administration of the feature is a nightmare for those environments that wish to control the call-back-phone. Yes, PowerShell is our friend and yes, PowerShell can help automate the need to create a CvW profile for every user - but there is still the potential for a single profile per end-user - yuck! Since this is a PowerShell-only task that means typical Level1 and perhaps even Level2 support will not be involved making the provisioning process tedious, cumbersome, and prone to errors.

Could Microsoft make the process better? Sure - a simple option in the policy that states the call-back-phone number is automatically set to the users' LineURI would be an awesome feature/option. One global policy, one setting, and we are done. We could then make user policies for those that we want to be different if that was our need. Or vice-versa - we could set the global to no set call-back-number, a user policy to use the LineURI, and then the occasional odd-ball users where they do not match we could create yet another user policy. Today the options are limited but who know what the future of Microsoft holds. One thing is for certain, options are the key to Skype for Business and that is what we need.

So, stepping back a bit, let use start with what is CvW (I know, a little late in the game but better late than never)?

CvW is a feature that allows the end user (assuming allowed by policy) to set their ring-back-number that will be used when making outbound calls from Skype4B. The user would initiate the call, their specified number would ring, and when the Skype4B user answered the incoming call, the system would bridge their two calls together presenting the user's Skype4B caller-ID to the outside callee.

Awesome right? That means I can be at home, make a call back to a customer/vendor/whomever and it would appear to be coming from my office. Perhaps that is an awesome strategy for staying at home when the boss is away and any calls to the boss would look like they were coming from the office. :) Or perhaps your Internet connection at wherever you are is simply unreliable or experiencing poor bandwidth so that a VoIP call would not be practical. Or maybe you simply forgot your headset and would rather not talk into the microphone of the laptop, so using a land line makes more sense (or cell - whatever number you wish).

The point is - there are all kinds of reasons you may want to use this feature; in fact, there are a bunch of good ones. My favorite use happens to be when I am travelling. Inevitably the hotel Wi-Fi is congested and poor quality at the end of the day; if I need to make a call to anyone (family, friends, clients), I use the hotel phone as my call back number and I have a great calling experience. However I am not using it - as my presentation title suggested - as my PBX phone in hopes of retaining life out of my PBX system. Instead, I am adding to the feature-rich experience of Skype for Business, something we all can appreciate as a good idea.

One of the general use concepts from Microsoft's perspective deals with "what do I do with my PBX and desk phones if I implement Skype4B? Am I duplicating systems?". In some aspects the answer is yes - in fact you are. However, there is a potential use case where instead of purchasing a new desk phone and ripping out the PBX we simply tie Skype4B into the existing system using CvW, and create the hybrid-type solution. As mentioned in the presentation, this is not the correct solution for all phone systems, companies or even users. This rolls back to making intelligent deployment decisions and testing, testing, testing. Ideally once the ROI on the old phone system is reached, it would be removed, Skype4B would replace the system as a complete solution, and everyone is happy.

In my experience and with my customers this would not fit well but the important thing to remember is that you have options.

Hopefully this clears up the confusion on my like/dislike of the feature and feel free to leave your comments/questions below, I'd love to hear your thoughts on the matter.