Adventures in SharePoint variations - part deux

So to recap - recently i had problems with SharePoint variations, the client reported that pages weren't being propagated to all child variation sites

after some research see "adventures in sharepoint variations" - i discovered that the client was only running SP1 of MOSS and that SP2 had significant improvements in the reliability of the variations infrastructure and that SP2 also included some powerful new stsadm commands to help debug problems with variations.

This includes the very aptly named variationsfixuptool 

Which provides the two functions i used to fix the variations "relationships list" for Compass

stsadm -o variationsfixuptool -scan -url http://server/sites/pub/vhome/source > C:\report1.html

This does what it says on the tin, it scans through the relationships list and outputs the relationships in a nice HTML table as URL to URL relationships. This is much easier to read and understand than the relationships list.

Looking at this you can see which pages have failed to deploy to all the variations and focus on fixing the relationships for these pages.

stsadm -o variationsfixuptool -fix -url http://server/sites/pub/vhome/source/sub1 -recurse

But wait you don't need to fix these relationships, the second cool thing about variationsfixuptool is that it includes a method that will actually recurse through the root variation spot your missing relationships and fix them for you! 

I would have been here until the end of time trying to fix relationships without this, i so feel justified for installing SP2.

However this isn't the end of the story......

Although the relationships are fixed there is still a lot of damage to repair not to mention figuring out how this happened in the first place.

When you enable variations on a publishing site template two timer jobs are created to propagate content out to the variation children

I initially suspected these as the culprits for why the variations failed in the first place. On the stage environment these hadn't actually run when i'd published a test page.

running the stsadm -o execadmsvcjobs command seemed to free these up and i was able to publish pages to variations again on staging. However on production the timer jobs seemed to have been running recently. 

If that's the case then all i need to do is republish all the pages identified in the initial scan and with their fixed relationships they should propagate out again as intended. 

Now what's the problem with that you might think. Quite a lot of clicking to do but hey it's not difficult to republish everything.

Well this client has just been on a translation spree. The idea is that when you publish a page in the root site this page is created in the same place on each child variation in DRAFT mode ready to be translated into the native culture for that variation. If you then republish the same page from the root variation again the same process occurs and a new version of the page is propagated to the child variation in draft mode over-writing the previously translated version. This is not something you want to have to inform the client.

So a lot of hard work ahead assessing which pages need to be republished but any new pages fixed should propagate as normal 

As yet i'm still working on how it got into this state in the first place. I only hope the installation of SP2 means it won't happen again...