Posted in Governance, Information Management, Information Security, Records management, SharePoint Online

Tips to reduce complexity when implementing SharePoint

Over a period of almost 10 years of providing support for SharePoint (2010, 2013, Online), one of my key learnings has been to avoid complexity in its implementation. The more complicated the implementation is, the harder it will be to support, fix and maintain.

This post contains several tips for implementing SharePoint to minimise complexity and therefore the need for support.

Before the tips, it is important to understand the original SharePoint architecture model as this model (a) likely continues to exist in many organisations and (b) can influence decisions – not necessarily in a positive way – about how to implement SharePoint Online.

Understand the (historic) dual nature of SharePoint

SharePoint was first released in 2001. There continues to be a lot of legacy SharePoint implementations and approaches to SharePoint Online that reflect these older implementation models.

SharePoint has always had two sides – the publishing functionality (usually in the form of an intranet) and the document management functionality (where documents are stored). Sometimes these two are conflated into the single term – ‘intranet’ when in fact they are two quite different things in terms of architecture and usage.

Older (pre Online) on-premise versions of SharePoint typically consisted of multiple web applications in several app pools, as the diagram below shows.

(Source: Microsoft ‘SPS 2010 Design Sample Corporate Portal with Classic Authentication architecture’ model)

Within each of these web applications, organisations would have one or more site collections, often with sub-sites. Almost none of this architecture model remains in SharePoint Online – there are now only sites, which are still technically site collections, but preferably without any subsites – see below. This is sometimes described as a ‘flat’ implementation as every site (formerly a site collection) is on the same ‘level’.

The publishing functionality, enabled through the publishing features, was typically used for intranets. Most information was presented on pages, typically across multiple subsites, with some use of the document libraries (e.g., to store common forms or policies).

But the publishing User Interface (UI) was poor; most organisations engaged a third-party to create more engaging (and usually heavily customised) intranets. The outcome has often been that organisations have had to maintain old legacy SharePoint servers to keep the ‘old’ intranet running. In most cases, these older SharePoint sites cannot be migrated ‘as is’ to SharePoint Online.

The former publishing functionality was replaced in SharePoint Online with communication sites.

The document management functionality was (and continues to remain) the default ‘out of the box’ (OOTB) option for all new team sites. Most older SharePoint sites had to be accessed via a browser and the older UI was often seen as not very interesting or engaging. Business areas would sometimes customise the site pages, sometimes to the point of making them appear to be ‘local’ (business area) intranets.

Although SharePoint Online has the same dual nature, it does not use web applications. Instead, all site templates (communication or team) must be created under one of two paths: /sites/ and /teams/. Organisations may default to just one of these two paths for all sites, or could decide to make use of them to differentiate between, e.g., enterprise sites (cross organisational, e.g., the intranet) and team sites (the name of the business area/team comes after /teams/).

Tip 1 – Try to avoid or minimise customisation

As noted above, customisation was common in on-premise versions of SharePoint. Microsoft have done a lot to improve the UI for both communication and team sites.

Microsoft have released a range of pre-canned templates for communication sites that can be downloaded from the ‘lookbook‘ site. (These templates will soon be available as a choice when new sites are created as well.) These templates and new web parts allow organisations to set up a nice-looking and engaging intranet, with no customisation, (other than via the web parts on each page), that is easy to support and manage.

Organisations that require more complex intranets can of course continue to customise their communication sites and/or use a wide range of third-party tools. These are likely to require a higher level of support to maintain and troubleshoot issues, including from third-party vendors.

The customisation of SharePoint team sites used primarily to store and manage document-type content (e.g., to replace network file share storage) is now a different matter. The rapid adoption of MS Teams as the primary UI to access this content over the past 18 months and the ability to sync document libraries to File Explorer and access the content on a mobile device, has in most cases made browser-based access redundant.

There is no longer much point in customising the browser (pages) view of SharePoint team sites used to store documents. Customisation in these sites is more likely to take the form of the site structure, content types and columns, permissions, or the types of information stored in them. Any customisation of team site pages should be restricted to the out of the box options.

Tip 2 – Don’t overcomplicate the structure

Older versions of SharePoint could have quite complicated structures – from the web application through to the site collection, sub-sites, libraries, content types and columns.

These structures would inevitably cause issues over time as organisations re-structured or were renamed, or wanted content moved to different parts of a site or a different site. The easiest sites to manage were always the simple stand-alone sites which is, fortunately, the preferred model in SharePoint Online.

To avoid complexity with all SharePoint Online sites, don’t create sub-sites unless absolutely necessary. Microsoft don’t recommend sub-sites any more – see ‘Planning Your SharePoint Hub sites‘. To quote from that page:

Subsites don’t give any room for flexibility and change. Since subsites are a physical construct reflected in the URL for content, if you reorganize your business relationships, you break all the intranet relationships in your content. Subsites can also create challenges when it comes to governance because many features (including policy features like retention and classification) in SharePoint apply to all sites within the site collection, whether you want them to or not. This means that you must frequently enable a feature for the entire site collection, even if it’s only applicable to one subsite.

Instead of using sub-sites in communication sites, create multiple pages linked via the out of the box mega menu or links.

Avoid using sub-sites at all for team sites unless there is a genuine requirement to restrict access to part of the site. The same outcome can usually be achieved by changing access controls on a document library.

Tip 3 – Use Content Types and columns selectively

SharePoint is built on content types, including the common ‘item’, ‘document’ and ‘folder’ types. Older SharePoint implementation models sometimes made extensive use of Content Types and site (or library) columns to define content added to document libraries. This meant that end-users would have to select a Content Type and/or add or choose metadata when content was saved, a process that was seen as off-putting for most.

To minimise complexity, deploy custom Content Types and additional site or library columns only where really necessary, not as a default approach. Don’t use Content Types to differentiate between (ironically) content or document types but consider using site or library choice columns with default values instead. For example, if a document library is used to store records about meetings or committees, a drop down choice value for ‘document type’ is more likely to be used (and useful) than Content Types.

Tip 4 – Avoid complex permissions

Possibly up to 70% of all support queries over a decade related to permissions or access restrictions relating to a team site and usually started with ‘Why can’t I access …?’ or ‘Why can (so and so) see (or not see) this content?’ They rarely related to permissions on a publishing or communication site, which tend to have simple permission structures.

Almost all of the queries about team site permissions could be tracked back to someone changing the default inherited permissions. In one case, on a site with very complex permissions, a site owner deleted the site owners permission group, locking them out not only of the site but on every single part of the site that had unique permissions. It took a couple of weeks to restore these permissions.

Try to avoid changing the way permission inheritance works. The permissions set at the site level (example shown below) flow down to all the content. It is all too easy to lose sight of (and then find) what permissions have been changed.

If there is a genuine requirement to restrict access, consider moving that specific content to a separate library or even a separate site, rather than restricting access on items within a library, especially one that has a complex folder-based structure.

Also, keep in mind that over the past decade, the access model for SharePoint content has changed from (a) restrict access everywhere and only grant access to those who can access it, to (b) open access everywhere and only restrict access to what needs to be restricted. This is a much easier model to support.

The easiest way to give ‘everyone’ internally access to all SharePoint content is to add ‘Everyone except external users’ to the Visitors group of every SharePoint site, including sites linked with MS Teams. This access does NOT give them access to the Team channel posts in MS Teams.

Whether or not external users should be allowed access via external sharing will depend on each organisation, but it is a good way to reduce the volume of duplication that happens when content is attached to emails. It can also be monitored.

Avoiding access control complexity should also help to improve information security, by ensuring that controls are more easily understood.

Tip 5 – Avoid storing too much and/or unrelated content together

SharePoint sites (including those linked with Teams) are a form of logical aggregation or container. And you can store a LOT of content on those sites. According to the Microsoft site ‘SharePoint Online limits‘:

A library can have up to 30 million files and folders. When a list, library, or folder contains more than 100,000 items, you can’t break permissions inheritance on the list, library, or folder.

But, as the saying goes, just because you can doesn’t mean you should.

It is all too easy to see the ‘Documents’ library of every SharePoint site (especially Teams-linked sites) as the equivalent of a top level folder in a network file share with multiple folder hierarchies. This might seen quite appealing and simple to use at first, but after several years, the ‘Documents’ library can end up a lot of content, not all of which is related to the site’s original intended purpose.

After 10 years, the content is likely to resemble an uncontrolled network file share, with redundant, trivial and outdated content all over the place. With potentially up to 30 million items, this will make managing the content so much harder.

As much as possible, try to ensure that SharePoint sites are based on logical business functions and the libraries in those sites mapped to business activities.

This is not always easy; for example, many smaller organisations have a ‘corporate services’ type function that includes a range of business activities, including managing property, general admin, legal, HR/personnel, fleet and corporate meetings etc. While all of this content could be stored in a single SharePoint site, there is likely to be a requirement to restrict access to content (see previous point) which will only result in increasingly complex permission controls and support issues over time. Mixing unrelated content could also become a nightmare for compliance and records management.

A better, more sustainable, option would be to create multiple SharePoint sites (or Teams) with multiple libraries, linked via a hub site as necessary. This approach will also make it easier to manage records in the longer-term.

Feature image – original source unknown

Posted in Compliance, Exchange Online, In Place Records, Information Management, Records management, SharePoint Online

In place vs in place management of records in Microsoft 365

The ability to manage records ‘in place’ in SharePoint has existed since around 2013. But this is not the same thing as leaving records where they were created or captured and managing them there – ‘in place’.

This post explains the difference between the two ‘in place’ options. In brief:

  • The Microsoft ‘in place’ model is based on making the distinction between non-records content and content declared as records (as per DOD 5015.2), that may be stored in the same SharePoint site, or using Exchange in-place options.
  • The other ‘in place’ model is simply based on leaving records and other content where they were created or captured, and managing it there – including (where necessary) by applying the ‘in place’ options in the previous point.

The Microsoft in-place model

SharePoint

The Microsoft in-place model for managing records in SharePoint is based on the requirement to comply with the US Department of Defense (DOD) standard titled ‘Design Criteria Standard for Electronic Records Management Software Applications’, usually known by its authority number – DOD Directive 5015.2, Department of Defense Records Management Program, originally published in 11 April 1997.

Section C2.2.3 ‘Declaring and Filing Records’ of the standard defines 26 specific requirements for declaring and filing records, including the following points:

  • The capability to associate the attributes of one or more record folder(s) to a record, or for categories to be managed at the record level, and to provide the capability to associate a record category to a record
  • Mandatory record metadata.
  • Restrictions on who can create, edit, and delete record metadata components, and their associated selection lists.
  • Unique computer-generated record identifiers for each record, regardless of where that record is stored.
  • The capability to create, view, save, and print the complete record metadata, or user-specified portions thereof, in user-selectable order.
  • The ability to prevent subsequent changes to electronic records stored in its supported repositories and preserving the content of the record, once filed
  • Not permitting modification of certain metadata fields.
  • The capability to support multiple renditions of a record.
  • The capability to increment versions of records when filing.
    Linking the record metadata to the record so that it can be accessed for display, export.
  • Enforcement of data integrity, referential integrity, and relational integrity.

Microsoft’s initial guidance on configuring in place records management describes how to activate and apply this functionality primarily in SharePoint on-premise. It is still possible to apply this in SharePoint Online (but see below). The SharePoint in place model refers to a mixed content approach where both records and non-records can be managed in the same location (an EDMS with RM capability):

Managing records ‘in place’ also enables these records to be part of a collaborative workspace, living alongside other documents you are working on.

The same link above, however, also refers to newer capability that was introduced with the Microsoft 365 Records Management solution in the Compliance admin portal. This new capability allows organisations to use retention labels instead to declare content as records when the label is applied, which ‘effectively replaces the need to use the Records Center or in-place records management features.’

The guidance also noted that, ‘… moving forward, for the purpose of records management, we recommend using the Compliance Center solution instead of the Records Center.’

Exchange

A form of in-place management has also been available for Exchange on-premise mailboxes, with in place archiving based on using archive mailboxes – see the Microsoft guidance ‘In-Place Archiving for in Exchange Server‘.

One draw-back of this model is that the (email) records in these mailboxes were not covered by the same DOD 5015.2 rigor as those in SharePoint, but they could at least be isolated and protected against modification or deletion, for retention, control and compliance purposes.

Archive mailboxes, including ‘auto-expanding archives’, also exist in Exchange Online. In the Exchange Online archiving service description, it is noted that:

Microsoft Exchange Online Archiving is a Microsoft 365 cloud-based, enterprise-class archiving solution for organizations that have deployed Microsoft Exchange Server 2019, Microsoft Exchange Server 2016, Microsoft Exchange Server 2013, Microsoft Exchange Server 2010 (SP2 and later), or subscribe to certain Exchange Online or Microsoft365 plans. Exchange Online Archiving assists these organizations with their archiving, compliance, regulatory, and eDiscovery challenges while simplifying on-premises infrastructure, and thereby reducing costs and easing IT burdens.

The new ‘in place’ model

A newer form of in-place records management has appeared with Microsoft 365.

Essentially, the new model simply means leaving records where they were created or captured – in Exchange mailboxes, SharePoint sites, OneDrive or Teams (and so on). and applying additional controls where it is required.

The newer model of in place records management is based on the assumptions that:

  • It will never be possible to accurately or consistently identify and/or declare or manage every record that might exist across the Microsoft 365 ecosystem. For example, it is not possible to declare Teams chats or Yammer messages.
  • Only some and mostly high value or permanent records, will be subject to specific additional controls, including records declaration and label-based retention.
  • The authenticity, integrity and reliability of a some records may be based more on system information (event metadata) about its history, than by locking a point-in-time version.

Microsoft appear to support this dual in place model with their information governance (broader controls) and records management (specific controls, including declaration) approach to the management of content and records across Microsoft 365, as described in the Microsoft guidance ‘Information Governance in Microsoft 365‘, which includes the graphic below, modified to show the relationship between the two in place concepts.

The relationship between Microsoft’s ‘in place’ focussed records management, and managing everything (including records) in place.

In place co-existence

Can both in place models exist? Yes. There is nothing to prevent both in place models existing in the same environment, in which some records may need to be better managed or controlled than others, but it is important to understand the distinction between the two when it comes to applying controls.

Image: Quarantine Building, Portsea, Victoria Australia. Andrew Warland 2021