I have two SharePoint 2013 farms: authoring and publishing target.  Content deployment jobs are used to push changes from authoring.  This has been working just fine until I applied the latest updates.  The upgrade process create a log files in the _catalog/MaintenanceLogs library.  The Content Deployment process wants to deploy this list now.  Since it already exists on the target, the import fails.

Has anyone run into this?  Is there any way to tell Content Deployment to not export this?  There's really no reason to publish this library.  Any way to delete it on the target so it just gets re-created?

Hi,

Thank you for your question.

We are currently looking into this issue and will give you an update as soon as possible.
 
Thank you for your understanding and support.

Thanks,
Linda Li
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Hi Ray,

Please let me know what update did you install. And if there is any error after we publish this library. Based on my experience, we do not need to delete this log file.

Regards,

Dats Luo

I ran Windows Update and applied the latest updates for SharePoint.  After running the product config to complete the upgrade, the upgrade logs are there.

Hi Ray,

If we have installed the latest update, and the logs are there. In fact, the upgrade logs may not cause any issue. Would you let me know how you import and the error message when it fails?

Regards,

Dats Luo

There error message is "There can only be one instance of this list type in a web. An instance already exists.".  The object is the Maintenance Log Library.  I'm using content deployment jobs to import.

To reproduce this, you have to have the 2 farms deploying content and THEN deploy the latest updates.  When you run the upgrade on the target farm, the Maintenance Log library gets created which breaks the deployment.

Hi Ray,

From the error message, the instance already exists and we can't have another instance. Please refresh the deployment job and reset the cache.ini file(Stop Timer Job service and set the cache.ini to 1, then start Timer job service).

Best Regards,

Dats Luo

Dear Dats Luo,

I'm running into the same issue as described by Ray. I tried resetting the cache.ini but that won't help. The destination content database keeps a record in the AllDocs with dirname: sites/temp/_catalogs and LeafName: Maintenancelogs which results in the error "Unable to import the folder _catalogs/MaintenanceLogs. There is already an object with the Id.... "; I tried removing the destination site collection and recreating it as an empty site like being proposed in step 3 here; also detaching an attaching the content database from Central Admin is not working. The object stays in the AllDocs table in the content database. I can't enumerate / find the site where the object supposed to be existing using powershell or central admin. It just doesn't exist, so it seems to be an orphaned object ?

Any other suggestions?
Thanks,

Jeroen

         

Update:

I ended up detaching the content database and re-create a new one using Power Shell. (I'll create a blog post for that). Then created an empty Site Collection in the new content database using stsadm (not the blank template using the interface).

Please notice that, amongst other things, the local (site collection) term groups will be inaccessible after executing above. They are still available in the MMD store but not accessible for the new site collection (ID). Again, with Power Shell you will be able to make them available again. (I will also document this method in the blog post).

        

Kind regards,

Jeroen Schoenmakers