Solicitamos un certificado de servidor de la Fábrica Nacional de Moneda y Timbre (FNMT) ya que queremos demostrar que somos oficiales y no nos autofirmamos los certificados. Nos vamos a la web de la FNMT y tras pasar un precioso infierno de procedimientos engorrosos de solicitud, pago y procedimientos engorrosos de descarga, obtenemos nuestro par de claves en formato pfx. En este follón de procedimientos no voy a entrar y os lo dejo como terreno para explorar a los administradores valientes en busca de aventuras.

Una vez se dispone del certificado en formato pfx conteniendo la clave privada y la clave pública (supongamos un fichero llamado glados.pfx), se genera el almacén de claves, que debe contener tanto el par de claves almacenado en el pfx como el certificado de la CA o autoridad certificadora correspondiente (en este caso el certificado Raiz de la FMNT) que complete la ruta de certificación. El almacén de claves se llamará .keystore que es el nombre del almacén por defecto en Tomcat y al que no parece hacer mucha gracia que le cambies el nombre.

Se descarga de la web de la FMNT el certificado raíz y se añade al almacén con el comando de Keytool:

keytool -import -alias root -keystore “\.keystore” -trustcacerts -file “FMNTCA.cer”

Esto es importante, ya que los gestores gráficos de claves NO realizan esta funcion y nos toca hacerlo a manita o el quisquilloso Tomcat se negará a mostrarnos la página protegida con este certificado.

Tras esto, se importa el par de claves almacenado en el pfx a nuestro almacén de claves. Podemos hacerlo mediante GUI o mediante comando:

keytool -import -alias tomcat -keystore “\.keystore” -file “glados.pfx”

Sustituimos el .keystore original por el .keystore recién creado en la carpeta de configuracion y reiniciamos los servicios de Tomcat. Y voilá el certificado mostrado a partir de ese momento es el nuevo certificado instalado.

Espero que os ayude.

Saludillos

Entras en un Controlador de Dominio que no replica del todo bien la unidad de sysvol y te pasas por el registro de eventos a ver que se cuece. Casi te da un infarto cuando te encuentras chorrocientos mensajes de error como el siguiente:

Nombre de registro:Application
Origen: Group Policy Registry
Fecha: 27/06/2012 7:01:18
Id. del evento:8194
Categoría de la tarea:(2)
Nivel: Error
Palabras clave:Clásico
Usuario: SYSTEM
Equipo: SERVERDC
Descripción:
La extensión del lado cliente no pudo registrar quitar equipo configuraciones de directiva para ‘Default Domain Policy {IDGROUPPOLICY}’ debido a un error con el código ‘0x8007000d Datos no válidos.’ Consulte el archivo de seguimiento para obtener más información.

Parece una cosa muy complicada de arreglar pero ¡Nada más lejos de lo contrario! Simplemente, el XML de la group policy  {IDGROUPPOLICY} se ha corrompido en algún momento y no es capaz de regenerarlo.

Para solucionarlo:

  • Accedemos a C:\ProgramData\Microsoft\Group Policy\History
  • Entramos en la carpeta de {IDGROUPPOLICY} indicada en el evento.
  • Buscamos el XML corrupto (tendrá un tamaño de o Kb o 1 Kb)
  • Lo renombramos.
  • Realizamos un gpupdate /force para que se regenere

Y voilá! todo  vuelve a estar como nuevo.

Decidimos cambiar las bases de datos de nuestro servidor de Exchange a un nuevo disco con mejores características de velocidad de acceso y estabilidad. Cuando el Servidor de Exchange no está en alta disponibilidad el procedimiento es muy sencillo y puede realizarse desde la consola de administración de Exchange. Sólo es necesario tener en cuenta que el grupo de replicación debe estar parado y la base de datos desmontada antes de comenzar el procedimiento.

Para un entorno CCR, la cosa cambia. Para comenzar, el procedimiento debe hacerse desde la shell de Exchange ya que uno de los comandos requiere un parámetro no configurable a través de la consola. Y para continuar, el movimiento de los ficheros se realiza a mano. Los pasos son:

Paramos el grupo de replicación con Suspend-StorageGroupCopy -Identity ‘mailbox\Grupo Buzones’ donde “mailbox” es el nombre de nuestro cluster de servidores Mailbox y “Grupo Buzones” es el grupo de replicación que deseamos mover. En este punto no hay pérdida de servicio.

Peliconsejo: Comprueba que los nombres coinciden con los configurados en el servidor hasta el último espacio o no funcionará.

Ahora desmontamos la base de datos. Esto provoca corte de servicio: Dismount-database -Identity ‘mailbox\Grupo Buzones\database donde “database” es el nombre de la base de datos a mover.

Copiamos (Importante COPIAR no mover, por si hay que dar marcha atrás) los ficheros del grupo de buzones a su nueva ubicación que es la que configuraremos a continuación. Este paso tardará más a más grande sea la base de datos.

Cambiamos las rutas al nuevo disco tanto de la base de datos como del grupo de replicación:

Move-StorageGroupPath -Identity ‘mailbox\Grupo Buzones‘ -LogFolderPath ‘I:\Program Files\Microsoft\Exchange Server\Mailbox\Grupo Buzones’ -SystemFolderPath ‘I:\Program Files\Microsoft\Exchange\Mailbox\Grupo Buzones’ -ConfigurationOnly

Move-DatabasePath -Identity ‘mailbox\Grupo Buzones\database -EdbFilePath ‘I:\Program Files\Microsoft\Exchange\Mailbox\Grupo Buzones\database.edb’ -ConfigurationOnly

Donde los parámetros  path determinan la nueva ruta física. El parámetro -ConfigurationOnly es necesario y no puede ser ejecutado por consola.

Ya podemos reestablecer el servicio montando la base de datos: mount-database -Identity ‘mailbox\Grupo Buzones\database

Peliconsejo: Si os aparece un mensaje de que la base de datos no existe y os pregunta si deseáis crear una en blanco, es que habéis metido la gamba. Cancelad, revisad que el nuevo path escrito en el comando sea correcto y ejecutad de nuevo los comandos de cambio de ubicación pero ahora con los datos correctos.

 Por ultimo reiniciamos la copia  Restart-StorageGroupCopy -Identity ‘mailbox\Grupo Buzones’

Pese a que tengo pendiente un extenso artículo con todo lo que he aprendido de clústeres Load Balancing en modo multicast de Checkpoint, os dejo un pequeño apunte para ir abriendo boca.

Si tenéis un clúster Load balancing (es decir, activo/activo)en modo multicast en checkpoint es posible que tengais que configurar las rutas ARP de forma estática en los switches para la MAC de multicast de las interfaces del clúster (sobre todo si los switches son Cisco). Para saber cuales son estas MAC, podéis utilizar la siguiente fórmula:

En una red con un clúster cuya IP de clúster es x.y.z.w:

  • Si y<=127, La MAC de multicast será:  01:00:5e:y:z:w. Por ejemplo si la IP es 192.90.10.100 la MAC será 01:00:5e:5A:0A:64
  • Si y>127, La MAC de multicast será 01:00:5e:(y-128):z:w.  Por ejemplo si la IP es 192.168.10.100 La MAC será: 01:00:5e:28:0A:64(168-128=40 = 28 en hexadecimal) .
  • Para una red  x.y.z.0 sin IP de clúster,como la de sincronización, se usa el mismo procedimiento sustituyendo el último octeto por fa. Por ejemplo para la red 10.0.0.X la MAC será:  01:00:5e:00:00:fa

Espero que os sirva.

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.

Imaginad esto: nos quedamos sin espacio en el disco de Exchange que almacena los logs de las bases de datos. El correo deja de funcionar. Queremos hacer espacio, pero ¿cómo?

Lo primero y más importante, Los logs de Exchange no deben eliminarse o moverse a la ligera de su ubicación original. Estos logs, almacenan transacciones de la base de datos y son fundamentales para que la información de la misma sea coherente. La información de alguno de estos logs se ha escrito en la base de datos correctamente y ya no son necesarios pero hay una cantidad indeterminada de logs, cuya información aún no haya sido almacenada correctamente en la base de datos y cuya eliminación puede provocar inconsistencias en la información que requieran una restauración de la misma desde backup.

Lo recomendable para vaciar el disco de logs, es la realización de un backup (incremental o Full) exitoso sobre la base de datos de buzones, lo que provoca la eliminación de los logs de forma automática y correcta. En caso de que esto no sea posible y como procedimiento de emergencia, se puede realizar el borrado de los logs no necesarios mediante el siguiente método:

  •  Se localizan los logs necesarios para la base de datos en cuestión. Esto debe hacerse leyendo el contenido del fichero de Checkpoint de la base de datos. Este fichero se encuentra en la ruta principal del grupo de almacenamiento y su nombre responde al patrón EXX.chk. Una vez localizado este fichero, se lee su contenido mediante el comando:

C:\Program Files\exchsrvr\bin\eseutil.exe” /MK “<ruta del fichero EXX.chk>

Este comando nos da una salida de la que debemos revisar el parámetro Checkpoint: Checkpoint (0x21EE,11B0,9A). De estos tres valores de Chekpoint, el importante es el primero que es el número de secuencia del último fichero de logs del que se ha realizado el commit. Por lo que, tomando el ejemplo anterior, el último log necesario es EXX21EE.log y los posteriores pueden eliminarse de forma segura

  • Una vez localizado el log, se pasa a parar el grupo de almacenamiento y desmontar la base de datos en cuestión. Esto provoca cortes de servicio ya que dicho grupo de almacenamiento afectado deja de funcionar durante el procedimiento.
  •  Se mueven los logs no necesarios a otra unidad con espacio. No se borrarán hasta estar seguros de que todo funciona correctamente.
  •  Se vuelven a poner en línea, primero la base de datos y después el grupo de almacenamiento. Si tras un tiempo de pruebas todo es correcto, se puede proceder al borrado de los ficheros movidos.

Como referencia os incluyo el link del blog oficial de desarrolladores de Exchange:

http://blogs.technet.com/b/exchange/archive/2004/05/12/130556.aspx

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!

Hoy he encontrado esta guía publicada por el gobierno de los estados unidos, en el que se explican de forma detallada los principales riesgos de los medios sociales y la mejor forma de reducirlos al mínimo.

Muy completa, interesante y disponible para su descarga gratuita.

Os dejo el link: http://www.businessofgovernment.org/report/best-practices-guide-mitigating-risk-use-social-media

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.