Beware – MOSS migration of SPS Listings generates problematic Site Columns

OK, so if there's one thing that drives me insane, it's when people complain and criticize something without having a solution at hand. I always believe that if you have objections or criticism to how something works, you should be ready to defend your position with suggestions on how to do it better. This is especially true in politics, but I apply it to my life in the software world as well. That is why I don't generally as a rule blog about product oddities that I've discovered, UNLESS I also have a workaround ready to demonstrate in the same blog entry.

I've been working on our SPS to MOSS migration for quite some time now. We had quite a bit of pre-existing content though I wouldn't describe it as anything more than medium size. Nonetheless, we did have some interesting obstacles to clear, such as our use of custom area definitions, which turned out to be unsupported per PSS. We had to work around that issue by reverting back to standard area definitions, a process which I documented in this KB.

I have today confirmed what appears to be a bug that could cause lots of frustration. It certainly has caused lots of frustration to us over the last couple of weeks as we worked to isolate and identify its cause. The problem originates with the use of "Listings" in SPS 2003. We used Listings everywhere because its automatic linking functionality made life easy for our content editors. We had run the "/" site collection, which represents the portal areas, through the migration process and started cleaning up, branding and customizing our portal. Despite our utter disappointment that Listings had been dropped as a content type, we worked to address the issue. It's during this process that we were customizing Site Columns and Site Content Types. Our listings had used a property called "Group". Group was defined as a Choice field with 3 values:

• Overview
• Highlight
• Resources and Information

Anyway, after the migration, Group was defined by MOSS as a Custom Site Column that sourced from the Page type.

We then proceeded to add Group as an existing site column to the Article Page site content type under Page Layout Content Types.

You can see from this screen shot:

That the Zip/Postal Code which is a pre-existing Site Column which we added to the Article Page content type as a column, shows up in our properties. So too does the CvDGroup which is a recreation of the choice column that Group represents, but the Group column simply does not show up. It does not function as expected in proliferating out through the site collection.

We confirmed that if you actually deleted the Article Page content type and then add it back as a content type, then the Group column will show up. This is obviously not a desirable situation as it would not be practical to remove the Article Page content type in each site in the portal and then add it back again. Besides, you can't delete a content type unless all references to it has been removed and/or deleted. That would mean deleting all article pages on all sites, removing the Article Page content type from all sites, deleting the Article Page content type from the portal, adding the Article Page content type back to the portal, adding the Article Page content type back to each Pages library on each site within the portal and then finally recreating all article pages off this new type. Not practical…

So, what's the warning then?

WARNING! Do not attempt to use migrated site columns anywhere with your content types.

WORKAROUND – Instead, simply recreate the migrated site column manually as a custom site column. It can be made identical and will function as expected without any side effects.

Not quite the ideal solution, but it will keep you out of hot water and save you hours of frustration. I'll be filing a bug report for it and will post here if it is resolved/fixed.

Later
C