Managing Content Types across many Site Collections

Made many corrections on Oct 7, 2011

When using content type hub and syndication, to more than a couple site collections, management difficulties arise as follows. Answers are below.

1. All Site collections automatically receive a new content type from the hub when published and when deleted at the hub they are not deleted at each site collection, how to turn this on and off or control it?

2. I cannot delete a content type!

3. Sometimes you add a field to a content type and for some unknown reason it cannot be deleted.

4. Content Type syndication decides to stop working.

5. Site collections will be accepting changes that are published at the hub when you allow it via a link in site collection admin called mange content type publishing. Clicking the link launches a form with a checkbox at the top called Refresh all published content types on next update. If you check this box, the site will accept updates from now on. Problem is the checkbox does not stick so it makes you think you need to check it every time to accept updates. Do you really have to?

6. Changing the field order in the hub after first publish of content type does not propagate new field order to site collections. When adding new fields or changing existing fields at hub and setting a preferred order, they appear in different order at the site collections, they go to bottom of field order, why? How to control this?

7. How can I use content type syndication but stop fields from re-appearing on my list that I have removed manually from the list, every time the Administrator publishes from the Hub the fields re-appear. How to I control this for my list?

8. Another problem is how to turn off accepting updates for an individual content type on a site, maybe you have a content type that is not to accept any updates from hub?

IMPORTANT TO NOTE: If you add a formula to a custom column incorrectly, it will let you, it will add to a site collection and will syndicate but when you attempt to add the associated content type to list it will error out at that point and you will not know which one it is, I went a whole day trying to figure this out. Some good advice might be to fully test formulas on a non syndicated test site collection. A correctly formatted formula will publish to all site collections just fine.

If you add a site collection site Colum to your site collection syndicated content type with different settings such as default value and then later the hub adds this same column and publishes it, your column will inherit the hub settings, not good, it can change the functionality of your app. another good reason to always inherit the published content type to a local content type.

Answer to No. 1

The content types will not be deleted and will become remnants. They will need to be manually deleted with the UI or with code. There is an article here from Microsoft with some code to delete content types. If you want to completely stop a site collection from receiving content types, disassociate it using Service App Associations in Central Admin.

Answer to no 2 from here

If you create a content type and build a list from it then delete the list it goes to many recycle bins on site and on site collection. All recycle bins need to be cleared of the content type before it can be deleted so clear all 3 recycle bins. SharePoint is quite rightly trying to stop you from breaking anything by not allowing to delete a hub content type if: A. the content type is being used by a list or library somewhere in your site; or B. Another content type inherits from the content type you are trying to delete.

The tool called SharePoint manager is a windows app the you can download to SharePoint server  to help determine what content types are used where. Down load it here. Just double click the exe and voila. One drawback is that from the hub, where you create content types, you cannot see what site collections use it, you still have to navigate to each site collection to see. again, make sure your check the recycle bins for any lists or list items (including documents) that might be using the content type. These don’t show up in the “usages” in the content manager tool.

There is the site recycle bin AND site collection recycle bin. Within the site collection recycle bin there are two recycle bin views to select from “End user Recycle Bin items” and “Deleted from end user Recycle Bin”, your content could be hiding in any one of those places. Actually you may not see documents that are using the content type because you don’t have rights to.

More answers from here

If the list allows both minor and major versions and if any of the documents in the list is a minor version, but also has an existing previous major version (i.e. published version), then SharePoint will refuse to delete the content type if it is used by this last major version, even if the latest minor version is not using it.  I don’t have an explanation about why it is doing it, but this is how it works. It seems that you will need to check in a major version if you want to remove the content type in this case.

If the list has the ForceCheckOut flag enabled, then someone may have just added a document and may have not yet pressed “Check In” or may have pressed “Cancel” on the EditForm page. In such a case the document will be added to the list with version 0.1 but will be checked out to that user and will not show up for anyone else (including site collection admins). Actually even if you check through code the SPList.Items with elevated privileges account you will still not be able to see this item if it is not checked out to the elevated account.

One way to detect whether you are having such a “hanging” document is to check the SPList.ItemCount property and see if its value is the same as SPList.Items.Count. If they are different then you may have this type of “hanging” documents in your list. The ItemsCount seems to be stored in an internal array of list properties and counts all the items in the list, while SPList.Items will return only the items you can see.

public int ItemCount





return (int) this.m_arrListProps[20, this.m_iRow];




Answer to no. 3 from here

You will need a PowerShell script to fix. Some columns once added to a content type don’t allow you to remove them, you don’t got a delete button. To delete one such column from your content type you can use the following SharePoint PowerShell Script: But this may not always be the case, sometimes you may deploy a field via hub content type, and test the a list or an existing list with some data in that field, once date is in the field it cannot be removed until the data is removed. Content types do not go in recycle bin.

#Attach to the web and content type
$web = Get-SPWeb http://fldev003/sites/pjstest/
$ct = $web.ContentTypes["Post"]

#Get link to the columnn from the web
$spFieldLink = New-Object Microsoft.SharePoint.SPFieldLink ($web.Fields["Page Image"])

#Remove the column from the content type and update

#Dispose of the web object

Answer to No 4.

I simply had to reset the owstimer and that fixed it in my case.

Answer to No 5

No you don’t, in my testing it seems you have to only check the box once to initialize syndication for a Site Collection, you do not have to visit the site collection again on each publish, it seems like a bug it should stay checked once checked but the checkmark disappears.

Answer to No 6

It seems the syndication would not know the order so it puts it at bottom. So, get the field order close as you can in hub before you create your lists and libraries. Then change to suit in the list version of the content type by accessing it via list settings. Do not change the content types at the syndicated content type site collection level as they will disappear anyway it seems. In order to make the field order changes, you need to make the content type not read only via list settings. Make sure you change it back to read only and try to limit changes to it as there is a message popup saying be careful some things may break workflows etc,

How to Control this?. I created a local content type in my site collection inheriting from the hub based one and set the “Update all content types inheriting from this type?” under advanced settings to no. This fixes the issue, now when the administrator changes a field, say adds some values to a choice field, the new values will deploy to the local site collection but the field order will not change. Strange UI design. even stranger the “No” setting will not stick and will be set to yes next time you go into advanced settings. Very very strange. Make sure you always leave it in read only mode because the timer jobs runs all the time and it could re-set your fields un-knowingly.

Answer to No 7

All you need to do after your list is created and based on a syndicated content type is to remove or add and fields, rules etc on the list and then set it to read only. simple. The publishing will only add new fields or first time added to content type fields, no other fields or changes will propagate.

Answer to No 8

Making it read only or read write does not help because after a publish from the hub, it sets it to read only afterwards and removes any fields you added manually at the site collection level. It seems Microsoft design is for you to create your own content type inheriting from the published master then you can turn on or off changes from the published master. needs validation I am not sure it will do this?.