For you to understand this chapter and the knowledge shared, the following requirements must be met:

• Current admin experience on SharePoint farms 2007, 2010, 2013, or 2016
• Current enterprise experience supporting a collaborative user community with SharePoint
• Project planning experience related to SharePoint
• You must be a SharePoint power user

Planning a new SharePoint environment or a migration from an older SharePoint environment requires us to define future goals for collaboration solutions within our enterprise, as well as research to provide clear requirements and project schedules. Whether it's SharePoint or other collaborative applications, planning to add additional systems to your environment requires great insight. This requires attention to detail and building teams that can do the work to support the scheduling and delivery of the application.

For the record, I am not a project manager in any light but I understand what things should be identified as specific to a SharePoint implementation project. It doesn't take a PMP certification to understand the tasks and timelines needed for a successful implementation. These certified project managers look at these tasks differently from architects and measure against them using other mechanisms. In this planning chapter, I am just going to touch on the areas needed to help you as an engineer or architect understand your responsibilities and what areas need to be concentrated on as part of this process from an IT standpoint.

SharePoint is often a huge piece of the pie or central focus for many enterprise collaboration environments. There could be other cloud apps or large applications that play a part as well, but in this planning exercise, we will concentrate on SharePoint with some caveats where the integration or confirmation of other applications needs to be present in our plan. With SharePoint, there could be integration with the cloud or other Microsoft communication platforms, such as Teams, Skype, or OneDrive, which could play a part in how fast we can provide our environment to our user community. This may also require a different team or consultant who may be providing those services.

As you saw in the first chapter of this book, we assessed our environment, new features, and deprecated features, and did an overall assessment of our current state, be it new or already in place. In our planning process, we will use those documented areas to determine what needs to be completed to finish our project and what resources we may need to do so. We will also determine the time it will take based on these assessed areas by using the data to figure out what tasks are needed to complete the project.

These tasks could range from reporting or the clean up of our old environment to working to create our new environment. Some of our tasks could even relate to our last SharePoint project and the requirements will remain the same or look very similar. If you have an old SharePoint project plan, you can use some of those areas in that plan for a new project for SharePoint Server 2019. SharePoint at its core does not change, as you will see when we install a VM and host servers. Most of everything you have done in the past you will also do now. You will install SQL Server and SharePoint, which works very similarly to in previous installations. This can be said about every SharePoint installation we have installed since SharePoint 2007, with the exception of those environments where SQL Express was used for a single server installation, as this is not supported in SharePoint Server 2016 or 2019.

Goals and objectives

As part of our goals and objectives for our SharePoint project, we should proceed to start our planning by finding out the goals of the enterprise solution from a company standpoint. We want to make sure to understand how, as a company, they would like to use this collaborative environment to support the goals of the company. We also want to find out general information supporting the project, which would include information such as funding, completion expectations, and any other details related to the project.

This project will take a team effort as all requirements and tasks may not be specific to a central group. Coordination of these efforts is very important and should be completed before you start on any project, especially SharePoint projects. During this project, you will have internal meetings with many different teams supporting the project individually and collectively. This would include all external team representatives from the different specialist areas, such as Active Directory (AD), networking, database, server, governance, management, and user community, and whoever is a stakeholder in this implementation. These teams will need to be assembled, which would be a requirement before starting any technical configurations.

There could also be other projects in progress or in the planning stages that relate to your SharePoint project. This could mean integration points and/or other types of intercommunication that would need to happen to make sure your project is successful. An example of that could be an AD restructuring project. AD would be required to be completed before SharePoint could be installed and configured due to the fact that AD is the method of authentication needed for users and service accounts to be functional. AD restructuring, be it on-premises or on the Azure cloud, as a project could put our overall project on hold because identities needed for administrators and service accounts would not be able to be created. The reason AD restructuring is important is there could be a change in the domain structure or we could be upgrading to a newer level of server, cloud, or integrated authentication method, such as SAML. This could delay your project if you are bound to using this new AD structure.

One of the goals we need to understand before going forward is to determine the architecture and the reason SharePoint is being implemented. The architecture is important because it drives our cost, which also drives what resources we need to support the environment. As part of our assessment, we found out things that we need to change within our current environment and things we need to bring to the table to support our SharePoint 2019 environment. Let's take some fake data and make some determinations from that data to create some architectures to work with.

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.

We have seen how we use our assessment data to figure out the options to move forward with for our implementation. With those collected details, we need to examine them thoroughly so that we can architect our new farm. Since we have some details that will continue to be defined as we go through the project on how we move forward, we now need to take cost into consideration. The cost will not be your area of expertise because we, as technologists, want the biggest and the best technology to work with, but with feedback from management, we can look for solutions to support our dream environment while still saving money and getting the same stability with other products and services.

Management, however, will be looking at these numbers to make sure they fit within the company's budget. You can get some numbers from them to make sure you are totaling close to where they want to be with hardware and software costs. There needs to be an understanding and an explanation of the new platform so that management understands where the costs are coming from.

As an example, you may add a third-party tool as part of your needs assessment to help you with Remote Blob Storage (RBS). This solution can be beneficial in a lot of ways that management may not understand, and they may question why you are purchasing this solution. So, we must help management see the big picture of the architecture, which can help you with your case to receive more money if needed so that approvals can be given for your architecture.

While we can be looking for ways to find savings in our project, we know first off that we have little or no choice in using Microsoft platforms in almost all cases, especially SQL Server. There really is no way to leave Microsoft per se, because we know everything is built on Microsoft's platform that supports SharePoint. If we look at this with our eyes wide open and examine the new features mentioned in this book, there have been some big changes with SQL Server 2016, 2017, and 2019. We may be able to take advantage of the fact that SQL Server now runs on Linux, which may save us money on our operating system licenses. Although this is new, we can test the server to make sure we are comfortable with using this platform within our architecture to support the database layer of our farm. We know that we will have to use Enterprise to support the efforts of bringing the acquired farm applications in-house for use.

There are other areas as part of cost savings in hardware and software that we will be looking at next.

Virtualization

Which virtual platform will you use? You have many choices when finding a platform to support your VM servers. Some of the solutions cost a considerable amount, but then there is Hyper-V, which is part of your Windows license. There is also other virtual server technology, such as VMware, which is a valid platform as well. Find your platform for your virtualization and find out which platform is cost-efficient while giving you the support and stability needed for your environment. Host cost can also save you money as the cost for the server resources needed to support a development environment will not be the same as a production or User Acceptance Testing (UAT) environment. Plan your resources and do not just buy the same amount of resources for all the environments you plan to support.

Disk space and speed

Not all disks used for our host and VM servers or data storage need to be super speedy. There are some areas where we can let go of speed and exchange it for capacity and/or vice versa. Some areas that can use slower disk speed are backup storage locations and record center content for database storage. These areas are usually low usage and do not require speed to get the job done.

Cloud and Services

The Azure cloud is another option for your SharePoint implementation. You can build your infrastructure there and connect it using hybrid configurations if needed for Microsoft 365 and Azure AD. The cost for this platform can be expensive depending on the size of your farm, the number of users, and the horsepower needed for your server builds. You could also hire or train someone to manage the infrastructure, which may be expensive but could provide the goals the company is looking for. Savings for computer rooms, electrical, and other environment support would go down as well for cost savings.

Azure will bring some complexity to your architecture, as stated, due to the expertise needed to set this environment up correctly, along with those skills in the management of this architecture. Azure provides many services and software features that make it seem overwhelming, but with some training and coaching, this environment can be a rewarding experience due to servers being outside our organization and managed in the cloud. With that, it helps to cut costs using this platform, which cuts down on electricity bills, leasing for computer rooms, fire prevention systems, and server hardware costs.

If you are considering Azure, make sure you understand the benefits you can achieve using Azure:

• Deploy a SharePoint farm and scale it up and down as needed.
• Host in a cost-effective environment.
• Advantages of location with minimal investment.
• Disaster recovery.
• Move VMs from on-premises to Azure.
• Run Microsoft applications where they are safe.
• Run Microsoft applications where they have been tested to run effectively.

When configuring your Azure environment, you will want to build in high availability. The following diagram explains how your Azure environment should look for SharePoint Server 2019:

Figure 2.4 – Azure On-Premises Gateway

AD could be located on-premises or in Azure, depending on your configuration. For more information, you can refer to https://docs.microsoft.com/en-us/SharePoint/administration/designing-a-sharepoint-server-2016-farm-in-azure.

AWS

AWS is another cloud offering that can provide a cloud space to implement your infrastructure for your SharePoint environment. AWS provides similar supported cloud infrastructure that can be compared to Azure. While being not as complex as Azure, it takes a large learning curve to get started on both platforms, but as we are technologists, we know how to dig deep to learn new technologies.

Microsoft 365

Migrating to Microsoft 365 is another option to get SharePoint without the server hardware. There are other issues that go along with this type of implementation because you have to think about other Microsoft applications that would need to be moved as a part of this migration. Some of the solutions you use today may need to be rebuilt using other technologies provided with Microsoft 365.

We will see Exchange as part of the offerings for Microsoft 365. This is a migration that will take time and planning, which could lead to putting your SharePoint migration off until this is completed. The Office server would not be needed as part of your planning because it's built into Microsoft 365. This would be one server application we would not need to worry about as the functionality is already available.

As licenses are complex with the offerings in the cloud for the suite, there are different levels of licensing that are available. The higher the cost, the more features and space you receive. The platform also offers government tenants that are specifically created for government entities and do not support some of the flash and glamour that normal tenants support. You would need to look at these options very closely and find something you can move into.

Storage is key in this environment. There may be some splitting up of sites needed before your move. Splitting sites involves taking content from a site collection and moving into another site collection so that the site can grow and stay under a quota. As you sort the sites that are being moved from on-premises to the cloud to make them work as part of Microsoft 365, please be sure to take a look at the size of subsites and areas within the site collection to make the best decisions going forward.

Make sure to make the right decision going forward. Stop here and evaluate where you are and what your future is for SharePoint and other Microsoft ecosystem applications within your environment. Stepping to the cloud makes sense in some cases where you want to save money, but there is more to it than money when you look at the whole picture.

SharePoint licensing

Finding the best licensing for your on-premises implementation can be as easy as asking yourself whether you will be using business intelligence as part of your configuration. If you don't need it, then you should get the licensing for the standard version of SharePoint. Enterprise licenses are expensive, but with the need for data and functionalities that this version provides for reporting, KPIs, and other data reporting, this is your go-to solution.

With development environments, you will want to support the same version of SharePoint so that developers are developing on that same platform. There are versions of SharePoint that are free with Microsoft Partner subscriptions that can be used for this purpose, as well as free versions that can be downloaded as 90-day trials that also work. Ultimately, you want to gravitate to a license that can be sustained with no issues or complex situations coming up in the future. It's better to get a license that works forever than to plan your development on a 90-day license for your operating system, SQL, or SharePoint.

Battling contingency

Backup and Disaster Recovery (DR) are some of the most important solutions you will implement within a SharePoint farm. Without it, you will fail and fail miserably. The way you implement backup and DR will impact everything you build in SharePoint and how you could restore it from scratch if the need arose. This can be a rewarding experience in which you get a solution that makes this process easy, or you can stick with SQL backups and make your administrators work harder to restore and provide consistent support for your SharePoint implementation.

To start, as mentioned, SQL server backups are the basic backup plan for a SharePoint farm. Backing up databases, logs, and other areas of the server is very important to recreate the server when a disaster happens. In most cases, you will have an Always On configuration for the data tier of your architecture. Rebuilding this configuration and the associated data can be very complex without a tool to help you manage the databases involved.

If you add RBS to the mix of your supported configurations, you then add a different level of backup support that would need to be in place to support this integration. This solution is very complex and if your backup is not done correctly, you may not be able to restore your farm correctly, which could lead to disaster. The content used in a farm that is supported by RBS is programmatically associated as content within the sites using links to the content to associate the content on the disk within SharePoint.

Note

RBS is a way to keep large files outside of the database on a disk so that the files can be retrieved without disrupting the database and other users working with content in that database. The larger the file, the more work for the database to bring it to a user. If this is kept outside of the database, you get better performance when using large files.

Business intelligence as a service adds complexity to the farm and to the backup and DR solution that supports the farm. Business intelligence integrations need to be planned and even put on their own web application so that they can be used separately from the rest of the users in the farm. Separation using its own application pool separates the web application from the rest of the sites to provide better performance for those using this service. This service pulls on the server resources and will cause a delay in your data rendering if you're not careful to follow some best practices.

Solutions for backup and restore are available but there is only one I recommend and trust as I have seen this solution work and have supported it in many environments. AvePoint has a backup solution that helps in almost all scenarios for contingency planning. Their solution is superior because they have been in this space from the beginning. Over the years, I have seen many solutions they have offered and they really get administrators' pain points.

As I have stated, AvePoint offers a full backup and restore solution. The solution runs from its own server in your environment and uses agents to communicate with your farm and not embedded farm solutions. This is a very good way of integrating a solution from a third party into a farm. The solution is easy to clean up, not like embedded farm solutions I have seen that require troubleshooting to uninstall. Their suite of products gives you many solution options, including backup and restore, blob storage solutions, and so many other ways to support your farm.

AvePoint also has a solution for replicating content to another farm over a data connection. This will sync the content so that all content that is updated in the production farm gets updated in the DR farm. There are many configurations that can be determined for your environment but the bottom line is, you want to make sure you cover all areas with your backup solution that supports the SharePoint farm so that you can recover either from backup or a standby DR site.

Monitoring

Often, we think that as we add products or third-party solutions to our architecture, we are absorbing costs that we could be saving, but we have to look at this under different circumstances to support the farm proactively. The areas where we save money are not always cost savings but also downtime, which may cost you more in the long run. When looking at SCOM, which is a monitoring application used to monitor services and performance in SharePoint, this product can save a lot of cost in downtime, which in some cases can add up to dollar amounts for employees not being able to perform their jobs. If you look at it from a hosting model where we want the best up-time possible for our customers, this is a component we would not want to leave out of our architecture.

The savings monitoring can bring to the table are invaluable to our architecture, as we can find out areas of concern before something happens that can bring down the service. When a service is down, you lose confidence and you also lose money. Most customers will request information on why the service was down and may ask for money back for that downtime, in the end, depending on the severity.

Customers do understand, but when you have a business that depends on a service to work, they expect the service to work as it should. We often take monitoring for granted and use other tools and checks to figure out our pain points, such as Windows logs, ULS logs, and Task Manager, where we can monitor the resources on our servers. This is not the best effort for SharePoint as there are many services that could be in limbo if not monitored consistently.

There are many tools out there that work to provide monitoring, but SCOM is one of the more integrated tools that can work within your farm and other Microsoft products in your enterprise. This product gives you a one-stop solution for your Microsoft products and interface into those enterprise areas that need constant monitoring. There is another tool I really like called SolarWinds that also gives you real-time monitoring of services and server resources.

There are other areas where the benefit of having other applications integrated into our architecture outweighs the costs that come up in the SharePoint cost for hardware and support. Make sure you protect your investment while saving in other areas of the platform.

Now that we have understood how we can manage the cost of our environment, let's look at the aspect of resources.

Adding resources also adds to the cost of our project, but in most cases, the resources requested will be needed to implement and support the project. Resources are generally handled by your project manager but with full transparency supporting the IT team and management. Everyone involved needs to make sure that there is a good project plan as part of structuring this project and make sure there is the availability of resources, as well as enough team members to support it. The team also needs to make sure that they have the cycles to start and finish the jobs they are assigned to complete.

There could also be concerns with resources that have been assigned to the team where there could be other projects these resources have that could take priority or eat into the time they can spend on the project. One of the biggest errors I have seen in the field is under-resourced SharePoint projects. This is one area where you do want to pay attention and make sure you either hire personnel or contract the positions to get the work completed.

The change management board and operations teams also come into play in planning as since we are adding or changing resources within the environment, these changes need to be confirmed by the owners of the environment. This can also add more pain to the implementation and take up time you were not planning for. Make sure to add in planning for this change review to make sure there are no hidden scenarios where you will get behind on the project. One thing you can do also is talk to this group before you get started. This will help them understand what's coming and they may be able to give you details they may need to move forward successfully. I notice this especially in secured areas where the SharePoint service would be used.

Another issue that is always seen from my experience is that I will run into a SharePoint admin that has not had much experience with the product and/or there is one SharePoint admin supporting a large farm alone. I have also seen cases where SharePoint is running without any real supervision but relied on heavily within the company. In these cases, these scenarios almost always bring to light the issue that the support personnel are overwhelmed and do not know where to start to fix issues and expand when added requirements arise. The team, in some cases, can also be running the help desk, managing customers, applying updates to the servers, and supporting all other areas that come with the SharePoint territory. Make sure you budget for the right size team for the environment you want to support.

Here is an example of a resource matrix to support SharePoint:

Figure 2.5 – Resource matrix

To avoid scenarios where you have overwhelmed support personnel, management needs to understand that this product is not easy to implement, manage, administer, support, and maintain. The platform requires many skill sets, along with experience, to really support the environment in the right way. There are many best practices that can really drive you crazy if you do not have experience with the product that will creep up on you at a later time. There is a reason why these best practices are used and specified in the Microsoft documentation to support the environment, so do not bypass them.

Being new to the product or not as well seasoned can really cause projects like this to fail. Your resources should be somewhat seasoned in the SharePoint space and you should have a good understanding of the product. Remember that your project is only as good as the people implementing it.

The outcomes of this resource exercise should help create thought processes around gathering resources to support the platform for the help desk, site collection admins, and farm admins. The support for the platform is essential and we should not hesitate to get these resources in place before starting the implementation. Training and knowledge sharing also make a big difference in these roles; do not forget it!

I can't tell you how important it is to have resources available that understand the product and can help make supporting the product easier using separated roles that bring together a team of knowledgeable professionals. You will see a big difference in how users perceive your service and how less complex the support process can be.

Assessment review

An assessment review is a meeting of the minds of IT and management supporting the efforts of the implementation. This could mean your CIO, director, and, in some cases, the CEO would be part of this meeting. The goal of this meeting is to review your assessment and its results. As assessments can be done over intervals of time, these meetings may happen when assessments are needed for the farm environment. The attendees would have a chance to review the document before the meeting so that they can come to the meeting with an understanding and questions about the document as well. This gives those teams a heads up on what the project consists of, gives them an idea of the resources that may be needed during this project, and helps them to plan for what resources can be provided for you to work with during the project.

This is a somewhat difficult task because you do not want to overstate the project goals and you do not want to show huge costs for the project, nor do you want to overstate the requirements with solutions not needed. When management is reviewing whether to approve the work, you want to be cautious and explain things in good detail (where they need to be explained) and leave some areas out that are common and not elaborate on them in great detail if no questions are asked. This is because the scope of the meeting could be directed in the wrong direction due to comments on details that are already clear and understood.

However, we should be prepared for anything during the meeting and questions could come out of the left field. Make sure you know your presentation well and practice it with the other team members so that everyone understands the direction the meeting should go. If things are rehearsed or talked about in depth, there will be no error in the delivery of the message sent during the meeting. Keep the meeting simple and to the point, validating the assessment and areas of concern, how you plan to remediate those concerns, and the direction or path for the future.

Management will be all ears and listening to certain details. In the meetings I have been a part of, most managers and even executives do not want to hear too many technical details. They want to hear concerns, fixes, and costs, as well as how you are addressing those concerns. Those areas of technical concerns help with new solutions you plan to implement, but overall, management has no ears for IP addresses, protocols, and so on in most cases.

Now, I am telling you this from my experience, but there could be some CEOs and upper management who may want to hear more technical details to figure out why you are heading in a certain direction for the platform. Some CEOs and other management are technical, and in some cases, you will need to explain your position more thoroughly. You need to gauge your situation and plan for it accordingly.

Prioritizing requirements

As things change within an organization, the goals set out within an organization may change as well. When an organization makes those changes to its future goals, this can bring changes in personnel, security, structure, and business processes. As part of those effective changes, IT can be affected, which can bring change to the way the IT department delivers solutions and secures data and content, platform support, governance, and other IT policies, which, in turn, will affect the way the technical teams support the enterprise.

As a part of the goals of this planning prioritization exercise, we need to define the purpose and motivation for our new or migrated SharePoint farm to this newer version of SharePoint Server 2019. When defining priorities, please consider the following items:

• Top tasks
• Milestones
• Deliverables
• Schedules
• Organizational charts
• Resources

All these areas can affect our implementation project in ways where we will need to rework our project schedule. We don't want this to happen, so planning around current and long-term projects is a must to avoid any situations where you have to, for example, change your schedule or resources in the midst of implementation. If you want management to get involved and give you some grief, just let that happen and you will see things fall apart.

Another example would be a change in deliverables. If we had a certain set of deliverables and all of a sudden you forgot about RBS, and have to make a change where you have to go back and ask for money, this brings the pain. You want to make sure you prepare all areas, especially technical solutions that form the environment, to support the farm and its functional components.

Prioritizing what's important as part of the implementation is needed because there are logistics involved as well. You need hardware before software, you need a network before you can configure servers, and you need SQL installed and configured before SharePoint can be installed. These examples help you understand how important order is in your project plan.

With that, there will be some tasks that take priority in these examples. In the case of ordering software, finding out when the software would be delivered is an example. The delivery of equipment and software can ruin a project plan as well. It's best to get a list of the items you need to start the process before you get started writing your project plan, so you don't have any items that fall by the wayside. Licensing and even funding sometimes take time to procure, especially in government projects. Make sure to put in requests once you finalize your architecture so that these areas can be in the works while you are finalizing your plan.

This is a good place to start evaluating the timing and prepping resources. Look over your work and make sure you have taken everything into consideration. Changing things now can make a big difference in your timing, so you do not want to change too much at this point. Also, evaluate the platform you are proposing. Make sure you're making the right decisions and press forward.

Generating a mapping of how site collections per department will be represented in a hierarchical architecture is a task you should carry out with the management and stakeholders. The hierarchical order can make a difference in how users navigate the structure of the sites but can also be confusing to them if not thought about thoroughly.

Creating an intranet of the content doesn't have to be a hard task. Use resources around you to help with the organization of the sites. Where I believe this process goes wrong is when teams who are responsible for this architecture do not take into consideration the landing page. The landing page in all site collections can be used to help users navigate the site collection and even sites within the web application. Users should be able to browse just like when they access content on an internet site, which gives them links to areas within the site collection that are available to everyone. This method gives you the ability to bring content that could be buried in the site to the forefront, but other users outside your site may need access too. Breaking inheritance in a site, list, or library is always looked down upon, but in these cases, this should be considered to secure information that not everyone should have access to. We would also use a separate site to support content that is "for everyone" as well. Presenting hyperlinks that expose the content should be part of this exercise, which is to organize the sites and content for ease of use.

Some sites I have seen have terrible designs and content structure. Content exposure is so important on landing pages; for example, the name of the site is important with a real description of the department's responsibilities in the company. This verbiage makes it clear to the user looking for information that they are in the right place to get the information they are looking for. Listing the name of the site collection administrator and their contact information is another piece of good information that should be a part of the site collection landing page. There should also be some information on some team members and links to the department forms where information is collected, for instance, an employee vacation request form. This could be useful for the users surfing your site where they shouldn't have to have lower-level access to fill out a form that could be used by everyone.

As always, security is another area of concern of most site owners, but it doesn't have to be. Using the landing page as a read-only page is commonplace and in SharePoint 2019, you can use a team or communication site as your landing page as well. If the user is not a team member, then give them access to what they need from the landing page and secure the content they need to have access to with permissions. Make sure to create groups for your department users so that those users do not get mixed in with users with read-only access. All employee groups would get read-only access and internal groups that work behind the scenes within the site could give these users deeper access as needed.

If we look at the external sharing of information in our farm, we could see how some of the components within SharePoint 2019 and the cloud affected as part of your implementation. There are some things we want to be aware of in opening our content for sharing outside the company. Overriding that governance rule will make your admins work a little harder. You also need to trust that your users are sharing information that is OK to share. The security of your content is most important when it comes to sharing. I have seen some bad practices that could cost a company their secrets because external sharing was enabled and other mobile solution apps were being used within the company without IT knowing. Be on top of external sharing and make sure to secure your content.

Site collections are a great way to capture a bulk of content at a time as these can be a one-to-one relationship with content databases. In this configuration, you now have a database that encapsulates all the content for one particular department. Management of a content database is what you would like to work with as a farm admin and not a content database with mixed site collections from different departments. This site hierarchy gives you complete isolation of the content from a security and recovery perspective. All backups are of that database and content can be restored individually without having to interfere with other departments' content if something were to happen to the database. Migration efforts are clean as well, with no mixed site migrations or work beforehand to separate sites into separate content databases.

Database naming conventions should be used, as well as site collection URL names. We should, as administrators, be using good naming conventions to make sure our content is organized and named so that we understand what that content is. This goes along with naming our site collections and providing content in the site collection that describes it. There is nothing like going to a client's office, reviewing their farm with them, and seeing errors where content databases cannot be contacted. In review, I sometimes find out they do not know what the database is supporting, what the content is being used for, or even what department it supports. This all happens because it is named improperly. Please don't be that client.

Site collection templates should also be used to add functionality to your farm's logical structure when needed. One of the big perks of using some of the site templates are data compliance, record center, and document center templates. These templates can enhance how your logical structure works together. These templates can be used to create automated processes that protect content and store content. These processes use key data fields to set policies that automate the protection of data. Make sure to use these features in templates so that you have a well-rounded process in place when needed.

Physical server assessment

As we start our physical planning for servers and roles within the farm, we need to understand what architecture will best support the user community and be the least complex to support. Some solutions may be needed to support our farm, but it's a best practice to really understand your requirements and not just add solutions because they will be used minimally. One example of that would be a distributed cache and web frontend MinRole. If I was providing services for 100,000 users, then I would most likely separate the cache cluster process over several servers, but if I was only supporting 5,000 users, I would most likely keep them together on one server for a small deployment and over two servers if I needed redundancy.

Note

RAM comes into play as in the initial farm, we will only see 5% of our RAM on each server supporting the MinRole dedicated to this service. The more we play with the configuration of distributed cache, the more RAM you may have to reserve for this service. We talk about this more in Chapter 9, Managing Performance and Troubleshooting.

Physical design is not hard like it used to be. Before, we had to worry about services and what services were started on what server. Now, with MinRoles, that issue goes away if you use them. We can now be alerted for compliance based on the role of the server in the farm. If a service is not supposed to be started, we will see that the server will be out of compliance. MinRoles help with these types of scenarios by keeping the services needed to support the role of the server minimal. In the past, we were responsible for managing this ourselves, and I am sure Microsoft saw the writing on the wall from its long list of support tickets, which gave them the idea to put this MinRole in place. The MinRole was created to help administrators and was started in the MOSS version of the product, but was discontinued in SharePoint 2010. The MinRole helps administrators follow best practices and wisely use server resources to support how farm server resources are configured and to support the performance of those resources. Here are some examples of MinRoles:

Figure 2.6 – Examples of MinRoles

In creating a physical architecture, we have to know what we are building. If the farm is going to support 5,000 users, then we figure out how important the farm is to our company's application support. Is it a tier 1 application, or is it tier 3, where we don't need redundancy and quick response times? In most of the companies I have worked at, SharePoint was a tier 1 application because everyone used it. I have also seen where it wasn't tier 1, but if one of the applications within SharePoint went down, it was a fire drill. We have to understand how SharePoint needs to be supported and have the company recognize its importance in the enterprise.

Now that we know our architecture will be tier 1, we need to take into consideration redundancy and up-time for the farm. Server resources and topology will mean that we have two servers for each tier and any other services that need to be robust in performance. Looking at our scenarios in this chapter, we know that we are part of an acquisition. The acquisition is bringing Power BI and large files to the table, which means we need a separate BI server redundancy and RBS as part of our architecture. 10,000 users may be a number that may be reached sooner or later, so three web frontends will be great as part of our architecture. A search may be a service we want to duplicate as we do not want this to fail as well.

Looking at these areas of concern, we can create an architecture for the hosts and the farm shown in the following figure for SharePoint Server 2019:

Figure 2.7 – An architecture for the hosts and farm

As you can see, we have redundancy on the hosts and redundancy within the farm. We also have the server resources to run the farm at a minimal requirement for SharePoint servers at 16 GB for each server, and all SQL servers at 64 GB, which is more than enough for this configuration. The SQL server needs this extra boost as we are using Power BI and SQL reporting services within the farm configuration, which can lead to big queries that pull on SQL resources pretty hard. If you remember, there are a couple of new applications we are introducing as part of the acquired farm configuration and these will be used by our users in a few different departments.

Aligning a farm to the requirements of the assessment is key in building a topology for the physical architecture. Make sure to take into consideration all areas of configuration, user traffic, and other areas that can pull on resources. Do not undersize your farm and always test your farm using a load tester as in Visual Studio. This will give you a sense of how the resources are going to perform using the number of users expected to be part of the environment that will use SharePoint.

Dev and test environments will also need to be stood up as part of the architecture. Dev environments vary in size. Usually, we have one SharePoint server and one SQL server as part of this environment just to do some little development on. This would support out-of-the-box development for different departments using separate site collections. Scheduling of reboots and testing should be coordinated with the users that require this development farm.

When talking about larger environments where there are several developers, each developer should get their own server. The problem with SharePoint 2019 is that it is not like older versions where you can install SQL Server on the same box and/or use SQL Express, as it is not supported. So, each developer, in this case, needs to have a separate SQL server for each server farm, or use a large SQL server to support all developers, using separate namespaces. This can work, but having those developers independent makes more sense as each should have their own environment.

Team Foundation Server comes in to play as well, so any code that's developed can be pushed for deployment and tested in the test environment before it's pushed to production. Pre-test environments can also be stood up in some cases where you want to validate before putting the code on your test environment. Test environments should be a duplicate of the production environment and should have minimal use and test content. This environment should be clean and the only changes made should be good changes that were tested previously.

Time and money are always part of the equation, so with that, we need to do our due diligence when planning our IT architecture. We need to review our requirements and make the right decisions to bring the best solution to management for the best cost. Looking at our current state and our acquired farm, we have to combine each of the farms and solutions into one. This can be a complex process depending on your situation.

In this situation, we have some clear guidance, and we understand this from the information that was given in this chapter. We have pointed out the server resources currently in place, and some details on the farm configuration. Assessment data has been gathered and again, all bases have been covered when finding out the information on SharePoint Server 2019.

What role does the cloud play in your environment? Can we build this into our architecture to save on costs? Well, in this scenario, we don't have any requirement to add the cloud to our migration process or even a hybrid solution, but you may find yourself in this situation. If you do, study the cloud thoroughly; there are many subscription models, and within those models, there are solutions that you may need that may not be offered in others.

Call Microsoft for support if you get stumped and do not guess on this type of configuration. Licensing can be very complex and it may not make sense to you. Make sure to ask the experts when coming up with strategies to move to the cloud.

As you can see, building server architecture is not hard but you have to take into consideration all the requirements and research: how you can create a low-cost, extremely robust, and best-performing server farm for your company.

Design – documenting the design

From my experience over the last 15 years, I have seen two design documents while I have been supporting SharePoint. Most environments I have worked and consulted in run in a reactive support method, which is an uncomfortable seat for those that manage the farm. This is a sign that companies are not making the effort and exerting due diligence to document the installation, configuration, and use cases of the SharePoint farms architected to support their company's collaboration efforts. It was often said in the past that installing SharePoint was easy, just throw the disk in and walk away. This was said early on when 2003 and 2007 SharePoint were just getting started, which was not true and showed in so many failed deployments of the product.

Little did these people know that their support for the product would take a considerable amount of time on the phone as they wondered why certain errors and functionality for users of the product were not working as they should in these environments. Early on in the evolution of SharePoint, there weren't a lot of documents or sites you could use to support yourself through a project like this. There was a very minimal amount of information available, even from Microsoft. This happened due to the product really not making much headway during the 2001, 2003, and WSS versions of the product.

When 2007 MOSS hit the market, it seemed like there was a wave of interest in the product, and Microsoft really got caught off guard at how this took off. Once they saw the need to address these issues, we started seeing more support for SharePoint and more websites and blogs. Some of the third-party blogs and sites could not be trusted in those days due to the newness of the product. Someone could have found a solution to an issue with BCS but then you find out it wasn't a best practice on the Microsoft website. There was a lot of pain and learning during those times, and you had to almost do some of the configurations blind and test them yourself to see whether the solution worked.

Now, with the vast information from Microsoft and blogs online, there is no excuse to not have documents in place to support your efforts for the SharePoint enterprise. Yes, it takes more time, but be thorough so that you can be successful and have references on why, what, and how you created this platform. I cannot express the importance of this and other documents that I am walking you through in this book enough. These are needed to support the product and user communities using the SharePoint farms for services and solutions. This also helps you to understand as an admin or architect what you have designed. As you configure and support the farm in the enterprise, this document, which is the foundation of the build, will be able to be referenced and updated in case you need to review a configuration or make changes as you grow.

So, in my efforts to help organizations do the job of supporting their environment with documentation, I have composed an outline of what I use to document the design of my SharePoint environments. This documentation is for the design of the SharePoint environment and is not intended to collect any SharePoint installation step-by-step instructions, but rather to cover the build of the environment that frames the moving parts and how they are working together to support the farm. The document should include an executive summary, solution design, and security.

Executive summary

This section of the document should be used to give an overview of what the document represents in support of the SharePoint project. Here, we would write a summary of the document within this area for executives who may not have the time to read through the entire document. This portion of the document includes the underlying topics listed:

• Purpose: This section of the document should be used to give a brief description of the document's purpose. In our case, this document represents the design and configuration for the SharePoint enterprise environment we are deploying.
• Scope: This section of the document lists the scope of the environment. This could include the Office server, SQL Server Reporting Services, PerformancePoint, PowerPivot, storage configurations, third-party integration, or anything that is not a native SharePoint installation.
• Out of scope: This section of the document lists the services or solutions within the environment that will be out of scope, such as business intelligence, RBS, hybrid connectivity, or third-party tools you may have discussed previously that didn't make it within the budget.
• Assumptions: This section of the document describes your design assumptions, which would be based on the requirements you gathered. This would include things such as PPI data restrictions within the environment or that access to the SharePoint environment will be authorized by AD.
• Terms and abbreviations: This section of the document should be a table of abbreviations used throughout the document that support protocols or even solutions or frameworks. This gives the reader a list of those abbreviations in case they do not understand them. This should also include the meaning of the abbreviations so that all abbreviations are understood in layman's terms. You could also add a hyperlink to those referenced abbreviations as well to give more detail to the reader.
• Reference documents: This section of the document provides a list of documents, which should also be in a table within the document. These documents are supporting documents from other supported IT or project-related areas that will be supporting this SharePoint design. This would include documents such as governance, installation guides, project plans, and any documents you would like to add that will support this work. Links to documents within SharePoint should be used so that documents can be in a centralized location. Referencing documents in shared drives would only confuse people as naming and versioning changes in this solution.

Solution design

This section of the document provides details of each portion of the solution. So, in our case, since we are designing a SharePoint enterprise solution, we will need to mention all the design requirements we reviewed to create this environment. You would want to mention what services will be used to support the environment from a SharePoint perspective.

We would also need to mention how the environment will be supported from a security, capacity, scalability, and availability perspective. You would also include contingency plans as bullets on how you would support the environment in a disaster crisis. Mention any security design considerations you took during your research as well. A summary of these items and then each of the following listed areas would be presented in a more complete explanation:

• Network: In this section, you would want to mention best practices; for example, SharePoint Server roles as in a Web Front End (WFE) server would not run any SharePoint services or the WFE should have index partitions for search residing on the server as part of the search configuration. You may want to mention any other network-related areas, such as VLAN configuration and domain information that might weigh in on the design. Include any diagrams as well.
• Hardware: In this section, you would want to mention best practices related to hardware. This could be related to SQL Server as you may not virtualize this hardware or mention which type of virtualization you will be using, such as Hyper-V or VMware. Make sure to mention anything you are changing in the hardware design from the norm.
• Software: In this section, you would want to list any software that would be used for the installation of this enterprise solution. This would also include listing the prerequisites as well as any extra tools, such as ULS Viewer or Fiddler, which are utilities that you might use for administration.
• Environments: In this section, we want to list the environments and their purposes supporting the enterprise solution, which could be dev, test, UAT, and production. We would want to mention any best practices, such as any separate service accounts and/or domains that will be used for each environment for security separation. You would also want to mention a release management plan or guidance on how this process will be managed within the environments. Include any diagrams or supporting documentation names and links as well.
• Virtualization: In this section, we want to list all servers that will be created in the environment, using a table with names, descriptions, quantity, CPU, memory, operating system type, and other information that can be captured for each server you are creating to support the environment. We also need to mention any best practices that we will use in the configuration of our hosts and VMs to support the environment. As an example, mentioning a best practice such as no VM server will use dynamic memory allocation would be the best practice of what to list here.
• Availability: In this section, we want to list all specific service-level agreements that will be defined as part of the customer agreements. Only list sections that are covered through the SharePoint service and components only. This section should not include disaster recovery or data protection. You would mention percentage up-time, redundancy specifically supporting the enterprise solution, and specific services within SharePoint that will be redundant, such as search or application services that support redundancy. Then, include those that do not support redundancy, such as SMTP, from a SharePoint perspective.
• Load balancing: In this section, we will list how we plan to support load balancing as part of our enterprise solution. This would include what type of load balancing, hardware, or software (NLB) to use, and how these components will be set up or configured to support the SharePoint environment. This could include mentioning SSL certificates, VIP pools, and distributed cache, to name a few.
• .NET Framework: In this section, we will list the .NET Framework that will be used to support the SharePoint Server 2019 installation. We would need to be sure to mention .NET 3.5 if it is still relevant in your installation as well.
• IIS Settings: In this section, list all configurations that will be used within IIS and mention the version of IIS being used. We would also want to mention log locations and how often these logs will be captured. Also, list all web service extensions and which are allowed and which are prohibited for use on the SQL and SharePoint servers.
• Farm services: In this section, we would need to include a table that lists all SharePoint services, which could include hybrid connectivity. This table also provides columns for server host and state, meaning stopped or started. This gives a precise configuration of the services that will be available within the farm and what servers they will be running under. The use of MinRoles and service compliance, introduced in SharePoint Server 2016, will help to keep your servers compliant at all times.
• Active Directory: In this section, mention all AD interaction that will take place and any required objects that will be needed to support the SharePoint farm. This could be mentioning the domain name, Organizational Unit (OU) structure, service accounts, and or security groups. Also, Azure AD could come into play, as mentioned here, in this document.
• Capacity and storage: In this section, we talk about the databases and storage needed for the overall enterprise solution. User capacity would need to be tested and can be tested using a Visual Studio load testing application. This would be good to use so that you can verify the number of users the hardware you configured will support and give the solution great performance based on best practices. Defining the types of drives could mean OneDrive or search considerations in the cloud that will be used as part of the environment, and their speeds are crucial as well as this can keep the cost down by using slower disks in areas where they can be utilized.

  We should also document the sizes of all databases and configuration details and define all database size limitations within this section of the document using a table. If you're pre-creating databases, this is a good place to list those databases, and if you are not, this is a good reference for naming conventions as you install the product. As a documented process, we would also want to document our database maintenance plan here as well.

  Don't forget to define drive sizes for our servers for the expected disk space needed to support search indexing. When defining the search indexing location, we must remember that indexes can be replicated to other servers depending on their role in the farm. This location is defined during the SharePoint Server installation process as a data location or will reside on the cloud if you use search in a hybrid configuration.

  We also need to remember logging for each component we are using to support the environment. This includes SQL with Always On, SharePoint, and IIS. We also want to remember that logs grow substantially when migrating content from one farm to another. Make sure to account for these sizes when building your servers.

• Web applications: In this section, we define the dedicated web applications that will be used as part of our solution for the administration of SharePoint and for supporting our user community. Web application settings should be captured as part of each of these web applications, which define areas such as authentication type, time zone, file upload size, and others, and should be documented as part of this section of the document.

  You should also define standards that should be followed in naming web applications, the application pools associated, and databases associated. We should also define our sites and what configuration details should be listed here in this document. This should also include all site collection best practices and areas of web applications that should be followed within some guidelines for site collection admins.

  Note

  Remember, host-named site collections are discontinued in SharePoint Server 2019.

• Central administration: In this section, list all details pertaining to the central administration site, which could be a vanity URL or the port that the site will run on. We would also want to mention access to the site as this could be a limited community of users. With that, an AD group should be created, which should also be listed here.
• Site collections: In this section, let's cover how we will create site collections and how they will be used within our organization. You could mention that a site collection will be created for each department or that a site collection will be created for each site as determined by our stakeholders. We also want to mention quotas and other details related to metadata, content types, and site columns.
• Email: In this section, we need to define how email will be used within the SharePoint enterprise solution. Define use with workflows and notifications as well as the configuration of TLS using the new configuration settings within SharePoint Server 2019.
• Search: In this section, we need to define all that is search. Define the configuration, any content sources that will be configured, redundancy configurations, index and capacity, crawl logs, and any special configurations. Crawling of content should also be captured here as schedules and other targeted content sources as per their requirements. Service accounts and the configuration for using those accounts should be defined as part of this section. Remember, hybrid could come into play in this configuration as well.
• Profile imports: In this section, we define profile imports and scheduling for imports within our SharePoint configuration. Any service accounts that are needed that will be used as part of the import would need to be defined in this section as well. Remember, Azure AD could come into play here as well.
• Monitoring: In this section, we define how we monitor the enterprise solution and mention what tools we will use to do so. As we define these areas, we want to make sure that we have made mention of any third-party solutions at the beginning of the document that are in scope. This would include monitoring of the network components, services, servers, VMs, and so on. We should also set any thresholds per component that need to be captured in this document so that others that are administrators of this environment understand those thresholds and make sure to adhere to those maximums. These thresholds would be defined by testing using the Visual Studio tools for simulation or other tools as you see fit.
• Backup and recovery: In this section, we list all areas of the farm that should be backed up that are essential in recovering the farm in case of disaster (DR). These documented areas should be listed and configured in your backup software. The frequency of these areas should also be documented as some may not need to be backed up as often, such as a records management platform where documents are finalized and in a view-only access area. We would also need to consider SQL database backups, which should be part of a maintenance plan but could also be picked up as part of a daily backup for offsite storage. Timing and frequency should be considered as part of this documentation.
• Software updates: In this section, we need to define how software updates will take place, either manually or automatically. In most environments I have been in, most do their patching manually. This would be my recommendation as well. We should be testing our environments through development, test, UAT, and production to make sure these new updates are working as they should. This alleviates the destruction of our production environment as we test through those lower environments for verification of the patches.

  Most companies also have separate teams that support individual IT areas, so in that case, you will have an overlap of support for updating servers, SharePoint, and SQL Server. In this case, scheduling becomes a factor or you have your SharePoint admin update all areas of the server. In a lot of cases, SharePoint admins can have many servers, depending on how their environment is configured, and could have to do updates in a certain order based on the application.

  Some third-party tools require servers as support for their platform. My recommendation is to give the SharePoint admin access to update all servers supporting the environment. If the environment is built for redundancy, then we should be equipped to provide users around-the-clock access to the environment. In this case, we can use what are called zero-downtime methods so that we can update the server without disruption. This would mean all levels of the stack would have redundancy: WFE, the application, and the database.

• Ports: There is a pretty detailed list of ports needed for SharePoint to communicate between servers within the enterprise. These ports should be documented here either through diagrams or a table listing those ports and descriptions. With SharePoint, there are intra-server communications, which refer to how SharePoint services communicate, and extra-server communications, which refer to how SharePoint communicates with other servers and applications supporting the platform. We will detail that list and the script to configure them later in this book.
• Development farm: In this section, we define how the development environment will be used to support the enterprise solution. In most cases, the development environment, as mentioned, is the first environment to get patches and updates related to the servers and applications supporting the enterprise solution. Using a development environment supports the total solutions from a development standpoint. This is the messiest environment in most cases and there could be multiple servers, depending on the number of developers supporting it.

  Consolidating developed code would be another defining area we would want to add here in this section. If you are using Visual Studio and Azure DevOps Server, then centralizing code is fairly easy to do even if there are multiple developers and servers. From there, we define how code is entered into the testing environment, where there should be only one or at most, a few testers reviewing the functionality of the coded solutions. Once it is tested, there will be a verdict that it either failed to meet the requirements or successfully met the requirements. At that point, we would then move the code to UAT.

• UAT farm: In this section, we define how the UAT environment will be used to support the enterprise solution. This environment is used as the name states. Once code or even UI functionality tested in the lower environments is moved to this location, users can log in and test the solutions before they are moved to the production environment.

  We will speak more about this in Chapter 12, SharePoint Framework, to provide some lessons learned and best practices. After working as a developer, I saw many things that could lead to disaster, along with choices that need to be made as an admin function or a developer function. This decision could cost you if you are relying on code to build environments for new developers and rebuilding a production environment that was lost due to disaster.

• Migration: In this section, define migration and how it will support the enterprise solution. In reality, migration can either come as a tool that requires its own server or workstation and can be a process we follow using our SharePoint server and SQL servers. Document how the tool will be used, especially when it comes to environment migrations, release management processes, and who has access to the servers and tools. Document the selected tools and processes chosen as well to do migrations and the content that will be migrated. Schedules and other areas concerning migration will be documents in project-related documentation.

  Note

  Documenting any of these sections with supporting diagrams is also a great way to present solutions as part of this documentation.

Security

This section of the document should be used to give an overview of what the document represents in support of the SharePoint project. Here, we would write a summary of the document within this area for executives who may not have the time to read through the entire document. This portion of the document includes the underlying topics listed here:

• General: In this section, we need to define general security practices that will be followed within our SharePoint environment. Some of the areas that could be mentioned in this area would be the central administration location, direct user access to databases, separate accounts being used to separate services used within the environment, and any other SQL or environment general security best practices you will follow that are part of this enterprise solution.
• Physical security: In this section, we need to define any physical layers of security, as in server rooms and PIV card security, which would count as physical security accessing servers and desktops. Physical security could also be part of a certification you hold as more companies are using these certifications for government contracting. Any physical security enhancements and authorizations would be good to mention in this section.
• Authentication and authorization: In this section, we need to define which types of security you will use for authentication and authorization. If you're using AD, you are most likely going to use claims authentication and Kerberos for integration with AD. There could be a mention of other authentication areas, such as SAML, which provides the integration of PIV cards for more physical security options. Authorization can be mentioned, as in how you use groups within the solutions, either SharePoint groups or AD groups.

  Note

  Always use AD groups for your SharePoint security when you can. If there are areas where they just don't work, then use SharePoint groups.

• Antivirus: In this section, we need to define the type of antivirus we will use to support the upload and download of documents within our SharePoint farm. This is one area I saw during my travels that was abandoned because everyone thought since they had antivirus on desktops, there would be no need for it to be installed on the farm. My opinion is you always need to be careful and don't take chances with your data.

  With antivirus, there are areas on the server that need to be documented as well, which should be excluded from the antivirus scanning those areas on the hard drive. Those areas are documented on Microsoft's website. These exclusions help to protect files from being compromised by the antivirus program and interrupting the SharePoint service.

• Auditing and policies: In this section, we need to define how we will audit users and what policies we will put in place to ensure data compliance. Information Rights Management (IRM) and a new feature called Data Compliance that was introduced in SharePoint Server 2016 can be used to flag documents and make sure data is protected from use by users who do not need access.
• Security principles: In this section, we need to define how admin and service accounts will be used in the solution for the separation of duties. Document their purpose, local policy settings, and database access in this section. Use a table to pull together the best results. Local service and network service accounts should be documented here as well. Also, document group permissions as well, as out-of-the-box SharePoint creates groups that are used within the configuration. These are often forgotten about. Document these groups and make sure they are a part of your documentation for reference.
• Group policy: In this section, we need to define GPO settings. This is one area where a lot of admins get stuck and wonder why security isn't working in the environment. We need to make sure that all of these policies are documented, as well as GPO settings.
• Blocked file types: In this section, we need to define a list of file types that will be blocked from use within the SharePoint libraries. These file extensions should be documented so that they are captured for reference.
• Appendix: If needed, add an appendix to the document.

You are not finished with creating your design document as this document is a living document created to capture changes in your design. Keep this document safe in a place where only you and your team can get to it. Have someone review it as well to make sure you hit all areas of your design to support the services you are planning to configure in your farm. The key to a successful implementation is getting things right the first time and always checking and rechecking against the Microsoft best practices and your assessment.

Disaster recovery

In this section, we need to look at recovery from the unknown glitches that can happen that bring down the server environment, where the service is unavailable or partially available. This could be the loss of the application services or even just the loss of data. In the case of SharePoint, there are network components that can also cause issues as well, such as load balancers, routers, and DNS, which can alter the availability of the service.

With that, we need to take into consideration the company's policies on the Recovery Time Objective (RTO) and Recovery Point Objective (RPO). There are disaster recovery concepts that can be followed that support SharePoint 2019. These concepts have not changed since SharePoint 2013 was in play, which includes standby recovery options, service application redundancy, and third-party solutions specifically for SharePoint:

• The RTO defines the time metric to calculate how quickly we can recover from a disaster. This would be the expectation the company would like to support as part of an Statement of Work (SOW), which supports the service and is given to users or departments using the service. This is so that customers understand all the services provided and situations that may come into play within the environment.
• The RPO defines the point in which you would like to be able to recover. This means that the point of recovery could be a full SQL database backup time and maybe you also have a differential backup that was done later, combining these two backups, so overlaying the differential backup would then bring our point of recovery to a more recent time. This would be defined in the backup strategies, which we will talk about later in the book.
• Standby recovery options are provided using separate data center locations to house a system or service so that in the case of a service or group of systems that go down, those systems can be recovered and provide the service from a different set of servers or services. There are three different models for these options:

  The first is cold standby, which is a data center that could be back online within hours.

  The second is warm standby, which is a data center that could be back online within minutes or hours.

  The third is hot standby, which would make the systems redundant, and if something were to happen, the users would not see much of a change in service. This would facilitate an almost-instant recovery, with some caveats of URL changes, DNS updates, and other networking configurations that could be automated or done manually.

• Service application redundancy can be configured when you configure services within SharePoint to be redundant as part of an outage, which would then require services to be running on hot standby servers. This is not a bad solution but we have to remember that SharePoint also brings with it a database side. In that case, we also must remember that we can also ship logs to another database server in another data center as well. This would push all database changes from the production farm to the DR farm in another location. These databases that support SharePoint can also be in read-only mode in the event that you do not want any changes to be made once failed over. This could come in handy in some scenarios.
• Third-party solutions come into play, and I refer you to AvePoint again as they provide some solutions that provide synchronization of content between locations and disaster recovery solutions just for SharePoint. If you have the funding, these are good to take a look at, but also remember that this comes at the cost of new servers to support the functionality and more time spent by your administrators managing these services as well.

In conclusion, the design of your SharePoint farm means everything to the support of the service. This means you cannot miss much when implementing a SharePoint farm. Making sure to document your infrastructure is key due to three things you will need now and in the future:

• Having a place to create, share, and save your design for review and changes
• Making sure you do not miss anything during the design process
• Giving someone else a chance to help, troubleshoot, and take over if you leave the company

Again, I cannot stress enough to document! I will say this many times in this book but documentation helps you figure things out because you write it out and don't just keep it in your thoughts. We admins tend to want to be smart off the top of our head but some things need to be written down. Don't keep things hidden in your mind; make sure to put them on paper. I have heard others who I have worked with always ask themselves why their team member doesn't know something, because it's obvious. Well, writing things down will make it even more obvious and get people working independently so that you don't have to hold their hand.

As part of that, always make sure to go through the scenarios when examining your current state. The assessment, best practices, and other planning information help to bring your design into a perfect scenario for your company. Remember that detail needs to be captured. Any little nuances, such as a custom port for incoming mail or as little as a service account used for a custom service – all these items need to be captured so that the design is understood. No one should be hunting you down for information or to see how things were designed.

We learned a lot in this chapter from the many angles that SharePoint has to offer. Some parts I didn't even touch upon. This chapter taught you a few things that will help you plan for success in many different scenarios. Although I didn't go too deeply into some of the areas I wanted to, this gives you a road map on where you need to go and what you need to focus on when designing and planning your architecture. Planning is everything and it creates the design for the farm as it answers many questions for you and your management. Always make sure to focus on planning as this is the only way to a successful SharePoint environment. There is no other way.

In the next chapter, we'll look at how we can go about creating and managing VMs.

You can find the answers on GitHub under Assessments at https://github.com/PacktPublishing/Implementing-Microsoft-SharePoint-2019/blob/master/Assessments.docx

1. What standby recovery options would require some configuration to bring online?
2. What Microsoft Server product is used to support the development cycle and uses the three environments to help push and version developed code through those environments?
3. I can configure my SharePoint 2019 farm to use hostname site collections. True or false?
4. As part of our assessment review, what areas of our old farm should we be reviewing?
5. In our logical design, we should use one content database with a site collection and many subsites to support all departments in our company. True or false?
6. In our physical design, MinRoles play a big part in how we build service compliance in our server resources. Which MinRole is used for capturing a mix of services and has no compliance?
7. Should the help desk as a support resource field all SharePoint issues within the environment?
8. When designing our farm, what tier supports user connectivity?