¿ 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.  

 

Cuando los mundos chocan (Buscar información en Outlook 2010 desde Windows 8)

Windows 8 ya está disponible en estado RTM, pero la versión de Outlook 2013 aún no. Esto nos presenta un escenario que seguramente se va a repetir durante algún tiempo: La versión de Windows y de Outlook no son de la misma generación, son de mundos diferentes. 

 

Tanto en Windows 7 como en Windows 8 tenemos la posibilidad de hacer una búsqueda desde el menú de Inicio al escribir y permitir al motor de búsqueda del sistema operativo que nos muestra los resultados. Con Windows 7 esos resultados incluyen los resultados de información del Outlook (Mails, contactos, adjuntos, etc). No es así en Windows 8, en donde el motor de búsqueda realiza su tarea dentro de ciertas aplicaciones (Metro) que pueden presentarse al sistema operativo como capaces de ofrecer resultados de búsqueda. Outlook 2010 (ni Outlook 2007) no tiene esta capacidad.

 

Figura 1

 

Es por eso que Outlook no aparece en la lista de aplicaciones ni muestra resultados cuando por ejemplo busco "Rodrigo", esperando que la información del contacto guardado en Outlook se muestre (Figura 1). Aunque la información si este presente (Figura 2).

 

Figura 2

 

Para buscar información guardada en Outlook 2010 (o en Outlook 2007) debemos abrir un explorador de Windows (Por ejemplo con la Tecla WIN+E) y escribir la información que queremos buscar (Figura 3).

 

Figura 3

 

En forma predeterminada, Windows no busca en el Outlook desde el explorador. Para poder indicarle que busque información en el Outlook, debemos ingresar al menú "Search Tools", seleccionar "Search Again in" y por último indicar "Microsoft Office Outlook" (Figura 4).

 

Figura 4

 

Finalmente nuestra búsqueda fue exitosa! (Figura 5).

 

Figura 5

 

Seguramente cuando Outlook 2013 esté disponible, también habrá empresas que no quieran migrar su suite de oficina por diferentes motivos (Licenciamiento, costo del despliegue, falta de capacitación de los usuarios etc), esta es la forma que se deberá utilizar para buscar en Outlook 2010 o 2007.

Cambiar configuracion TCP/IP con un usuario no Administrador

Mi amigo Mariano me consultó si me era posible ayudar a resolver el siguiente planteo:

"Hay muchos usuarios que trabajan como consultores en diferentes empresas, algunos necesitan cambiar la configuración TCP/IP de sus equipos cuando se conectan en las redes de las otras empresas, pero ninguno es administrador local de su equipo. ¿Se puede permitir a usuarios que no son administradores cambiar la configuración TCP/IP? ".

La respuesta fácil es "Si, se puede" pero me pareció más interesante dar la respuesta completa.

Para equipos con Windows 7, es posible incluir a los usuarios en el grupo "Network Configuration Operators", lo que les dará la posibilidad de cambiar las configuraciones de red pero sin la necesidad de ser administradores del equipo. Claro que para configurar muchos equipos, debemos utilizar GPOs. Comenzamos creando dos grupos de seguridad en nuestro AD (Figura 1). Uno de ellos lo usamos para administrar los usuarios que queremos que tengan derecho de cambiar la configuración de red y el otro para administrar los equipos sobre los cuales se va a poder realizar este cambio.

Figura 1

Luego creamos una GPO que configuramos para que actualice el grupo "Network configuation Operators (built-in)" con el grupo de usuarios que queremos que modifique la configuración de TCP/IP (Figura 2) (Computer Configuration-->Preferences-->Control Panel Settings-->Local Users and Groups).

Figura 2

En la GPO, cambiamos los Security Filtering (Figura 3) en donde quitamos "Authenticated Users" y agregamos al grupo de seguridad que incluye los equipos en donde queremos que se pueda realizar el cambio de configuración. Esta configuración, nos va a aplicar la GPO solo en esos equipos y no en todos los de la OU.

Figura 3

Cuando un usuario quiera cambiar la configuración TCP/IP de un equipo, el UAC va a pedir credenciales para poder hacer este cambio. Si el usuario y el equipo en donde está realizando la acción están incluidos en los grupos de seguridad que creamos previamente, solo debe introducir sus propias credenciales (Figura 4).

Figura 4

Realizar todas estas configuraciones es recomendable, que ya no queremos que todos los usuarios puedan cambiar la configuracion TCP/IP de cualquier equipo de la red. De igual manera tampoco queremos tener que realizar la configuración manualmente equipo por equipo.

Adicionalmente, podemos realizar otras restricciones sobre que pueden hacer los “Network Configuration Operators” (Figura 5) si no queremos, por ejemplo, que accedan a las configuraciones avanzadas de TCP/IP (User Configuration-->Policies-->Administrative Templates-->Network-->Network Connections).