SharePoint Server 2016 Release Candidate and Project Server 2016 Release Candidate are now available

SharePoint Server 2016 Release Candidate and Project Server 2016 Release Candidate versions were released today, January 19th. I’ve been fortunate enough to have been working with SharePoint since the earliest versions in around year 2000, so after so many generations it’s very nice to see the latest release being feature complete and closer to the final 2016 version. I wanted to write a few thoughts on SharePoint Server 2016 while spinning up my VMs to update with the latest RC build.

You can download bits for both release candidates here.

Where are we today?

After SharePoint releases in 2001, 2003, 2007, 2010 and 2013 we’re finally very close to SharePoint 2016. Here’s the helicopter view with the history and the near future for SharePoint:

As I see it, SharePoint 2016 is still relevant today. While SharePoint Online, and other services Office 365 offers such as Office 365 Groups, Planner and Office Online provide a lot, there are still requirements and needs for certain content and functionality to stay on-premises.

While SharePoint 2016 is soon ready for prime time, we’ve said warm-hearted goodbyes to InfoPath Designer 2013, SharePoint Designer 2013, SharePoint 2010 and Internet Explorer 8, 9 and 10.

I can’t say I’m missing InfoPath, at all. It was time for it to go, after so many years of struggling with its identity and features. I had very high hopes for InfoPath since 2003 when the initial version was released. At or around 2010 time frame I finally gave up. PowerApps, which is currently in gated preview, is a somewhat close replacement to InfoPath but it’s not really a mental successor but rather something that evolved in recent years with the rise of mobile devices and ad-hoc needs for line of business apps.

For SharePoint Designer 2013, I’m old school in that sense that I worked with Frontpage when HTML was still a coding technique. I was happy to see some features ripped away from SharePoint Designer with the name change some years ago. Since there is not going to be a SharePoint Designer 2016, I see the 2013 version of the tool mainly useful for working with workflows and maybe troubleshooting Page Layout issues. I normally do not have SPD 2013 installed anywhere, and I hope I can keep living that way in the future.

What about Office Online Server?

Office Online Server (OOS), the successor to Office Web Apps (or “WAC” as it was awkwardly abbreviated) was not updated during today’s RC releases. For OOS, you must resort to using the Technical Preview that was released last September. It works very smoothly during my tests with the Technical Preview, as well as with later builds. I’m hopeful we’ll see a RC or RTM version of OOS sooner rather than later.

To upgrade or not upgrade?

Many clients I work with are using both SharePoint 2013 and Office 365 today. For them, SharePoint 2016 provides some new features they might need – especially with the new hybrid features. For customers using SharePoint 2010 in an on-premises scenario I anticipate SharePoint 2016 will be a major upgrade, and mostly a necessary one. I’m seeing the exact same discussion today with customers using Windows 7 throughout the organization and they are busy planning an upgrade to Windows 10, bypassing Windows 8/8.1 altogether.

It’s not as simple for SharePoint, as you cannot jump directly from SharePoint 2010 to 2016 without custom tooling or a third-party migration solution. Thus, companies seeking a solid path from SharePoint 2010 to 2016, must choose one of the following approaches:

1. Upgrade to 2016 with an interim upgrade to 2013 first. A very classic IT approach, which often works surprisingly well. The benefit for this approach is that Microsoft supports this, as a version-to-version upgrade is supported. The downside, and often something that is hard to verify during design phase, is the unforeseen technical issues and glitches with existing customizations and even built-in functionality that travels through 2 generations of platform. It often does not go through on first try, so planning ahead and reserving enough time and resources for multiple upgrades is necessary. Also, depending on existing database sizes, this might take considerable amount of time.
2. Use custom tooling and/or third-party solutions to migrate from 2010 to 2016 directly. Often a preferred approach. Depending on level and amount of customization, this is often a solid approach. Consider the cost of creating custom tooling, as well as purchasing a third-party solution – they are often not cheap, and still require someone to understand the intricacies of SharePoint issues when migrating complex structures and content.
3. Fresh SharePoint 2016 with minimal content migration. Not at all a bad choice either. Typically the new 2016 platform would crawl and index the old platform, but start with a fresh approach. This effectively cuts away all legacy customizations and issues but introduces a blank platform that needs to be built. This approach also grants an option for doing a staged migration over time, while simultaneously setting migrated content to read-only or simply removing it from the older platform. Keep in mind that this is a time consuming exercise, and probably not suited for a small farm with limited number of services.

I’ve created a simplified graph on the options described above, which hopefully clears this up a bit more:

Hybrid

Much has already been written on hybrid investments on SharePoint 2016. Start by checking out http://hybrid.office.com, a lot of guidance there. I’ve created the following image to better give an overview of the functionality that can be hybridized:

For larger organizations I see huge benefits with Cloud Hybrid Search. Smaller organizations who wish to move towards the cloud, I don’t see this as something each organization should deploy.

My setup

I’ve played around with different setups with SharePoint 2016 previews and builds. As of today, I’m mostly content with my current setup, where I’m running SharePoint 2016 Beta 2 with Minrole configured with the minimum number of servers, which is 5. There’s zero tolerancy for errors, so high availability is something I haven’t built for my day-to-day tests and demos I use the virtual machines for.

I’ve got a separate Active Directory Domain Controller (actually 3, since it’s a production domain I’m using), with one of each VMs:

• Front-end with Central Administration
• Application server with Central Administration
• Search
• Distributed Cache
• Custom with Project Server
• Office Online Server
• SQL Server 2016 (CTP 3.2)

This gives me a fairly lightweight approach for testing most aspects of SharePoint 2016, Project Server 2016 and SQL Server 2016. I can also easily scale the farm up and down by adding new VMs, and simply selecting a role with Minrole.

Through Central Administration, I can now see a clear overview on what’s going on and where.

I’ve deployed all VMs to a separate Hyper-V host, with 2 Intel 750 NVME SSD devices. I’ve never seen SharePoint start up and execute so fast, so it was a worthy investment!

What next?

The following months will be a great time to play with the release candidates. I’m especially going to test in-place patching/upgrades from Beta 2-builds to RC-builds using the zero downtime patching approach. I’m also gearing up towards upgrades from SharePoint 2007/2010 to 2016, but at the same time I’m seeing little interest so far from companies wishing to move from 2013 to 2016. It’s early days, but I keep remembering the interest when SharePoint 2010 and 2013 were released, and now the focus is much more geared towards Office 365 than on-premises SharePoint.