Planning – SharePoint farm design

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.