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

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.