Tag Archives: Exchange 2000

Cómo agregar Hub Transports adicionales a un Routing Group Connector

En un escenario de coexistencia entre Exchange 2003 y 2007/2010, el setup de Exchange crea un nuevo Administrative Group y un nuevo Routing Group para los servidores 2007/2010. Este Routing Group es creado debido a los cambios en la estrategia de routeo intersite – intrasite que tienen las nuevas versiones de Exchange.

Ahora bien, para poder asegurar el flujo de correos entre estos Routing Groups es que se crea un Routing Group Connector (RGC). Este conector se crea durante el setup del primer Hub Transport 2007/2010.

El RGC tiene como servidores de puente (Bridgehead Servers) el primer servidor Hub Transport de la Organización y un servidor 2003 que nosotros definamos durante el setup. Es muy probable que en nuestro escenario tengamos más de un Hub Transport para darle alta disponibilidad al routeo entrante y saliente de correos. Es por eso que necesitamos agregar ambos Hub Tranports al RGC, y así asegurarnos que ante la caída de uno de ellos (ya sea por una falla o por mantenimiento) el flujo de correos desde y hacia Exchange 2003 sigua funcionando.

Dentro de Exchane 2’007/2010 veremos que existen dos RGC:

Get-RoutingGroupConnector

Uno de ellos es desde Exchange 2003 a 2010 y el otro es desde Exchange 2010 a 2003.

 

Modificar el Routing Group Connector desde Exchange 2010 a 2003

 

Para agregar un servidor de Exchange 2010 al RGC creado durante la instalación, será necesario ejecutar:

Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "E2010HubTransport01"} | Set-RoutingGroupConnector -SourceTransportServers "E2010HubTransport01",”E2010HubTransport02”

Reemplazar E2010HubTransport01 y E2010HubTransport02 por los valores correspondientes a los nombres de los servidores de transporte de Exchange 2010.

Bien, si ahora queremos agregar otro servidor de Exchange 2003, el comando debería ser similar a:

Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "E2010HubTransport01"} | Set-RoutingGroupConnector -SourceTransportServers "E2010HubTransport01",”E2010HubTransport02” –TargetTransportServers “Exchange2003A”,”Exchange2003B”

 

Modificar el Routing Group Connector desde Exchange 2010 a 2003

Si seguimos el paso anterior al pie de la letra, Exchange 2010 puede enviar desde dos servidores de Hub Transport hacia uno o dos servidores de Exchange 2003. Para poder configurar esto mismo, pero en el conector con dirección Exchange 2003 –> Exchange 2010, es necesario ejecutar este comando:

Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "Exchange2003A"} | Set-RoutingGroupConnector -TargetTransportServers "E2010HubTransport01",”E2010HubTransport02”

Reemplazar E2010HubTransport01 y E2010HubTransport02 por los valores correspondientes a los nombres de los servidores de transporte de Exchange 2010.

Si queremos configurar varios servidores de Exchange 2003 como origen del conector (como aneriormente hicimos con Exchange 2010, el comando sería parecido a:

Get-RoutingGroupConnector | where {$_.SourceTransportServers -like "Exchange2003A"} | Set-RoutingGroupConnector -SourceTransportServers  “Exchange2003A”,”Exchange2003B” –TargetTransportServers "E2010HubTransport01",”E2010HubTransport02”

 

Nota final

Con estas configuraciones podemos asegurarnos que el flujo de correo Exchange 2003 –> Exchange 2010 y el flujo de correo Exchange 2010 –> Exchange 2003 es resistente a la caída o bajada de servidores por mantenimiento.

 

>> Pablo Vernocchi

Cada cuánto defragmentar la base de datos de Exchange?

Estaba ejecutando un proyecto en un cliente, cuando lanza la pregunta…:

La defragmentación (offline) de las bases de datos:

  • ¿debe ser incluída dentro de las tareas rutinarias de la administración de Exchange?
  • ¿cada cuánto tiempo es recomendado defragmentar las bases de datos?

El proceso de defragmentación offline no es una tarea trivial. Para empezar es necesario bajar las bases de Exchange antes de ejecutarla.

Por otro lado, el proceso de defragmentación lee la base original y copia los datos a una nueva base. Luego reemplaza la nueva base (desfragmentada), reemplazando la original. Este paso no es gratuito. Al crear una nueva base, también tenemos nuevos signatures para esa base. Todos los transaction logs están asociados a la base por este signature. Por lo tanto, si tenes que hacer un restore de la base, con una copia de seguridad anterior a la desfragmentación, seguramente no seamos exitosos en la tarea. Las signatures no van a coincidir, y los Transaction logs no se van a aplicar a la base.

Quizás esa sea la razón principal por la que el defrag offline no se debe incluír como una tarea frecuente.

Sin embargo, si necesitaramos ejecutar el defrag, sí o sí necesitaremos un buen full backup!

Cuando realizar un defrag:

Más allá de las recomendaciones, sí es neceario desfragmentar las bases de datos luego de ejecutar una reparación de la misma ya que no está soportado tener una base reparada en producción (recuerden que al desfragmentar se genera una nueva base).

También es recomendado desfragmentar cuando estamos usando las versiones estándar de Exchange 5.5/2000/2003 y llegamos al límite de la base de datos (16 GB para 5.5/2000 y 75 GB para 2003).

Así como también se debe desfragmentar si tenemos algún problema con la base de datos que se solucione con el defrag de la misma.

Por otro lado, como regla general y si necesitamos el espacio en el disco, podemos desfregmentar la base de datos cuando el evento 1221 del Event Viewer indica que podemos recuperar más del 30% del tamaño de la base.

Les recomiendo esta lectura adicional sobre espacios blancos en la base y el evento 1221:

http://blogs.msdn.com/jeremyk/archive/2004/04/09/110553.aspx

 

Saludos,
>> Pablo Vernocchi

A parchear los Exchange!

Esta semana se publicaron varias acutalizaciones. Por un lado tenemos los nuevos rollups:

Para las versiones 2003 y 2000 se publicaron dos fixes muy importantes descritos en KB976703 (Ex2000 SP3) y KB976702 (Ex2003 SP2).

A parchear se ha dicho!

 

>> Pablo Vernocchi

Cómo restringir que usuarios envíen correos a Internet con Exchange

Gente,

En esta oportunidad veremos cómo limitar usuarios para que no puedan enviar correos a Internet.

Antes de empezar tendremos que tener en cuenta la modificación de una clave en el registro. Para eso, abrimos el regedit, y vamos a HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Resvc/Parameters/, agregamos un valor del tipo:

Value Name: CheckConnectorRestrictions
Data Type: REG_DWORD
Radix: Hexadecimal
Value: 1

Una vez que tengamos hecho eso, empezaremos a configurar todo.

Como primer paso, creamos un grupo donde alojaremos los usuarios que no puedan enviar correos (por ejemplo “Sin mail Saliente”).

Luego, abrimos el administrador de sisitema, expandimos servidores, expandimos nuestro server y, sobre conectores hacemos clic con el botón secundario –> nuevo conector SMTP. Le ponemos el nombre que querramos.

Ahora debemos asociar ese conector con un servidor virtual SMTP, para ello hacemos clic en el botón “Agregar” que está abajo a la derecha. Veremos una lista de servidores virtuales SMTP, seleccionamos el que corresponda y hacemos clic en Aceptar.

Luego tendremos que asociar ese conector con un grupo de direcciones a las que afectará. En nuestro caso será * (asterisco) ya que valdrá para todos los dominios en Internet.

Nos vamos a la solapa llamada “Restricciones de entrega” y veremos las configuraciones por defecto. Tendremos que agregar nuestro grupo (“Sin mail Saliente”) en el campo “Rechazar mensajes de”.

Listo, ahora lo que falta es reiniciar dos servicios, SMTP y Microsoft Exchange Routing Engine para que apliquen las configuraciones del registro que cambiamos al principio.

Espero que les sirva,
Vernocchi Pablo.

NOTA: Antes de implentar los cambios recomendados en este artículo, les recomiendo leer estos dos artículos de Microsoft por efectos secundarios:

Mail delivery is slow after you configure delivery restrictions that are based on a distribution list:
http://support.microsoft.com/kb/812298

In Exchange Server 2003, message delivery to local mailboxes and to external mailboxes is slower than you expect after you configure delivery restrictions based on distribution groups
http://support.microsoft.com/kb/895407/