SharePoint 2016 Features: Cloud Inspired Infrastructure
We've been discussing how SharePoint 2016 is “born in the cloud” (see SharePoint 2016 Features Post 1), however the average Admin logging into the SharePoint 2016 Central Administration for the first time might have a hard time believing it since resembles SharePoint 2013.
Being “born in the cloud” means that SharePoint 2016 solidifies a true hybrid scenario for engaging content and capabilities between on-premises and Office 365 while simultaneously taking the lessons learned from Microsoft's on-going Office 365 implementation and translating that to our on-premises experience.
There are several pieces related to this cloud-inspired architecture that are expected in SharePoint 2016 – some that are hybrid-based and others that are improvements to the on-premises experience. In no particular order:
While the hybrid picker already exists in SharePoint 2013, SharePoint 2016's Hybrid Picker allows you to configure your SharePoint farm to function as a hybrid in exactly the manner desired. This is more wizard-driven for ensuring that everything just works, and your hand is held through the whole process.
SharePoint Search Improvements
Mentioned previously as an end-user benefit, search has been improved in several ways. First, there is a single authoritative index and results for content from SharePoint 2016 and Office 365. For this article I'll focus a little more on how this is done. SharePoint 2016 continues to use the Cloud Search Service Application (Cloud SSA) that was designed to integrate the indices from on-premises and the cloud in SharePoint 2013. An interesting benefit of the Cloud SSA is the ability to also index SharePoint 2010 content if needed. Everyone's concerned about sensitive content being sent to the cloud accidently, the Cloud SSA is ready and you can keep indices on-premises.
Fast Site Creation
Site Collection creation and provisioning can be a time consuming process, especially when done in bulk. Fast Site Creation is a new feature in SharePoint 2016 that helps mitigate some of those concerns.Currently when new Site Collections are created, there’s a template used as a basis that introduces particular features and structure and similar. Ensuring all features are activated (plus any custom ones or specialty pieces) and ensuring all lists, libraries, and apps are present can take some time – not just for provisioning but for UAT and remediation in bulk. In this context a new Site Collection is built from scratch each time. Fast Site Creation aims to use a template to generate this new Site Collection, and rather than making a variety of API calls there is instead a direct copy within the Content Database from the template. Configuring and using this template requires PowerShell (or other programmatic access) but is fairly straightforward in SharePoint 2016:
Next is the creation of the SiteMaster. This is effectively the template that is used for the creation of all other Site Collections when using Fast Site Creation. The templates are broken up on a per Content Database basis and a per web template basis.
The creation PowerShell cmdlet is New-SPSiteMaster and it looks for both the Content Database in question, and the web template that was already enabled for a SiteMaster. Both can be provided as a SharePoint object or a string of the name.
The creation cmdlet is subject to many of the standard parameters we’re used to in SharePoint such as Confirm, Language, and WhatIf. Just like with enabling the SiteMaster for a template, Compatibility Level is optional and will default to the highest possible level if not provided.
To get a list of all SiteMasters in the database, the cmdlet to fetch is Get-SPSiteMaster accepting a parameter of –ContentDatabase:
Lastly, to take the template off the list the cmdlet would be Remove-SPSiteMaster accepting a parameter of –ContentDatabase and also the GUID of the Site Template:
Once the SiteMaster is constructed, it’s time to create a Site Collection using the new template. The process is very familiar, as it’s the same PowerShell syntax for Site Collection creation since SharePoint 2010 with an extra flag.
The PowerShell cmdlet is New-SPSite with the flag –CreateFromSiteMaster. That will use the template over the normal creation process.
Keep in mind, these Site Collection templates are actually Site Collections in their own right as we can see in Central Administration and through PowerShell. However they are locked for change:
Previously in SharePoint there were rough guidelines on what types of servers should be in the farm (App Server, Web Front End (WFE), SQL Server, etc.) but the descriptions of what those servers are supposed to be doing was fairly generic. As a result there were users having Search Servers and App Servers serving up content for end-users just the same as WFEs, and WFEs that were doing intensive Search work. This happens due to overall customization as time goes on with the SharePoint environment as well as simply setting up the farm outside of the standard practices.
To make life a bit simpler, SharePoint 2016 has introduced the concept of MinRole. When adding a new server to a server farm, the SharePoint Products Configuration Wizard asks how you would like the server to be templated:
A brief explanation of the roles as explained by Microsoft:
Front-End: Service applications, services, and components that serve user requests belong on Front-end web servers. These servers are optimized for low latency.
Application: Service applications, services, and components that serve backend requests (such as background jobs or search crawl requests) belong on Application servers. These servers are optimized for high throughput.
Distributed Cache: Service applications, services, and components that are required for a distributed cache belong on Distributed Cache servers.
Search: Service applications, services, and components that are required for searching belong on Search servers.
Custom: Custom service applications, services, and components that do not integrate with MinRole belong on Custom servers. The farm administrator has full control over which service instances can run on servers assigned to the Custom role. MinRole does not control which service instances are provisioned on this role.
Single-Server Farm: Service applications, services, and components required for a single machine farm belong on a Single-Server Farm. A Single-Server Farm is meant for development, testing, and very limited production use. A SharePoint farm with the Single-Server Farm role cannot have more than one SharePoint server in the farm.
Keep in mind that the Single-Server Farm install is the replacement for the former Standalone Install that was available in older versions of SharePoint. Single-Server farm will not install SQL (that is required separately) nor is it meant for any production usage.
This can be accomplished programmatically as well. To join a server to an existing server farm while leveraging the MinRole option, the following PowerShell will assist:
These decisions are also reflected in Central Administration where it displays each server’s role and whether it is compliant with the role. Should the server not be compliant there will be an option to remedy.
However, these server roles exist solely to make the process of raising and maintaining farms easier. Should you wish to opt out of this process then choosing the Custom role is possible? That will allow services to be configured as desired.
Zero Downtime Patching
One of the biggest concerns that any SharePoint team has run into over the years has been the dreaded “Maintenance Window” in order to ensure the environment is patched and up-to-date. If SharePoint is treated as a mission critical business platform, especially if it’s being used globally, downtime may be difficult to obtain, and requires work in off-hours.
Thankfully, as part of SharePoint 2016 being designed from the Cloud, the Cloud concept of no downtime during patching has been implemented on-premises. Rather than delivering large Cumulative Updates (CUs) and smaller (yet still robust) patches, Microsoft is breaking up the updates into smaller bundles. These bundles will be targeted to specific systems, allowing for a granular update process to the SharePoint farm.
We'll continue to focus on the new features being brought to SharePoint 2016 on premises by examining the Compliance area of investment that includes Data Loss Prevention (DLP) and Analytics capabilities within SharePoint 2016 itself and hybrid functionalities.
Ryan Patrick Tully is a Product Manager at Metalogix focusing specifically on SharePoint and other Enterprise Collaboration Management systems. Ryan comes with a background of over ten years in Client-Focused Information Technology delivery, with the last three years focused primarily in the SharePoint space. Prior to Metalogix, Ryan was a SharePoint Developer for Axceler Software.
Adam is a Director of Product Management at Metalogix and a Microsoft MVP advocating for collaboration by connecting business needs with the right technology. Prior to Metalogix, Adam was a Practice Lead for Office 365 in a cutting edge Microsoft Consulting firm where he was responsible for moving customers to the cloud, designing and implementing information architecture (SharePoint Farm and content) and increasing user adoption. Adam is an ongoing member of the SharePoint Saturday DC coordinating committee and active speaker at various events.