Details about how Document ID Service is activated

You may have found that Document ID Service is a very interesting feature. Sometimes you activate it and it just works as expected. But sometimes you activate it and it doesn’t work immediately. A typical example is to activate it on a team site and a publishing portal site. On the team site, it works immediately, but on the publishing portal site, it doesn’t work immediately. So what is the reason behind?

The reason why this feature works like that is related to how it is activated. Basically, when we activate this feature, it will check if the current site collection is a big site or not. If the site collection is not big, it will just enable the DocId on the site collection and register a work item for the Document ID Assignment timer job (DocIdAssignment). But if the site collection is too big, it will just register a DocIdEnableWorkItem for the Document ID Enable/Disable timer job (DocIdEnable). So to big site, it relies on the DocIdEnable timer job to enable the DocId. But you may find even if you run this timer job immediately after the feature is activated, the DocId is not enabled. It is because when the DocIdEnableWorkItem is added to the site by the feature activation, it has been specified to be executed 30 minutes later to avoid the potential conflict. You can check the real scheduled delivery time by querying ScheduledWorkItems table in the content db. So the DocId will only be enabled when you run DocIdEnable timer job after the scheduled delivery time. For example, suppose you activated DocId feature on a publishing portal at 8:00am, the DocIdEnableWorkItem was scheduled to be delivered at 8:30am. If you ran DocIdEnable timer job before 8:30am, nothing really happened. Only when you ran it after 8:30am say 8:35am, DocId was enabled then.

The final question is how big a site collection is big? The boundaries are maximum 1 web/site, 40 lists/web and 20 doclibs/web. A publishing portal is too big because by default it has 3 webs. The OOTB document center is OK because by default it has 1 web, ~30 lists and ~15 document libraries. The numbers are hard coded and, so far as I know, there is no way to change them. 

Comments (7)
  1. TomResing says:

    I wouldn't have even thought to check for the time job. Great post and congratulations on the MCM!

  2. Chun Liu says:

    Thanks, Tom. 🙂

  3. Chris Byrom says:

    This explains it. Thanks for the information. I have been pulling my hair out trying to figure out why this wasn't working when I rant the enable/disable job after enabling the Document ID Service feature.

  4. Arthur M. says:

    Cool. Thanks for sharing. It saved me couple of hours to localize a problem. Thanks.

  5. Thanks Chun, you saved me hours of work on this issue.

  6. James says:

    Hi Chun,  Thanks so much for this.  I've been banging my head against the wall for days.  Now – do you by any chance know if there's a way to reset all document ids when using a custom provider?  We added a custom provider AFTER activating docid, so now we have a mix of old and new ids.  Any help appreciated.

  7. Javi Cartin says:

    Hi, I have this issue, we migrated a site from SP2007 to SP2013, so, we activate the feature but, when you view an item or edit an item (metadata), the documentid column is not present on those pages; newform.aspx, editform.aspx, any ideas?

Comments are closed.

Skip to main content