Thursday, March 13, 2008

Protecting SharePoint customisation against SP's, hotfixes, et all

Changes to 12 Hive
Changes directly to the out-of-the-box files in the 12 hive, should be avoided whenever possible. The reason being, you risk losing those customisations whenever a service pack/hotfix is applied. And always backup the 12 hive, so that it can be restored if it all goes pear shaped. And use a good diff tool to check for changes, and merge (as against replacing) when copying the backed up file into the 12 hive.

Whenever possible deploy our customisation as features and solutions. And follow the MS best practice guideline for keeping you customisation upgrade safe. To build a comprehensive customisation policy document read policies around development and customizations.

Changes to the SharePoint DB
MS does not support modification to the SharePoint DB. If you do have to make changes, keep a backup of DB which does not contain any customisation. MS will ask you to revert back to that DB, if you ever need to lodge a disaster recovery case with them. Changes to the following are not supported:
  • Adding database triggers
  • Adding new indexes or changing existing indexes within tables
  • Adding, changing, or deleting any primary or foreign key relationships
  • Changing or deleting existing stored procedures
  • Adding new stored procedures
  • Running stored procedures manually or programmatically
  • Adding, changing, or deleting any data in any table of any of the databases for the products that are listed in the "Applies to" section
  • Adding, changing, or deleting any columns in any table of any of the databases for the products that are listed in the "Applies to" section
  • Any modification to the database schema
  • Adding tables to any of the databases for the products that are listed in the "Applies to" section
Read this article on what is supported, which basically includes DB maintenance tasks only. If you have to query SharePoint DB, I suggest you do so against a copy of the production data, and build maintenance plans to keep it in synch with prod data. Maintenance plans though can cause issues in themselves, such as index corruption as described here .

No comments: