How do you modify existing SharePoint sites?

Question

I often have customer requesting changing properties, like the version history setting on all document libraries on all existing sites on a farm.

So far the best solution I have been able to think of is to script it in Powershell, test the script before I run it, and then pray that I have not overlooked something critical. Is there a better and safer way?

Answer 1

Take a content backup first then run the script.

Backup either through stsadm or database.

Does not work for any central admin changes.

Answer 2

Well, if you want to automate something, PowerShell can be one of the best methods to do so. You can see the actual commands being run before trying it (versus having something compiled that you can't peak into).

Depending on what the PowerShell script will be doing, you can often using simple parameters like -WhatIf and -Confirm for cmdlets that have a impact on the system (that delete, move, etc.).

-WhatIf provides: Output that indicates the action that would be normally undertaken if the command was run. You can see the actions that would be undertaken.

-Confirm: Before an action would be actually undertaken, you are basically asked "are you sure you want to do xyz".

With -WhatIf, if all your information scrolls off the screen, you can simply use Start-Transcript to start a log of your console session, then you can review that log to carefully look at all the actions that would have been taken. That way you can make sure your commands are correct before running them.

Answer 3

My personal "customization workflow" is as follows:

1. Prototype solution in PowerShell. Messy.
2. Export my messy PowerShell command history.
3. Paste command history into Visual Studio, do line-by-line conversion to C# (this is a mostly mechanical process, with the exception of converting pipelines)
4. Package as a Feature deployed by a SharePoint Solution (using WSPBuilder Extensions); specifically, call my converted "script" from a Feature Receiver. Also write code that undoes your customization when your Feature is deactivated.
5. Test in dev, test in QA. 5b.If it's a huge script with a big impact, I'll ask our DBAs to restore a big content database into the QA db server; then I'll attach this copy of production to our QA farm and run the script against a copy of production data. This was a crucial step for our migration from WSSv2/2003 version; I think I did four full test runs before migrating to 2007. Anyway, if you need it, you need it.
6. Install/activate Feature in production.

It's a lot heavier than "run script on prod server," but if you're looking for a "better" way to push in customizations, this is the proper way to do it in SharePoint. SharePoint's Feature and Solution frameworks are designed for this scenario.

And yes I use PowerShell heavily for prototyping/object spelunking.

EDIT: I didn't mention, but you need to have a disaster recovery plan that revives all your customizations. This is where it starts to get crazy, depending on which customizations you've made. In your example above, the content database stores the data, but other customizations aren't as easy to restore in a DR situation, notably with the SSP and farm-level customizations stored in the config db, or if you've modified the web.config or the IIS metabase.