Its very clear to me that content types after they are deployed their inherited lists shouldnt be changed manually using the web gui.

“Do not, under any circumstances, update the content type definition file for a content type after you have installed and activated that content type. Windows SharePoint Services does not track all the changes made to the content type definition file. Therefore, you have no reliable method for pushing down all the changes made to site content types to the child content types.”

In the current project I am suspecting that some changes were done to the content type after the deployment and activation, and I need to know in which lists the link to the parent content type definition is broken.

This link: http://blog.karstein-consulting.com/2011/09/20/powershell-tool-to-enumerate-the-content-type-usage-in-sharepoint-2010/

Tells me for each content type, its usages, but what I need to know its if for a list the inheritance link is broken or not.

  • Can you guarantee the inheritance link is broken? Or is it rather that the content types aren't at the same rev.? The description makes it sound like the inheritance link would still be there, just the revision wouldn't be pushed down the line. Could you find some discernible difference between the "good" CT and the "bad" CT and use that as your basis of comparison? Commented Jan 28, 2013 at 21:13

2 Answers 2


I was wondering if there was a Modified date property to the content type but unfortunately there isn't

However you could compare the SchemaXml properties of the Child Content Types with the Parent Content Type and see if they are different. You will need to exclude checking some properties such as ContentTypeId because of the reason below.

The way that Content Types work is that apart from the System Content Type they always inherit from a parent Content Type.

When a content type is added to a list / document library its ContentTypeId is set to inherit from the Content Type at the Site level.

So for example if you have a Content Type called Sales Invoice which inherits from Document then an example Content Type Id would be

  • Document Content Type Id: 0x101
  • Sales Invoice Content Type Id: 0x101007E31BF9A4BCF483B9D9367D4A8A351C5

If that Sales Invoice Content Type is added to a document library then its content type id will be different but based on the Sales Invoice Content Type Id.

For example:-

  • 0x101007E31BF9A4BCF483B9D9367D4A8A351C5005F54410CB66C4730996E01EC9C82CC96

Once you have got all the content types in shape, why not then set them to read-only so that they cannot be changed by anyone else without Admin rights.

When you need to push down changes, write a bit of PowerShell to go through all the child Content Types to turn off the readonly flag. This is what the Content Type Subscriber Timer Job does.

Would that be a suitable solution?


In your case you don't have broken inheritance between a site content type(parent) and a list content type(child), but some changes in the parent that are not pushed down to the child. You could try to push down the changes through the user interface or you could create upgrade of the feature that deploys the content type.


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.