Had a "great" morning this morning involving releasing to our SharePoint 2007 Production environment which has been in place for nearly 18 months now - 6 server farm. Our UAT environment was built by myself last month which "matches" Production as closely as possible in terms servers etc. but it's been hard because the documentation of how Production built is incomplete. So far anyone out there who has built an environment, I would strongly recommend documenting ANY configuration change made to that Farm environment.

Anyway, I released to our Shared Dev environment fine and dandy and also to our UAT environment with no problems. Then I came across an error in Production, fortunately I had enough exception handling in there to throw and error when I called GetAvailablePageLayouts in the EventReceiver that was trying to create the page and didn't get back the Page Layout I expected in this collection!

Much digging around the web pointed me towards looking at SPWeb.AllProperties["__PageLayouts"] which in a default environment isn't even there but can also be string.Empty. In my Production environment it included a bunch of XML.

So, then started looking around at how this is set on the web and came across SetAvailablePageLayouts. But reading around it wasn't obvious how you got the PageLayout objects to put in the PageLayouts[] array parameter of the method. And Google said nothing on this :-(

I then dug some more and found this property on PublishingWeb called AllowAllPageLayouts , so I set that...and nothing seemed to happen! Then I noticed there is a Update() method also! So the key here is to call both in order ;-)

$baseURL = "http://intranet"

$web = global:Get-SPWeb($baseURL, $null)

$pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)

$pubweb.AllowAllPageLayouts($true)

$pubweb.Update()

$pubweb.GetAvailablePageLayouts() | ft Name, Title

And here were the results! Phew!

There was no documentation on this being locked down at the Site Collection RootWeb, these kind of changes can cause all sorts of issues when you're not expecting them! So again, I recommend documenting anything that is different from a base install when it comes to configuration, or at least have a Solution package that can configure it in a new environment.

I guess the big point is how far do you go with documenting and scripting configuration? The whole point of SharePoint is to be collaborative and let it evolve naturally. Realistically not every dev environment is going to have enough room to restore a entire Site Collection into it, so the rule of thumb is everything but the content should be re-deployable in your Dev / UAT environment. Where the line is drawn between Configuration and Content is left to discuss another day...