Planning – how to find the best architecture based on requirements

Planning an enterprise SharePoint farm takes a lot of work. Do not skip the planning phase of your new farm as it will have consequences later during your move to that environment if you are not careful about doing some upfront work. The following exercise examples are based on existing company infrastructure and an acquired company that is merging their SharePoint into your new environment. In the exercises, we will go through some basic examples of how to identify the required architecture and configuration based on different versions of SharePoint and different farm configurations. These exercises will help you to figure out the necessary changes to your new environment and give you recommendations in those areas.

Exercise 1

The current SharePoint 2013 farm architecture used by your company that was assessed is structured as follows.

The architecture is as follows:

• Two web frontends
• One app server
• Redundant database servers (two)

The license details are as follows:

• Windows 2012 R2 Standard: Two CPUs, 8 GB RAM, C drive = 60 GB, E drive = 60 GB
• SharePoint 2013 Standard: Four CPUs, 8 GB RAM, C drive = 60 GB, E drive = 60 GB
• SQL 2012 R2 Standard: Four CPUs, 16 GB RAM, C drive = 60 GB, E drive = 60 GB, H drive = 2 TB, L drive = 500 GB
• NLB load balancing
• Two virtual server hosts: Eight CPUs, 96 GB RAM, C drive = 120 GB, E drive = 2 TB

The content details are as follows:

• 1 TB of data
• No custom applications
• No third-party applications
• File size max: 2 GB
• Claims authentication
• Supports 3,500 users

In our current company's configuration, you will see in the following diagram that we are lacking coverage for all the tiers within our design:

Figure 2.1 – The company's farm design

The acquired business's current 2010 farm architecture used in these exercises is as follows.

The architecture is as follows:

• Two web frontends
• Three app servers (one server dedicated to search)
• Redundant database servers

The license details are as follows:

• Windows 2008 R2 Enterprise: Four CPUs, 8 GB RAM, C drive = 60 GB, E drive = 60 GB
• SharePoint 2010 Enterprise: Four CPUs, 8 GB RAM, C drive = 60 GB, E drive = 60 GB
• SQL 2008 R2 Enterprise: Four CPUs, 8 GB RAM, C drive = 60 GB, E drive = 60 GB, F drive = 3 TB, L drive = 1 TB
• Hardware load balancer
• Four virtual server hosts

The content details are as follows:

• 2 TB of data
• Four custom applications
• One third-party solution
• File size max: 2 GB
• Scan to SharePoint capability
• Classic authentication
• One web application with forms-based authentication
• Supports 6,600 users

In the following diagram, we can see that there are four hosts and VMs are dispersed across the hosts for the best recovery and stability of the SharePoint farm:

Figure 2.2 – The acquired farm design

Let's look at some scenarios to gain a better understanding of how we can plan our architecture.

Scenario one

In our assessment, we found that we currently support 3,500 users running SharePoint Server 2013 Standard and the company is planning to grow to 5,500 users by the end of the year due to an acquisition of another company. SharePoint adoption is low at this point at your company but the company you acquired uses SharePoint 2010 Enterprise heavily, using Key Performance Indicators (KPIs), SQL Reporting Services, and Power BI. Your management plans to adopt some of their business applications for use within your business processes. Your management would also like you to take into consideration that as the company grows with this acquisition, the understanding is that this will bring more customers, which then brings more revenue for the company. This will, in turn, create more jobs and more users to support the enterprise.

Recommendations

In this situation, we have many things to look at from a planning perspective. We need to take into consideration our environment, the acquired environment, and our move to SharePoint Server 2019. Some of the big things that jump out to me in looking at the requirements are that we have a 2010 Enterprise environment and a 2013 Standard environment. This means we need to make sure that our SharePoint 2019 environment supports the applications developed in the acquired SharePoint farm. This would mean upgrading the SharePoint environment from Standard to Enterprise as well as upgrading SQL Server to Enterprise level. In this case, we would also need to upgrade our Windows operating system to Windows Server 2019.

Authentication stands out as well as we have both farms using different authentication methods. This would need to be resolved as part of the integration of both farms into a single farm. The acquired farm could be using classic authentication, which is obsolete and not supported in SharePoint 2019. The course for upgrading from classic to claims would be to migrate the users over in that environment using the original AD domain. Once the authentication process is completed using PowerShell, we would then migrate the content once it had been updated to claims authentication. Testing this process in your dev and test environments first would reveal any troubleshooting efforts you may need to make before trying this in your production environment.

The next recommendation in planning for the new farm is we would need to resolve areas of the farm architecture that will not support the users from a service standpoint for redundancy. The architecture is also not built for growth as the company could bring on more users in the next year due to the acquisition. In this plan, we need to make sure we can accommodate the new users that come on board, which means we may want to add one or two more web frontends. Adding one would be ideal, but when you have three, it gives you flexibility when doing updates to your servers as there are always two more available to handle the load. We also need to think about MySites and how we approach that configuration. We should look at using OneDrive as our target if no applications are being run against files in SharePoint currently.

When thinking along the lines of redundancy as part of the solutions, we also need to find a new way to support our load balancing for our web frontends, which is more reliable and doesn't take away from our web frontend service performance. We would need to look at a hardware load balancer at this point and maybe even hire a person to handle this from a technology perspective if you do not have someone in-house already. This is very important as you add more users to the platform and spread those users across two or more servers to handle the load. Power BI and other data-related services will need to be considered as well as these could give a much more intense user experience and workload on the web frontends.

There is also the need to redefine the number of hosts that support the VMs in your environment. Currently, we have two hosts with four servers, which provide no redundancy for each area of our platform. In our platform for SharePoint, you will see that we can mock this up with MinRole, as seen in this diagram:

Figure 2.3 – A mock-up in MinRole

When following some host best practices, you can see that we need to create redundancy from a host perspective so that if one host server is lost, we could still be somewhat effective at keeping the service up and alive until that host server is brought back online. There are other tools available as well for the cloning and duplication of VMs, which can be considered as a partial solution.

When cloning and duplication tools are used, these tools can help with duplicating servers. One thing to mention is SharePoint doesn't like servers to be duplicated or cloned because of the complexity of the farm/server configuration, so there would be no way to capture the total configuration of a server without some deep recreation and manual steps. It's best to keep servers on standby that are already in a warm standby state. These servers should be part of the farm or at a state where the operating system is installed and configured and SharePoint is ready for connectivity to the farm. In these situations, third-party tools can come in handy, as you can use them to recreate your server farm from scratch – I specifically refer you to AvePoint's tools. At this point, we would install the server as usual with a new server name and configure the server quickly using PowerShell or AutoSPInstaller.

To provide support for SQL Reporting Services and Power BI, which is non-existent in our company farm but does exist in our acquired farm, we would need more server power to support these services, as well as a plan for the installation of these integrations for the farm. When looking at our new features, we can see that SQL configurations have changed in support of SharePoint Server 2019. This would mean that you will have to understand which version of SQL to use (2016 or 2017), which was mentioned in Chapter 1, Understanding Your Current State. Plan your SQL supported services using the information in the new features area to make sure to architect your solutions based on a new configuration.

Scenario two

In our assessment, we found out that we currently have authentication concerns. Each environment acquired and our company farm support different authorization methods. We also noticed that both environments are currently using separate domains and neither one has trust between them. Both domains are using AD for user login but the acquired farm is also integrated with SAML for authentication within the enterprise.

The acquisition farm uses custom code within the farm to support user profiles. The custom code brings in user identities from the source of employee profiles instead of AD, which this code is established on one server in the farm. We need to find out how we support AD, SAML, claims authentication, and services for user profiles going forward in SharePoint 2019.

Since we are on SharePoint 2010, shredded storage has not been introduced. So, the size of your overall content is one to one. So, if there is a 2 GB file in a library, all versioned documents are 2 GB as well. Once you migrate to the newer version of SharePoint, these documents will change in size if you use a migration tool. If you are using content database migration, these documents will stay the same size in the database and will not change until you start adding versions in the new 2019 library. Once you start using shredded storage, you will see a dramatic decrease in document sizes and storage being used in site collections.

The need to check the sizes of your content databases and site collections is so important as you should have been managing them as you managed your current farm. Some of these databases could be over the best practice limits and may need to be broken up, or site collections may need to be moved to a new content database. Shredded storage will play a part in this as well once you get over to your new environment if you are on an older version of SharePoint. You will see some dramatic downsizing in your file sizes for versioning.

Note

Make sure to examine some of your data within your libraries. I had one customer who had one Excel spreadsheet that was set to have unlimited versions in SharePoint 2007. When calculating the size of that one file, it came up as a 20 GB footprint in the content database. At this point, with all the versions of this document over the years, they limited the versions and saved over 18 GB of storage on one file.

Recommendations

There have been a lot of updates to the SharePoint architecture in the last two versions of the product. As for authentication, SharePoint only supports AD out of the box as of SharePoint 2016 and 2019. This change really limited what authentication methods could be used to connect to SharePoint. Since we already have differences with user accounts using classic and claims identities, we would need to fix that issue first as stated, and then figure out support for SAML. Forms-based authentication is still supported in SharePoint 2019 and is still configured pretty much the same as it always has been.

Microsoft provides a product that gives a solution for these types of issues and integrates with SharePoint seamlessly. Microsoft Identity Manager supports authentication stores that are outside of AD. This server would need to be built and configured to support a final configuration for SharePoint 2019. Migrating to SAML and using PIV cards is a project you would want to plan out thoroughly with a lot of testing.

With this type of security, an Active Directory Federation Services (ADFS) or trusted identity provider will come into play, and the ADFS server will be needed for the users to authenticate properly. ADFS is a server that gives access to sites within SharePoint for external access. There are other providers, such as Okta, who also provide these services in the cloud in which the integration is a solution and PowerShell would be used to create realms and connectivity to Okta for authentication.

You can configure this integration after you go through the process of implementing the new farm. This would need to be tested in a lower environment, or even a separate environment, before implementation within the production environment to make sure the authentication works as it should do based on your requirements.

There are many scenarios we can go through with this assessment data but I wanted to point out some obvious details to get you thinking about where you are in your planning and how you can start rebuilding your company's SharePoint environment with Server 2019. Please make sure that you have checked under the covers of every configuration, content database, service database, service, Global Assembly Cache (GAC), and site collection with the utmost granularity. The last thing you want is to be blindsided after your move to the new farm.

Looking at these scenarios gives a sense of what things we need to be aware of to support our environment. Essentially, the standard for a web frontend configured with Microsoft-recommended resources can support up to 15,000 users concurrently. This means that you need to understand your community and how many users you will be supporting with your SharePoint services. If you have more than that number of users, you will need to add web frontends and use a load balancer to distribute traffic between them.

In doing this analysis for web and app tiers, you will notice a cost associated with the hosts that will support your server VMs and costs for software and other incidentals, such as third-party solutions. You would also need to include outside network hardware and software needed for load balancers and other interfaces that may be required in your environment. As you can see, costs will add up.

In the next section, we will talk about costs and how these costs can be lowered by solutions and other known recommendations we can show to help you create a shopping list to get started with. Once you have really gone through your planning process, your shopping cart will be completed and you can order equipment and other software to help get ready for your installation. Right now, we need to make sure we are thinking correctly about what we are building and what we need in place to support our services.