Update y distribución de OAB

Suele ser habitual tener que actualizar de urgencia la libreta de direcciones sin conexión u OAB. Normalmente es suficiente con hacerlo mediante la GUI o mediante el comando:

Update-OfflineAddressBook -Identity "Default Offline Address Book"

En el caso que queramos actualizar la que se está usando por defecto y tengamos una decena de ellas (como he visto en algún cliente) tenemos dos opciones: mirar cual está por defecto o lanzar la actualización mediante un cmdlet que compruebe cual es esta , como por ejemplo:

Get-OfflineAddressBook | where {$_.IsDefault -eq "true"} | Update-OfflineAddressBook

Envío de tareas a usuarios fuera de la organización

Los usuarios de mi entorno comenzaron a enviar tareas a usuarios de otra organización Exchange con la que compartimos el espacio de nombres (mismo dominio SMTP).

En cuanto los usuarios eran migrados a los nuevos servidores cuando se les asignaba una tarea desde la organización origen en su lugar recibían un correo de texto con el formato deformado y con un adjunto en lugar del típico correo de tarea con los botones de aceptar y denegar.

Configuración de shared namespace en dos organizaciones Exchange distintas

Últimamente con el tema de la nube privada cada vez más proveedores ofrecen a sus clientes entornos Exchange en instalaciones del proveedor.

En los casos en que el cliente tiene una organización Exchange muy grande suele ser  necesario un periodo largo de coexistencia durante el cual se van moviendo buzones desde la organización en casa del cliente (on premises) y la organización en la nube. Durante ese tiempo los correos deben seguir llegando a todos los buzones independientemente de que estén en una organización u en otra.

Existen dos aproximaciones posibles en estos casos, una sería a través de un dominio auxiliar al que se redirigirían los correos y la otra es el espacio de nombres compartido.

Vamos a configurar dos organizaciones, una 2007 que simulará nuestro cliente (el sistema origen) y otra 2010 que simulará el proveedor (o sistema destino) .

Se tratará de dos organizaciones totalmente distintas pertenecientes a dos bosques distintos. Ambas deben ser capaces de recibir correos dirigidos al mismo dominio DNS con un funcionamiento transparente independientemente de dónde se encuentre el buzón de destinatario.

Instalación de una organización Exchange 2010 desde cero por linea de comandos. Parte I

Esta va a ser la primera de una serie de entregas en la que vamos a configurar una organización de Exchange desde cero a través de la linea de comandos.

El objetivo será montar un entorno compuesto por 2 servidores. Configuraremos un DAG con los dos servidores y adicionalmente con los mismos servidores crearemos un Array de CAS. Por tanto los 2 servidores poseerán los 3 roles: MBX, HUB y CAS.

Este escenario es posible siempre y cuando el balanceo de carga se realice mediante balanceadores hardware y no mediante NLB de Windows el cual es incompatible con la característica de Failover Cluster (en el caso de quere usar Windows Network Load Balancing sería necesario usar 4 servidores en lugar de 2).

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: