Demystifying Document ID's part 2 – The Content Type Hub

Demystifying Document ID's part 2 – The Content Type Hub header image

Almost two years ago I did a write up on the Document ID solution. In the Demystifying Document ID’s post I worked out the flow on how and when Document ID’s are provided. Over the course of the last two years there where some changes and SharePoint 2013 got released. Besides that the public beta of SharePoint 2016 is here, and Office 365 got pretty big.  So when I found myself working with the Document ID’s again I dug into it again to see what changed. In my case I had to work with Office 365 and the ContentType Hub.

Document ID’s

As expected the document id features didn’t change all that much. Though in my last post I looked at when the Document ID feature got activated and when a site would be classified as too big. That didn’t change at all. It still is is classified as too big when:

  • The site has a subweb (if it has more then 1 web, including the rootweb)
  • The site has more then 40 lists
  • The site has more then 20 document libraries

You will see that this is the same behavior for SharePoint 2016 as well.

Content Type Hub

What ended up being confusing was the Content Type Hub. Working with the Content Type Hub in Office 365 helps you in centralizing your Content Types. However publishing the content types from the hub poses a risk. The Content Type Hub does not publish event receivers. When the Document ID feature gets activated it adds an event receiver to all documents that derive from the Document content type. On the content type hub this will work and you will see that the document id gets added to your newly created documents. When you publish the content type it will propagate to all subsites, including the document id column. However when uploading new documents you will not see the Document ID show up. It will take up to 24 hours before a the timerjob passes by and sets the document id for the document.

Actually the document id gets created and you will be able to access the document through the document id link if you know it. However due to the lack of the event receivers the item itself does not get updated with the id. That’s why after 24 hours it does show up, as there is a timerjob that cleans up and sets the id’s correctly for items that are missing them.

It also does make sense that if you are using the Content Type hub to publish the content types activating (or reactivating) the document id feature does not help you in this case. The document id provider does not update read only content types, and any content type pushed from the Content Type Hub is read only.

Long story short the only way to work around this is to either not use the combination of content type hub and document id’s.

Workarround

You can work around it by writing some custom logic to add the event receivers to the Content Type or Document Library. Because if you add the required event receivers to the list everything will work as expected. In order to add the event receivers just use the following receiverassembly:

ReceiverAssembly="Microsoft.Office.DocumentManagement, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

and receiverclass:

ReceiverClass="Microsoft.Office.DocumentManagement.Internal.DocIdHandler"

For the following four event types:

  1. ItemAdded
  2. ItemCheckedIn
  3. ItemUncheckedOut
  4. ItemUpdated

Once the receivers are attached to the list any content type that is added to that list will automatically use them. This will result in the expected behavior as all items will be updated with the correct document id.

Loading comments…