Posts etiquetados ‘windows’

En esta entrada trato de resumir las conclusiones de tres días de intenso y tedioso troubleshooting, investigacion, aprendizaje express y prueba y error de numerosos métodos de resolución hasta lograr reunir todos los datos que encontraba con cuenta gotas en la Technet y dar con la solución definitiva. Espero que este post ahorre trabajo de investigación a través de las engorrosas páginas de la Technet a alguien.

Me notificaron que las búsquedas de Sharepoint del portal corporativo de uno de mis clientes habían dejado de funcionar. Casualmente habían dejado de funcionar el mismo día que tuvimos un problema con el Sharepoint completo relacionado con el antivirus que había provocado la necesidad de reinicio de los servidores de Sharepoint.

Antes de continuar, os explico la arquitectura, aunque esta es poco relevante para la solución. Disponen de un clúster de balanceo de carga para el servicio de Sharepoint formado por dos servidores (SP1 y SP2) y un cluster de alta disponibilidad que aloja las bases de datos correspondientes a Sharepoint (bdd). Para el servicio de búsquedas disponen de un único servicio compartido (SharedService) del cual el servidor SP1 es el índice y servidor de consulta y el SP2 se usa tan sólo como servidor de consulta.

Bueno pues, manos a la obra. A la hora de investigar un problema en Sharepoint, el registro de eventos de windows es vuestro amigo. Es bastante chivato y proporciona información útil. En este caso, observamos en un pricipio los errores:

Nombre de registro:Application
Origen: Office Server Search
Fecha: 19/06/2012 13:37:25
Id. del evento:10038
Categoría de la tarea: Servicio de búsqueda
Nivel: Advertencia
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP2
Descripción:
El equipo de consulta ‘SP1’ ha salido de la rotación a causa del error El índice de contenido está dañado. 0xc0041800. Se volverá a intentar dentro de 900 segundos. Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

——————————————————————————————————————————————————————————–

Nombre de registro: Application
Origen: Office Server Search
Fecha: 19/06/2012 13:37:25
Id. del evento:10039
Categoría de la tarea: Servicio de búsqueda
Nivel: Advertencia
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP1
Descripción:
El intento del equipo de consulta ‘SP1’ no se ha producido a causa del error El índice de contenido está dañado. 0xc0041800. Se volverá a intentar dentro de 900 segundos. Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

Y tras el reinicio de los servicios de búsqueda con net stop osearch (se inicia sólo automáticamente) comienza a aparecer también el registro:

Nombre de registro:Application
Origen: Office Server Search
Fecha:19/06/2012 15:20:04
Id. del evento:4138
Categoría de la tarea: Servidor de índice de contenido
Nivel: Error
Palabras clave: Clásico
Usuario: No disponible
Equipo: SP1
Descripción:
Se han detectado daños de índice en el componente ShadowMerge del catálogo Portal_Content. La referencia de la pila es .Componente: cc575544-4acf-490f-bed4-d23cd4b56d90

Y aquí es cuando os ahorro el calvario. Este error viene del reinicio realizado al servidor de índices en el momento equivocado y en el lugar equiv… no, no. Sólo en el momento equivocado, dado que el servidor estaba realizando el registro de transacciones del índice en el momento del reinicio y estas han quedado en estado inconsistente. Al haberse fastidiado el índice, las búsquedas no funcionan aunque exista otro nodo de consulta. Tampoco funcionan los rastreos de contenido. Aparecen como “En ejecución” pero no están haciendo nada. Puedes comprobarlo accediendo al registro de rastreo y comprobando que no existe ninguna entrada con fecha posterior a la corrupción del índice. ¿Por qué este bloqueo no canta en ningun lado? Pues no lo sé, tal vez a los rastreos de índice les guste vaguear.

Para arreglarlo tenemos que seguir unos sencillos pasos (una vez te los sabes…)

1) Paramos completamente los servicios de búsqueda de Sharepoint en ambos nodos. Es decir, los desconfiguramos y desactivamos a nivel de Sharepoint en los dos nodos.(ojo, antes de hacer esto, asegúrate de apuntar todos los parámetros del servicio) Esto puede hacerse desde el menú de servidor en la administración central de Sharepoint o con el comando de consola:

stsadm –o osearch –action stop

Stsadm lo podreis encontrar en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.

2) Paramos los servicios de búsqeda de ambos servidores desde el administrador de servicios o con el comando

net stop osearch

En este caso el servicio se mantiene detenido.

3) Accedemos a la ruta de almacenamiento de índices del servidor de índice. Allí habrá una carpeta cuyo nombre-número-chorizo coincida con el componente que se indica como dañado en los registros de eventos anteriores. En nuestro caso, habrá una carpeta llamada cc575544-4acf-490f-bed4-d23cd4b56d90. Renombramos esta carpeta, la movemos a otra localización o si somos unos temerarios, la borramos.

4) Desde la administración central de Sharepoint reconfiguramos y arrancamos los servicios de búsqueda de los nodos tal y como estaban antes. Puede que no reaccione y tengais que ejecutar en la consola:

stsadm –o osearch –action start

5) Levantamos los servicios de búsqueda desde el administrador de servicios o con el comando:

net start osearch

6) Configuramos el servicio SharedService para usar SP1 como generador de índice. Para ello, en la pestaña de “Administración de servicios compartidos” de la administración central de Sharepoint pinchamos sobre “SharedServices” (nombre de nuestro servicio, si el vuestro se llama “pepito”, pues debeis pulsar en él) y aparecerá un desplegable con las opciones de configuración, donde en el SSP, podreis configurar el indizador.

A partir de aquí, la carpeta de índice debería haberse regenerado y el servicio de búsqueda debería funcionar de nuevo. Sólo queda asegurar que el nuevo contenido añadido durante el problema se incluya en la búsqueda y esto se consigue realizando un rastreo completo de las áreas de búsqueda.

Eso es todo amiguitos. Si quereis mi dirección para mandarme jamones de agradecimiento por esta valiosa información, dejad un comentario con vuestro email y os la haré llegar encantada.

Saludillos.

Hace unas semanas tuve que que arreglar el desaguisado que había causado un administrador irresponsable. Intentando liberar espacio de disco, tuvo la “genial” idea de mover algunos logs de exchange sin utilizar el procedimiento anteriormente publicado en este blog.

Cuando por fin ampliamos los discos y restauramos los logs (al menos había sido precavido y sólo los había movido) dos de los grupos de almacenamiento de mailbox no levantaban correctamente quedando en estado de error. Al tratar de resincronizar, el error indicaba la falta de un fichero de log cuya numeración no se encontraba entre los existentes.

Lo primero que debemos hacer es ejecutar un comando que nos permitirá conocer el estado real de la replicación de los grupos de almacenamiento. get-storagegroupcopystatus. Estos procedimientos siempre se ejecutan desde la Shell de Exchange.

La salida tendrá el formato:

Name Summary CopyQueue ReplayQueue LastInspectedLogTime
StorageGroup1 Healthy 0 0 6/14/2007 4:42:01 p.m.

Los resultados que nos indican que existen problemas con la base de datos son que en cualquiera de las dos colas aparezca un número distinto a 0 o que en Summary aparezca “error”  Podemos hacer que los datos en ambos nodos coincidan pero para ello tenemos que asegurarnos que la base de datos del nodo principal no está corrupta y que el servicio de correo funciona con normalidad.

Para poder regenerar los datos de forma que se encuentren sincronizados entre ambos nodos el procedimiento que se debe de ejecutar desde el nodo pasivo:

  • Paramos la replicación: Suspend-StorageGroupCopy –id ‘clustermailbox\grupoalmacenamieto’
  • Eliminamos la base de datos del nodo secundario y restauramos desde el nodo 1:Update-storagegroucopy -id ‘clustermailbox\grupoalmacenamieto’ -DeleteExistingFiles
Hay que tener en cuenta que la base de datos almacenada en el nodo pasivo se eliminará durante el procedimiento, por si deseáis realizar antes una copia de seguridad.
Durante la ejecución,
Tras esto, activamos de nuevo la replicación de los grupos de almacenamiento y comprobamos que ya no existe error.

Las bibliotecas de documentos de sharepoint 2007 tienen la posibilidad de adjuntar documentos de forma sencilla, mediante email. El usuario, no tiene más que enviar un correo a la dirección de la biblioteca con el fichero adjunto y una descripción del mismo en el cuerpo del correo. Pero para que esto funcione, necesitamos que nuestro clúster de Sharepoint sea capaz de recibir estos correos a través de la infraestructura de Exchange existente.

Por suerte, sólo tenemos que seguir unos sencillos pasos de configuración.

1. Se debe crear un alias DNS que será el nombre del clúster de sharepoint: sharepoint.contoso.es A IP_servidor

2. Desde el administrador de la infraestructura de Exchange, vamos a servidor> hub transport y creamos un conector de envío. Estos conectores indican una serie de direcciones de correo que el Exchange escucha e indican a que servidor deber de enviarse estos correos. El dominio de recepción de correos será @sharepoint.contoso.es y el Smarthost de este conector de envío será el alias DNS que acabamos de crear “sharepoint.contoso.es”.

3. En cada uno de los nodos de la granja de Sharepoint instalamos el servicio SMTP y lo configuramos como arranque automático.

4. En cada uno de los nodos de la granja de Sharepoint debemos configurar algunos parámetros del servidor virtual SMTP. Para la configuración de este servidor, debemos acceder a la consola de configuración de IIS 6 de cada uno de los nodos del clúster.

a. Desplegamos el árbol hasta el servidor virtual de SMTP > botón derecho > Propiedades. En la pestaña de acceso, creamos un nuevo Rely y se configura como IP de rely las IPs de los HT de Exchange ( una si va a ser un sólo servidor el que se encargue, varias si es un clúster).
b. En la pestaña de entrega > avanzadas cambiamos el FQDN del servidor virtual de SNMP por el alias sharepoint.contoso.es para mantener el espacio de nombres coherente.
c. Dentro del sitio de SNMP > en el objeto de dominio > botón derecho > nuevo dominio y creamos uno nuevo para sharepoint.contoso.es.

5. Reiniciamos el servicio SMTP de los servidores sharepoint para que los cambios tengan efecto.

6. En la administración central de Sharepoint > Configuración de correo saliente se configura con el servidor sharepoint.contoso.es.

Et voilá, con estos pasos, y la configuración de la cuenta de recepción dentro de la propia biblioteca, ya se pueden recibir los correos.

Saludillos.