Las colas de Exchange 2010

Supervisar las colas de un Exchange 2010 es una tarea clave para detectar cuellos de botella producidos por mensajes acumulados en algún servidor de Transporte. Exchange 2010 ofrece dos formas de ver el contenido de las colas:

• Mediante la consola de administración de Exchange 2010.
• Mediante los cmd-lets de Exchange 2010 de PowerShell.

Para simplificar el acceso a las colas también puedes utilizar colas_exchange_2010.exe. Esta utilidad puede correr en cualquier equipo conectado al mismo dominio que el servidor Exchange 2010 y como requisitos necesita .NET 3.5 o superior y PowerShell 2.0:

Esta utilidad conecta con cualquier servidor Exchange 2010 y después tienes que elegir el servidor de Transporte que quieres consultar. Cambiando "Intervalo" modificas la frecuencia de la consulta. Los campos que muestra son los mismos que ofrece por defecto el visor de colas de la consola de administración de Exchange 2010. Recuerda que esta utilidad tiene que ser ejecutada con un usuario que pueda realizar estas consultas.

Perl: mitos y ventajas

Hace poco di con un interesante artículo escrito por Simons Cozens que trata sobre los diez mitos de Perl. Ese artículo data del año 2000 y tristemente todavía veo que esos mitos persisten.

Al margen de los mitos, yo veo a Perl como un C de buen rollo y a lo bestia: con pocas líneas y algunas expresiones regulares estás leyendo sólo lo que necesitas y a la vez de una base de datos, de un router, de una impresora, de un fichero de texto plano y de una web, lo pones todo en un informe y lo guardas donde quieras y en el formato que quieras (por ej. en HTML).

Luego el sistema operativo te da igual: el único sistema operativo que no soporta Perl yo creo que es el de las lavadoras (y no se yo). Allí donde haya una línea de comandos hay Perl, casi seguro. En concreto, para Windows recomiendo la distribución Strawberry Perl (también recomendada por Larry Wall que es el creador de Perl).

Y bueno, en el terreno de sistemas hay dos cosas: Perl para llegar a todo sistema que funcione (routers, switches, servidores, clientes, linux, microsoft, mac, solaris, etc) y donde no llega Perl llega PowerShell.

Qué decir de Perl y el mundo Web, si fue Perl junto con Apache y CGI el que construyó la web antes de que PHP llegara. Aún así, Perl persiste en webs serias y tiene muchas de las comunidades más serias que he visto en la red, como PerlMonks, entre otras.

He visto dos cosas que realmente me han impactado de Perl: una es la facilidad de aprenderlo (yo aprendí casi todo con este estupendo manual en castellano de Jose Miguel Prellezo) y la otra es la cantidad de módulos disponibles para hacer cualquier cosa o para llegar a cualquier cosa: CPAN.

Otra cosa que me gusta de Perl es que va al grano: es corto, rápido y conciso. Este ejemplo lo ví en el artículo de los diez mitos y es impresionante:

s/(.*):(.*)/$2:$1/

La línea de código anterior puede hacer lo siguiente: toma una línea de texto que contenga cualquier cosa, luego el símbolo de dos puntos y después cualquier otra cosa. Lo que hace es intercambiar las dos cosas que están a los lados de los dos puntos (puedes leer el artículo ya traducido para ver la explicación).

Sin dudarlo, de todos los lenguajes que he utilizado: Basic, Logo, Pascal, Ensamblador, Cobol, Batch, Bash, Python, Ruby, C, C++, C#, Visual Basic, Java, PowerShell y Perl, me quedo con este último.

KB2490606, nueva vulnerabilidad

El pasado día 4 de enero, Microsoft anunció una vulnerabilidad importante en el archivo de Windows shimgvw.dll, que permitiría ejecución remota de código malicioso en Windows XP SP3, Windows Server 2003 SP2, Windows Vista y las primeras versiones de Windows Server 2008, entre otras de 64-bit.

Este archivo es el Visor de imágenes y fax de Windows, aplicación que Windows utiliza por defecto para abrir imágenes y también para mostrar las Vistas en miniatura de una carpeta que pueda contener alguna imagen.

Si el Visor de imágenes y fax de Windows abre o muestra la vista en miniatura de una imagen especialmente creada para aprovecharse de esta vulnerabilidad, ésta se produciría permitiendo la ejecución remota de código malicioso.

De momento no hay parche para shimgvw.dll, pero Microsoft aconseja quitarle privilegios para minimizar el riesgo, hasta que publiquen el parche. Para ello Microsoft recomienda utilizar la siguiente línea de comando (versiones de 32-bit de Windows XP y Server 2003):

cacls %WINDIR%\SYSTEM32\shimgvw.dll /E /P Todos:N

Y para deshacer lo anterior:

cacls %WINDIR%\SYSTEM32\shimgvw.dll /E /R Todos

Más líneas de comandos para otras versiones de Windows en la publicación de esta vulnerabilidad.

De momento no ha habido mucha repercusión con esta vulnerabilidad, pero es igual de peligrosa que la de agosto del año pasado relacionada con la visualización de iconos.

Tres reglas en la administración de sistemas

Fuente original: http://www.thegeekstuff.com/2010/07/three-sysadmin-rules/

El borrador de este artículo trataba de las 7 costumbres de los administradores de sistemas. Tres de ellas destacaban realmente.

Si las costrumbres son buenas, a veces las reglas son incluso mejor, especialmente en el mundo de la administración de sistemas cuando se trata de un entorno de producción.


Regla #1: Haz copia de seguridad de todo ( y compruébala con regularidad )

Los administradores de sistemas experimentados saben que, independientemente de lo proactivo que seas, un sistema en producción fallará algún día. La mejor forma de estar preparado para esta situación es disponer de una copia de seguridad correcta.

Si no dispones de una copia de seguridad de tus sistemas críticos, deberías empezar a pensar en ello inmediatamente. Ten en cuenta lo siguiente:

• ¿Qué software o script utilizarías para realizar la copia de seguridad?
• ¿Dispones de suficiente espacio en disco para la copia de seguridad?
• ¿Con qué frecuencia se actualizarán las copias de seguridad?
• ¿Necesitarás copias de seguridad incrementales además de la copia de seguridad total?
• ¿Cómo se ejecutaría la copia de seguridad, por ej. utilizando crontab o algún otro sistema de calendarizaje?

Si no tienes una copia de seguridad de tus sistemas críticos, deja de leer este artículo y ponte a trabajar. Comienza la planificación de tu copia de seguridad inmediatamente.

En una de las investigaciones realizadas por una compañía (no recuerdo cual), recuerdo que sólo el 70% de las aplicaciones en producción tenían copia de seguridad, y de ellas el 30% eran incorrectas o estaban corruptas.

Supongamos que Samuel realiza copia de seguridad regularmente de las aplicaciones críticas, pero no las comprueba. Por otro lado, Javier no realiza ninguna copia de seguridad de sus aplicaciones críticas. Se puede pensar que Samuel lo hace mejor que Javier, pero en mi opinión los dos están en una mala situación: Samuel no puede asegurar la restauración correcta de la copia de seguridad en caso de desastre.

Si eres un administrador de sistemas y no consideras esta regla de oro número 1, debes pensar seriamente en dejar de administrar sistemas y dedicarte al desarrollo de aplicaciones.


Regla #2: Domina la línea de comandos ( y evita las ventanas )

No hay una ni una tarea en un servidor Unix / Linux que no puedas realizar con la línea de comandos. Existen algunas aplicaciones de administración basadas en ventanas para hacerlo más fácil, pero realmente no las necesitas y deberías utilizar siempre la línea de comandos.

Si eres un administrador de sistemas Linux, debes dominar la línea de comandos.

En cualquier sistema, si quieres ser fluido y productivo, debes ser un maestro con la línea de comandos. La diferencia principal entre un administrador de sistemas de Windows y de Linux es: Interface gráfica vs. Línea de comandos. Los administradores de sistemas de Windows no se sienten muy cómodos con la línea de comandos, mientras que los administradores de sistemas de Línux si.

Aparte de utilizar la línea de comandos, también debes entender cómo funciona un servicio en particular. En muchos entornos de servidor en producción, los administradores de sistemas normalmente desinstalan los servicios y herramientas que utilizan la interface gráfica.

Si eres un administrador de sistemas de Unix / Linux y no te gusta esta regla, es posible que realmente te guste más la administración de sistemas de Windows.

Regla #3. Automatiza todo ( y hazte vago )

El mejor administrador es el vago.

No conozco a ningún administrador que rompa esta regla. Esta es la parte más vaga.

Piensa durante unos minutos en la lista de tareas rutinarias que tienes que hacer todos los días, semanas o mensualmente. Cuando tengas esa lista, piensa en cómo automatizarla. El mejor administrador de sistemas normalmente no está ocupado, todo lo contrario: está relajado y deja que el sistema haga el trabajo por él.

Exchange 2010: informe de buzones grandes

Objetivo: enviar informe por email (por ej. una vez por semana) con los tamaños de los 10 buzones Exchange 2010 más grandes y sus respectivos usuarios.

Requisitos: en un servidor Exchange 2010 lanzar el script una vez por semana mediante una tarea programada.

Observaciones: indicar en el script los campos adecuados del email del remitente, del destino y el servidor smtp de destino correspondiente.

---- comienzo del script --------

# top 10 en tamaño de buzones de Exchange 2010 vía email
# datos envío email

$remitente = "remitente@dominio.com" # origen email
$destino = "destinatario@dominio.com" # más de uno separados por coma
$asunto = "TOP 10 buzones de usuario"
$servidor_smtp_destino = "smtp.dominio.com" # servidor smtp destino

# extracción ordenada de tamaños de buzones

$buzones = Get-Mailbox |
get-mailboxstatistics |
select-object DisplayName, TotalItemSize |
sort TotalItemSize -Descending

# selección de los 10 primeros

$top10buzones = 0..9 | % {$buzones[$_]}

# elaboración del informe

$informe = "`n" # primera línea en blanco del texto del informe

$informe = $informe + " Tamaño Usuario" + "`n"
$informe = $informe + "-------- : ----------------------" + "`n"

foreach ($buzon in $top10buzones) # procesa los 10 buzones
{
$informe = $informe + "{0,5:n0}" -f ($buzon.TotalItemSize.value.ToGB()) + " GB" + " : " + $buzon.DisplayName + "`n"
}

# envía email con informe

$smtp = new-object Net.Mail.SmtpClient($servidor_smtp_destino)
$smtp.Send($remitente, $destino, $asunto, $informe)

---- fin del script --------

Exchange 2010: creación rápida de usuario y buzón

Con un único formulario, crea un usuario con buzón de correo en Exchange 2010 desde cualquier host conectado al dominio del Directorio Activo. Sólo es necesario tener instalado PowerShell 2 y .NET 3.5 en adelante.

Características:

• Un sólo formulario.
• Nombre de dirección de correo igual al nombre de inicio de sesión.
• Inserción única de la contraseña.
• Visualización del tamaño de las bases de datos de Exchange 2010 antes de elegirla.
• Distinción entre cuenta personal y de servicio.
• Inserción en grupos del Directorio Activo.
• Inserción de los atributos más utilizados.
• Visualización en la barra de estado del servidor Exchange 2010 conectado.
• Gratuito.

Modo de empleo:

• Ejecuta la herramienta "alta_usuario_mailbox_2010.exe" con un usuario que tenga privilegios para crear buzones en Exchange 2010.
• Elige en el árbol de la izquierda la Unidad Organizativa donde quieres ubicar la nueva cuenta.
• Rellena los campos que necesites (algunos son obligatorios).
• Clica en "Dar de Alta" y si todo es correcto, el usuario (con todas las opciones indicadas en el formulario) y su buzón de correo aparecerán en su sitio.

Pantallazo:

Directorio Activo: Informes de usuarios

Toca realizar consultas al Directorio Activo en busca de patrones que guardan los usuarios. Sólo vamos a utilizar PowerShell y .NET (sin más).

Un usuario de un dominio de un Directorio Activo es un objeto y tiene una serie de propiedades (también conocidas como atributos) que le hacen único para unas cosas y común para otras. Entre otras, las propiedades más conocidas de un usuario son: name, displayname, samaccountname, company, department, division, memberof y mail.

Como ejemplo a ilustrar, vamos a obtener un informe de todos los usuarios del grupo G_ADMON y cuya oficina (atributo physicalDeliveryOfficeName) sea Madrid. Primero pongo el código PowerShell y después lo explico:

----comienzo de script.ps1-------------

$rootdse = New-Object DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$dominio = $rootdse.Properties["defaultNamingContext"]
$raiz_dominio = New-Object DirectoryServices.DirectoryEntry("LDAP://$dominio")

$busca = New-Object DirectoryServices.DirectorySearcher $raiz_dominio
$busca.Filter = "(&(objectClass=user)(objectCategory=person))"
$usuarios = $busca.findall()

$c=0

foreach ($usuario in $usuarios)
{
if (($usuario.properties.memberof -like '*G_ADMON*') -and
($usuario.properties.physicaldeliveryofficename -eq 'Madrid'))
{
$usuario.properties.name
$usuario.properties.mail
"-----------------------"
$c++
}
}
"$c usuarios encontrados."

----fin de script.ps1-------------

En las tres primeras líneas se crean tres objetos consecutivamente:

$rootdse: localiza la configuración principal del Directorio Activo.
$dominio: extrae el valor del dominio de la configuración de $rootdse.
$raiz_dominio: partiendo de $dominio, se ubica en su elemento raíz para realizar búsquedas.

Las tres siguientes líneas preparan y ejecutan la búsqueda de usuarios:

$busca: objeto que busca en $raiz_dominio.
$busca.Filter: es un filtro para que sólo busque usuarios y no otro tipo de objetos.
$usuarios = $busca.findall(): busca y encuentra a todos los usuarios que cumplan con el filtro y los deja en $usuarios.

Después se inicializa un contador a 0 y luego hay un bucle foreach que recorre todos los usuarios encontrados. Por cada usuario ($usuario) en $usuarios se busca con if a los usuarios cuyo campo memberof (grupos a los que pertenece el usuario) contenga lo que estamos buscando (el grupo G_ADMON) y cuyo campo physicaldeliveryofficename (oficina) sea Madrid. Si las dos condiciones anteriores se cumplen, mostramos el nombre y el email del usuario en cuestión; además se incrementa el contador. El informe finaliza con el número de usuarios encontrados que cumplen las condiciones.

Este es el armazón básico para realizar consultas a objetos de un Directorio Activo, en este caso han sido consultas a dos atributos de todos los usuarios, pero podemos consultar cualquier atributo de cualquier usuario u otro objeto. Sólo necesitamos saber cómo se llaman los atributos de los objetos para buscarlos. Para averiguar estos nombres de atributos aconsejo utilizar la herramienta AD Explorer de Mark Russinovich para ver el Directorio Activo por dentro, localizar los objetos y ver sus atributos.

Además, escribir código para estos menesteres es mucho más corto y rápido con PowerShell que con cualquier otro lenguaje que utilice .NET como VBasic o C#.