Resources Blogs SharePoint 2016 Frequently Asked Questions Answered

SharePoint 2016 Frequently Asked Questions Answered

Post Date: 03/10/2016

Since the announcement of SharePoint 2016 last year, we’ve been in a constant, open dialogue with both Microsoft and our customers in SharePoint 2016 previews, testing new features and developing best practices for migrating, designing, and preparing for the next era of SharePoint Server. In the process, we realized there were a number of very specific but commonly asked questions about changes in SharePoint 2016, taking advantage of hybrid functions in SharePoint 2016, and executing SharePoint 2016 migrations. As a result, we’ve created a list of frequently asked questions about SharePoint 2016! Have a question that’s not covered below? Leave a comment on this post and our experts will answer!

Top Questions about Migration and Architecture in SharePoint 2016

Content database size recommendations have gone way beyond 200 gigabytes in SharePoint 2016. How would the backup/restore operation performance be taken care of if content databases grew too large?

Large content databases are a concern for backup and recovery. In on-premises environments, the strategy to address this could involve multiple approaches and strategies:

Consider if your content databases need to actually be that big. Consider policies that sweep old, unused, or archive content out of the SharePoint content database using a Remote BLOB Storage solution like DocAve Storage Manager, but retain accessibility and search-ability of that content from within SharePoint.
Ensure that your backup/recovery solution can use both traditional, streaming types of backups and snapshot-based backups, so you can capture quick snaps of the data periodically and then offload to backup media less frequently. DocAve Backup and Recovery supports this type of functionality.

In very large data environments, we have leveraged our deep integration with NetApp storage hardware. We’ve been able to support hundreds of terabytes of SharePoint content in standard backup/recovery scenarios.

What is the best way in SharePoint 2013 to have a site where internal workers and clients have access to it to share their project data, and will that translate to SharePoint 2016?

There are a few different strategies for allowing external users to access your SharePoint 2013 sites. One is to add the users to your internal Active Directory (AD) (the “v-dash” approach) and assign them permissions like any other user. Another approach is to use an additional authentication provider, such as forms-based authentication in the Web App for the external users so that you do not have to create accounts for them in your internal directory. The third option is to use a different mechanism to share the content to the external parties. Other systems like Box or Dropbox are options, but the problem is that they move the content OUTSIDE of SharePoint making it harder for internal users to find and collaborate on it. A solution like AvePoint Perimeter solves this exact problem by keeping the content in SharePoint for the internal users, but creating a replica of that content in a secure, external-facing location called the “Perimeter Portal” for external users to access. You can determine what those external users are allowed to do with the content (read, download, edit, etc.), and all changes on both sides (SharePoint and the Perimeter Portal) are synced so you still have only one version of the truth. In SharePoint 2016, the options will remain the same as the “external sharing” features of SharePoint Online will NOT be coming down to SharePoint 2016.

For full MinRole farm, it was stated that the minimum number of servers is four. What is the topology?

For the MinRole-compliant farm, the 4 required servers are:

Front-end
Application
Distributed Cache
Search

The MinRole concept is that you have a server play one (and only one) of these roles. For a fully resilient farm, you would need nine total servers – two each for the front-end, application and search roles and three for the distributed cache as one needs to act as a quorum server. More information can be found on this TechNet article.

What if you had templates that moved from SharePoint 2007 into SharePoint 2010? Is it better to just start over than try to migrate these to SharePoint 2016?

Microsoft’s general guidance is to use the OOTB site templates rather than customizing templates. However, if there is a business need, you could create the custom site template on the destination and do your migration using a tool like DocAve Migrator – just be sure that you have updated any customizations or features that your template relies on for SharePoint 2016 and deployed those customizations before migrating your content. If you do want to follow Microsoft’s advice and convert your custom templates back to standard ones, DocAve Migrator can map your old templates to standard SharePoint templates during the migration process.

I would like to know if it would be better to implement SharePoint 2016 from scratch or migrate from SharePoint 2007.

That depends on a number of factors such as the current state of SharePoint 2007. How much content is in there? How much is current? What is the business need regarding continuity of the SharePoint applications and data? As there is no “in-place upgrade” of SharePoint to 2016, you will be standing up a fresh instance of SharePoint 2016 anyway. The decision of whether to migrate some or all of your existing sites and content has to be a business decision. AvePoint’s Discovery Tool can help you understand what you have in that source SharePoint 2007 environment and give you suggestions for what you may want to move (and how difficult it will be).

I am on SharePoint 2010. Is it better to wait a few months and upgrade to SharePoint 2016 (after first jumping to SharePoint 2013), or just upgrade to SharePoint 2013 (yet have that technology be four years old already)?

SharePoint 2016, while technically a new version, is largely based on SharePoint Online’s code base, which is well battle-tested. In turn, SharePoint Online was based initially on the SharePoint 2013 code base, so in essence, there is a long and established lineage for SharePoint 2016. The general consensus is that SharePoint 2016 should be more stable than a typical new version would generally be. That said – it’s a business decision. To help you determine which course of action could be best for your organization, check out our post on Choosing Your Upgrade Path from the SharePoint 2016 Readiness Guide blog series.

What are the SQL Server requirements for SharePoint 2016, and do they affect the way that you might prepare for an upgrade/migration?

Databases require the 64-bit edition of SQL Server 2014 Service Pack 1. RAM requirements have increased some since the last release. Make sure to check the hardware/software requirements before building out your farm. If those are in place, you should be good to go.

Does the upgrade require the creation of a new farm?

Yes. SharePoint has not had an in-place upgrade option for a few versions now, so the migration process always involves standing up a new farm and then migrating content to it.

What do you think of the Microsoft service to export site collections and ship hard drives to them for import into Office 365?

The backbone of this service is a new Azure API, and we use it ourselves in our High Speed Migration to Office 365 features. The API allows content sitting in Azure to be sucked into SharePoint Online and OneDrive for Business much faster than was previously possible. We have built lots of additional value into the usage of the API so take a look at some of the blogs and materials we have on this capability.

——————————————————————————————————————————

Do you have a question not covered on this list? Ask it in the comments below and one of our experts will get back to you!