Event ID: 1136 and 1464 being logged every 5 minutes on the domain controllers

Ran into an interesting problem at a client a few months ago while deploying OCS. They had already deployed an OCS standard pool in their environment for testing purposes earlier but decided to get us in to deploy an enterprise pool from scratch. The administrator told me that he had already uninstalled the standard pool so the environment should be free of any OCS settings but when I arrived on site, I noticed that the domain controllers were logging the event ID 1136 error every 5 minutes with the following message:

Active Directory failed to create an index for the following attribute.

Attribute identifier:

2383405064

Attribute name:

msRTCSIP-ApplicationDestination

A schema cache update will occur 5 minutes after the logging of this event and will attempt to create an index for the attribute.

Additional Data

Error value:

-1403 JET_errIndexDuplicate, Index is already defined

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The research I did on the internet didn’t help so I reached out to our Microsoft Partner Support forums and was recommended the following:

There are 2 ways to clear out the event ID 1136 on the domain controllers.

1. Clear up the corrupted database – This option is too complicated to do.

2. Temporarily disable index for this attribute in forest – Easier to do.

I would suggest to do option #2. Once we turn off indexing for this attribute and enough time has passed to ensure that all domain controllers have replicated and has defragged its database, we can then turn it back on.

Here are the steps to disable indexing for the attribute:

======

1. Logon to schema master DC.

2. Run adsiedit.msc

3. Expand schema partition.

4. Find object “cn=ms-RTC-SIP-ApplicationDestination”

5. Double click to modify the attribute

6. Find the attribute “searchFlags”

7. Modify it to 0 (by default is 3)

8. Save the setting and wait for AD replication.

This error will not be logged on the domain controllers anymore after the schema change has replicated to all the DCs.

To enable indexing again, take the steps above and change it back to what it was before in about 3 after weeks.

------------------

I went ahead and recommended #2 to the client, made the appropriate changes and the errors were cleared up on the domain controllers but after 3 months of error free logs, I went back to enable the flag only to find that the errors would come back. I went back to the Microsoft Partner forums and was told the following:

The only identified workarounds to eliminate the event are:

1. Do not index this attribute for containerized searches in the active directory like Paolo mentioned.

2. Or make sure the system locale installed in schema master doesn’t fall into the listed ones in the following article.

- ADPREP Challenges - Mark Empson's Blogalot - Site Home - TechNet Blogs ...

http://blogs.technet.com/b/mempson/archive/2009/06/11/adprep-challenges.aspx

I went back and asked the engineer:

We used Paolo's suggestion to stop the errors but would like to know how to fix it while still getting the improved search performance through indexing.

Is option #2 this KB? http://support.microsoft.com/kb/932862/

I looked at the steps and it's pretty much the same.

… then go this response:

Yes, the option listed in the KB is to remove the index for the specific attribute. So far the workaround to eliminate the errors are the two I mentioned in the last reply. Actually, the impact should be very small and the functionality won’t be affected since we don’t index only a single attribute. If you insist indexing the attribute, I’m afraid you have to install a DC (host schema master role) and make sure that the installed system locale doesn’t fall into the list of the link previously given.

It sounds like there really isn’t an easy way to fix this other than disabling the indexing of that attribute.