Lync 2013 to Skype for Business in-place Upgrade...the experience

I was sitting at my desk today, waiting for (ironically enough) a client's new Skype for Business install to complete in a far far away country when I decided - hey, I am not expecting calls today, why not do a quick in-place upgrade to S4B?

Quick was not the operative word here. For reference, I have two pools - once user pool and one Persistent Chat pool (need it for demos :)), and edge pool, and a few trusted apps. Once I began the process - installing the admin tools on an admin server (not Lync), I upgraded the topology for the two pools, published, and so far so good.

The required KB2982006 was not installed on my FE servers so that was where we started, which required a reboot. Had I been wise, I would have disabled the Lync services so I would not have to wait for them to start post reboot of the server only to shut them down again so I could begin the upgrade process. I started the process on both pools, all servers, all at the same time. This was not an issue since all the services are shut down anyway, so there was no apparent communication occurring anyway.

The process started at 2:30pm my local time and the PChat pool finished approximately 30 mins later (less to uninstall and reinstall). However, the user services pool ran for two hours. It appeared that the servers were doing little to nothing during every step so I can only assume there is some fail-safe code slowing the process of uninstall and reinstall down. As a reference, the installation of the new Skype pool was completed (along with the Edge) in under one hour (granted basic install, no config, no uninstall).

I am happy to say that after the long wait, everything came up as expected and worked as expected. The edge pool was the last thing that needed an upgrade but I was waiting to get the inside pools completed prior to starting that process. I suspect it will not take long but will complete tonight and post my timings.

In short - make sure you have the requirements met for in place upgrading and the time set aside. Since the entire pool is down during the process you will have some sort of outage unless users are rehomed.

UPDATE 5/12

The upgrade of the Edge pool went as expected. The total time for upgrade was 30 mins and like the inside pools above, both servers were upgraded at the same time. I did notice that when I upgraded the Edge pool in the topology, the Skype-Skype Federation Search was automatically enabled. While this is a feature I do want, if you do not, or perhaps do not have the port open on the edge servers (outbound 443), then this is something you would want to disable before publishing.

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.