Tag Archives: Exchange 2007

Update Rollup 1 para Exchange 2007 SP3 para descargar!

Hola a todos,

Se publicó el RU 1 para Exchange 2007 SP3 esta semana.

La descarga puede hacerse desde http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ae45d06e-dcb7-43d8-b1ff-d3953836425b&displaylang=en o el 21 de Septiembre estará disponible via Windows Update.

La descripción con los fixes está disponible en: http://support.microsoft.com/kb/2279665

 

Para todos aquellos que tienen Exchange 2007, es importantísimo que actualicen a Service Pack 3 a la brevedad. De esta manera no son sujetos a http://www.microsoft.com/technet/security/advisory/2401593.mspx que sólo afecta a Exchange 2007 pre SP3 y Exchange 2003 SP2. En Exchange 2007 Service Pack 3 introdujimos URL Canaries para evitar este tipo de acceso no autorizado.

 

>> Pablo Vernocchi

Autodiscover en escenarios de múltiples dominios SMTP

En alguna oportunidad, escribí algunas palabras sobre el servicio de Autodiscover (incluído en Exchange 2007 y 2010). En este link podrán encontrar la referencia anterior (http://www.eseutil.net/autodiscover-a-fondo).

Supongamos mi Organización de Exchange, donde hosteo los dominios SMTP eseutil.net y vernocchi.com.ar. En esta organización tengo tanto usuarios de un dominio como del otro.

Si un usuario de vernocchi.com.ar intentara conectarse a Autodiscover lo hará por las siguientes URLs:

https://autodiscover.vernocchi.com.ar/Autodiscover/Autodiscover.xml

https://vernocchi.com.ar/Autodiscover/Autodiscover.xml

Mientras que un usuario de eseutil.net, al conectarse, intentará iniciar sesión a:

https://autodiscover.eseutil.net/Autodiscover/Autodiscover.xml

https://eseutil.net/Autodiscover/Autodiscover.xml

¿Cuál es el desafío en este escenario?

Ambas URLs apuntan al mismo sitio web, y sólo se puede tener un único certificado por sitio Web. En este escenario, claramente tenemos URLs distintas, por lo que nuestros clientes recibirían un error en los Outlook 2007 y 2010. En este escenario tenemos varias alternativas, ya que las configuraciones por default no alcanzan.

Existen, básicamente, 4 escenarios soportados:

  1. Utilizar un certificado que soporte varios nombres (SAN Certificate, o Subject Alternate Name Certificates, o comunmente los podemos encontrar como UC Certificate).
  2. Utilizar un certificado SSL clásico, estándar, de un sólo nombre.
  3. Utilizar dos certificados SSL clásicos, estándar, de un sólo nombre.
  4. Utilizar Autodiscover con Redirects HTTP de IIS.

Dentro de cada uno de estos escenarios, existen varias alternativas que vamos a cubrir una por una.

Utilizar un certificado que soporte varios nombres (SAN Certificate)

Esta es la solución más simple, sin embargo una de las más costosas. Un SAN Certificate cuesta casi 3 veces más que un certificado estándar.

En este casi este certificado podría ser válido para Autodiscover, Webmail, EWS, ActiveSync, etc. Cada URL nueva, es una entrada en el certificado.

 

Utilizar un certificado SSL clásico, de un sólo nombre

Esta es la alternativa más barata.

Este método consiste en apuntar tanto las InternalURL como ExternalURL al mismo nombre. De esta manera todo apunta a un único nombre y no necesitaríamos más de un certificado (proceso descrito en Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site").

Adicionalmente, tenemos que informarle de alguna manera al cliente Outlook 2007 ó 2010 que la URL de Autodiscover no será https://autodiscover.dominio.com/Autodiscover/Autodiscover.xml sino que será https://webmail.dominio.com. Esto lo podemos hacer a través de un registro SRV (Service Locator).

Entonces, en este caso, el registro SRV debería quedar algo así como:

_autodiscover._tcp.vernocchi.com.ar SRV service location:
          priority       = 0
          weight         = 0
          port           = 443
          svr hostname   = webmail.vernocchi.com.ar

Y:

_autodiscover._tcp.eseutil.net SRV service location:
          priority       = 0
          weight         = 0
          port           = 443
          svr hostname   = webmail.vernocchi.com.ar

Utilizar dos certificados SSL clásicos, estándar, de un sólo nombre

En este escenario, se debería crear un sitio web para cada dominio nuevo a servir dentro de Exchange 2007/2010. Es uno de los que menos recomiendo ya que cada vez que se da de alta un nuevo dominio SMTP, se tendría que dar de alta un sitio web para Autodiscover, configurarlo con una dirección IP diferente al resto y adquirir un nuevo certificado SSL.

Es el que más overhead administrativo tiene de todas las alternativas.

 

Utilizar Autodiscover con Redirects HTTP de IIS

Este tipo de despliegues es y probablemente será la solución ideal para los escenarios de Hosting, ya que no todos los servidores DNS públicos aceptan registros SRV.

Consiste en crear un certificado estándar en el Default Website y crear un nuevo sitio web,  sin certificado, y ahí configurar un redirect al default website.

 

 

>> Pablo Vernocchi

iPhone 4, iOS 4 y Exchange: Problemas de sincronización

En las últimas horas se detectó un issue con los dispositivos iPhone, iPod Touch, iPAD que corren la versión 4 de iOS y Exchange ActiveSync.

Esta nueva versión de sistema operativo para los dispositivos de Apple agrega un cambio al timeout de request de 4 minutos a 30 segundos, e inmediatamente los dispositivos dejan de sincronizar.

Apple también advierte que los administradores de Exchange pueden notar que los servidores corran más lento.

Para corregir este bug, Apple publicó un workaround en http://support.apple.com/kb/TS3398 y publicará la corrección definitiva en una actualización (nuevo release), que no tiene tiempo estimado de lanzamiento aún.

 

>> Pablo Vernocchi

Exchange 2007 Service Pack 3 listo para descarga!

Hola gente,

Ya se publicó el SP3 de Exchange 2007 que, entre otras cosas, brinda compatibilidad para ser instalado en Windows Server 2008 R2.

El documento con todo lo nuevo en SP3 está disponible en http://go.microsoft.com/fwlink/?LinkId=193965

Y el link de descarga es: http://www.microsoft.com/downloads/details.aspx?FamilyID=1687160b-634a-43cb-a65a-f355cff0afa6&displaylang=en

 

>> Pablo Vernocchi

Nuveas versiones de Storage Calculator para Exchange 2007 y 2010

El grupo de producto actualizó ayer ambas versiones de Storage Calculator.

La descarga la pueden realizar desde el Blog del grupo de producto desde http://msexchangeteam.com/archive/2010/06/15/455159.aspx

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

Storage Calculator para Exchange 2007 actualizada v17.3

El grupo de producto publicó ayer la nueva versión de la Storage Calculator (versión 17.3) para Exchange 2007.

Esta actualización mejora el cálculo de IOPS adicionales para los usuarios de BlackBerry, y está alineado con la guía de Performance Benchmarking de RIM.

La nueva versión puede descargarse desde este link y los cambios agregados están descritos en el siguiente link.

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 prevenir correo no deseado desde nuestro propio dominio – Parte 1

Hace un tiempo ya que este mecanismo de Spamming es frecuente, junto con otros como por ejemplo el Spam de NDRs. Lo que pretendo explicar en este artículo son dos estrategias que podemos implementar para evitar el correo no deseado (SPAM) con direcciones de correo de nuestro propio dominio. Ambas se pueden implementar por separado, o en conjunto.

 

Método 1: Exchange 2003 y superiores

Este primer método consiste en implementar SenderID. Esta tecnología anti spam permite a los administradores crear un registro en el DNS público donde se declaran las direcciones IP de los servidores de mail que pueden enviar correos para nuestro dominio. De esa manera sería la primer configuración para evitar lo que comunmente se denomina domain spoofing.

Este método no sólo evita que recibamos SPAM de nuestro propio dominio, sino que también sirve para evitar SPAM y virus de otros dominios.

Configuraciones necesarias para SenderID

Nosotros tenemos que configurar el DNS para que los antispam de terceros puedan validar este registro, y también para nosotros mismos.

¿Cómo configurar el DNS?

Sencillo. Existen distintos websites con asistentes para la creación del registro TXT. A continuación les paso los que más frecuentemente uso:

¿Cómo configurar Exchange 2003?

No es necesario tener creado el registro TXT para que Exchange utilice la comprobación de SenderID, pero sí es necesario si queremos evitar recibir correos de SPAM de nuestro dominio.

Para habilitar las comprobaciones, es necesario habilitar el filtro AntiSpam de SenderID. Para ello, dentro de la consola de administración de Exchange, vamos a Global Settings –> Message Delivery –> Properties

capture_03032010_214102
 

Dentro de las propiedades, seleccionamos la solapa Sender ID Filtering y seleccionamos la opción Reject. De esa manera, todos los correos que no pasen la validación no ingresarán a nuestro sistema:

capture_03032010_214151
 

Por último, tenemos que asegurarnos que en el SMTP Virtual Server se estén ejecutando las validaciones de Sender ID. Para ello, debemos ingresar a las propiedades del SMTP Virtual Server que está de cara a Internet (por las dudas que tengamos más de uno):

capture_03032010_214202

Entrar a la sección Advanced:

capture_03032010_214209

capture_03032010_214211

Y asegurarnos que esté marcado Sender ID Filtering o marcarla nosotros:

capture_03032010_214214

¿Cómo configurar Exchange 2007?

En el caso que la infraestructura no cuente con un Edge Transport Server, primero debemos instalar los agentes de Antispam. Para ello pueden seguir los pasos descritos en este artículo: Cómo instalar los agentes Antispam en un Hub Transport. Si ya contamos con un Edge, no hace falta este paso.

Dentro de la consola de Exchange, ir a Organization Configuration –> Hub Transport. Luego ir a la solapa Anti-Spam y seleccionar el filtro Sender ID.

capture_03062010_153108(2)

Seleccionar la opción Reject message de la lista:

capture_03062010_153115

De esa manera, tanto en Exchange 2003, 2007 o 2010 estaremos evitando la entrada de mensajes de SPAM enviados con cuentas ficticias de nuestro propio dominio. En la segunda parte, cubriremos una alternativa para hacerlo con permisos en el receive connector y sin agentes AntiSpam.

>>Pablo Vernocchi

FBA Editor para ISA Server y TMG

Navegando por la web, encontré este software que parece una buena alternativa a las implmentaciones de ISA Server y TMG que requieren la edición del Formulario de Autenticación (para la publicación de Exchange, por ejemplo) para agregar el logo de la compañía, modificar la fuente, color, etc.

 

 

 

 

Si les parece interesante, pueden descargarlo desde FBA Editor version 1.0

>> Pablo Vernocchi