Category Archives: Exchange

Online Archive a fondo – Parte 2

En el artículo anterior: Online Archive a fondo–Parte 1 vimos algunas de las generalidades de Archive y cuáles fueron los motivos para extender la funcionalidad del Archive y poder separarlo de la base de datos de buzones, a través de un procedimiento de mover buzones. En esta parte 2 veremos algunos otros aspectos del los Archives:

Delegación de Archive

En Exchange 2010 SP1, el servicio de Autodiscover publica los Archives que fueron delegados al usuario. Antes de SP1, el usuario B no podía acceder al archive delegado del usuario A, sólo podían acceder a su propio Archive y no al de un tercero.

Esta delegación puede hacerse desde el Management Shell:

 

Add-MailboxPermission –Identity Manager –User Assistant –AccessRights FullAccess

Es importante entender que un delegado sólo podrá acceder al buzón de Archive sí y sólo sí tiene Full Mailbox Access sobre el buzón primario del usuario al que quiere acceder al Archive.
Es decir, para poder acceder al archive de un usuario, tengo que tener Full Mailbox Access sobre el buzón primario. No existe un Workaround para evitar este paso.

 

Reconexión / Recuperación de un Archive en Exchange 2010 SP1

Previo a Exchange 2010, no existía la posibilidad de reconectar un Archive una vez deshabilitado si la cuenta primaria era movida. Por otro lado, si tanto el buzón primario como el archive eran deshabilitados, sólo se podía recuperar el buzón primario.

En Service Pack 1, se agregaron 2 atributos para facilitar este proceso:

  • msExchDisabledArchiveGUID
  • msExchDisabledArchiveDatabaseLink

Al momento de deshabilitar un Archive, estos dos atributos son completados con la información que existe en los atributos msExchArchiveGUID y msExchArchiveDatabaseLink del usuario, de esa manera se mantiene la información necesaria para la reasignación del archive al buzón.

 

Exportación e Importación de PSTs al Archive

El servicio de MAilbox Replication fue extendido en SP1 para soportar requerimientos de Mailbox Import y Export. Éstos son realizados a través de los CMDLets: New-MailboxImportRequest y New-MailboxExportRequest.

Ambos CMDLets incluyen el parámetro IsArchive que deberá ser usado para especificar si la operación de importación/exportación deberá hacerse desde/hacia el archive en vez del buzón primario.

 

Archive en la nube

Nuevamente el servicio MRS (Mailbox Replication Service) ha sido mejorado, esta vez para soportar mover los buzones de Archive a una base de datos en la nube. Por ejemplo, para un usuario nuevo con Archive en la nube, el comando de alta sería:

 

New-Mailbox –Name: TestUser –RemoteArchive –ArchiveAddress:CloudDomain.com

Para un usuario que ya existe, y lo único que se quiere hacer es habilitar un Archive en la nube, el comando sería:

 

Enable-Mailbox –Identity: TestUser –RemoteArchive –ArchiveAddress:CloudDomain.com

 

>> Pablo Vernocchi

Grandes novedades del setup de Exchange 2010 SP1

Haciendo un poco de reseña, y comparando con versiones anteriores, noto claramente una tendencia a hacer el proceso de instalación de Exchange, algo más sencillo.

Recuerdo en Exchange 2000/2003 que antes de instalar Exchange había que ejecutar por separado el setup /ForestPrep y /DomainPrep. Exchange 2007 permite ejecutar estas dos acciones (en realidad ahora son /PrepareSchema y /PrepareAD) dentro del mismo proceso de instalación de Exchange, si nota que no se ejecutaron previamente.

Me encanta ser protador de buenas noticias. Y en esta oportunidad quisiera comentarles de este tilde… un simple tilde que nos va a ahorrar muchos dolores de cabeza, tiempo de documentación y clicks…

He aquí el “Automatically install Windows Server roles and features required for Exchange Server”. Genial! Ya no tenemos que instalar todos los complementos de Windows necesarios para poder instalar Exchange!

capture_08282010_164842

 

Si alguno de estos requerimientos precisase reiniciar el servidor, al retomar el setup de Exchange 2010, este amable mensaje nos ofrece la posibilidad de retomar la instalación hasta el último punto donde la dejamos:

capture_08282010_165858[3]

 

 

Espectacular!

 

>> Pablo Vernocchi

Online Archive a fondo – Parte 1

Introducción

El Personal Archive Mailbox es un buzón de correo asociado a la misma cuenta de Active Directory que el buzón primario. Este buzón secundario reduce/reemplaza la necesidad de utilizar archivos PST, proveyendo seguridad y redundancia.

Se pueden aplicar políticas de retención al buzón primario, para que automáticamente se muevan al Archive los correosque excedan un tiempo determinado, configurado por el Administrador.

Este buzón secundario, o Archive, es accedido por el cliente desde Outlook Web App (OWA) o el mismo cliente de Outlook 2010 y 2007 (próximamente).

Novedades en SP1

Finalmente en Exchange 2010 existe la posiblidad de mover el Archive a una base de datos diferente de la primaria, sin embargo debe residir en el mismo Forest (salvo cuando se mueve a la nube).b

¿Cuál es fueron los motivos para este cambio?

  1. Archive en la nube: De esta manera podemos tener los buzones primarios on-premise y el archive en la nube.
  2. Administración: Las bases de datos de buzones (Mailbox Database) que almacenan buzones primarios y archives corren el riesgo de crecer incontroladamente, bases extremandamente grandes e imposibles de administrar.
  3. Performace: Almacenar los archives en la misma base de datos que los buzones, acarrea impacto en performance y administración. Generalmente en el archive almacenamos información antigua, no crítica. ¿Tiene sentido almacenar esta información en el mismo storage donde las bases de buzones? ¿O es mejor configurar un storage más barato, con un SLA distitno para esta información?.
    Los buzones tienen un requerimiento de capacidad y rendimientos de discos. Estos requerimientos estan basados en acceso constante a los buzones. Un archive no tiene la misma frecuencia de acceso que un buzón, por lo tanto el requerimiento de calidad y rendimiento de discos es completamente distinto.
  4. Costos de Storage: Asociado al punto anterior de performance.

¿Cómo reconfigurar los Archives?

Si la opción de Personal Archives ya fue implementada en la Organización, entonces tenemos dos alternativas para mover estos archives a otro disco o la nube:

Desde PowerShell

Utilizando el CMDLet New-MoveRequest que permite la administración del buzón y del Archive de manera independiente a través de los parámetros: PrimaryOnly, ArchiveOnly. Si ninguno de estos dos parámetros es especificado, entonces se utilizará el comportamiento del New-MoveRequest de versión RTM, es decir se mueve tanto el buzón Primario como el Archive, en el mismo proceso al mismo destino.

Desde Exchange Management Console

Desde la consola gráfica de Exchange, el proceso es el mismo que para mover un Buzón regular. En ese momento, al iniciar el asistente, las opciones de “Move only the user mailbox”, “Move only the archive mailbox” y “Move both the mailbox and the personal archive” aparecerán:

image

 

>> Pablo Vernocchi

Exchange 2010 Personal Archive y Outlook 2007

Hola a todos,

Para todos los que están planeando usar la funcionalidad de Archiving de Exchange 2010 en sus despliegues, ya deben saber que sólo se puede consultar el Archive Online desde Outlook 2010 y OWA.

Será una buena noticia, entonces, saber que habrá una actualización para el cliente Outlook 2007 para esta funcionalidad:

For those of you that have been holding your breath for this one, we’re also happy to let you know that in SP1 timeframe, there will be an update which will enable us to support access to a user’s Personal Archive with Outlook 2007.

Es un alivio saber sobre esta noticia! Para mucho de nosotros era un bloqueador de deployment del archiving de Exchange 2010.

>> Pablo Vernocchi

Qué funciones fueron removidas de Exchange 2010 SP1?

Muchos cuentan lo nuevo en Exchange 2010 SP1, sin embargo pocos cuentan lo que no está más Winking smile

 

Veamos la lista de funcionalidad discontinuada en Exchange 2010 SP1 con su workaround correspondiente:

  • Export-Mailbox e Import-Mailbox: Estos cmdlets fueron reemplazados en SP1 por Export Mailbox Request e Import Mailbox Request (Understanding Mailbox Import and Export Requests). Lamentablemente la documentación no está lista aún.
  • Enable-AntispamUpdates: Con este cmdlet podíamos configurar si habilitábamos o no las actualizaciones de firmas de los agentes antivirus de Exchange. Ahora debemos usar Forefront Security for Exchange para poder actualizar los filtros de antispam.
  • Federated delivery: Fue reemplazado por Tenant Mail Flow Control.
  • ISInteg: ISInteg está integrado dentro del producto pero en la forma de cmdlet en vez de un ejecutable por separado. Ahora podremos invocarlo desde New-MailboxRepairRequest o New-PublicFolderDatabaseRepairRequest.
  • Managed Folders en la consola MMC: Ahora las configuraciones deberán realizarse por el Exchange Management Shell (PowerShell).

Y? Qué esperas para actualizar a SP1?

 

>> Pablo Vernocchi

Exchange 2010 Service Pack 1 Disponible para descarga!

Finalmente lo tenemos! El SP1 está disponible para descarga en la versión final (RTM) desde las siguientes URLs:

Microsoft Exchange Server 2010 Service Pack 1 (SP1)

Exchange Server 2010 SP1 UM Language Packs

 

>> Pablo Vernocchi

Circular Logging y Exchange 2010

Circular Logging, o registro circular es una configuración para truncar Transaction Logs que ya fueron comiteados a la base de datos, replicados, inspeccionados y aplicados a bases de datos pasivas y lagueadas.

Continuous  Replication Circular Logging está recomendado únicamente si el despliegue de Exchange 2010 cuenta con múltiples copias de las bases de datos de Mailbox, incluyendo copias lagueadas y no se está realizando copia de seguridad de las mismas. De esa manera es como se logra una Organización de Exchange Backup-less.

En cambio, si ya se están tomando resguardos (backups) de las bases de datos, el mismo proceso de backup se encarga de truncar (purgar) los logs que ya fueron resguardados, en ese escenario no se debe habilitar Circular Logging.

Para mayor información sobre Circular Logging y Organizaciones de Exchange sin backup, les recomiendo chequear el siguiente link:

http://technet.microsoft.com/en-us/library/dd876874.aspx (inglés)

http://technet.microsoft.com/es-ar/library/dd876874.aspx (español)

Además, el grupo de producto publicó un artículo con mayor información sobre Circular Logging y backups VSS en: Exchange Circular Logging and VSS Backups

>> Pablo Vernocchi

Comportamiento de clientes Outlook en DAGs Exchange 2010

Muchas veces, tanto en Workshops como en proyectos, los clientes se acercan para consultarme cuál es el comportamiento que tienen los clientes Outlook soportados en Exchange 2010 ante un failover/switch-over y activación de Datacenters de contingencia.

 

Alta disponibilidad en un único Datacenter:

Este es el escenario más simple. Desplegamos nuestra topología de Exchange 2010 compuesta por un CAS Array y un DAG de Exchange 2010 con las bases replicadas en X cantidad de Mailbox Servers. Los perfiles apuntan al Cas Array.

Todos los clientes de Outlook (2003, 2007 y 2010) se comportan de la misma manera en un escenario de alta disponibilidad en un único Datacenter: No hay modificaciones en el perfil de Outlook, ni requiere internvención manual.

 

Activación de bases de datos a través de sitios (Cross Site)

Supongamos el hipotético caso de un escenario donde se requiera alta disponibilidad local y, además, un sitio de contingencia remoto. Este escenario se podría diagramar de la siguiente manera (el que me roba el gráfico, le corto los dedos):

 

dag

En este escenario tendríamos un DAG distribuído en dos datacenters, con un CAS Array para cada Datacenter, Hub Transport y Global Catalogs (que no los dibujé). Para reducir los backups, en el datacenter de contingencia, el servidor MBX-D aloja una base de datos lagueada.

En el caso que la base hosteada en MBX-B hiciese switch over al servidor MBX-A, estaríamos en el caso anterior, donde la conectividad se mantiene dentro del mismo Datacenter y del mismo Cas Array.

¿Qué pasaría si la base se activara en MBX-C?
En este escenario, tanto el Outlook 2003, el 2007 y el 2010 se conectarían a la base de datos del servidor MBX-C a través del servidor CAS-Pri. No habría cambio alguno en los perfiles de los usuarios, ni tampoco impactaría a los mismos.

Los clientes Outlook sólo usarían CAS-Sec si no pudieran conectarse al CAS-Pri, haciendo failover de Cas Array, y ahí él problema estaría en los clientes Outlook 2003, ya que tanto Outlook 2007 como 2010 descubrirían el otro CAS por Autodiscover. Una reparación del perfil de Outlook 2003 cambia el servidor de conexión y resuelve el problema.

Dentro de las propiedades de las bases de datos, podemos asignar cuál es el CAS Array que va a dar conexión a esa base de datos. Suponiendo una activación de la base del MBX-B al MBX-C, podríamos cambiar esa propiedad de la base de datos, y esperaríamos que los clientes de Outlok 2007 y 2010 se conecten a esa base a través del CAS-Sec. Esto no va a suceder, lamento informarles, al menos no hoy con las versiones de Outlook que hay disponbiles. Este cambio de CAS Array podría ser corregido en Outlook 2010 SP1, pero no hay nada confirmado aún.

Activación del Datacenter de contingencia

Si durante la fase de diseño hicimos las cosas bien, en cuanto a diseño de espacio de direcciones y certificados SSL respecta, entonces pasar al Datacenter de contingencia se simplifica a un cambio de registros DNS, cambiando el registro DNS del CAS Array del Datacenter primario al secundario.

 

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