Consola SCOM 2007R2 Authoring no responde

Trabajando con SCOM 2007R2 me encontré con un problema. Cada vez que quería ingresar en la solapa de "Authoring" (Figura 1), aparecía un error que decía "System Center Operations Manager 2007 R2 has stopped working" (Figura 2).

Figura 1

 

 Figura 2

 

 

El mensaje no daba muchas opciones y finalmente la consola de SCOM 2007R2 se cerraba.

 

No era un tema de permisos, ya que sin permisos la solapa de "Authoring" directamente no aparece.

 

La solución fue cambiar la propiedad "Target" del acceso directo y agregarle "/clearcache"

 

"C:\Program Files\System Center Operations Manager 2007\Microsoft.MOM.UI.Console.exe /clearcache"

 

 

 



Nadie es testigo

En SANATIS hay varios DAG dentro de la infraestructura de Exchange Server 2010 para dar alta disponibilidad a las bases de emails de los usuarios.

 

Revisando la configuración de un DAG recientemente creado para dar servicios a la región del Norte Argentino, encontramos que el servidor que cumple la función de Witness del Cluster estaba configurado pero no estaba en uso (WitnessShareInUse: None).

 

Para verificar, revisé la configuración de otro de los DAG, el que da servicios a la región del Sur Argentino (Figura 1).

Figura 1

Al ver al DAG SANATISSA con el valor "Primary" en WitnessShareInUse confirmé que el DAG SANATISNA estaba en un estado incorrecto.

 

Para corregirlo, utilicé el cmdlet Set-DatabaseAvailabilityGroup, pero con la particularidad de que no indique ningún valor para configurar.

 

Incluimos como parámetro solamente el nombre del DAG (Figura 2), este cmdlet verifica y corrige problemas con el Witness cuando es utilizado de esta manera.

 Figura 2

Sin importar que este cmdlet no muestre ningún resultado, la configuración queda corregida (Figura 3), como podemos comprobar con el cmdlet Get-DatabaseAvailabilityGroup

¿ Esta soportado tu Exchange 2010 ?

Seguramente mucha gente está convencida de que su instalación de Exchange 2010 esta soportada... aún estamos en Enero de 2013 !

Para sorpresa de muchos, si tu Exchange 2010 tiene SP1, ya está fuera de soporte. Algunos esperaban para actualizar directamente a SP3, el cual fue prometido para principios de 2013, pero aún no esta disponible.

 

El la página de ciclo de vida del producto puede consultarse todas las fechas de fin de soporte.

Buscar equipos según el Service Pack Versión 2012

Anteriormente, publiqué una entrada en donde mostraba como buscaba equipos en un dominio para verificar el Service Pack del sistema operativo.

Claro que eso fue en Noviembre de 2009! Un largo tiempo en términos informáticos. Aunque ese procedimiento aún es válido, en el 2012 hacemos todo con PoweShell.

El cmdlet que utilizaremos es Get-AdComputer, el cual está incluido en el módulo de PowerShell para Active Directory. Si la consola de PowerShell que estamos utilizando no tiene los cmdlets de AD, podemos importar el modulo (Figura 1) con otro cmdlet:

Import-Module ActiveDirectory

Figura 1

Primero realizamos la consulta para ver todos los equipos (-Filter *), todas las propiedades (-Properties *), y en un formato de tabla (ft) buscamos nombre, sistema operativo, service pack, IP y fecha de la última vez que el equipo inició sesión (Figura 2).

Get-ADComputer -Filter * -Properties * | ft Name, OperatingSystem, OperatingSystemServicePack , *IPv4* ,LastLogonDate* -AutoSize

Figura 2

En esta tabla rápidamente podes ver varios datos:

1-BPSARGTestPC no tiene ningún valor en Operating System, lo que indica que nunca se unió al dominio pero existe en AD una cuenta de equipo.

2-Algunos equipos no se validan hace casi dos años, por lo que seguramente son cuentas de equipo que deberíamos depurar o deshabilitar.

3-Podemos obtener la IP de los equipos en forma remota.

Seguramente, en un entorno mediano o grande, es impráctico ver todos los equipos por pantalla, por lo que tenemos dos opciones.

A) Acotar nuestra búsqueda, por ejemplo a equipos con Windows XP con Service Pack 2 (Figura 3)

Get-ADComputer -Filter 'OperatingSystem -like "*XP*" -and OperatingSystemServicePack -like "*2*"' -Properties * | ft Name, OperatingSystem, OperatingSystemServicePack, *IPv4*, LastLogonDate* -AutoSize

 

Figura 3

B) Enviar el resultado de la búsqueda a un archivo .CSV (Figura 4)

Get-ADComputer -Filter 'OperatingSystem -like "*XP*" -and OperatingSystemServicePack -like "*2*"' -Properties * | Select Name, OperatingSystem, OperatingSystemServicePack, *IPv4*, LastLogonDate* | Export-Csv C:\Temp\ADComputerInfo.csv

Figura 4

Cambiando los valores que fueron ingresados en el cmdlet anterior, podemos buscar equipos con diferente sistema operativo o service pack según la necesidad que exista.

En estos ejemplos solo trabajamos con algunas propiedades, pero podemos hacer consulta de muchas otras. Para ver la lista completa de propiedades podemos utilizar el cmdlet Get-ADComputer

Get-ADComputer -Properties *

Para aprender más...

Get-ADComputer en SS64

Mailbox Database Resynchronizing Forever

Recientemente en Distus necesitábamos crear unas Mailbox Databases de Exchange Server 2010. Estas bases debían contar con alta disponibilidad, por lo que se las agregó a un DAG. La copia activa en el servidor DISARWEX203 y la copia pasiva en el servidor DISARWEX202.

Cuando utilizamos el cmdlet get-MailboxDatabaseCopyStatus, vimos que la base pasiva quedaba en un estado de Resynchronizing eterno (Figura 1).

Figura 1  

Hacer un update a la copia pasiva o incluso borrarla y volver a crearla no solucionaba el problema.

El inconveniente se presentó porque cada miembro del DAG que contenía una copia de la MailboxDatabase utiliza un Domain Controler diferente al ser un DAG geodistribuido. El cmdlet add-MailboxDatabaseCopy realiza configuraciones en cada miembro interviniente en la operación, efectuando una escritura en diferentes Domain Controlers que no replican entre ellos en forma instantánea, pues pertenecen a diferentes sites AD.

La solución fue suspender la replicación, quitar la copia pasiva, borrar manualmente los archivos que estaban en el server que tenía la copia pasiva, y volver a agregarla, seleccionando en cada operación cual Domain Controler utilizar (Figura 2).

Figura 2

También es posible suspender la replicación, forzar un update, optar por la opción que permite borrar los archivos que están en el servidor que contiene la copia pasiva e indicar qué Domain Controler utilizar (Figura 3).

Figura 3

Exchange Server 2010 no usa un DC que está en el mismo Site AD

En la empresa Technology Labs contamos con tres sites AD (Figura 1):

• East (East)
• Midwest (Midwest)
• Saint Nicholas (StNic)

También hay tres dominios

• LabmsgRoot.Techlab.net
• LabmsgMid.Techlab.net
• LabmsgStn.Techlab.net

Para que Exchange Server 2010 tenga acceso al AD, pusimos dos DC en el site Midwest. Uno es DC de LabmsgMid y otro es DC de LabmsgStn.

Figura 1

Cuando por mantenimiento se necesito apagar uno de los DC, los servicios de Exchange dejaron de funcionar. Sabiendo que había otro DC en el mismo sitio comenzamos a buscar que podría estar mal.

Lo primero fue verificar que DC utilizaba el servidor de Exchange (Figura 2).

Figura 2

Ese comando de PowerShell nos reveló que Exchange utilizaba el equipo que habíamos apagado, pero que adicionalmente no tenía otro equipo a donde conectarse.

Buscamos en el Even Viewer el Event ID 2080 para ver información relativa al acceso al AD que tiene el equipo de Exchange Server 2010 (Figura 3), nos encontramos que se reflejaban los dos DC del sitio.

Figura 3

Sin embargo, un pequeño detalle nos dió una pista de donde podría estar el problema. El equipo que no era listado por Exchange Server 2010 nos marcaba un CERO (Figura 4) en el campo SACL Rights.

Figura 4



Este indicador nos avisa que el servidor de Exchange no tiene permisos de "Manage auditing and security logs" en ese DC, permiso necesario para todos los Exchange Server 2010. Después de que el equipo de Administración de AD confirmó que este equipo no contaba con ese permiso y se lo asignó correctamente (Figura 5), volvimos a buscar el Event ID 2080 (Figura 6). 

Figura 5

Figura 6

Ahora se podía ver que ambos DC reportaban un UNO en SACL Rights (Figura 6), y finalmente verificamos con el mismo comando PowerShell que al principio, cuales DC podía utilizar el servidor de Exchange 2010 (Figura 7).

Figura 7

Apagando cualquiera de los DC, Exchange Server 2010 continúa funcionando si el otro DC se encuentra activo.

Importación manual de máquina virtual en Windows Server 2012 (Hyper-V 3.0)

El proceso de importación de una máquina virtual (VM) en Windows Server 2012 es más simple que en las versiones anteriores. Anteriormente era necesaria una operación de exportación previa, la cual consumía tiempo y espacio de almacenamiento.

 

Importar una VM es muy útil en diversos escenarios como migrar el servidor físico donde se ejecutan las VM, armar un ambiente de laboratorio separado o antes recuperación de desastres.

 

Lo primero es tener un Windows Server 2012 (o Hyper-V Server 2012) con el rol de Hyper-V en ejecución (Figura 1) sin ninguna preparación especial.

 

Figura 1

 

En la consola administrativa de Hyper-V, seleccionamos el servidor que queremos utilizar para importar la VM pulsando con el botón secundario y hacemos click en la opción "Import Virtual Machine..." (Figura 2)

Figura 2

El asistente de importación se va a abrir, nos dará un mensaje de bienvenida y al pulsar "Next >" podremos seleccionar el directorio en donde están los archivos de configuración de nuestra VM (Figura 3).

 

Figura 3

 

Se nos presentan tres opciones:

 

a-Register the virtual Machine in-place: Para utilizar la VM tal cual en el lugar en donde esta y registrarla con el mismo ID que estaba utilizando previamente.

b-Restore the virtual Machine: Para copiar la VM a una nueva ubicación, registrarla en el Hyper-V,  pero conservando el ID de la VM original. 

c-Copy the virtual machine: Para copiar la VM a una nueva ubicación física y utilizar un ID diferente.

 

En este ejemplo, en donde movemos la VM a un nuevo servidor Windows Server 2012, se utiliza la primer opción ya que el almacenamiento en donde esta la VM es el mismo (Figura 4).

 

Figura 4

 

Cuando Hyper-V tiene toda la información necesaria de la configuración nos permite seleccionar el directorio en donde está el VHD (Figura 5).

 

Figura 5

Antes de comenzar el proceso de importación, nos permite seleccionar a que red vamos a conectar la VM, ya que es muy probable que la red original no esté disponible (Figura 6).

 

Figura 6

En la pantalla de resumen podemos revisar las opciones seleccionadas y confirmar o detener la operación (Figura 7).

 

Figura 7

A los pocos segundos podemos ver como la VM está ahora en la consola de Hyper-V lista para se utilizada (Figura 8).

 

Figura 8

 

En conclusión, el proceso de mover una VM a otro equipo quedo notoriamente simplificado en Windows Server 2012, agregando opciones como poder seleccionar a que red conectamos el equipo, lo que permite tener la VM importada en ejecución a los pocos segundos luego de terminar de trabajar con el asistente de configuración.