Here we are in the 1st half of 2015, and the anticipated general availability of Skype for Business 2015 is fast approaching. Microsoft has started to release details surrounding this new version of what could possibly be (and my opinion is) the best and fastest growing collaboration and communication tool on the market today. According to available data, 90% of the Fortune 500 use Lync in some capacity, and 89% of enterprises that trial Lync are including Enterprise Voice, Lync 2013’s flavor of SIP-based VOIP. With that in mind, and leveraging the popularity of Skype, Microsoft has rebranded the Lync Server as Skype for Business Server 2015 for this new version release.
With all that in mind, and keeping in mind that upgrading what might be the core communication application for your organization, we need to start looking at what the planning process is going to look like for this upgrade evolution.
In this article, I will outline what I consider to be the crucial considerations. I am not going to try to detail the product enhancements in this version, nor the pros and cons of taking this action; we will focus on the overall upgrade process and what your organization will need to consider BEFORE embarking on the procedures.
The General Idea
First off, Skype for Business Server 2015 (Skype4B) does not support three version coexistence. This means that Microsoft recommends that if you are partially into an upgrade to Lync 2013 that you continue forward and complete that process. If you have not started, then stand pat and upgrade from Lync 2010.
If you have Lync 2013, then you can take advantage of the in-place upgrade that is now available. If you are on, and staying with Lync 2010 until upgrading to Skype4B, then you will be building new servers and moving into/onto them. There is no path from OCS 2007 R2 or earlier.
Next, the overall flow is inside out, user pools first, then the supporting Lync server roles are upgraded; mediation servers, directors, and Edges. Yes Matilda, there is still a director.
A Few Specifics
All of the Lync 2013 infrastructure that we know and love is going to look the same in Skype4B. DNSLB, HLB, Reverse Proxy, firewalls, Web Access Servers, Persistent Chat, pool pairs, virtualization support, SBS/SBA; it is all there. About the only significant change that I see is the support for SQL AlwaysOn Database Availability Groups. If you wish, SQL clusters and SQL Mirroring are still supported. If you have mirroring now, there is a spiffy procedure to upgrade your mirror to AlwaysOn.
If you are using SQL AlwaysOn today with Lync 2013 – you can move straight into the upgrade, but Skype4B will never know that the supporting SQL is in an HA posture. While things SHOULD work, you will be firmly in a non-supported scenario with Skype4B topology not having all the facts.
If you want to get the SQL AlwaysOn, keep in mind that the AlwaysOn requires SQL Enterprise with the attendant cost. Unless your database team is dictating AlwaysOn for some technical or business reason, I simply cannot see the benefits of AlwaysOn over mirroring; but that could be just me.
Lync 2013 will run on Windows Server 2008 R2. So will Skype4B. However, if you take this route, you will be pretty much dead ended – Server 2008 R2 is getting a tad long in the tooth. Take a look at the support cycle, and then make your own decision. For the most part, I have been deploying Lync 2013 on Server 2012 R2. If this is the case for your organization, or if you have been doing Server 2012, you should be OK. But I would be thinking twice about moving forward with an in-place upgrade of Server 2008 R2 hosts. Server 2008 R2 uses a version of Windows Fabric that will update to Fabric 2.0, but about 100 or so bug fixes did not make it into v2, so using Server 2012 and 2012 R2 will get you the upgrade to Fabric v3, which is the optimum platform for Skype4B.
Whichever server host you choose to use, even the in-place upgrade has some prerequisites to install before running the Skype4B setup. As you might expect, the Lync 2013 servers should get all windows updates and the prerequisites before moving forward; the upgrade process will error out if it thinks something is missing. Nothing new here, but be prepared.
SQL on the front ends needs to be SQL 2012 SP1 (Express) to get the direct upgrade treatment. So you might need to figure out some time to handle this before starting the core upgrade project.
The Skype4B Topology Builder is going to be needed before you upgrade the first pool, and the Lync 2013 Topology Builder won’t open a topology that has been upgraded. Most folks run Topology Builder on one of the Front End servers in Lync 2013; but you cannot get to the direct upgrade features from the Lync 2013 Topology Builder. You are going to have to get the Skype4B Topology Builder onto something else; documented supported platform information is not available at this time, but a good guess will be x64 and Windows 8 or Server 2012 and up.
You are going to want to keep the Central Management Store until last. Obviously, if you only have one server, this won’t be a possibility. But if you have only one Enterprise Pool, you might want to consider standing up a 2013 Standard Edition to move the CMS onto; this will create a fall back position for you should things get ugly. I also think that a judicious upgrader will run export-csconfiguration and export-csLISconfiguration before starting; again, for the obvious fall-back planning.
If you have Survivable Branch Appliance (SBA), there is no current upgrade available. Microsoft is leaving that process to the SBA vendors. You will need to plan for a maintenance window during the upgrade as the SBA pool will be in resiliency mode while the central site pool is down for the upgrade. After the pool comes back from the upgrade, the SBA will register back into the central site just as before, so no worries there. According to the good folks at AudioCodes, it will most likely be until June 2015 before a vetted SBA upgrade process is fully tested; until then, the Skype4B pool will work with the Lync 2013 SBA just fine.
SBS will direct upgrade provided you have all the host server items covered just like on an SE or EE pool.
To direct upgrade pool pairs, the entire pool needs to be down. I suggest that moving all of your users to the other pool whilst upgrading will be a prudent move. Note that this does NOT MEAN doing a pool failover, just moving the users off. You might also want to consider a little disaster proofing by moving the conference directories. And keep in mind that your SBA structure will be down while the central site pool is down for upgrade. I suppose you could redo the SBA backup registrar relationship, but I think that is way more work than is called for.
Skype for Business is coming and there is a different light at the end of this particular tunnel. To whit, we can do in-place upgrades. The supporting SQL backend and how to handle that aspect of your environment will need examination and forward planning. Likewise, the host server version will demand attention and presents some decision points.