none
Content Index Unknown State after Exchange 2013 CU15 update RRS feed

  • Question

  • Hi guys - I have just upgraded to CU15 and when checking Get-MailboxDatabaseCopyStatus | FL Name,*Index* I receive the following:-

    Name                         : MDB1\CERBERUS
    ContentIndexState            : Unknown
    ContentIndexErrorMessage     : Could not find registry value of Index Status for database
                                   {2c569645-36e4-4906-848d-5c38d67c7574}.
    ContentIndexErrorCode        :
    ContentIndexVersion          :
    ContentIndexBacklog          :
    ContentIndexRetryQueueSize   :
    ContentIndexMailboxesToCrawl :
    ContentIndexSeedingPercent   :
    ContentIndexSeedingSource    :
    ContentIndexServerSource     :

    I have tried all the usual fixes.  

    Deleting content index folder and restarting Search services.

    I have also created a new database and migrated mailboxes across, hoping a new DB might fix it - no luck..

    This has not resolved the issue, as I suspect the registry keys are the issue here.

    When checking HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Search\IndexStatus there are no keys present. 

    This is a single Exchange 2013 server, so I do not have another server to copy the keys from.

    Any ideas?



    • Edited by Misan Monday, January 16, 2017 4:11 PM
    Monday, January 16, 2017 4:03 PM

Answers

  • I have managed to resolve this issue by creating a new REG_SZ key with the GUID of my mailbox database under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Search\IndexStatus.

    I then entered some value data from another forum post of 3,3,51539607564,2014-06-12 21:54:48Z,0,,0,0

    I then stopped the two Search services and deleted the content index folder.  I then restarted the two search services and could then see the Index status go back to an Unknown status.  The registry value data then updated accordingly and the content index is now healthy.


    Monday, January 16, 2017 4:57 PM

All replies

  • I have managed to resolve this issue by creating a new REG_SZ key with the GUID of my mailbox database under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Search\IndexStatus.

    I then entered some value data from another forum post of 3,3,51539607564,2014-06-12 21:54:48Z,0,,0,0

    I then stopped the two Search services and deleted the content index folder.  I then restarted the two search services and could then see the Index status go back to an Unknown status.  The registry value data then updated accordingly and the content index is now healthy.


    Monday, January 16, 2017 4:57 PM
  • Hello Misan,

    You could try to recreate the keys. Create a string value, in the name, insert the GUID of the database, in the Data, create a value according to this link:

    https://blogs.technet.microsoft.com/johnbai/2013/07/16/exchange-2013-high-availability-fast-search-and-the-windows-registry/

    Also, check this blog post were you can find an example of the data value:

    https://social.technet.microsoft.com/Forums/office/en-US/7dea2ac7-6f9a-4b2d-800c-1c13a98d84df/cu6-issues?forum=exchangesvrdeploy


    Por favor, se te ajudei, não esqueça de marcar como resposta. Acesse meu blog: http://msexperts.blog.br ____________________________________________________________ Please remember to mark the replies as answers if they help.

    Monday, January 16, 2017 5:14 PM
  • I know that this is a really old thread, but the issue wouldn't be truly resolved by changing these reg key values. These values are a reflection of how the CI system is currently operating. Yes ECP will show it's state as "healthy", but it is still really in a failed state until the root cause is resolved.

    A way to check this is to visit those same updated reg keys an hour later and see if the timestamp has changed. My bet is that it hasn't, and if that server or DAG node became the client focus, searches would fail.

    Another hint that the service is still broken is to use shell to query the DB, and notice that the CI backlog is unchanging. Mine was 163 items, not changing.

    I had already tried the contentsubmitters approach, as well as reseeding to no avail.I had these symptoms on only one of my 4 servers in a DAG, all others were healthy from the start.

    Turns out that Exchange was a victim of a Windows process that had gotten out of control. C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys on the DAG member with the failed CI contained over 577,000 files, and had been generating 10-15 per minute. Other DAG members had between 5 and 14 files. I renamed the folder to \Machinekeys-old and rebooted the server.

    CI now showing as "failed", but the reg keys were updated to reflect the failed CI. I then reseeded the indexes, and CI is now functioning.This caused a blowup of the certs between front-end and back-end, but that is easier to resolve from an Exchange point of view.

    I hope that this saves someone else a lot of time.

    We're running Exchange 2016 CU10 on Server 2012 R2 nodes.

    Brad


    B

    Friday, August 24, 2018 4:46 PM
  • Hello,

    This was exactly the issue I've just found with our 2 node Exchange 2013 cluster. Having a similar thing with certificates now. When I go to the Certificates section in the EMC, the page is just stuck loading for the server that had the issue. 

    Did you have this, and if so how did you overcome the issue?

    Thanks


    Steve

    Monday, March 11, 2019 4:42 PM