Ú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.
lunes, 8 de julio de 2013
jueves, 25 de abril de 2013
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).
martes, 5 de febrero de 2013
Windows 2012: Teaming nativo
Una de las novedades que incorpora Windows Server 2012 es la inclusión del teaming nativo. En versiones anteriores debíamos recurrir al software del fabricante de las tarjetas (HP, Broadcom) para poder configurar una agrupación de enlaces o teaming de tarjetas.
A modo de cultura general el teaming consiste en agrupar N tarjetas físicas en una única tarjeta lógica. Existen varias configuraciones posibles dependiendo de si los switches a los que están conectadas las tarjetas físicas. Algunos switches como los Cisco "colaboran" en la creación del teaming junto a las tarjetas permitiendo realizar funciones avanzadas cómo sumar el ancho de banda de los integrantes del teaming.
Volviendo a Windows Server 2012 la forma de implementar el teaming es muy sencilla:
Vamos al administrador del servidor (server manager) y en la pestaña de servidor local tenemos un resumen de los datos del equipo:
viernes, 7 de septiembre de 2012
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:
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:
lunes, 20 de agosto de 2012
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.
viernes, 17 de agosto de 2012
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:
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.
domingo, 29 de julio de 2012
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.
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.
Suscribirse a:
Entradas (Atom)
