SharePoint logo shown on screen of mobile device. Image courtesy of Adobe Stock.
When working with the SharePoint Content Type Hub and published Content Types in general, one mistake a lot of experienced users and administrators make is deleting published Content Types from the Content Type Hub before unpublishing them first. This can result in the Content Type becoming a published orphaned Content Type, which continues to show up in new site collections or sites requesting a refresh of all published Content Types.
I’ll go over some of the basics before walking you through the process of unpublishing published orphaned Content Types. This post will cover:
- How to publish Content Types from the Content Type Hub
- How to unpublish Content Types
- How published orphaned Content Types are created
- How to deal with orphaned Content Types
- How to unpublish orphaned Content Types using the provided script
- What do to with orphaned Content Types in SharePoint Online
How to publish Content Types from the Content Type Hub?
Definitions for all published Content Types are stored in the term store database (Managed Metadata Service database) and all sites subscribing to the Content Type Hub pull the definitions from the term store database rather than from the Content Type Hub.
- Go to the Content Type Hub and create a new Content Type (let’s call it “CLM Document”) and configure it with the appropriate columns and settings. Currently, this Content Type only exists in the Content Type Hub site collection.
- As soon as you select the option to Publish the Content Type and click OK (shown in image below), the Content Type definition is added to the term store database.
- The table in the term store database is called “ECMPackage” (shown in image below) and has information on all Content Types that have been published in your farm, even if they were later unpublished. Please note that you should never directly edit SharePoint databases, because that will render your farm in an un-supported state from Microsoft’s perspective.
- Now, when “Content Type Subscriber” timer job will run for the web applications in your farm, it will pull the “CLM Document” Content Type’s definition from the term store database into all site collections in those web applications.
How to unpublish Content Types?
Unpublishing the content type is very similar to publishing it and involves following steps:
- Go to the Content Type Hub, locate the Content Type “CLM Document”, go to its publishing settings, select the option to Unpublish, and click OK (shown in image below).
- As soon as you click OK, the Content Type entry in the term store database will be marked as unpublished.
- Now, when “Content Type subscriber” timer job will run, it will unpublish those Content Types from the subscriber site collections. What that means is that the content type “CLM Document”:
- will be turned into a local (site collection) content type in all existing site collections,
- and will not be added to any site collections created from now on.
How are published orphaned Content Types created?
If you forget to unpublish a Content Type before you delete it from the Content Type Hub, SharePoint will not warn you about it and that Content Type definition will still exist in the term store database as a published Content Type.
During my projects, I have run into two types of problems resulting from published orphaned Content Types:
- Some SharePoint administrators and record managers complain that newly created site collections continue to have Content Types that have long been deleted from the Content Type Hub. This is an obvious result of published orphaned Content Types and can easily be diagnosed.
- Some SharePoint administrators complain that they keep making changes to a Content Type (adding or removing columns etc.) but none of the changes ever make it to the site collections.
The second issue happens frequently in upgrade and migration scenarios where a content migration tool (like ShareGate) is utilized. These tools can bring over content and recreate the Content Types, but with incorrect parent Content Types (i.e., instead of the CLM Document, they may set the parent to Document) which breaks the connection to the published Content Type.
However, in some instances the issue arises when someone deletes a published Content Type without unpublishing it first, and then recreates another Content Type with the exact same name. The newly created Content Type has the same name but a different ID in the term store database and is treated as a separate object/content type. When the Content Types are published, the orphaned Content Type will be added to site collections first, and when the second Content Type is added (with the same name) it will run into a name conflict and fail to publish to the site. Instead, you will get an error logged in the Content Type publishing log on the site collection.
How do you deal with orphaned Content Types?
Unfortunately, there is no way to unpublish a published orphaned Content Type in the SharePoint interface. Furthermore, you should never alter SharePoint databases directly, so you cannot unpublish them directly in the term store database.
After searching on this issue for a while, I have come across a PowerShell based approach and script provided by Microsoft’s Stefan Gossner. It seems you can issue a supported unpublish command to SharePoint for the Content Type definitions stored in the term store database using PowerShell. The script identifies orphaned Content Types by comparing names of all published Content Types in a target/sample site collection and the Content Type Hub. It also issues the unpublish call to all published Content Types that are found in the target site collection but are missing from the Content Type Hub.
While this is a great solution, there is a minor problem in the script’s approach which is specific to the second problem scenario I previously mentioned, where a user may have deleted published Content Type without unpublishing it, creating a new Content Type with the exact same name. The script’s logic will do a comparison and find a Content Type with same name in both sites (target site and Content Type Hub) even though the Content Type IDs will be different. This can easily be remedied by changing the comparison in the script from name to the ID of the Content Types.
Attached to this post, you will find a slightly updated script that you can use to unpublish orphaned Content Types. I should caution you that I have used this script before in several test and production environments without any issues, but the script is being provided as-is without any expressed or implied warranties. Please use it at your own risk.
How to unpublish orphaned Content Types using the provided script
If you suspect there are orphaned Content Types in your SharePoint environment, you can run this script to verify that.
If you run the script without the unpublish switch, it will not make any changes to the environment and will only report on the published orphaned Content Types that it discovers.
Please follow these steps to run a comparison and unpublish orphaned Content Types:
- It is highly recommended that you create a new test/sample site collection for running the comparison because it will have the latest Content Types from the term store database.
- Download the script and unblock it (if it is blocked) and ensure you have access to run scripts (Set the execution policy).
- Run the PowerShell script on a SharePoint server in the farm as an administrator as follows:
.\Unpublish-ContentTypes.ps1 -SubscriberSite https://sharepoint/sites/samplesite -ContentTypeHub https://sharepoint/sites/contenttypehub
Here:- SubscriberSite parameter will need the URL for the sample site collection you created for comparison,
- ContentTypeHub parameter will need the URL to your Content Type Hub.
- Since we ran the script without the unpublish switch, the script will only do a comparison and list any orphaned Content Types it finds. In the example screenshot below, I have intentionally generated an orphaned Content Type called “Orphan Test Content Type” that is discovered by the script:
- Once you have verified the results, you can run the script again with the unpublish switch. That will unpublish the orphaned Content Types.
.\Unpublish-ContentTypes.ps1 -SubscriberSite https://sharepoint/sites/samplesite -ContentTypeHub https://sharepoint/sites/contenttypehub -Unpublish
Here is a screenshot for the test content type being unpublished: - Please note that the script will continue to report the orphaned Content Types until the “Content Type Subscriber” timer job has been run and completed because the Content Types in the subscriber site will only be converted to local Content Type after the job has completed. So, run the Content Type subscriber job, wait for it to complete, and then run the script again to verify no orphans remain.
What about SharePoint Online?
In SharePoint Online, you do not have access to the timer jobs or the back end so there is no way (that I am aware of) to be able to issue the unpublish command. You should be extra careful and remind all users that have access to the Content Type Hub to always unpublish Content Types before deleting them.
If you still find yourself in the situation where you have published orphaned Content Types, then reach out to Microsoft support and they should be able to unpublish those for you.
Update: Microsoft has since rolled out the modern interface for Content Type Gallery which is available on the Content Type Hub and the SharePoint Admin center in Office 365. In this modern interface, when you delete a published content type, you are shown a warning message that confirms that the content type will be unpublished before being deleted. Going forward, you should not run into the orphaned published content type situation described above in SharePoint Online.
Thanks for reading our article about unpublishing orphaned Content Types! Want to learn more? We've got an article about how to create SharePoint Content Types, and an advanced discussion on Content Types.
Our team is happy to assist with your information management in M365 needs, so contact us with your questions or check out our free chart covering the capabilities of M365 and our data lake, Collabspace, below: