Here is an interesting behavior that I came across in the last weeks.

You attempt to enable the Document ID feature at site collection level.

The enablement works fine but you do not receive any errors, however no document ID field is generated for the documents in the site collection (if you check for example the View Settings of a document Library).

Not very obvious but here’s one explanation:

During the enablement, we attempt to modify the default Document Content Type. If this content type is Sealed or Read Only the update will fail and the Document ID Column along with the respective Event receivers cannot be added to the Document Content Type.

Now you will ask, what on earth could have set the field ReadOnly ?

Easy.

If you are using Content Type Deployment ( through a Content Type Hub) and published the Document CT the deployment in itself will set the Document Content Type to Read Only at subscriber level to prevent future alterations and to make sure we inherit the properties from the source ( the CT hub).

What you need to do, if you find yourself in this situation is to :

  • Activate –Document ID Feature on the site where you want it
  • Go to Site Settings-Content Type Publishing at Subscriber (the site above) level
  • Check the box to refresh all the published Content Types  on the next update
  • Go to Central Administration->Timer Job Definitions and Locate Content Type Subscriber (your Web Application where your site resides) .
  • Open it and click Run Now
  • Wait for the job to complete.

At the end, you should have the Document ID Field available in the View Setting for the Shared Documents Library (or any library that has the Document as the content Type)

If you are not making use of the Content Type Deployment feature, you need to check whether you use code (your own or third party) that makes use of that flag or might need that (or has set one of these flags to true by mistake). If you are confident that this is not used, you can go to Site Collection->Site Content Types->Document->Advanced Settings and set the Content Type to Read Only False, then go and activate the Document ID Feature

here’s the version for those who think point and click is just lame Smile

$Site= get-SPSite –identity http://Sharepointsite

#first, just check

$ct= $Site.RootWeb.ContentTypes | where {$_.id -eq "0x0101"}

$ct.ReadOnly

$ct.Sealed

#now do the magic

$ct.ReadOnly=$false

$ct.Update()

Why would a content type be read-only

http://office.microsoft.com/en-us/windows-sharepoint-services-help/change-a-content-type-for-a-list-or-library-HA010110607.aspx#BM6

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spcontenttype.readonly.aspx

PS: if by any chance you run into Content Type Sealed =True and ReadOnly = True , we call it a “catch 22” situation, because the read-only setting will fail due to the content type being sealed and the sealed setting will fail due to the content type being read-only.

The only way out at this point in time would be to create a new site collection and move the content over, or open a case with Microsoft to unseal the content type.

How can this happen : through custom solutions that overwrite the default Document Content Type schema.