My SharePoint best practices

  • Backup – Due to SharePoint becoming a pivotal part of the business where significant chunks of the company will rely on its functions to perform their job, I would recommend the following:
    • SQL backups should be performed directly on all databases (or at leastthe content databases (Databases prefixed: WSS_Content_)) on a cycle that is a good compromise between ‘maximum allowable data loss window’ (ie, backup period. Eg, hourly), storage consumption and the fastest speed at which backups can be taken.
      • ‘directly on database’ means using a backup product to perform a full back up at least daily, with differential or incremental backups performed as per the ‘maximum allowable data loss window’
      • Make sure your backup product is fully SQL VSS compliant (it should be initiating a snapshot against all databases simultaneously to ensure a consistent backup state for all databases) and also deals to the transaction log when performing full backups. It should be truncating the transaction log (clearing it out) on each full backup. This helps prevent unnecessary disk space consumption on the SQL server and therefore keeps speed up and reduces the possibility of disk capacity exhaustion.
      • A highly recommended SQL backup product, or even a full SharePoint farm backup product is Microsoft System Center Data Protection Manager 2012 – this product is developed from the ground up to perform the best possible backup of Microsoft technologies and is very efficient and powerful.
    • Once documents and other important ‘business as usual’ documents are being edited and consumed from SharePoint, it is likely that losing more than a few hours of changes across the business is more costly than the extra storage and backup server resources required to backup that frequently. SQL backups are also far less troublesome for minor restores (eg, one file for the Director) compared to having to restore a whole VM farm.
  • Security – we discussed this pretty thoroughly and everyone left on the same page, but I thought I would reiterate what we went through so that it is held in writing for reference:
    • Users should never be assigned to SharePoint groups directly – this creates an administration nightmare because tracing rights has to then be done in AD as well as SharePoint directly – and there is no central place in SharePoint to see all rights assigned to a user.
    • There should be a 1-to-1 mapping between a SharePoint group and its equivalent group in AD, thereby giving you the ability to control the exact rights someone is given in SharePoint by adding them to the AD group that corresponds to that permission.
    • Example: UserA wants to be able to contribute documents on SiteC. SiteC has a SharePoint group called SiteC Contributors which has the permission Contribute assigned to it. SharePoint SiteC – Contributors is an Active Directory group which has been added as the sole member of the SharePoint group SiteC Contributors. UserA is added to the Active Directory group SharePoint SiteC – Contributors and now has the access required to contribute to documents on SiteC.
    • Further points about Security do’s and don’t’s
      SharePoint 2010 Security Best Practices for Mortals
  • Documentation – should be kept transactional and light. Monolithic once-off documents are not as useful as they are not agile to be kept as up-to-date as is required by the fast moving nature of Sharepoint.
    For this reason, it is best to create a SharePoint custom list, use an existing change management software, an excel spreadsheet or even OneNote to capture every configuration change made to the farm along with a reason for the change. It is best to keep this list synced to somewhere accessible should any servers fail (such as an admins desktop; OneNote or Outlook SharePoint list/document library syncing makes this easy)
    Using a transactional documentation approach makes problem diagnosis in the future easier, as one only needs to review this one list to understand what might have changed in the farm to create the problem. Whereas a once-off environment document might only capture the final state of settings, which won’t reflect how a certain service or configuration item reached the state it is in, which omits possibly useful diagnosis information (as certain changes in SharePoint can affect other services/settings without knowledge due to its massive and complex scope). Not having enough time for SharePoint documentation at the time a change is made will only mean yet more time consumed in future when (not if) an issue does occur.
  • Development and testing changes – all configuration changes and site structure changes should always be tested on the development farm before being enacted on the live/production environment. Depending on the scale of the change, especially updates or reconfiguring service apps, the development environment should be a recent copy of everything from the production environment – this ensures the best possible test platform to ensure the change will work as intended on production. A change log is just as important for these changes on the development farm as it is on production – if you miss one of those changes when you go to do the update on production, it may be the difference between the farm being operational and not.
  • Site structure guidelines
    • Try not to create site collections, sites/webs or lists/document libraries with spaces in their URL. It is easy with a Site Collection and Site/Web, because SharePoint allows you to specify the URL separately. However, with Document Libraries and Lists, it is best to create it without any spaces in the name, so that the URL is created without spaces as well, then go back into the settings of the list/library and rename it to be as desired. Spaces cause messy URLs and can be a leading cause of links to pages and documents breaking – especially when various different publishing tools (such as Citrix) or software (such as Outlook) are in use to share links.
    • Keep total URL length short – this means if you are creating document libraries and sites with intentional long display names, create them with short URLs to begin with to prevent hitting the maximum URL length prematurely. Eg, Fleet and Plant Document Library for Photos, Videos and Scanned Documents should be first created as photosvideosscans and then renamed to the long name so that the URL is only photosvideosscans.

General Guidance:

TechNet wiki article gathering a bunch of best practice links. use with caution, but worth reading as the odd page should contribute to further understanding SharePoint and the types of things that needed to be considered in a good site governance procedure.
TechNet Articles > SharePoint 2010 Best Practices

I recommend that you start to form your own “this is how we do things in SharePoint” (ie, governance) document (or wiki page on SharePoint? =P) for SharePoint. Therefore at least everyone within your organisation can then see and contribute – but more importantly – follow those guidelines so that everyone is treading the same path. The more it feels like people can become involved and contribute to the governance of SharePoint, the more likely everyone is to adopt it, and then the more likely your SharePoint environment is to succeed.

SharePoint may seem like just a website, with the ability for document storage and basic database-like functionality – but its inherent flexibility and power is sitting on top of a massive complex engine that works in the functionality of the largest collection of Microsoft software of any other system. Therefore, to keep all those systems in check, strict conformance to some sort of process is required.

Geek, wanderluster, pochemuchka, wannabe-polyglot, photographer and UK-resident kiwi here for the travel.

Leave a Reply

Your email address will not be published. Required fields are marked *