Alta disponibilidad en Exchange 2010: hay vida más allá de DAG

Cuando pensamos en alta disponibilidad para Exchange 2010 nos vienen a la cabeza las siglas DAG (Database Availability Group) pero ¿es esto suficiente?

Exchange desde su versión 2007 basa su funcionamiento en roles. Cuando pensamos en dar alta disponibilidad lo primero que nos viene a la mente son las bases de datos de buzones, pero ¿Qué pasa con los otros roles? ¿De qué sirve tener los buzones Online si los servidores de acceso cliente no están disponibles? Y  aunque lo estén, si no tenemos servidores HUB o EDGE que mantengan el flujo de correo tendremos parada toda nuestra organización lo cual es inadmisible para cualquier empresa.

Vamos a realizar un repaso por las diferentes tecnologías implicadas en la alta disponibilidad de Exchange analizando rol por rol y viendo qué alternativas tenemos.

Comenzaremos por los servidores perimetrales:

Sobre la libreta de direcciones sin conexión de Exchange 2010

Vamos a dedicar una serie de artículos a comandos de Power Shell de Exchange y a la vez continuando con el anterior post el artículo de hoy lo vamos a dedicar en exclusiva a comandos útiles para resolver problemas con la OAB (Offline Address Book):

A modo de cultura comentaré que el proceso de generación o actualización de la libreta de direcciones sin conexión consiste en dos pasos:

1. El servidor de buzones crea a través del servicio Operador de Sistema de Microsoft Exchange la libreta de direcciones sin conexión el el directorio <Instalación de Exchange>\ExchangeOAB (que a su vez está compartida con nombre OAB).

2. Una vez creada, el servicio de distribución de archivos de Microsoft Exchange que está en servidor de acceso de cliente se encarga de replicarla en el directorio virtual del IIS que está situado en <Instalación de Exchange>\ClientAccess\OAB.

Problema común en relación de confianza NT - 2003

Hoy vamos a hablar de uno de los problemas más comunes a la hora de realizar una relación de confianza entre dominios: la resolución de nombres y más concretamente con un NT.

Para poder llevar a cabo una relación de confianza es requisito indispensable que exista una correcta resolución de nombres DNS.

Cuando hablamos de dominios post NT podemos realizar cualquiera de los siguientes pasos para poder resolver nombres:

• Usar reenviadores condicionales
• Usar reenviadores
• Usar stubs zone
• Usar zonas secundarias

Pero en el caso de un NT que se basa totalmente en WINS no es suficiente con realizar esto dado que cuando queramos realizar la relación de confianza el servidor NT será incapaz de localizar al 2003.

SCCM: Informe de direcciones MAC

Hola otra vez. En más de una ocasión se me ha pedido obtener un listado de direcciones MAC de los equipos que administro. Si disponemos de SCCM esta información está en su interior aunque no hay un informe preestablecido que nos muestre esta información (o yo no lo he encontrado).

A continuación pongo el listado de un informe que nos dará esta información.


SELECT
 CS.Name0, 
 NAC.MACAddress0,
 NAC.IPAddress0
FROM
 v_GS_Computer_System CS
 join v_GS_Network_Adapter_Configur NAC on CS.ResourceID = NAC.ResourceID
WHERE
 (not (NAC.IPAddress0 = 'NULL'))
 AND NAC.IPAddress0 != '0.0.0.0'
ORDER BY
 CS.Name0


Espero que sea de mucha utilidad.

Esos comandos anónimos que nadie conoce: getmac

Hola, hoy me voy a centrar en un comando que no suele ser conocido (yo por lo menos no lo conocía) y que te puede sacar de más de un apuro. Se trata de getmac y como supondréis con él puedes obtener la dirección mac de tu equipo o de otro remoto.

La sintaxis es muy sencilla: getmac /S sistema.

Ejemplos:

getmac
getmac /S 192.168.0.4
getmac /S eseEquipoDesconocido.frikis.local

Eso es todo por hoy. Espero que lo hayáis encontrado interesante.

DHCP por script: creación de reservas y rutas

Si bien en el anterior artículo de esta serie vimos cómo crear ámbitos por línea de comandos, hoy vamos a ver cómo crear reservas y cómo setear rutas mediante DHCP


Creación de una reserva:

Queremos crear una reserva con los siguientes datos:

Dirección mac: 08-00-27-00-60-5A
IP a reservar: 10.0.1.200
Dirección del ambito: 10.0.1.0
Servidor DHCP: 10.0.1.1
Nombre de la reserva: Win7User1

Exchange 2010: Configuración de autodiscover

Tanto si vamos a usar Outlook Anywhere, como si queremos distribuir la OAB vía web o si queremos que las cuentas de Outlook se configuren solas debemos configurar el servicio de autodiscover en Exchange 2010.
En primer lugar para poder realizar esta configuración necesitamos tener un certificado válido con multiples SAN (Subject Alternate Names) e instalado en el Exchange. Sin este certificado sólo los equipos del dominio podrán descargar la OAB el resto recibirán un error 0x8004010f.

Se trata de una configuración sencilla de 4 pasos:

1. El registro DNS

Debemos crear un registro de tipo A en nuestro dns en la zona del dominio de la dirección principal de correo del usuario. Si nuestro usuario es usuario1@gersonrodrigo.es habría que crear un registro A en la zona gersonrodrigo.es llamado autodiscover y que apunte a la IP del servidor CAS.

Creación de ámbito DHCP por linea de comandos

Hoy vamos a crear ámbitos DHCP por línea de comandos. Para ello vamos a realizar un pequeño script que usará el comando netsh.

Crearemos un ámbito sencillo con las opciones típicas: a nivel de ámbito la puerta de enlace y a nivel de servidor los servidores de nombres y el nombre del dominio.

Necesitaremos crear un fichero de texto auxiliar llamado Datosambitos.txt con el siguiente formato:

Ambito, Descripcion,IP Subred,Mascara,router,IP inicio,IP fin
Servidores, sede principal,10.0.1.0,255.255.255.0,10.0.1.1,10.0.1.10,10.0.1.200

Y ahora creamos un script con el siguiente contenido (recordad cambiar las variables en negrita por las de vuestro entorno y ponerle extensión bat o cmd):

Control de sesiones de Terminal Server por línea de comandos

Aunque los sistemas operativos de microsoft son plenamente visuales no por ello carecen de una poderosa línea de comandos. Hoy vamos a ver cómo consultar las sesiones de terminal server en curso y cómo podremos cerrarlas mediante comandos.


El comando está en C:\WINDOWS\system32 en windows 2003 (está en el path) pero en Windows XP el comando está en C:\WINDOWS\system32\dllcache por lo que desde fuera del directorio no funcionará.

Para ver las sesiones remotas en un servidor escribimos:

Automatización de filtros en FSRM

En muchas ocasiones los usuarios se empeñan en llenar los discos de la compañía (que no son precisamente baratos) con ficheros de películas y música. Para impedir que esto suceda podemos usar el componente FSRM de Windows.

Vamos a crear un filtro para impedir la grabación de este tipo de ficheros con ayuda de FSRM (File Serve Resource Manager). Dado que es posible que haya que realizar más de un tipo de filtrado, lo haremos a través de la linea de comandos:

Para ello crearemos 3 objetos:

1. Un grupo de ficheros que contendrá ficheros de video.
2. Una plantilla que usará ese grupo de ficheros para aplicarse
3. Un filtro que aplicará esa plantilla en la ubicación deseada.