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