Archivos de la categoría ‘Errores’

Los que conocéis las connector appliances de ArcSight sabéis que el acceso a las mismas está tremendamente cerrado ya que, pese a ser un software propietario instalado sobre un proliant G7, son consideradas “cajas negras”.

Para acceder, Arcsight nos ofrece una consola web por HTTPS bastante completa, pese a ser un poco engorrosa en cuanto a visualizacion de logs y troubleshooting. Esta consola es la que se usa para gestión, configuración… de los conectores, incluyendo aquellos instalados fuera de la consola con la gestión remota activada. Si el acceso web deja de funcionar, nos quedamos sin uno de los puntos vitales de nuestra arquitectura de ArcSight.

Si esto ocurre pero los conectores siguen funcionando (siguen enviando eventos a los destinos) el acceso por SSH a root es una opción aunque por desgracia, al estar el sistema cerrado, para realizar este acceso necesitaremos la respuesta a un Challenge que debe ser obtenida a través del soporte de HP. Si queremos ahorrarnos este engorroso proceso, el truco es sencillo:

  1. Accedemos a la consola del appliance bien por método teclado+pantalla, conexión al puerto serie del appliance o mediante ILO (en caso de tenerlo configurado)
  2. Accedemos con nuestro usuario local al appliance. Para aquellos que tengan autenticación remota el método es igualmente válido.
  3. ejecutamos status process
  4. ejecutamos restart process web.
  5. En caso de que siga inaccesible, reiniciar apache con el mismo procedimiento.

Espero que os sirva.

Saludillos.

Anuncios

Cuando establecemos filtros en los destinos de los distintos conectores desde las herramientas de edición de la interfaz web de la connector appliance (versión 6.4), estos almacenan de forma errónea los caracteres especiales y por tanto, nunca son matcheados.

Por ejemplo si escribimos el filtro como se muestra en la imagen
Entrada antes de guardar

Al hacer click en aceptar y volver a editar las opciones del destino este aparece como:

FiltersError2

Es decir, las comillas son sustituidas por " que es la forma de escribir los cararcteres especiales en XML.

Para corregir este filtro y que se aplique correctamente debemos editar el fichero xml dentro del container que define el filtro para eliminar los carácteres especiales adicionales.

NOTA: No podemos realizar la modificación mediante el Diagnostic Wizard del container correspondiente ya que presenta el mismo problema

Para editar el XML:

  1. Realizamos un backup del container desde el repositorio de backups.
  2. Descargamos el backup en formato zip.
  3. Extraemos todos los ficheros del backup para que podamos trabajar cómodamente.
  4. Entre los ficheros .xml existentes con nombres del tipo 3+BET8T4BABCADtPYAQdd6g==.xml buscar el que contiene el filtro erróneo. Aparecerá la línea con formatodeviceEventClassId EQ "agent:050"
  5. Corregimos el filto eliminando los amp; sobrantes. El fitro quedaría: deviceEventClassId EQ "agent:050"
  6. Comprobamos que el filtro es correcto visualizando el xml en un navegador. El filtro debe aparecer correctamente
  7. Comprimimos en zip los ficheros de backup extraídos previamente, incluyendo los .xml modificados.
  8. Subimos el nuevo zip al repositorio de backup.
  9. Aplicamos los cambios al container correspondiente.

Hasta la proxima

Hoy, de hecho ahora mismo, he tenido que realizar la actualización de un cluster de cortafuegos UTM-1 que se encuentra configurado en full ha (o full hihg avaiability) desde su versión R70 a R75. De hecho la versión final es la R75.20 pero no es posible realizarla directamente y hay que dar el paso intermedio a la R75.

Como está siendo un infierno, os describo a continuación los pasos que deben darse, los problemas encontrados y su resolución.

Tenemos un clúster full ha con dos nodos. Fw1 es el nodo activo tanto de firewall como de management y es el que tiene una mayor prioridad y Fw2 es el nodo pasivo de ambos elementos que asumirá los roles sólo en caso de fallo del nodo principal.

Backup de los elementos:

Lo primero que debemos hacer es un backup completo de ambos nodos, así como de la base de datos de políticas en un equipo externo a los mismos. Así, nos curamos en salud y nos ahorramos disgustos.

1)      Backup de la configuración del equipo a través de la administración web de secureplatform. Esto nos guarda los datos básicos de red del equipo. Aseguraos de tener cerradas todas las GUIs de Smartdashboard o fallará.

2)      Exportado de la política en versión R70 – > #$FWDIR/bin/upgrade_tools/upgrade_export <nombredelfichero>

3)      Exportado de la política en versión R75

  • Para ello, descargamos las migration tools correspondientes a R75 del usercenter y las subimos al appliance principal (bien por SCP bien por FTP) a una carpeta temporal. “/var/tmp” es un buen punto.
  • Damos permiso de ejecución a las migration tools: #chmod a+x *
  • Generamos el fichero de políticas: #migrate export <nombrefichero>

Aseguraos de descargar las políticas generadas bien por FTP, bien por SCP.

4)      Ejecutad el verificador de actualización para comprobar que no existen errores a corregir. Este se encuentra en las migration tools. Si da un error, corregidlo antes de empezar.

Bien, hasta ahora, nada fuera de lo normal de cualquier actualización.

Actualización:

Los pasos son:

1)      Realizar un failover del tráfico al nodo secundario:

#cphaprob -d STOP -s problem -t 0 register

Para dar marcha atrás (por si fuera necesario)

# cphaprob -d STOP unregister

Nota: este paso supone un microcorte

2)      Entrar con Smartdashboard en el management secundario. Al entrar nos dirá que el nodo activo es fw1 y que si queremos cambiarlo. Hacemos que el management secundario sea el activo.

3)      Actualizamos el nodo principal, cargando el correspondiente paquete a través de la interfaz de administración web del nodo fw1. Ojo, en este paso, es recomendable realizar un snapshot y una actualización segura. Es más lento pero nos salvaguardará de errores en la actualización, asegurando la marcha atrás.

4)      Accedemos con la consola de dashboard de R75 al nodo fw1. Colocamos el objeto de clúster a versión R75 e instalamos políticas. Recordad desmarcar la opción de “For firewall cluster install on all members” o fallará.

5)      Actualizamos vía web el nodo fw2 con la imagen correspondiente. Al ejecutar un cpstop para actualizar, el tráfico pasará al nodo fw1 con un microcorte.

6)      Una vez sincronizado, abrimos smartdashboard en fw1. Instalamos políticas en ambos nodos.

7)      Abrimos Policy > Management high Availability y pulsamos el botón sincronizar.

Parece fácil y sencillo ¿verdad? Pues nada más lejos de la realidad.

Problemas, problemas, problemas.

Justo después de sincronizar, si refrescamos el estado de ambos cortafuegos, aparece el nodo fw2 como unreachable. Si tratas de comprobar la SIC de este nodo, se indica lo siguiente:

“SIC Status for : Not Communicating Authentication error [error no. 147] ** Check that peer SIC is configured properly and that system date and time on the SmartCenter Server and peer are synchronized.

Tratamos de resetar la SIC de este nodo pero no hay cambios, no se puede conectar.

Si cerramos el smartdashboard, no podremos conectar de nuevo con fw1 apareciendo un error:

“Connection cannot be initiated make sure the server “xx.xx.xx.xx” is up and running and you are defined as a GUI Client”

Si realizamos: # ps aux | grep cpca  el resultado aparecerá como cpca – readonly

Lo que ocurre es que durante la actualización se ha perdido un certificado de CA en el nodo principal fw1 y es por esto por el que no podemos conectar al smartdashboard o al otro nodo.

Para corregirlo ejecutamos en el nodo fw1:

#cd $CPDIR/conf

# cp sic_cert.p12 sic_cert.p12old

#cpca_client revoke_cert -n “CN=cp_mgmt”

#cpca_client create_cert -n “CN=cp_mgmt” -f $CPDIR/conf/sic_cert.p12

#cpstop

#cstart

Esto regenera los certificados y nos permitevolver a conectar al smartdashboard. OJO: ESTO PROVOCA CORTE TOTAL ya que paramos los servicios del nodo que gestiona el tráfico y el cluster no está montado.

Pero, ¿Qué pasa con el nodo secundario? Pues que aún no lo hemos conectado. Para ello:

Ejecutamos en ambos nodos #fw unloadlocal esto vuelve a PROVOCAR CORTE TOTAL  pero es necesario dado que las políticas no nos permiten conectar ambos nodos del cluster puesto que en este momento fw2 no forma parte del cluster. Reestablecemos la SIC e instalamos políticas. En este punto el firewall está operativo.

Sólo nos queda sincronizar ambos management, pero el del nodo 2 no se deja. Pese a que la SIC está establecida y funcionando, la sincronización de managements nos dice que el fw2 está unreachable. Para corregir esto:

#cpstop

#cd $FWDIR/conf/mgha

# rm ./*

#cd ..

#rm applications.C* CPMIL*

#cpstart

Ahora podemos realizar la sincronización y todo vuelve a la normalidad. Ya sólo queda la actualización a R75.20. Que cthulhu nos coja confesados.

Saludillos

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.

No os lo he dicho antes pero, soy la orgullosa propietaria de un HTC desire S que me encanta cada día más.

En el momento de salir el “Ice Cream Sandwich” me puse a investigar si existía versión oficial disponible para mi bichejo. No quería una versión no oficial de HTC por que siempre te arriesgas a bugs extraños y falta de soporte técnico y las oficiales son mas seguras. Ilusa de mí.

Después de que HTC me dijera que no iban a sacar lce Cream Sandwich para mi modelo de teléfono decidí poner la última versión disponible de Gingerbread oficial de HTC, la versión 2.3.5. De paso, también actualicé el HTC Sense a la versión 3.0. ( ya puestos pues hacíamos un combo). Después de un rato de reinicios y y  “No apague el dispositivo mientras se realiza la actualización” se completó el proceso y me dispuse a trastear la interfaz molona.

Todo fue muy bien, de hecho a mejor, durante un par de semanas. Las aplicaciones que antes fallaban más “que una escopeta de caña” (somo se dice por andalucía) iban bien, las transiciones eran mas fluidas y molonas, el desbloqueo traía la mejora de acceso directo a algunas aplicaciones, mas gadgets…. El problema apareció el viernes.

Este viernes tuve que coger un avión y no pude apagar el teléfono. Sí, por increíble que parezca, al presionar el botón de encendido con pulsación larga el HTC sólo se bloquea. Por mucho que dejemos el dedo puesto hasta que nos duela, no aparece el menú de apagado, modo avión o reinicio. Tampoco existe ningún menú que permita el apagado del teléfono (o estoy ciega y no lo vi).  No me quedó otro remedio que quitarle la batería.

Hoy he contactado con el soporte técnico de HTC, donde amablemente me han indicado que la solución a mi problemilla es resetear el términal y por tanto perder todos los datos almacenados. ¿Really? Pues no. Googleando un poco (bendito sea, habría que hacerle dios de alguna religión o algo) he encontrado que hay una solución más sencilla para el error. La solución es un gradísimo WTF??!!?!?

Para poder acceder de nuevo al menú de reinicio a través del botón de encendido tenéis que eliminar la contraseña del almacén de credenciales (venga todos a la vez: WTF??!!!??!!) Sí amiguitos, por inconexas que parezcan estas dos cosas, si eliminas la contraseña, el menú prófugo sale de su escondite pero si volvemos a establecer dicha contraseña, el menú vuelve a desaparecer (debe tenerle miedo al almacén de credenciales).

Esperemos que saquen pronto una actualización que corrija este fallo, aunque si hay que confiar en el servicio técnico de HTC, me temo que eso nunca ocurrirá. Al menos, ya sabéis el truco para no tener que sacar la batería cada vez que queráis volar.

<eot>

Hace unos días, al revisar el estado de los managements por un problema de instalación de políticas, me dí cuenta que el estado del management secundario de CheckPoint para la alta disponibilidad de las políticas era “Lagging” en lugar de “Synchronized”.

Vale. Stop. Para los que no tengan ni papa de lo que va esto una breve introducción:

Los managements (o gestores de políticas) de Checkpoint puede configurarse en alta disponibilidad. Esto es, que se dispone de un management principal que gestiona las políticas y uno secundario en standby que dispone de una copia actualizada de las políticas, listo para entrar en acción en caso de desastre. Se puede comprobar el estado de la sincronización desde el dashboard Policy > Management High Availability.

Aquí se abre una ventana que nos muestra al management principal como activo y una ventana con el estado del secundario. En esta ventana se nos indica si hay conectividad con este management (Reachable), si está en standby y el estado de la sincronización.

Los posibles estados son:

Never been synchronized – Justo después de instalar cuando aún no se ha sometido a la primera sincronización manual.

Synchronized – está bien sincronizado y tiene la misma información de bases de datos y política de seguridad instalada.

Advanced – la base de datos del management en standby tiene datos más actuales que la del management activo. Esto indica que una de las bases de datos debe ser sobreescrita.

Lagging – El secundario está preparado para sincronizar pero no se ha realizado la misma.

Collision – Hay distintos datos de políticas y de bases de datos en ambos servidores, se deben sincronizar manualmente con la información correcta.

Para realizar la sincronización manual, sólo tenemos que pulsar el botoncito de la parte interior que pone “synchronize”.

Bueno, ¿aclarado? Aclarado.

Como iba diciendo, el estado de mi servidor era “Lagging” lo cual, no es un estado muy bueno ya que, aunque no indica errores graves, significa que el secundario no tiene toda la información necesaria para funcionar. Lo primero que hice fué comprobar la conectividad (ping desde el management principal as secundario) y la sic (objeto del management secundario > Test SIC status) y todo estaba OK.

Lo siguiente fué comprobar la hora y la fecha de ambos servidores, ya que una diferencia entre ellos, es la causa más común de los errores de sincronización. Todo correcto por esta parte, así que procedo a darle al botoncito de sincronizar, pensando que se va a solucionar fácilmente.

Nada más lejos de la realidad. Tras un buen rato pensando, aparece un precioso cartel de error que dice ” Failed to Synchronize: Failed to update internal CA-DB” del management secundario.

Tras un poco de investigación de fondo y de buceo en la KB de Checkpoint, se obtienen dos procedimientos:

Procedimiento 1

En ambos managements al mismo tiempo ejecutar:

# cpstop
# cd $FWDIR/conf
# rm CPMIL*
# rm applications*
# cd mgha/
# rm *
# cpstart

Tras esto, se entra en el dashboard de management principal (a veces falla después de la actuación, así que sigue las recomendaciones del autoestopista galáctico y Don’t Panic! ) y sincroniza manualmente.

A mi este procedimiento me ha funcionado a las mil maravillas. Pero por si no va, aquí va otro:

Procedimiento 2

1. Para el management principal y borra los journals: # rm $FWDIR/conf/mgha/*

2. En el management secundario, haz un backup y borra:
InternalCa.p12
InternalCa.NDB*
InternalCa.crl
ICA.crl

3. Inicia los servidores y sincroniza manualmente.

Y eso es todo. ¡Espero que os sirva de ayuda!

¡Fantasmas! Who you gonna call? Ghostbusters!

Bueno, no hay que ser tan drásticos. En este caso nos encontramos con que tras eliminar un objeto de clúster en el SmartDashboard, uno de los nodos ha quedado como “fantasma”. Si tratamos de crear un nuevo objeto con esa IP, DahsBoard nos indica que está en uso, si hacemos una búsqueda nos aparece y está en la lista de nodos de SmartMonitor y SmartUpdate. Al tratar de borrarlo desde la ventana de búsqueda o desde Monitor o Update, nos sale un cartelito indicando que el objeto está en uso (cosa desmentida por el botón “where used”) y no nos permite borrarlo. ¡Vaya! Tenemos un poltergeist persistente.

Estás almas errantes que habitan en la base de datos de gestión, se quedan atrapadas sin poder pasar al otro lado, debido a que se ha realizado un borrado del objeto de cúster al que pertenecían sin realizar un detach de las licencias asociadas primero. Para exorcizar estos casos y ayudarlos a encontrar la paz, tenémos tres métodos:

Método 1:

1. Realizar un “Install Database”
2. Reiniciar smartview monitor y smartupdate.

Este método acaba con los más débiles, pero funciona en pocos casos. La ventaja es que es sencillo e inouo.

Método 2:

1. Dashboard -> Manage -> Network objects.
2. Si está visible, tratar de borrarlo desde ahí.

Lo más probable es que, al igual que desde la pantalla de búsqueda no nos permita borrarlo.

Método 3:

Este funciona siempre pero es el más delicado. No olvideis realizar estas técnicas bajo la supervisión de un exorcista profesional, niños y NUNCA lo realiceis sin tener un backup de la configuracion del management. (Upgrade_export del que prometo hablar pronto.)

1. Realizar un backup de $FWDIR/conf/ del management principal.
2. Ejecutar guidbedit.exe que está en: C:\Program Files (x86)\CheckPoint\SmartConsole\R70.30\PROGRAM (En mi windows 7 pero la ruta es básicamente la misma)
3. Buscar el objeto en Network objects y borrarlo. El cambio se aplica automáticamente.

Con esto os habreis librado de los fantasmas y sin gastar dinero en profesionales con mochilas de protones.

¡Hasta la próxima!

Administro un clúster de servidores activo-activo que da soporte a todas las páginas web corporativas de uno de nuestro clientes. Estos servidores cuentan con un IIS 7 sobre el que corren distintas aplicaciones web, incluyendo una cosa “preciosa” llamada Sharepoint 2007. No niego la utilidad de sharepoint de cara a la gestión de información corporativa y visualización vía web pero la administración del sistema es, en ocasiones, una autentica pesadilla.

El caso es que hace unos días, sin conocer aún las causas, los ficheros de configuración del IIS de uno de los nodos, se corrompieron durante una de las sincronizaciones del clúster. Resultado: las aplicaciones iban sólo a veces (cuando el acceso se hacía contra el nodo correcto del clúster). Para solucionarlo, se regeneraron los ficheros a partir de un backup pero las bases de datos de sharepoint quedaron en un estado extraño. Desde la recuperación empezaron a aparecer en el registro de aplicación los errores:

Nombre de registro:Application
Origen: Office SharePoint Server
Fecha: 12/05/2011 16:00:00
Id. del evento:5555
Categoría de la tarea:Perfiles de usuario
Nivel: Error
Palabras clave:Clásico
Usuario: No disponible
Equipo: sharepoint1
Descripción:
Error al intentar sincronizar la aplicación Web IDAPLICACION, base de datos de contenido IDBDD Mensaje de excepción: Se encontró un Id. de sitio duplicado: IDDELSITIO (http://URLEMPRESA). Esto puede deberse a la restauración de una base de datos de un conjunto de servidores a otro sin quitar primero la base de datos original para, a continuación, ejecutar stsadm -o preparetomove. Si es esa la causa, se puede usar el comando stsadm -o preparetomove con la opción de línea de comandos -OldContentDB para resolver el problema..
XML de evento:

Nombre de registro:Application
Origen: Office SharePoint Server
Fecha: 12/05/2011 16:00:00
Id. del evento:7888
Categoría de la tarea:General de Office Server
Nivel: Error
Palabras clave:Clásico
Usuario: No disponible
Equipo: sharepoint1
Descripción:
Se ha detectado una excepción en tiempo de ejecución. Detalles.
Mensaje: Se encontró un Id. de sitio duplicado: IDDELSITIO (http://URLEMPRESA). Esto puede deberse a la restauración de una base de datos de un conjunto de servidores a otro sin quitar primero la base de datos original para, a continuación, ejecutar stsadm -o preparetomove. Si es esa la causa, se puede usar el comando stsadm -o preparetomove con la opción de línea de comandos -OldContentDB para resolver el problema.
Detalles técnicos:
Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: Se encontró un Id. de sitio duplicado: IDDELSITIO (http://URLEMPRESA). Esto puede deberse a la restauración de una base de datos de un conjunto de servidores a otro sin quitar primero la base de datos original para, a continuación, ejecutar stsadm -o preparetomove. Si es esa la causa, se puede usar el comando stsadm -o preparetomove con la opción de línea de comandos -OldContentDB para resolver el problema.
en Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy)
en Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds()
en Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken)
en Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB()
en Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

Estos errores aparecen cada hora en el registro. La solución consta de tres sencillos pasos que pueden hacerte perder tres días si no estás muy avezado en administracion de sharepoint. Los pasos a ejecutar en la consola (ejecutar > cmd)
1) Detectar la base de datos no sincronizada.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o sync -listolddatabases 5
2) Corregir la duplicación de Id de base de datos:

stsadm -o preparetomove -site http://URLEMPRESA -oldcontentdb IDBDD
Esta información se saca del registro de eventos.

3) Eliminar las notificaciones de sharepoint

stsadm -o sync -deleteolddatabases 0

Ojo, si no realizamos este último paso, el problema estará arreglado (la sincronización se comenzará a realizar correctamente) pero las notificaciones de error seguirán apareciendo cada hora en el registro de eventos.

Espero que os sea útil y no perdais en esto tanto tiempo y tanta salud mental como yo.

¡¡Saludillos!!

Este caso es muy específico y hace referencia a un producto de Checkpoint que está a punto de desaparecer definitivamente. De hecho, actualmente ya no se encuentra soportado por el fabricante, pero me he decidido a escribir este post dado que siempre hay lugares en los que aun mantienen esta versión de firewall.

Para la comunicación VoIP, eran necesarias una serie de reglas en el cortafuegos que permitían el acceso a través del protocolo SIP al servidor destino. Para realizar las pruebas, se habilitó una regla entre origen y destino sin especificar el puerto (any) de la comunicación y asegurar que todo estaba instalado correctamente. Estos paquetes atravesaban sin problemas y la comunicación se establecía correctamente.

Una vez comprobado el correcto funcionamiento de la comunicación se restringió la regla especificacando el puerto SIP predefinido en Checkpoint y se volvió a probar. En este caso la comunicación era rechazada por el cortafuegos. Los mensajes que aparecían en el tracker, indicaban que la macheaba la regla 0 (Implied Rules). Esta regla indica que la comunicación se ha rechazado debido a una de las comprobaciones configuradas en smartdefense. El texto del mensaje era:

” Atack Info: Malformed SIP datagram, Unknown SIP message type dropped by rulebase”

Una primera búsqueda de este error nos indica que el rechazo se produce porque se encuentra activado en Smartdefense el checkeo de cabeceras SIP para VoIP, y checkpoint no reconoce las cabeceras SIP especificas del fabricante de VoIP. Estas cabeceras no son estandard, y la de este fabricante no se encuentra registrada para la versión R55 de Checkpoint por lo que no permite la conexión al considerarla un posible riesgo.

En smartdefense se encuentra la pestaña VoIP, en la que podemos habilitar o deshabilitar el checkeo de cabeceras SIP y probamos a deshabilitar el chequeo e instalar políticas pero el error vuelve a repetirse. Tras un poco de investigación exahustiva hayo la causa del problema. En R55, existen una serie de protocolos predefindos que se pueden configurar en las opciones avanzadas de los servicios. Entre estos protocolos, se encuentra el SIP_UDP que es el que usa el servicio predefinido sip. Al identificar un servicio como usuario de ese protocolo y usar dicho servicio en una regla ( no está incluído en el any) se activa por defecto el chequeo de cabeceras SIP, incluso si este chequeo se encuentra desactivado en smartdefense. Este chequeo además se activa para todas las conexiones SIP aunque correspondan a otra regla.

La solución es la siguiente: se debe crear un nuevo servicio para SIP de tipo UDP para el puerto 5060, cuyo tipo de protocolo sea none. Este servicio es el que se debe usar para todas las reglas que necesiten habilitar acceso a SIP, ya que si en alguna usamos el servicio con el protocolo específico activaremos el chequeo.

Hasta la proxima!