Recently I worked a case where the customer was not able to create publishing pages at all.  Whenever they trying doing so, it errors out in the browser and in the ULS logs we see the following stack:

System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.  
Parameter name: index    
at System.ThrowHelper.ThrowArgumentOutOfRangeException
at System.Collections.Generic.List`1.get_Item
at Microsoft.SharePoint.SPFieldMultiColumnValue.get_Item
at Microsoft.SharePoint.Publishing.PageLayout.get_AssociatedContentTypeId
at Microsoft.SharePoint.Publishing.PageLayout.get_AssociatedContentType     
at Microsoft.SharePoint.Publishing.PageLayout.get_UIDisplayName
at Microsoft.SharePoint.Publishing.PageLayoutComparerByUIDisplayName.Compare
at System.Collections.Generic.ArraySortHelper`1.SwapIfGreaterWithItems
at System.Collections.Generic.ArraySortHelper`1.QuickSort
at System.Collections.Generic.ArraySortHelper`1.Sort

Following the stack, one can see the issue is with getting the associated content type Id information.  This makes sense because when we try to create publishing pages, we get directed to /_layouts/CreatePage.aspx which lists all the available page layouts in a list control to create our page from.

Hmm! So, something is causing that enumeration to bail out.  Further digging and probing, we saw that most of customer’s page layouts were “corrupt”.  Huh! How do I say this?  I say this because when I visit /_catalogs/masterpage/forms/allitems.aspx page at a good environment, I get to see the page layouts available as shown in the below screen shot.

Note the “Associated Content Type” column.  The values for this column for page layouts are like “Article Page”, “Welcome Page” etc.,

There are a few page layouts without associated content type information – that’s okay!

But at my customer’s environment, the values for associated content type for these page layouts were displayed as:

‘#VALUE!’

Hmm, that’s not right!!  Digging more from the database we saw the data that’s supposed to hold content type association information were messed up.

As an example, a typical content type association data will look like:

;#Article Page;#0x010100C568DB52D9D0A14D9<and a really long GUID kind of thing>;#

But at customer’s environment, this was stored as:

Article Page,0x010100C568DB52D9D0A14D9<and a really long GUID kind of thing>

Notice, there’s no ‘;#’ in the beginning, in the separator between the content type name and Id and in the end.

So, what did they actually do? Probing continued…

After more probing and good amount of research, this is what the customer did to get into this situation (Oh yes, this is SharePoint 2010 version dependent, it was SharePoint 2010 June CU 2010 environment we worked on):

• Create a SP2010 web application.
• Create a top-level site collection using the team site template.
• Go to: Site Actions > Site Settings > Site collection features > activate SharePoint Server Publishing Infrastructure.
• Go to: Site Actions > Site Settings > Manage site features > activate SharePoint Server Publishing.
• Be in the same /_layouts/ManageFeature.aspx page and deactivate SharePoint Server Publishing feature.
• Go to: Site Actions > Site Settings > click Save site as template.
• Provide a name for file name (e.g., teamsite) & template name (e.g., teamsite).  choose include content and hit OK.
• Go to: Site Actions > Site Settings > Solutions.  Click on the solution name (e.g., teamsite) and download a copy of it (e.g., teamsite.wsp).
• Go to: Central Administration site > Application Management (left nav) > Create site collections > create a new top-level site collection using the “<select template later>” option with custom tab either on the same web application or a different one.
• Browse to the new site collection > Site actions > site settings > solutions.
• Upload the WSP file downloaded in the above steps (e.g., teamsite.wsp).
• Activate it.
• Go back the to the same site collection where you are asked to select a template.
• Choose custom tab and then choose the template displayed in it (e.g., teamsite) & create the site.
• You will be asked to choose or create groups for visitors, members and owners.  Do it as appropriate & hit OK.
• Site should come up fine.
• Go to: site actions > site settings > site collection features.
• NOTE: SharePoint Server Publishing Infrastructure feature is enabled.
• Go to: site actions > site settings > manage site features.
• Activate SharePoint Server Publishing feature.
• Go to: site actions > more options > filter by: Page > click Publishing Page and hit Create.

There it was, I had June CU 2010 installed followed the above steps and go to see the same issue customer reported.  Unfortunately, it turned out to be an unsupported scenario: http://support.microsoft.com/kb/2492356.  However, the contradicting behavior observed to what’s published in the KB led me believe this could be something to do with June CU 2010 patch.

What’s the fix? So, the idea was to ensure we turn all those ‘#VALUE!’ things to read “Article Page”, “Welcome Page” etc.,  Well, it was easy as it sounds.  Since we were in kind of disaster recovery situation (the customer had almost 100 sites created this way), I wrote a tool that would look at a site with “good” data in it (in this case, a site where publishing infrastructure & publishing features are enabled at the site collection and site levels respectively) pick up the page layouts in question and overwrite them in the target site with “bad” data.  Simple yeah?

I’ve enclosed a sample code that does just this (click Download link below).  It uses SharePoint 2010 server object model and has to be run on the SharePoint 2010 server.  Feel free to download, modify & use it!  Hope this helps out if you ever run into this issue.