Friday, March 29, 2024
HomeAvePoint BlogThe Art and Science of Microsoft SharePoint Architectural Design

The Art and Science of Microsoft SharePoint Architectural Design

Architecting Microsoft SharePoint farms and its hierarchical containers (namely web applications, content databases, site collections, and websites) can be considered both an art and a science. Each decision, such as choosing to isolate or merge site collections, must first be rooted in clearly defined business needs and then evaluated by looking at the trade-off considerations of each choice. For example, list out the pros and cons of each design option. This evaluation process is essential to be sure the advantages and disadvantages of each SharePoint architectural design choice is understood and considered.

The science part of the evaluation is often the easier of the two, provided that a solid understanding of SharePoint and how configuration settings are “scoped” to a particular container or level. Scope refers to the options that SharePoint makes available within the different containers. For example, a web application has a number of configuration choices such as maximum file size or allowed file types. A site collection has its own set of configuration choices such as size (quota) and security management. The art portion is usually trickier as it involves organizations’ internal politics, risk management, weighing current-versus-future needs, and finding manual or automated solutions to work around some of SharePoint’s limitations. Before continuing, let’s use a simple scenario to help clarify these trade-off considerations.

Sample Business requirements:

  • The Human Resources team needs to collaborate on a new business process for onboarding employees. The team members will produce new process documents in Microsoft Word format.
  • The Marketing team wants to work on a new campaign initiative. The team members will produce a new strategy, advertising flyers, and related documents.
  • Content must be kept secure so that only that department can access their respective set of documents; in particular, HR content may contain confidential information.

Understanding SharePoint’s security model, there are several levels (or scopes) where a potential solution exist. These include: isolating the content across separate site collections, websites, libraries, or folders within a library. Each of these choices has its own pros and cons.

Let’s say it was decided to store these into a single existing site collection that is shared across multiple departments. Each of these collaboration requirements will be isolated into separate websites as shown in this diagram.

Example of collaboration requirements in a single site collection across multiple departments.
Example of collaboration requirements in a single site collection across multiple departments.

In this design, the scope (container) choice we have made is at the website level and the content security access control list (ACL) has been applied at that level as well. One advantage is that it’s relatively easy to create new websites, and this could be part of a site provisioning process if one is already in place. With regard to security, each of these websites can be secured so that users in one department cannot access documents in another website, so it meets the base requirements as defined.

There are notable drawbacks, however. First, the site collection administrator will have implicit access to all content in this site collection, and this could create a security risk. [Note: Site collection owners have full control permissions to all content in a site collection regardless of the assigned permissions. This can only be blocked (denied) at a web application policy level.] This is one advantage for having the isolation at the site collection level instead of a website. Second, if the marketing team produces a large number of heavily versioned documents, it could easily fill up the site collection size quota, affecting other departments that share this area. This is where a technical understanding of SharePoint’s configuration choices, their implications, and the scope(s) to which they apply is critical input to these decisions.

From a pure security isolation perspective, putting these in separate site collections is the best choice as already mentioned. (Note: One could argue that isolation across a separate farm or web application is an even more secure approach. This is described in more detail later in this article.) However, isolating these across separate site collections has its drawbacks. Creating dedicated site collections simply for these two use cases may not be practical because it lacks scalability. If separate site collections for HR and marketing already exist, finding or creating a suitable website or library within these site collections might be better. This can still be secured separately by breaking inheritance if needed.

Now that this rudimentary example has been covered, let’s discuss the configuration options that are available at each scope in the logical hierarchy (farm, web application, content database, site collection, website, and list/library). For each scope, recommendations on how to architect these is presented.

SharePoint List/Library

List and libraries make up the container for storing SharePoint items, whether these be contacts, calendar items, or library documents. List and libraries are very similar, and, internally, libraries are a special type of list.

Considerations for creating separate lists or libraries:

  • While SharePoint supports unique permissions at the item and folder level, this should not be used as a general practice across large lists or libraries due to the performance overhead associated with this configuration. If custom permissions are needed within a library, it is recommended to do this at the folder level before adjusting it at the item level.
  • In SharePoint 2010 and SharePoint 2013, a single list or library can scale to millions of items. (Note: Technically, the supported limit for a list or library is 30 million items.) Specialized library templates such as the Record Center and Document Center are optimized to efficiently store larger item counts. (For example, property promotion is disabled which allows SharePoint to take a value from within a document’s metadata and “promote” this value to a column value for the item on the library.)
  • For performance reasons, views should not be configured to display more than 5,000 items in a single display. (Note: This list item threshold can be adjusted for at the web application level, but this is not advised unless absolutely required.) By default, views are limited to 30 items and this should only be changed when necessary.
  • Individual list/library columns and views cannot be secured. Columns can be hidden from a view, but they are not technically secured.
  • SharePoint’s maximum document size for any document or attachment is 2 gigabytes (GB). This is both a SharePoint and SQL Server limitation. Third-party solutions such as DocAve File Share Navigator can help work around this limitation.
  • In general, separate libraries should be used to store logically separate areas of content in the same website. Here are the most common requirements to often require a separate list or library:
    • Unique security, unique content types, unique views, unique metadata columns, require check-out, unique document templates, and content approval.
  • The require check-out setting is also a require check-in setting. In other words, when adding a new document to a library, the user must manually perform a check-in unless the client application (e.g. Microsoft Word) is able to do it for the user. Uploading documents manually through upload controls (e.g. drag and drop in SharePoint 2013) will always require a manual check-in before other users are able to see these documents.
  • Documents that are checked-out cannot be used in co-authoring scenarios. For those libraries where co-authoring is needed, you must not enable the require check-out setting.
  • While versioning is an incredibly valuable feature, a limit on the number of versions should be set to avoid storage problems.
  • Newly created libraries automatically inherit the security settings from the website.
  • Site collection administrators have full access to all content in a list or library unless this is denied through a web application policy.

Here is a detailed list of the most common settings that are scoped to a list/library and therefore must be considered when creating separate or consolidating lists/libraries.

  • Unique Permissions (column level not supported)
  • Views
  • Versioning settings
  • Require check-out
  • Require content approval
  • Metadata navigation/filtering
  • Reindex Document Library (SharePoint 2013 only)
  • Indexed columns
  • Exclude from search
  • Workflow associations
  • Content type association
  • List/library template
  • Offline client support
  • Incoming email associated to a mail recipient
  • Default open behavior (open documents in client app or browser)
  • Information policies retention schedule (also configurable at content type)
  • Custom property bag (associated at the root folder)
  • Can be restored from first or second stage Recycle Bin
  • Backup and restore using PowerShell cmdlets (however, not this is not full fidelity, which refers to whether the contents can be recovered while preserving all of SharePoint’s content settings. In this scenario, creator, created timestamps, workflow instance state, and auditing settings are not preserved)

SharePoint Website

Here are the considerations for creating separate websites (or subsites):

  • By default, newly created websites automatically inherit the security settings from the parent website.
  • Some planning for website hierarchy within a site collection is advised. Having a deeply nested website hierarchy creates navigation challenges for users, including over-long URLs and performance issues for the system. Thus, in general, utilizing a flatter hierarchy over a nested one is a better design pattern. There are some exceptions to this rule. These include:
    • For any single level, it is recommended to create no more than 250 websites. If unique permissions are used for many of the websites, this number should be much less.
    • When structuring website hierarchies, use security inheritance to your advantage. For example, if there are several websites that each need the same unique security settings, it is best to store these as websites underneath a parent site that has the unique permissions configured rather than recreating the unique permissions multiple times.
  • Creating custom web templates that match common organizational use cases is a best practice. This ensures site consistency and increases the user experience.
  • Larger organizations including those that prefer to maintain a strong governance posture with respect to site sprawl find that having a site provisioning process works best. DocAve Governance Automation can completely manage this process.
  • Websites should have a content lifecycle associated with them. This is especially true for websites associated with a project that has a defined end date.
  • While this is rarely a restricting limit, SharePoint has a supported limit of 250,000 websites within a single site collection.
  • When creating websites, it is best to avoid using spaces in the URL name. Consider using camel case (ProjectFoo) or underscores (Project_Foo).
  • Site collection administrators have full access to all content in a website unless this is denied through a web application policy.
  • Most SharePoint 2013 apps will create an app web and this is internally stored as a sub web underneath the parent site in which it was added. However, users can only access the app by using the dynamically generated URL that SharePoint creates.

Here is a detailed list of the most common settings that are scoped to a website and therefore must be considered when creating separate or consolidating websites:

  • Unique permissions
  • Allow anonymous access (requires anonymous access enabled at the web application)
  • Custom look and feel (master pages, CSS, page layouts, or the use of Design Manager or Composed Looks in SharePoint 2013)
  • Site template (save site as template or create site from template)
  • Each website has its own recycle bin, often called the First Stage Recycle Bin
  • Override Global and configure current navigation (aka quick launch) settings
  • Regional settings (e.g. time zone, default language)
  • Apps (based on SharePoint 2013 app model)
  • Numerous search settings including result sources, result types, query rules, enable search, and reindex site (SharePoint 2013 only)
  • Site columns and content types (including modifying those scoped at the site collection)
  • Manage user alerts
  • Manage site-level workflows
  • Allow RSS feeds for lists and libraries
  • Custom property bag
  • Custom permission levels (configured through PowerShell or custom code)
  • Backup and restore using PowerShell (not full fidelity)
  • Can be restored from site collection (second stage) Recycle Bin
  • Manage site-scoped features [e.g. content organizer, legal hold, publishing, enterprise features, site mailbox (requires Exchange 2013), site feeds]

SharePoint Site Collection

Since site collections are the administrative and security unit for content in SharePoint, it is important to plan out site collections as part of an information architecture planning exercise. There are a number of techniques that can be used, including card sorting. Thus, unlike websites, site collections are generally pre-planned rather than created in an ad-hoc manner.

Technically speaking, site collections are not “hierarchical” like websites or library folders – all site collections are at the same level within the web application. However, through the magic of managed paths, you can create the illusion of a hierarchy. [Note: Host-named site collections are another option that can be used as described in later detail in this section. Host-named site collections use a URL construct that uses a unique DNS (or fully-qualified domain name) for each site collection.]

Considerations for creating separate site collections:

  • For collaboration and intranet workloads, in general, you create separate site collections for each business unit, department, team, or function that has diverse requirements (see the detailed list of settings below).
    • The most common practice for structuring site collections is to separate them across organizational departments/units (for functional structure organizations) or project based (for strong matrixed or project-based organizations). For example, each department – such as HR, Marketing, and IT – would be assigned their own site collection. While this is common, it is not always the best practice and the architect should never assume this is the best architectural pattern to employ without conducting proper due diligence. Instead, apply the techniques in this section to help determine what works best by evaluating the trade-off considerations.
  • It is a recommended practice to place each community site (part of the social feature set in SharePoint 2013) within its own site collection.
  • Security, including site collection administrator(s), is the most common reason to separate content across separate site collections.
    • If more than two site collection administrators are needed, these can be assigned after the site collection has been created from the site settings page. Active Directory (or external) security groups can also be assigned at this time.
  • In SharePoint 2013, Microsoft recommends using host-named site collections (aka vanity URLs) instead of path-based site collections. This choice alone has its own trade-off considerations, and some of these include:
    • Host-named site collections must be created using PowerShell, custom code, or a third-party site provisioning solution such as DocAve Governance Automation. They cannot be created using Central Administration.
    • Host-named site collection have the illusion of being separate web applications, but they all live within a single web application which has the same security, application pool, and most of the settings as path-based site collections.
    • Host-named site collections work well for intranet workloads, especially where there are global and sub (divisional) portals.
    • Host-named site collections cannot be used for My Sites.
    • Each host-named site collection must have a DNS record created.
    • If there is a long-term plan to move to Microsoft Office 365 – SharePoint Online, it is generally better to use host-named site collections up front as it can ease the eventual migration.
    • Host-named site collections have unique SSL requirements and may have issues if off-the-box SSL termination is used.
    • Self-service site creation cannot be used to provision host-named site collections.
    • For more differences between path-based and host-named based site collections, see this TechNet article.
  • In general, for collaboration workloads, a site collection should be kept to within 100GB where possible. For Document Centers and Record Centers, they can scale well beyond 1TB.

Here is a detailed list of the most common settings that are scoped to a site collection and must be considered when creating separate or consolidating site collections:

  • Establish unique permissions across site collection
  • Define site collection administrators
  • Custom permission levels (configured through UI or PowerShell)
  • Manage SharePoint groups and users
  • Content database association
  • Site columns and content types (unique ones that are not published in the content type hub)
  • Custom look and feel (master pages, CSS, themes, page layouts, or use of Design Manager or Composed Looks in SharePoint 2013)
  • Quota settings (storage size and sandboxed solution usage)
  • Lock site collection (e.g. No access, read only)
  • Numerous search settings including result sources, result types, query rules (SharePoint 2013 only)
  • Global navigation settings across site collection
  • Unique URL (if using host-named site collections)
  • Sandboxed solutions deployed and available for use
  • Enable RSS feeds
  • Audit settings (many are also configurable at the content type)
  • Web part gallery
  • Variation settings (multiple language)
  • Compatibility settings (Version 14 – SharePoint 2010 or Version 15 – SharePoint 2013)
  • Health checks (SharePoint 2013 only)
  • Custom site and list templates
  • Content query web part for rollup
  • Cross-site publishing
  • Custom property bag
  • Manage site collection scoped features (Unique Document ID support, Document set support, enterprise features, publishing, in-place records management)

Content Database

Content databases are not part of the logical hierarchy per se, but for a complete architectural summary, it’s listed here since there are trade-off considerations when planning content databases within SharePoint web applications. These trade-off considerations include:

  • A site collection cannot span multiple content databases.
  • For collaboration and general-use workloads, content databases should be designed not to exceed 200 GB in size
  • For document center or record management workloads, a content database should be designed to not exceed 4 TB. (Unlimited-sized content databases are technically supported provided certain criteria are met.)
  • A content database should not store more than 60 million total items.
  • Read-centric content databases, in general, can be sized larger than read-write.
  • Site collections that have related characteristics, such as recovery objectives, security, read/write patterns, or performance, should be co-located in the same content database, provided it doesn’t exceed the size or object count limits.
  • To move site collections across content databases, you can use the Move-SPSite PowerShell cmdlet or third-party solutions such as DocAve Content Manager. Due to the performance overhead, this operation should be done during off-peak hours.
  • A larger content database performs more slowly: As a general storage performance recommendation, try to keep the IOPS per GB ratio above 0.25 (at least 1.0 is recommended for better performance).
  • A larger content database takes longer to backup and subsequently restore, which can affect recovery time objectives. Third-party solutions such as DocAve Backup and Restore can help reduce the time associated with recovery.
  • A SharePoint farm has a supported limit of 500 content databases.
  • For more guidance on sizing content databases, see this slide deck on “Sizing Your Content Databases”.
  • For more guidance on optimizing SQL server for SharePoint, see this slide deck on “Optimizing SQL Server”.

Here is a detailed list of the most common settings that are scoped to a content database and therefore must be considered when creating separate or consolidating content databases:

  • Granting PowerShell administrator access using Add-SPShellAdmin
  • Database server assigned
  • SQL server authentication type (Windows or SQL authentication)
  • Storage settings (LUNs assigned, tier of storage)
  • Enabling RBS (remote BLOB storage)
  • Minimum and maximum number of site collections
  • Allow adding of new site collections (aka database status)
  • Setting a database as read only
  • Database version (i.e. the SharePoint build of the content database) and build history
  • A content database is the lowest unit of backup and recovery for farm-level backup
  • Unit of mirroring (SQL Server 2008 and 2008 R2)

Web application (including zones)

Web applications are SharePoint’s integration level with IIS and, thus, many settings that are scoped to a web application are also scoped to a single IIS website. Web applications are also the authentication entry point for users into SharePoint. When planning web applications, keep these primary planning considerations in mind:

  • Each web application can be extended out to up to a maximum of five zones. A zone is not a separate administrative unit, but rather an alternate URL and authentication type that can be used to access content. A common use case is to extend a web application to an extranet zone, allowing external users to collaborate with internal users. (Note: While this is a common use case, it is not recommended from a security point of view as it puts internal content at a much greater security risk of being accessed externally. A better solution is to isolate this across a separate web application. For even more complete security isolation and protection, a separate farm is even better but this comes at a much greater expense and administrative effort.)
  • Each web application is associated with its own IIS application pool (worker process). This affords a very high degree of application isolation but does come at the expense of higher RAM consumption on the web front-end (WFE) servers. If desired, separate web applications can also share application pools.
  • Newer design patterns in SharePoint 2013 have emerged where a consolidation of web applications is a more common practice. The primary advantages include reducing the amount of RAM needed and simplifying the design and administrative effort.
  • Where possible, custom or third-party applications that are not fully tested or trusted should be isolated into their own web application. (Note: This refers to custom farm solutions, not sandboxed or SharePoint 2013 app model solutions.) This ensures that any application pool recycles or other erratic behavior will have minimal effect on services hosted in other application pools.
  • Environments with limited amounts of RAM on WFE servers are encouraged to share application pools wherever possible. It is common for a single application pool (worker process) to consume up to or more than 1 GB of RAM.
  • SharePoint has a supportable limit of 20 web applications per farm.
  • SharePoint has a threshold limit of 10 application pools per web server. Using load balancers, web applications can be isolated to specific WFE servers in the farm.
  • Organizations that have significantly different workloads should consider whether or not to place each workload in a separate web application. In general, it is common to separate intranet, team or department collaboration, and extranet collaboration content across separate web applications.
    • A dedicated web application is recommended for My Sites although there are also different schools of thought on this. The strongest reason for isolation here is being able to have separate content databases for all of your My Sites.
  • Since web applications are directly associated with service applications, adjusting web applications to connect to separate service applications is a common architectural pattern. For example, there may be two separate search service applications, each crawling separate security levels of content (such as “confidential” and “unclassified”). By having two separate web applications (also “confidential” and “unclassified”), each web application can be associated with its corresponding service application. The same example can extended to other service applications such as MMS or UPS.
  • While they appear very similarly to users, host-named site collections and web applications are not the same. A host-named site collection is still a site collection, which means the configuration options available are based on the site collection.
  • Since web applications are the authentication entry point into SharePoint, where and how users authenticate often influences which web applications are created. In SharePoint 2013, SharePoint now supports multiple authentication methods (e.g. Windows authentication, forms-based authentication, custom identity provider) for each web application.
  • If you are using Integrated Windows authentication (NTLM or Kerberos). For non-Windows clients (e.g. Mac or mobile devices) or browsers that connect from untrusted workstations (that is, machines that are not joined to a trusted AD domain), you may be able to reduce the number of logon prompts by consolidating web applications. This is because each time a new request across a web application boundary is made, an additional logon is required.

Here is a detailed list of the most common settings that are scoped to a web application and must be considered when creating separate or consolidating web applications.

  • Service application associations
  • Recycle Bin settings
  • Maximum upload size
  • Blocked file types
  • Authentication modes and methods (including claims vs classic mode)
  • Allow anonymous access
  • Configure web application user policy (deny access, grant read or full control over the web application)
  • List view thresholds (aka item count throttling)
  • HTTP throttling
  • Enable SharePoint Designer
  • Mobile access settings
  • SharePoint change log settings (e.g. number of days to keep)
  • Whether custom declarative workflow (user-defined) is enabled
  • Managed paths
  • Alternate access mappings (configuring public and internal URLs)
  • IIS application pool isolation
  • Use of SSL
  • IIS bindings (TCP port, IP address, host header)
  • Location of IIS logs (configured in IIS)
  • Browser file handling (e.g. to allow PDF to open up directly in the browser)
  • SMTP server for outgoing email
  • Enable alerts
  • Enable RSS feeds
  • Scoped deployment of certain WSP (solution packages)
  • Web.config settings [including BLOB cache, output cache, safe controls (e.g. trusted web parts), custom HTTP handlers, workflow activities, federated identities]
  • WFE server assignment (configured via load balancers)
  • People picker filter (e.g. adjusting the LDAP query to a specific Active Directory OU)
  • Enable and configure self-service site creation
  • Automatic site deletion
  • Send-to connections
  • Document conversions
  • App catalog (SharePoint 2013)
  • Timer job definitions and schedule
  • Manage web application scoped features

Farm

The farm is the highest level in the SharePoint hierarchy. In SharePoint, a farm consists of all the servers that share a configuration database and collectively provide the content and services to a set of users. Although it is easy to add and remove servers from a farm as well as adjust a server’s services, the servers and their farm are tightly connected. Here is a summary of the primary considerations when planning farms.

  • Most enterprise organizations have separate farms for shared development, test, staging and production environments. Any organization that will be doing custom development should have at a minimum of three farms (shared development, staging, and production). Other organizations should have at least two (staging and production).
  • The staging environment should mimic the production environment as closely as possible, both in terms of hardware (virtual or physical) and configuration.
  • Isolating external users to a separate extranet farm is the best way to achieve isolation across a set of content. Keep in mind, this will require a solution to publish content between these two farm environments. DocAve Replicator is one such third-party solution that helps solve this problem.
  • A “stretched farm” is neither recommended nor a Microsoft supported design. All servers in a SharePoint farm should be considered co-located within the same data center interconnected with a high-speed LAN (at least 1 GBPS that delivers a less than 1 millisecond latency).
    • To optimize performance and isolate localized collaboration, organizations that are spread across a wide geography, including global organizations, must strongly consider the use of multiple farms that are located within major working centers. For example, a farm in London, New York, and Singapore.
    • Organizations that are located in the contiguous United States can often get by with a single data center, but performance testing from remote sites should be conducted to evaluate whether remote performance is acceptable.
  • Since neither SharePoint 2010 nor SharePoint 2013 supports running multiple versions side-by-side, and since SharePoint 2010 does not support in-place upgrade to SharePoint 2013, a new farm is required when upgrading from SharePoint 2010 to SharePoint 2013. This new farm is then used to gradually transition to the new version.
    • Certain service applications from SharePoint Server 2013, including Search, can be consumed from a SharePoint 2010 farm. This makes upgrading to improvements in the newer service application gradual since it does not require a complete farm upgrade.
  • The larger enterprise organizations (usually tens of thousands of users) should consider whether having a dedicated farm to critical service applications such as Search. Via a cross-farm trust, this search farm can then be consumed from a separate farm – this design affords greater scalability and performance.
  • Custom applications that are deeply integrated with SharePoint are quite challenging to upgrade to the next version of SharePoint. For this reason, it is common to isolate applications of this type to a dedicated farm. This allows other workloads such as collaboration and intranet (both of which are easier to upgrade comparatively speaking) to be upgraded quicker.
    • Cumulative updates and service packs are applied at the farm level. Based on server maintenance cycles, it is not uncommon to have separate farms that run an older build but still on the same SharePoint major version.
  • Public-facing websites are best when isolated onto a separate farm, which is typically deployed into a separate network such as a DMZ. This degree of isolation is best from a security point of view.
  • For those organizations building an IT Service Management (ITSM) model may consider whether varying levels of service necessitate a separate farm. For example, designing a separate set of servers, storage, disaster recovery farm failover, third-party applications, and other quality-of-service levels allows for a multi-tier model that can include corresponding chargeback costs. For example, you may have a gold and a silver tier farm.
  • For organizations that are extra security conscious, or must otherwise have complete isolation between content areas [including all administrative functions (SharePoint farm administrator, database administrator, etc.)], the only way to do this is through a separate farm. This is also required if a separate farm will run on a physically or logically separated network.
  • As organizations re-evaluate the investment and management of on-premises hardware, most organizations realize at some point that a cloud solution is visible in their near- or long-term future. One of the easier transitions to the cloud is to look at an established infrastructure as a service (IaaS) cloud provider such as Amazon AWS or Microsoft Azure Virtual Machine (VM). With a design pattern such as this, it is relatively easy to move or provision a new farm in cloud-hosted VMs. Of course, making a move to the cloud involved a number of other trade-off considerations which are out of scope here. Some of the most common workloads that are cloud “friendly” include public-facing and extranet. To learn more about the advantages of using a cloud-hosted Infrastructure-as-a-Service solution, read the white paper co-authored by Amazon Web Services and review my presentation, “Governing and Managing Hybrid SharePoint Environments”.

Here is a detailed list of the most common settings that are scoped to a farm and therefore must be considered when creating separate or consolidating farms.

  • Farm administrators
  • Farm servers and their roles
  • Farm services
  • Service applications and their proxies
  • Managed service accounts
  • Application pool creation and management
  • Language packs
  • Version and build (service pack and cumulative updates) making it the unit of upgrade
  • Licensing (Foundation/Server Standard/Server Enterprise)
  • Code deployment to farm servers (for example, deployments into the global assembly cache)
  • Quota templates
  • Most third-party solutions, including ones from AvePoint
  • SharePoint logging thresholds
  • Incoming email settings
  • Custom identity providers
  • SMTP server for outgoing email
  • Content deployment paths and jobs
  • Sandboxed solution settings (load balancing and monitoring counters)
  • Manage health analyzer rules
  • Configure Information Rights Management (IRM)
  • Configuring a Content Delivery Network (CDN)
  • Manage farm-deployed InfoPath form templates
  • Cross-farm service application trusts
  • Server to server (S2S) and OAuth trusts (SharePoint 2013 only)
  • Connecting SharePoint to Office Web Apps farm (SharePoint 2013 only)
  • Disaster Recovery (full-farm failover and restore)
  • FileWriteChunkSize Shredded Storage setting (SharePoint 2013 only)
  • Manage farm scoped features [spell checking, global web parts, site mailbox support (requires Exchange 2013)]

The Great Divide

With a solid understanding of the different scope options at each layer in the SharePoint hierarchy, take note that it’s not just as easy as creating a lot of site collections, content databases, web applications, and farms. While this may seem like the easy way out, it’s not. In particular, separate farms command the largest unit of maintenance and hard costs since each farm and its servers are licensed separately and must be separately maintained. In other words, creating more “containers” based on the governance requirements will increase the overall management effort.

As discussed previously in our simple collaboration example, creating and maintaining multiple site collections increases the management burden. You have separate sets of SharePoint groups, so you must employ a true global navigation system since SharePoint “global” navigation is site collection scoped. Also, quotas, content rollup, and dozens of other settings are scoped to a single site collection, making the use of multiple site collections more challenging.

Creating a complex structure of farms, web applications, site collections, and the like can also present a very confusing navigational system to the users, depending on how users navigate. Some users prefer to navigate in a somewhat “old-school” hierarchical method. Rather than searching or consulting a site directory, for example, they find their site by navigating down one level at a time. In short, having a complex “back end” logical architecture needs to be abstracted from the users. Instead, an intuitive site map is used instead to guide and direct users to common work areas. This separation between the interface layer and the back end is shown in the next figure.

Separation of the interface from the complex logical architecture.
Separation of the interface from the complex logical architecture.

To help clarify the management challenge associated with “too many containers”, consider the following figure which depicts the numerous level of settings for a relatively simple farm with just two web applications and four site collections. Again, the key point is that there is an additional trade-off consideration for each new container that is created.

Management burden associated with many containers.
Management burden associated with many containers.

Finding the balance

As you have seen, there are a number of considerations when making these difficult trade-off decisions. These considerations include:

  • Scalability
  • Availability
  • Performance
  • Future Flexibility
  • Ease of administration
  • Future requirements
  • Upgrade strategy
  • Budget
  • Cloud strategy

To address a big part of the management burden, one goal is to find a way to enforce governance policies across a wide spectrum of containers. For example, instead of managing each site collection individually, related site collections should be administered in batch. This is done through writing custom code, automating the provisioning of these containers, writing PowerShell scripts, or using third-party solutions such as DocAve Administrator and DocAve Governance Automation.

A related problem with having numerous containers is how to reorganize and restructure content at a later time. For example, it may have made sense last year to isolate content across two separate site collections, but now you realize it would have been better to centralize these into a single site collection. SharePoint out-of-the-box provides very few tools to help reorganize and restructure content. In some cases, export sites and lists/libraries by using Export-SPWeb can help, but this does not preserve all settings such as workflow instance state, timestamps, and audit settings. Some of this can be mitigated by using third-party solutions such as DocAve Content Manager.

In closing…

Architecting SharePoint farms is a tricky endeavor, especially when most decisions are not clear cut and multiple options are available. The recommended advice is to design for future flexibility, consider all available requirements and governance policies, and be sure you look at this from different angles. As part of this, you’ll want to measure the cost of management versus the cost of non-management. For example, while it might be best to have two separate farms, does the additional cost of a new farm outweigh the costs of staying on a single farm? These calculations will vary widely based on the scenario and the unique characteristics of each organization. Lastly, it is best to document the decisions that have been made so you can refer back to these at a later date. It is quite common to question difficult decisions like this at a later time and without any documentation trail, it is easy to forget and justify why earlier choices have been made.

4 COMMENTS

  1. Randy, quite a comprehensive and descriptive article behind the complexities of SharePoint. Part of the reason we are seeing the business have a poor view of the product, it can do anything with enough money thrown at it, but too complex to use for a lot of the population.

    Regarding the comment on documenting decisions made, I would find this very helpful 5 years post SharePoint deployment! Maybe a tool or template can be created by AvePoint to help with this. Maybe that same tool can feed decisions into the creation of, or changes to, your environment?

    • Couldn’t agree with you more Jon. My organization struggles internally due to the complexity surrounding SharePoint. We have some leaders within the organization who think every idea can become a SharePoint candidate given the right amount of time and money.

  2. Hi guys,
    Thanks for reading the article and adding your thoughts here. As powerful as SharePoint is, one of its weaknesses is the built-in reporting that it has. I find that many companies work around this in different ways. Some choose to document using PowerShell scripts, such as this one that Microsoft provides (https://technet.microsoft.com/en-us/library/ff645391.aspx). Other write their own console apps that call into the Server API to extract the settings needed. There are third party choices out there, and you can easily find these through your favorite search engine. At AvePoint, we have a product that can address this and a whole lot more called Report Center (https://www.avepoint.com/products/sharepoint-infrastructure-management/sharepoint-reporting/).

    For documentation that I referred to in this article, this is more of an output from a project team, such as something that might be described in technical specs. Another form of documentation I find helpful is to maintain a simple change log of server or farm/web app level configuration changes. The larger your organization gets and the more farm admins you have, the more important this becomes if you ever need to troubleshoot and wonder “what changed?”

    Hope this helps!

  3. This is a great reference for relatively new system admins like me. Thanks for the time putting this together.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

More Stories