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?

  • Great question.
    – Mr Smith
    Feb 20, 2013 at 20:49

5 Answers 5


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.

  • Querying OData probably works as long as the items are published in DB.
    – Likhan
    Feb 20, 2013 at 9:45
  • 1
    [Had to add an additional comment as I kept getting "You may only edit a comment every 5 seconds."] However, you could check the result of your broker query agains CM to see if they are already published to the publication target. If yes, just unpublish them, otherwise set the state to published using the old, deprecated, COM API/Republish them, and then unpublish.
    – Likhan
    Feb 20, 2013 at 9:50
  • LOL Nuno, I would not use either one of these approaches :) Call me old fashioned, but I would much rather start fresh with an empty CD DB :) Feb 22, 2013 at 19:20
  • You're old fashioned Mihai :p
    – Nuno Linhares
    Feb 22, 2013 at 20:23

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.

  • 1
    We've had the same publishing targets since day one in Tridion (v5.2 in late 2007) so for us it isn't that the old publication targets not available anymore. We think (but cannot prove) most of these stem from issues with either the publishing/deployer services where they or the com+ services required a restart in the middle of publishing an item. I am disinclined to directly update the CM database but you have me thinking maybe a sql query that compares the publish status of items in the CM and broker databases is in order here combined with one of Nuno's suggested solutions. Feb 20, 2013 at 3:30
  • Is it just as bad if using the API instead? For example, the old PowerTools had page/component "set unpublished" tools. Mar 10, 2013 at 7:02
  • that's only half bad ;) Mar 12, 2013 at 20:37

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.


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.

  • 3
    The thought of trying to use Content Porter to export or import several hundred thousand components/pages is somewhat horrifying. May 8, 2013 at 5:39

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. :)

  • Did the same with PowerShell to unpublish orphaned items in the broker database Jun 5, 2018 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.