How can we resync what the Tridion CM thinks are published to a specific publication target with what is actually published to that target?

Question

We’ve experienced issues where what the Tridion CM thinks is published to a specific publishing target (components and/or pages) doesn’t match the content that is actually located on that publishing target.

For instance, we have a daily job which queries the Broker database for a list of ‘expired’ components and then tries to unpublish them. Each day, roughly 400 of the components returned by the query are items the Tridion CM doesn’t think are published to the publishing target the broker database is associated with. This results in the unpublishing of those 400 component failing and the components continuing to show up as the results of queries we run against the broker database.

We have found we can rectify this if we re-publish the component and then unpublish it but this seems somewhat kludgy. Because the CM doesn't think these components are published we have also had some unfortunate situations where we have deleted the component from Tridion but the component still exists in the Broker database and now we cannot even use the kludgy solution to get these items unpublished.

We’ve had some similar issues with pages and we have also had instances where the CM thinks components/pages are published to a publishing target but the component/page doesn't actually exist on that target.

Any thoughts on how we can get the publishing statuses for items in the CM back in Sync with what the publishing targets actually have published to them?

Answer 1

There's multiple ways in which something like this could be handled...

Unresolve the resolving

The Tridion Publisher Resolving process is the one determining that there is nothing to be unpublished, because item x is not published to target y. One could potentially write a custom resolver that would change this behavior, so that the unpublish instruction is still sent to the deployer.

Over engineer

This would be easy to do if you have OData on the delivery side, not so easy if you don't. You could write a program that "double-checks" the published status of every item by calling the linking service, and then changes the published status in the CM using the old, deprecated, COM API.

Answer 2

This situation is a very sensitive one, but unfortunately you can get into this state quite easily, as you described (e.g. after a db backup/restore, the old Publication Targets are not available anymore, but the state of items previously published to these targets are kept).

The official fix for this situation would be to re-create the Publication Target and unpublish from it. This can be difficult or even impossible to achieve due to several reasons, so the following solution is really a hack that forces you to modify the CM DB manually. I cannot express strong enough how sensitive this operation is and it can leave your system crippled. Even worse, you won't realize right away it is crippled, but items might fail to publish in the future since the CMS believes the item is already published to a certain target. So take the following with a grain of salt and make DB backups before attempting it. One final scare :) if your manage to cripple your DB, Customer Support will not help you fix it! Moreover your system will no longer be supported.

So, you can change the publish state of Tridion items by modifying (i.e. deleting) the relevant records from the CM DB tables ITEM_STATES and PUBLISH_STATES. Of course you should only delete those for the column PUBLICATION_TARGET_ID that is no longer available in your CMS.

Make a backup first!!! Good luck!

EDIT: I see you are looking for an actual SYNC between the Content Manager and Content Delivery sides of your system, hence my answer above is only a partial one since it only tackles the CM side. I am afraid there is no way to 'RESYNC' your CM with CD. The only solution that comes to mind is a very drastic one: start fresh -- 1) empty your CM tables ITEM_STATES and PUBLISH_STATES; 2) take an empty Content Delivery DB (i.e. Broker DB); and 3) perform a full publish.

Answer 3

Perhaps you could do this.

1. Add a new broker database.
2. Configure this so that it gets published to when you publish to the problematic target
3. Publish your entire site (or those parts of it you think should be published)
4. Use the new Broker db to replace your current one

Step 2 could be achieved by adding another destination plus a complete CD setup, or perhaps by adding storage specifications (as I see your question is tagged as 2011)

Of course, this whole approach would be a carefully planned project, and you'd have quite some details to cover, but you'd end up with your systems in sync.

Variations on theme: you might want to set up an entirely separate publication target, use this to create your replacement db, back it up, unpublish everything, and pull the switch.

Answer 4

Do an export of all your publications with Content Porter before attempting to do any of above mentioned. So you could do a fresh import to a freshly reinstalled CM later on if things go SNAFU. This way none of your items will be in the 'published to' state.

Answer 5

We have observed the same issue and contacted SDL customer support. They advised us to capture transport package for unpublish and then get it's content, change it so that it reference "orphan" items in broker and just sent them in incoming folder of broker. This is indeed ingenious process because you mock unpublish process. We created .net project that creates those packages based on tcm ids, we just ran tool, copy zip files and voila, our broker is clean. :)