Busquedas de OWA no funcionan en Exchange 2013 – El Poderoso Exchangiiiiiiiii

Hola amigos,

Hace poco una persona me contacto por un problema, desde OWA no podían realizar búsquedas, no había errores simplemente le daba mensaje que no había resultados encontrados

Inicialmente hicimos una búsqueda sencilla al estado de su ContentIndexState de sus bases de datos mediante el comando:

Get-MailboxDatabaseCopyStatus *

Tal cual esperaba, el resultado fue un Failed para prácticamente todas las bases de datos (incluida la base donde estaba el usuario de prueba)

El error completo que recibíamos era:

Las bases no estaban en DAG, ejecutar un comando de update-MailboxDatabaseCopyStatus no era posible y como podemos ver, no era un error muy descriptivo…

——————————————————————————————————

Nota: Por tratarse de una organización verdadera no usare pantallas reales.

——————————————————————————————————

Ahora, como todo buen administrador lo que inicialmente intente fue regenerar las carpetas de catalog. Detuve el servicio de Microsoft Exchange Search y el servicio de Microsoft Exchange Search Host Controller

Acto seguido elimine el Catalog Index para la base afectada

Realizado esto, volví a iniciar los servicios, la carpeta se regenero como se esperaba pero seguíamos teniendo un estado failed y no el esperado Crawling

Validando en Event Viewer detectamos dos eventos que brincaron a la vista: 1009 y 1010

– – – – – – –

Log Name: Application
Source: MSExchangeFastSearch
Event ID: 1009
Task Category: General
Level: Warning
Keywords: Classic
User: N/A
Description:
The indexing of mailbox database DB6 encountered an unexpected exception. Error details: Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. —> Microsoft.Exchange.Search.Fast.FastConnectionException: Connection to the Content Submission Service has failed. —> Microsoft.Ceres.External.ContentApi.ConnectionException: Given CSS specification failed:Could not connect to CSS node at net.tcp://localhost:17028/ContentSubmissionServices/content with flow: Microsoft.Exchange.Search.Writer.12.14. Error: Object reference not set to an instance of an object. Inner exception:—
atMicrosoft.Ceres.External.ContentApi.DocumentFeeder.DocumentFeeder.SetCssNodes(IEnumerable1 newCssNodes)atMicrosoft.Ceres.External.ContentApi.DocumentFeeder.DocumentFeeder..ctor(DocumentFeederOptions options) at Microsoft.Exchange.Search.Fast.FastFeeder.Initialize() --- End of inner exception stack trace --- at Microsoft.Exchange.Search.Fast.FastFeeder.Initialize() atMicrosoft.Exchange.Search.Fast.Factory.InternalCreateFastFeeder(ISearchServiceConfig config, String indexSystemFlow, String indexSystemName, String instanceName, Int32 numberOfSessions) atMicrosoft.Exchange.Search.Engine.SearchFeedingController.InternalExecutionStart()atMicrosoft.Exchange.Search.Core.Common.Executable.InternalExecutionStart(Object state) --- End of inner exception stack trace --- at Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult asyncResult) atMicrosoft.Exchange.Search.Engine.SearchRootController.ExecuteComplete(IAsyncResult asyncResult)


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

Log Name: Application Source: MSExchangeFastSearch Event ID: 1010 Task Category: General Level: Warning Keywords: Classic User: N/A Description: An operation attempted against a FAST endpoint exprienced an exception. This operation may be retried. Error details: Microsoft.Exchange.Search.Fast.PerformingFastOperationException: An Exception was received during a FAST operation. ---> System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.Server stack trace: atSystem.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) atSystem.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) atSystem.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) atMicrosoft.Ceres.ContentEngine.Admin.FlowService.IFlowServiceManagementAgent.GetFlows() at Microsoft.Exchange.Search.Fast.IndexManager.<GetFlows>b__16() atMicrosoft.Exchange.Search.Fast.IndexManagementClient.PerformFastOperation[T](Func1 function, String eventLogKey)
— End of inner exception stack trace —

Ahora estos eventos, aunque a primer vista contienen información que parece útil sobre la causa del problema, no fueron de gran ayuda para este caso en particular

Intente generar un grupo de AD «ContentSubmitters» y le di permisos full a networkservice y administrators, reinicie servicios….Nada

Validamos mediante Get-ServerComponentState y todo se vea activo

Validamos servicios automaticos…Nada

Validamos que la salud de las bases de datos no estuviera comprometida, algún buzón corrupto tal vez, pero la lógica indica que era muy improbable que se corrompieran buzones en todas las bases de datos *ojo a este punto*

Ahora, algunas personas han logrado reparar este comportamiento jugando un poco con estos movimientos y desmontando/montando la base de datos. Desmontar la base de datos no era una opción a considerar ya que es un ambiente productivo

Este era un ambiente co-existido con 2010. En ocasiones pasadas me ha tocado que los buzones de -monitoring (HealthMailboxes) se corrompen durante la instalacion de 2013 si ya existe una organización previamente. La persona me comento que jamas habían logrado que funcionaran las búsquedas desde que instalaron Exchange 2013.

Con esta información pude ver mas claro cual podia ser la causa del problema, la cual era que los buzones de salud se habian corrompido durante la instalación. así que los valide

Get-Mailbox -Monitoring -Server «Servidor»

No recibí ningún error, sin embargo pude notar que el numero de buzones de salud no correspondía al que debería haber según las reglas de creación ( 1 por DB y 10 por CAS) por experiencias pasadas decidí eliminarlos mediante el comando:

Get-Mailbox -Monitoring -Server «Servidor» | Remove-Mailbox

Despues reinicie el servicio de Microsoft Exchange Health Manager, esta acción regenera los buzones de salud

Después de un momento, se generaron nuevamente los buzones de salud. Los cuales correspondían en número al ambiente . Nuevamente reinicie los servicios Microsoft Exchange Search y Microsoft Exchange Search Host Controller

Y woalá. Las bases de ese servidor comenzaron a mostrar estado de Crawling

Después de esperar un par de minutos, las bases comenzaron a mostrar estado de Healthy y eventualmente pudimos realizar las búsquedas de OWA

La razón de esto es que los Health Sets usan dos views dentro de Managed availability: internos y externos. Un health Set es un grupo de probes, monitors y responders que determinan si un componente esta saludable. Entre ellos se validan los componentes de OWA, EAS, IS, content indexing, transporte etc. Y fue ese health set que monitoreaba el componente de content indexing que estaba corrupto

¡Enhorabuena! Coman una galleta y dense una palmada en la espalda como premio, Acaban de aprender algo nuevo que pueden revisar al momento de reparar problemas de busquedas en OWA

Coman frutas y verduras

Por Geovany Acevedo