I heard someone yesterday going off about how they were freaked out about whether the next hotfix or SP was going to break their environment.  Odd I thought.  For me I’ve been here before through the previous versions.  Nothing has changed.

Before I got off on recommendations and links to articles meant to enlighten, I want to keep some balance to the topic.  Yes, SharePoint is an application platform, but there definitely are best practices in this area.  When I talk to AC a good dev friend for example, he tells me that any functionality he develops, he packages into a solution or feature no matter whether he builds it in Visual Studio or not for ease of deployment and retraction. 

I know there could be more information on change and configuration management and staged deployments.  There are some things in the works.

I think this KB clarifies the scenario and provides some good recommendations. KB 944105 Not all of that is necessary if you don’t need to touch those files.  It is a good rule of thumb to try to avoid staying out of that directory if at all possible.  If you don’t need to go to there don’t.  If you do, follow the KB.

First, solution deployments, features, and so on are great ways of deploying/rolling out changes to your sites.  Not saying you still can’t do bad things in those, but there are some sure no no’s in terms of changing the SharePoint code itself.

This KB points out that changing the files in the layouts directory *may* be changed during a hotfix or service pack update.  The only reason those pages might be updated is if there was a change in them.  There is some logic to follow here.  The pages that will be updated are those where there is a change that is newer than what is on the file system.  Something we use to do in IT and I’m sure they likely still do is to backup the entire 12 Hive, the /12 and down. 

The 12 Hive… 

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\

Basically all the program files and all the site definitions everything in /layouts etc… By first backing that up you know you can restore the file if you need to.  The other thing we do is to use WinDiff a very handy tool to tell us what files have changed.  It is obviously more ideal to add your own files rather than to change the out of the box files.  It really is improper to change the out of the box site definition files,

If you’re looking for look and feel ….. do it in a master page, a CSS, a theme or even with SharePoint Designer directly

If you’re looking for custom navigation …. do it in a master page, or with SharePoint Designer

If you really want to make your site have certain lists, or certain columns, first try to accomplish it with a feature or list template, but if you need much more than that you could create a list definition, but these are harder to support over time.

Doing a Windiff against an out of the box deployment vs. yours you’ll find the differences in the files, then you can even find the differences in the web.config, etc…  knowing what files and how many will give you a stronger idea of how customized an environment is and give you the level of difficulty around supportability.

Let’s say you backup your files and one of your files is over written.  Don’t just replace the file with yours from your backup.  What you should do is take the new one and merge in your new changes, this will update the date to a newer date, so it won’t happen again next time a repair happens and the fix will be included.

There are some tips on keeping your environment supportable from the previous version.  Best Practices for Ensuring Application Reusability and Upgrade. A lot of the advice is still very valid.  It talks about not modifying the out of the box site definition and creating a copy.  Before you jump in and start creating your own site defs, I say hold on and really really ask yourself if you want to maintain your custom site definition over time.  Try to talk yourself out of it and see how you can accomplish the same thing with features and solutions.  Even templates are much easier to maintain over time than custom site definitions.

If you’re looking at this post and saying man am I in trouble, let me encourage you and say support themselves will always do their best to try to support your environment.  More often than not even when they think you’ve made your environment unsupportable they’ll try.  Ryan Rogers in a post from a couple of years ago discusses supportability in SharePoint.  It’s still very relevant.  Another good product support blog to follow is Chris Gideon’s.  He’s been following the hotfxes around SP1 along with tips around applying and troubleshooting.

Here’s a quick list of supportability list what NOT to do in SQL:

This KB 841057 focuses on what NOT to do in the database very specifically.  Basically stay out of it. 

• 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
If a database modification is discovered during a support call, the customer must perform one of the following procedures: • Perform a database restoration from the last known good backup that did not include the database modifications
• Roll back all the database modifications

Great so what Can I do?  Here’s a great KB on SharePoint Safe DBCC commands and other things you can do in the database.

Check database integrity
Reduce a database
Reorganize an index
Clean up the history
Update statistics
Rebuild an index


KB 932744  Information about the Maintenance Plan Wizard in SQL Server 2005 and about tasks that administrators can perform against SharePoint databases. 

If you’re looking to put together some of your own policies around development and customizations, you may find Sean Livingston’s paper and really an outline for doing so, extremely enlightening.  This paper was orignially designed as a paper on recommendations for internal MS IT supportability.