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
Category Archives: Exchange 2010
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):
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
Mientras que un usuario de eseutil.net, al conectarse, intentará iniciar sesión a:
https://autodiscover.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:
- Utilizar un certificado que soporte varios nombres (SAN Certificate, o Subject Alternate Name Certificates, o comunmente los podemos encontrar como UC Certificate).
- Utilizar un certificado SSL clásico, estándar, de un sólo nombre.
- Utilizar dos certificados SSL clásicos, estándar, de un sólo nombre.
- 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
Update Rollup 4 para Exchange 2010 listo para descarga!
Hola a todos,
Se acaba de publicar el Update Rollup 4 para Exchange 2010.
Pueden encontrar información sobre los cambios que introduce este rollup en http://support.microsoft.com/?kbid=982639, además de recomendaciones útiles antes de instalarlo (Backupear las customizaciones de OWA, orden de instalación, etc).
Descarga desde: http://www.microsoft.com/downloads/details.aspx?FamilyID=09b4973e-3a80-4fb9-9f60-5c6e2b7a2727&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
Cuarentena de buzones… ¿y eso?
Un buzón dañado o corrupto puede tener el potencial de interrumpir el servicio por desmontar el almacén de información completo, lo que afecta a todos los usuarios en ese servidor. La cuarentena de buzones, una nueva funcionalidad de Exchange Server 2010, podrá ayudarnos a prevenir esta situación.
Mailbox Quarantine es una funcionalidad del Information Store de Exchange 2010 que, basado en valores que configuramos en la Registry, tiene la capacidad de detectar y aislar uno o más buzones puede podrían afectar la estabilidad del Information Store, por un tiempo determinado. Estos buzones se denominan Poisoned Mailboxes.
¿Cuándo un buzón es enviado a la cuarentena?
La cuarentena de un buzón puede suceder en dos ocasiones:
- Un thread trabajando en un mailbox crashea.
- Más de 5 threads asignados para procesar en un buzón, no reportaron avances por un período largo de tiempo.
¿Cómo funciona?
El store va a identificar con un tag el buzón que tiene el potencial de comprometer el store. Este tag incluye la cantidad de veces que el buzón causó este crash en el store y un time stamp. Si el Information Store fue impactado por un buzón, una clave en el registro se creará en el siguiente path:
HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox GUID}
Y contendrá los siguientes valores:
CrashCount: Es la cantidad de veces que el buzón impactó el store.
LastCrashTime: La última vez que lo hizo.
Cada vez que se monta una base de datos, el Information Store lee el regsitro para verificar si algún mailbox almacenado en esa base fue identificado. Si existe algún valor, entonces ese mailbox se pasará a cuarentena.
Por default, si un buzón fue identificado como amenaza 3 veces en 2 horas, entonces ese buzón estará en cuarentena por 6 horas.
Estas configuraciones pueden modificarse desde la siguiente key del registro:
HKLM\SYSTEM\CCS\Services\MSexchangeIS\ParameterSystem\Servername\Private-dbguid\Quarantined Mailboxes
Con los siguientes valores:
MailboxQuarantineCrashThreshold: Cantidad de veces que un buzón es tagueado antes de moverlo a la cuarentena.
MailboxQuarantineDurationInseconds: La cantidad de tiempo (en segundos) que el buzón permanecerá en la cuarentena antes que el Store lo libere.
NOTA: Estos valores no existen por default, deben crearse sólo si se pretende modificar el comportamiento por default.
¿Cómo nos damos cuenta de un buzón en cuarentena?
Sin una herramienta de monitoreo proactivo (como SCOM), el troubleshooting puede ser complejo. El usuario va a recibír un error bastante genérico, del tipo:
Cannot open your default e-mail folders. The attempt to log on to Microsoft Exchange has failed.
Intentando iniciar sesión desde el OWA, no va a ser muy diferente:
¿Porqué mencioné, entonces, las herramientas de monitoreo proactivo? Porque podemos monitorear dos cosas en particular:
- Cuando el store manda un buzón a la cuarentena, en ese momento se genera el evento 10018:
Log Name: Application
Source: MSExchangeIS
Event ID: 10018
Task Category: General
Level: Error
Description:
The mailbox for user /o=ESEUTIL/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=PabloV has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.
- La creación de la clave en el registro que mencioné más arriba: HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox guid}.
¿Cómo remover un buzón de la cuarentena manualmente?
Si no podemos esperar las 6 horas, entonces simplemente borrando la clave HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox guid} del registro, y desmontar y volver a montar la base es suficiente.
- >> Pablo Vernocchi
Exchange 2010 Beta 1 disponible para descarga
Hola a todos,
Hoy el grupo de producto publicó la primer beta de Service Pack 1 para Exchange 2010!
Lee la nota de prensa en http://www.microsoft.com/presspass/press/2009/apr09/04-15exchange2010pr.mspx
>> 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