Exportar listado de permisos de buzones de Enterprise Vault

Aquí dejo una consulta de SQL muy útil que exporta todos los permisos asignados a todos los buzones dentro de Enterprise Vault.

El flujo de la consulta es más o menos este:

  1. Chequea si existe la función para convertir SID de texto a binary. Si existe la elimina.
  2. Crea la función para convertir SID de texto a binary
  3. Saca el listado de permisos
  4. Elimina la función creada en el paso 2

Viene genial para saber hacer auditoría de los buzones o para saber si hay que notificar a alguien antes de eliminar un buzón cualquiera.

La consulta la saqué de este video que por alguna razón el autor no la puso en los comentarios.

Enterprise Vault con almacenamiento en EMC Centera va muy lento

Esta entrada, más que un articulo técnico es una demostración de por qué todos tenemos que ponernos de acuerdo en un departamento de TI. Operaciones, comunicaciones, helpdesk, todos tenemos que ser parte de un uno o de lo contrario pueden pasar cosas como estas.

Trabajar con entornos heredados es muy complicado, por lo general son entornos con tecnolgías muy antiguas, mal diseñadas, sin soporte y, peor aun, sin documentacion.

Nuestro entorno de Enterprise Vault iba muy bien hasta que un día, sin razón aparente, empezó a ir muy lento. Cuando digo lento me refiero a que la restauración de un elemento archivado tardaba entre un minuto y cinco minutos (y a veces daba timeout). Antes de esto la restauración tardaba unos 15 segundos, que no es muy rápido, pero parecía razonable.

Procedimos a la rutina de resolver problemas:

  • Revisar los logs de Enterprise Vault: no hay errores.
  • Revisar los logs de Windows: no hay errores
  • Revisar los logs de Centera: no hay errores. La tasa de I/O está casi en 0, por lo que no puede ser un problema de sobrecarga.
  • Llamar a soporte de Symantec: “Nosotros vemos todo OK, debe ser problema de EMC”.
  • Llamar a soporte de EMC: “Nosotros vemos todo OK, debe ser problema de Symantec”.

Llegados a este punto, solo quedaba irse a un rincón a llorar. ¿A quién llamamos? Por lo visto nadie sabe nada de estos sistemas.

Nos secamos las lagrimas y entramos en modo “por mis cojones que resuelvo esto”. No tiene sentido que todo vaya mal de un día al otro sin motivo alguno.

Afortunadamente, tengo algunos conocimientos de programación y sabía que en alguna parte se podía activar el debug log de la API de Centera.

Revisando el log vi que cuando el Enterprise Vault se conectaba a la Centera esta le entregaba un rango de direcciones IP diferente al que yo creía que tenía configurado en la Centera.

Revisamos la configuración de la Centera, aparece algo llamado NAT Externo con las direcciones en cuestión. Llamamos a EMC nuevamente “¿Pero esto que eeeesss? (En voz Mauricio Colmenero)”. Nos dicen que es algo que se configura cuando hay replicación entre dos Centera. Preguntamos a los dinosaurios del departamento “¿En algún momento se replicaba esto con otro site?” “Ahhh siiii, en el año 2010 esto se replicaba con el site de Mordor”.

Muy bien, ahora sabíamos mas o menos por donde iban los tiros. Sin embargo, si esto ya estaba configurado así ¿Por qué dejó de funcionar de repente?.

Hablamos con comunicaciones.

  • “Oye, ¿te suena este rango?”
  • “Si, lo configuramos la semana pasada para la wifi de los bosses”
  • “Pero… ¿No sabías que ya se estaba usando para otra cosa?”
  • “No, aquí en el inventario no estaba”

Maravilloso, maravilloso. El sistema ha estado fallando desde hace años, lo que pasaba es que el rango que se estaba utilizando para el fulano NAT no era enrutable. Ahora que era enrutable el Enterprise Vault tardaba mas en fallar, solo que lo hacía de forma silenciosa.

Llamamos nuevamente al técnico de EMC “¿Si no tenemos replicacion hace falta que el NAT esté configurado?” “Pues no, no hace falta”. Desactivamos, guardamos y ¡voila! Ahora el Enterprise Vault va como un cohete y los elementos se restauran en un par de segundos (más rapido que antes de la incidencia).

En conclusión, todo mal:

  • Un sistema heredado sin documentación, que falla desde hace años, pero nadie dice nada porque va “razonablemente bien”
  • Una aplicación que no muestra errores cuando los hay
  • Se elimina una replicación entre sistemas y no se borran las configuraciones necesarias
  • Un rango de IP en produccion que no estaba inventariado
  • Una parte del departamento hace un cambio y el resto no se entera
  • Los técnicos de los fabricantes no hace un troubleshooting completo

Así que ya sabéis, hay que comunicarse bien entre los demas miembros del departamento de TI. No podemos ser islas porque esto no da mas que problemas.

Busquedas LDAP en Enterprise Vault no funcionan correctamente

Esta entrada es una traducción parcial de este post.

Al crear un grupo de provisión en el Enterprise Vault se puede definir una busqueda LDAP. Para la mayoría de los casos esto funciona sin problemas, sin embargo, con algunos atributos puede que la busqueda no retorne nada o retorne menos resultados de los que tú esperas.

El motivo de esto es que por defecto el Enterprise Vault consulta el catálogo global para estos atributos, y no todos los atributos de un objeto son replicados en el catálogo global del Active Directory. Uno de estos atributos es el employeeNumber, que era el que estaba usando yo para una de mis consultas.

Para resolver este problema puedes hacer una de dos cosas, puedes hacer que el atributo que estás utilizando para la busqueda se replique en el catálogo global. Esto no lo recomiendo ya que tiene consecuencias como el aumento del tráfico de replicación que tienes que tener en cuenta.

La segunda opcion es hacer que para una consulta en particular el Enterprise Vault consulte un controlador de dominio directamente en vez del catálogo global. Esto último lo podemos hacer cambiando GC:// por LDAP:// en nuestra consulta.

Exportar detalle de Shortcuts de Enterprise Vault desde Exchange

Debido a una incidencia que tuvimos con el Enterprise Vault, tuve que buscar la forma de exportar los shortcuts de un buzón de Exchange a CSV para despues hacer un control de daños de cuáles correos teníamos que recuperar.

No fue una tarea fácil, pero al final lo logré teniendo como base el genial script de Michel de Rooij de este enlace.

Para ejecutar el script solo hay que descargar el Exchange Web Services API y ponerlo en la misma carpeta del script, luego hay que modificar los 5 parámetros del script y ejecutarlo.

El script no es bonito, ni está documentado, ni tiene control de errores (cuando tenga tiempo lo hago), pero funciona (por lo menos en Exchange 2010 SP3).

Descargar script.