Beware – MOSS migration of SPS Listings generates problematic Site Columns

Written by Cornelius J. van Dyk on . Posted in Annoyances

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.



Cheers
C




image

Tags: ,

Trackback from your site.

Cornelius J. van Dyk

Born and raised in South Africa during the 70's I got my start in computers when a game on my Sinclair ZX Spectrum crashed, revealing it's BASIC source code. The ZX had a whopping 48K of memory which was considered to be a lot in the Commodore Vic20 era, but more importantly, it had BASIC built into the soft touch keyboard. Teaching myself to program, I coded my first commercial program at age 15.

After graduating high school at 17, I joined the South African Air Force, graduating the Academy and becoming a Pilot with the rank of First Lieutenant by age 20. After serving my country for six years, I made my way back into computer software.

Continuing my education, I graduated Suma Cum Laude from the Computer Training Institute before joining First National Bank where my work won the Smithsonian Award for Technological Innovation in the field of Banking and Insurance. Soon I met Will Coleman from Amdahl SA, who introduced me to a little known programming language named Huron/ObjectStar. As fate would have it, this unknown language and Y2K brought me to the USA in 1998.

I got involved with SharePoint after playing around with the Beta for SharePoint Portal Server 2003. Leaving my career at Rexnord to become a consultant in 2004, I was first awarded the Microsoft Most Valuable Professional Award for SharePoint in 2005, becoming only the 9th MVP for WSS at the time. I fulfilled a life long dream by pledging allegiance to the Flag as a US citizen in 2006. I met the love of my life and became a private consultant in 2008. I was honored to receive my ninth MVP award for SharePoint Server in 2013.

Leave a comment

You must be logged in to post a comment.