Reparar el servicio "Microsoft Exchange Search Host Controller" en Exchange 2013

  • Article

Buenas, hoy os traigo un procedimiento para reparar el servicio "Microsoft Exchange Search Host Controller" en Exchange 2013 cuando no es posible levantarlo.

Primero deberíamos entender algunos conceptos que se introdujeron con Exchange 2013:

  • El motor de indexado que corre por debajo ha sido reemplazado por "Microsoft Search Foundation" basado en FAST, para proporcionar rendimiento y mejoras a nivel de funcionalidad.
  • Ya no es necesario instalar "Microsoft Office Filter Packs" para Exchange Search, ya que Search Foundation es capaz de indexar la mayoría de los tipos de archivo que se pueden encontrar como adjuntos en los mensajes de correo. 
  • El indexado de contenido es mas eficiente porque ahora procesa mensajes que se encuentren en el pipeline de transporte. Como resultado, los mensajes que contengan mas de un destinatario o grupos de distribución, se procesará una única vez, por lo que el rendimiento se incrementará y por ende el uso de recursos será menor.

Ahora que tenemos claro el tipo de motor que utiliza Exchange 2013 podemos continuar con el escenario:

Nos encontraremos con situaciones en las que tenemos un DAG montado con Exchange 2013 y al intentar ejecutar el CmdLet "Get-MailboxDatabaseCopyStatus" veremos que el content index State esta en "unknown":

Si vamos a los servicios y echamos un vistazo al de "Microsoft Exchange Search Host Controller" veremos que está en un estado "detenido". Intentamos iniciarlo y a los 2 segundos aproximadamente nos lo detendrá.

Por norma general, tendemos a irnos al application log y al system log dentro del visor de eventos y veremos un id de evento 1000 seguramente como el que sigue dentro del application log:

Faulting application name: hostcontrollerservice.exe, version: 15.0.712.0, time stamp: 0x5199c4fd
Faulting module name: KERNELBASE.dll, version: 6.2.9200.16451, time stamp: 0x50988aa6
Exception code: 0xe0434352
Fault offset: 0x000000000003811c
Faulting process id: 0x679c
Faulting application start time: 0x01d00afe38226850
Faulting application path: C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\hostcontrollerservice.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Faulting package full name:
Faulting package-relative application ID:

Como no nos dice demasiado podemos intentar ver cuantos procesos de "noderunner.exe" tenemos en ejecución, deberíamos tener 4 en ejecución y lo mas seguro es que tengamos únicamente 3 y eso nos deja las siguientes causas:

  1. El directorio "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\data" tiene alguna entrada corrupta.
  2. El fichero node.ini ubicado en "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\data\Nodes\Fsis\AdminNode1\Configuration\Local" esta vacío.
  3. El puerto 3802 ya esta en uso. (podemos ejecutar un "netstat -ano" y revisar si lo tenemos en la lista para luego buscar el proceso por el PID en el task manager).

Como solución a cualquiera de estas tres causas, podemos aplicar lo siguiente:

  1. Abrir una consola de Exchange Management Shell (EMS) en modo Admin.
  2. Ir hasta el siguiente directorio: "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Installer"
  3. Ejecutar ".\installconfig.ps1 -action U" Esto nos desinstalará el Search Foundation (en este punto no deberíamos tener ni el servicio de "Microsoft Exchange Search Host Controller" ni la carpeta "data" dentro de "'C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController "
  4. Ejecutar " .\installconfig.ps1 -action I -dataFolder 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\data' -baseport 3800". Esto nos volverá a instalar el Search Foundation, regenerando la carpeta data y tomando como puerto base el 3800.

La situación que deberíamos tener ahora al ejecutar un "Get-MailboxDatabaseCopyStatus" es que el content index State esté en "unknown". Ahora deberemos esperar un poco para que después de un rato, al volver a ejecutar el CmdLet, obtendremos el content Index State es un estado de "failed" seguramente.

En este escenario, podremos hacer un re-seed del catalogo de las bases de datos, tomando como origen el servidor que la tenga activa en ese momento con el CmdLet "Update-mailboxDatabaseCopy -identity BBDD\SERVER -CatalogOnly", o bien esperar a que el propio servidor lo haga de forma automática.

Espero que os sea de utilidad.

Alberto Pascual

Comments

  • Anonymous
    March 17, 2015
    exelent information thanks you so much, for your information very good and unique.
  • Anonymous
    March 17, 2015
    the information that you describe in this post is good and the result are exelents, the information is diferent to many other post in the internet and for that reason is very good, and efficient. working very well thanks :)
  • Anonymous
    March 17, 2015
    the information that you describe in this post is good and the result are exelents, the information is diferent to many other post in the internet and for that reason is very good, and efficient. working very well thanks :)
  • Anonymous
    August 20, 2015
    y si solo tengo un servidor de correo no un DAG como inicio el indexacion ya que no puedo realizar búsquedas en outlook y tampoco en OWA en ningún buzón.
  • Anonymous
    August 20, 2015
    Rafael, de los cmdlets comentados en el articulo, unicamente el ultimo de ellos (update-mailboxdatabasecopy) es especifico de un dag. Los otros pasos del plan de remediacion los puesdes llevar a cabo en un despliegue de un nodo
  • Anonymous
    August 22, 2015
    David, he realizado todos los pasos, pero el problema continua. como reemplazo los CmdLests (update-mailboxdatabasecopy) para mi único servidor.
    Gracias por responder.