Planning for SharePoint Server 2016 can be challenging due to lack of Microsoft documentation. If the purpose is experiment with SharePoint 2016 deployment on Azure IaaS, you can grab PowerShell with some of my notes down here. This post is going to share my real-world experience when planning for SharePoint 2016 farm on Microsoft Azure.
You want to know more as to why SharePoint on Azure IaaS is still a good consideration? Read here
With my experience, there are the following areas to help you get started with planning for SharePoint farm:
- Farm Topology
- Capacity Planning
- Identity Management
- Business Continuity
Farm Topology is very important for every SharePoint deployment. It indicates how the farm looks like from architectural perspective. From the SharePoint farm topology, we will have better preparation for capacity planning, high availability and security. Such a question like “How many web front-end server in your SharePoint farm” sounds very familiar with those whom have been doing the architecture design.
In SharePoint Server 2016, Microsoft introduces a new feature called MinRole. Described by Microsoft, MinRole is a new farm topology based on a set of predefined server roles. During your farm configuration in SharePoint Server 2016 you will see a difference compared with the version of 2013. You are allowed to specify the role for the server you are going to configure. MinRole basically offers 4 dedicated roles:
- Distributed Cache
“Custom” role is the traditional setup like SharePoint Server 2013 in which you can adjust SharePoint services of your choice. For example, you can start Managed Metadata service on a server to call it an application server.
More than the dedicated roles, if you set up your farm with Shared Roles mode if hardware resource is limited. There are two options in Shared Roles setting:
- Front-end with Distributed Cache
- Application with Search
Shared Roles mode is only available in SharePoint Server 2016 Feature Pack 1 or later.
The Single-Server Farm option is used purposely for a development or testing use.
For more information about MinRole in SharePoint Server 2016, read this article
To plan for SharePoint Server 2016 farm topology, firstly you need to think of the type of farm. It can be a content farm to store content databases. It can also be a service farm that does not aim to store content. A service farm is used to host sharable service application where other farms are consumed. The following service applications you can share across your farms.
- Business Data Connectivity
- Machine Translation
- Managed Metadata
- User Profile (*)
- Secure Store
(*) User Profile Service Application is not available in SharePoint Server 2016. You need to plan for a dedicated User Profile Synchronization server running the core of Microsoft Identity Manager server.
Another type of farm should be mentioned here is Search farm. In this farm, you are going to build a multi-server Search topology rather than hosting all Search components on a single server in the farm. The Search topology depends on how large your amount of data is. It also depends on performance expectation, and how much of Search your application is used.
|Server Role||Required for Content Farm?||Required for Service Farm?||Required for Search Farm?|
|Search||Yes, if hosting Search||Yes, if hosting Search||Yes|
After defining the type of farm, start looking into each tier. You can follow MinRole guideline to identify SharePoint tier. There is a so-called three-tier model:
- Front-End Tier
- Application Tier
- Data Tier
The Front-End tier means by its name, where web services and web application pages are handled. Server in this tier basically receives incoming page request including query made in browser from end users. Front-End server often makes people confused if used in the security context. This kind of server called Front-End interfaces with Internet to add an extra layer to mitigate attack to your actual web front-end server. In SharePoint, if we call a server “Web Front-End” we do mean that this is not an interfacing server with reverse proxy or security model installed. It’s a server running the Microsoft SharePoint Foundation Web Application service.
My article posted here would clarify just a little bit of a so-called SharePoint Web Front-End server.
A server in Application tier often run one or several services which are associated to SharePoint service applications to function for specific business needs (e.g. User Profile Service, Business Connectivity Services…). A server hosting Search component and running Search related services is considered an application server. In MinRole, Microsoft separates Search role to help you better optimize your Search. Below is the list of available service applications in SharePoint Server 2016:
- Managed Metadata Service
- Secure Store Service
- Business Data Connectivity
- Visio Graphics Service
- State Service
- App Management Service
Excel Services Service Application, User Profile Service Application and Work Management Services are deprecated in SharePoint Server 2016.
A server in Data tier is just running SQL Server to store content databases and other SharePoint databases.
Make sure you understand three-tier model. You do not have as always to build your SharePoint farm as three-tier model. However most of the cases people still prefer talking about three-tier model.
Capacity planning is one of the indispensable tasks for every SharePoint planning. Capacity planning often comes along with farm topology to complete the final proposal. Capacity planning commonly is to identify hardware specification requirement to run your SharePoint farm, and how much of allocated space to store system files, SharePoint related files (e.g. Search Index) and databases. We often call it a familiar term “Sizing”.
To effectively sizing your SharePoint farm, firstly you need to identify workload characteristics in your SharePoint application. To know the reference of workload characteristics, read this article https://technet.microsoft.com/en-us/library/ff758645.aspx
The approach to accurately identifying your needed capacity is to build a test environment, run several testing tools and record the result for comparison. The more time the test is conducted, the more accurate the capacity plan. It can be easily done in a large IT company where hardware resource is ready for your test. Unless you should follow Microsoft guide. HP Enterprise also provides you a very good guide in planning capacity here http://h20195.www2.hpe.com/v2/getpdf.aspx/4AA6-5186ENW.pdf?ver=1.0
You should not too much worry of your capacity planning because you can tailor your SharePoint farm at any time at needed. It can include adding more server to handle your workload. For example, when your web front-end server exceeds load baseline, you can go to add another web front-end server then set up load balancing to handle the workload. This can be costly. However, if that helps improve performance, you need to consider. SharePoint is designed in such flexibility. Another reason as to why not worrying capacity planning is that Microsoft Azure as said allows you to scale up and out your infrastructure when needed.
Without identity, SharePoint Server 2016 will not work. In the past, setting up a standalone SharePoint Server 2010 or SharePoint Server 2013 is supported without an Active Directory Domain Controller. However, this setup mode is no longer supported in SharePoint Server 2016.
There are several authentications method supported in SharePoint Server 2016:
- Forms-Based Authentication
Each authentication has its own purpose and mechanism to work. For example, if you have no intention to work with federation trust, just keep NTLM as it is a default authentication method in your organization. Perhaps you might need to use Kerberos for better authentication performance.
This term perhaps should not be used in this article because it’s very broad. Business Continuity is often a set of activities to make sure the business operation is available even when it runs into a catastrophic. In the IT field, it often refers to making your system to be available as much as possible, depending on how critical your system is.
If your SharePoint runs many critical classified business functions, it is the time for business continuity planning. It can include implementing high availability and disaster recovery for your SharePoint farm. As introduced here, Microsoft Azure can be a very good alternative for hosting a DR farm with the capability of Azure Site Recovery.
The setup of high availability for a SharePoint farm needs to include all of the tiers from front-end tier with Azure Load Balancer, Azure Application Gateway to application tier with a pair of virtual machines running the same set of services, put in the same Azure availability set, to database tier in which you implement AlwaysOn, or use third party storage for Failover Clustering Instance implementation. This article is not going to give you step by step for every piece mentioned here.
There was a rumor without any official confirmation from trusted source that the leaked information that Snowden revealed was stored in SharePoint. Anyway, we all heard of that. The store would disabuse those who don’t have security awareness in their mind. Daily activities on SharePoint is to create document, share information and work collaboratively. Shared documents may contain intellectual property, financial report, confidential employee information, business result or so on. Imagine if any of this kind of information are compromised to your company’s competitor someday, it will probably devastate the company’s business. Moreover, the compromising would debase your company reputation.
If you’re interested in hands-on SharePoint farm setup on Azure with applied defense in depth strategy, go purchase my book here with only 9,99USD
I was involved in a few SharePoint disaster recovery projects related to security incident. I can’t tell you more details but these incidents resulted huge impacts on those companies from stock value deduction, reputation going down to increasingly employee turnover.
I have number of articles covering Azure IaaS security which you can refer here
Be aware that this is the first step to planning SharePoint Server 2016 farm on Microsoft Azure. Each key described in this article has more things to do. For example, with capacity planning you do need to know appropriate Azure VM size and storage to optimize your workload. I will cover these things further in future posts.