Outlook OST/PST: Mejores y Peores prácticas (Parte 3)

por Daniel Seveso

En la Parte 1 y Parte 2 de esta serie, mencioné aspectos de uso de archivos PST en las empresas y una serie de problemas posibles a consecuencia de configuraciones no recomendadas. En esta entrega, algunos puntos sobre el tamaño de los archivos offline, desempeño y escenarios de despliegue en máquinas individuales y granjas de servidores de acceso remoto.

Tamaños de OSTs y PSTs y cómo controlarlos

Originalmente los PSTs y OSTs fueron diseñados con soporte ANSI solamente y tenían una capacidad de almacenamiento limitada a 2Gb. Si el usuario intenta grabar más allá del límite, Outlook genera un error del cual no podrá recuperarse por sí mismo, imposibilitando subsiguientes accesos al PST. Para estas situaciones existe una herramienta PST2GB que borra información del PST a un valor por debajo del límite, respetando el formato interno.

En Outlook 2003 se opta por el formato UNICODE como default, con lo cual el límite se incrementa a 20Gb (50Gb en Outlook 2010). Estos límites pueden cambiarse en forma administrativa siguiendo el artículo: 832925 How to configure the size limit for both (.pst) and (.ost) files in Outlook 2003

Para Outlook 2003 y versiones más recientes, existe además un límite en cuanto al número de ítems (mensajes, tareas, carpetas, etc) que pueden ser almacenados en una carpeta. Este límite también depende del tipo de archivo:

• ANSI: 65,535 items
• UNICODE: 500,000 items (aproximado)

Si intentamos sobrepasar este límite Outlook mostrará el siguiente error: "The folder is full" or 0x80040403 (MAPI_E_TABLE_TOO_BIG)

Haciendo un poco de historia, este límite era más estricto en versiones anteriores de Outlook, haciendo necesario la configuración de “large tables” para llegar a 65,535 items. La configuración large tables pasó a ser configuración estandard a partir de Outlook XP (2002).

Para verificar qué formato de pst está usando, consulte el campo “Format” en sus propiedades, Outlook Data File (97-2002) corresponde a ANSI, y Outlook Data File corresponde a UNICODE:

  

Conclusión

Asegúrese de utilizar el formato UNICODE para todas sus PST. Si aún está utilizando alguna PST en modo ANSI, cree un nuevo PST en modo UNICODE y mueva el contenido hacia el nuevo repositorio. No es posible “convertir” el repositorio de ANSI a UNICODE. Use el siguiente artículo para forzar la migración de ANSI a UNICODE. En caso de llegar al límite de 2Gb en formato ANSI, utilice PST2GB para reducir su tamaño. Tenga en cuenta que esta operación borrará mensajes para llegar al tamaño deseado.

Consideraciones para despliegue de clientes Outlook en un ambiente de Exchange 2010

En lo concerniente al tema de este artículo, Outlook ofrece dos modos de conexión a Exchange: Cached Exchange Mode y Online Mode. Cached mode involucra el uso de una copia local (archivo OST sincronizado con el mailbox del usuario), mientras que Online Mode implica que Outlook presenta directamente la información del server sin ningún almacenamiento intermedio. Motivo por el cual se le denomina en linea o Online.

En el artículo Plan an Exchange deployment in Outlook 2010, pueden encontrar las excepciones en las que se recomienda el uso de Outlook en modo Online.

Cached mode es el modo recomendado en la mayoría de las situaciones y especialmente cuando usamos computadores portátiles, existen latencias en nuestra red (>500ms), o tenemos usuarios que no están conectados permanentemente (usuarios móviles o a través de WiFi). Cached mode es el modo predeterminado para los perfiles de una instalación local de Outlook.

Cuando Outlook es ejecutado por primera vez por un usuario de Remote Desktop Services, la opción predeterminada del nuevo perfil es Online Mode, asumiendo que podemos no tener recursos para almacenar los OSTs de todos los usuarios que usan Remote Desktop.  En caso de disponer estos recursos, la configuración puede ser cambiado por el administrador via OCT o Group Policies, o por el propio usuario que manualmente puede habilitar Cached mode.

Outlook en Cached mode, necesita contactar al servidor de Exchange para algunas operaciones. La más obvia sería descargar nuevos mensajes y enviar mensajes pendientes en nuestro Outbox, sin embargo, estas no nos preocupan, ya que son operaciones realizadas en background, sin afectar la rendimiento percibido por el usuario. Por ejemplo,  el usuario no verá el nuevo mensaje hasta que el mismo está completametne descargado en el OST, por lo tanto, a los ojos del usuario, la operación de abrir un nuevo mensaje se realiza muy rápidamente. Las siguientes operaciones, sí necesitan contacto con nuestro data center en tiempo real: trabajo en mailboxes que nos han sido delegados, obtención de información de disponibilidad (Free/Busy) para agendar citas, configuración del mensaje automático de fuera de la oficina (OOF), acceso a carpetas públicas, lectura de un mensaje protegido con Right Management Service, modificación de reglas, consultas del MailTips, consultas de listas de direcciones alternativas (diferentes a la que se publica en el Offline Address Book).  Estas operaciones son las que más tardarán en caso de que la latencia de conexión con los servidores sea importante.

Por motivos de estructura interna, el OST normalmente tiene un tamaño mayor que su equivalente almacenada en el mailbox. Es normal planificar para un incremento de 50 a 80% mayor del tamaño de mailbox sincronizado. Este tamaño puede crecer aún más si el usuario decide sincronizar contenido de carpetas públicas o carpetas de otros usuarios a las que tenga acceso. Las opciones  “Download Public Folder Favorites” y “Download Shared Folders” pueden configurarse en la pestaña de configuración avanzada.

Esta y otras configuraciones relevantes pueden ser aplicadas a los usuarios vía políticas de grupo, mediante las plantillas administrativas para Outlook (Outlk14.adm).  Esta plantilla es parte del Office 2010 Administrative Template files disponible en nuestro sitio de Downloads.

Conclusión

Estas consideraciones sobre el OST son las más “populares” a tener en cuenta en términos de performance, tamaños y modos de funcionamiento. Mi recomendación es la lectura de la documentación de planificación para despliegue de Outlook en forma completa (Plan for Outlook 2010)

Outlook 2010 y ambientes de Remote Desktop Session Host

Existe un escenario donde actualmente (Mayo 2012) es soportado el acceso a PST y OST localizadas en servidores de archivo. Este escenario es cuando utilizamos Remote Desktop Session Host sobre Windows 2008 R2 y clientes Outlook 2010. El soporte está condicionado a las siguientes restricciones:

• Se utiliza una conexión de baja latencia y alto ancho de banda
• Solamente un cliente a la vez accede al PST / OST (un cliente Outlook por .pst)
• Se usa Windows 2008 R2 RDSH o Virtual Desktop Infrastructure.

En este escenario cuando existe un pool de Remote Desktop Hosts es una práctica común tener los perfiles de usuario en la red, para que la experiencia del usuario sea similar no importa a qué servidor del pool se conecte. Este escenario está documentado en el artículo 297019, y en el documento Cached Exchange Mode in a Remote Desktop Session Host environment: planning considerations

Outlook 2010 ha mejorado el acceso a los archivos PST/OST implementando file caching del lado del cliente. Esto significa que ha pasado mucha de la lógica de actualización de la estructura interna del PST (que es una pequeña base de datos) al cache, bajando la cantidad de operaciones de escritura al disco. Esto disminuye varios de los aspectos negativos de tener los archivos de office en servidores de red, como por ejemplo, el estrés causado a los servidores, y el excesivo tráfico de red causado por multiples clientes.  Sin embargo hay riesgos que aún existen e incluso se intensifican, como por ejemplo la posibilidad de corrupción del archivo de office en caso de degradación o falla de la conexión de red, o la finalización inesperada de outlook.exe. Este aspecto también está considerado y documentado en el artículo 297019.

Conclusión

En términos generales, Microsoft recomienda utilizar entrega de mensajes en el servidor de Exchange, con el cliente configurado en modo “Cached” y utilizando OST local. Esta también es mi recomendación, a efectos de evitar los riesgos y ofrecer la mejor experiencia al usuario de Outlook / OWA o dispositivos móviles.

En particular, si opta por la opción descrita anteriormente de acceso a PST/OST en servidores de archivo, deberá considerar la posibilidad de corrupción del archivo, implementando salvaguardas adicionales como backup diarios de los PSTs o soluciones similares.

Los archivos PST/OST conforman un formato estándar, público, documentado en MSDN el cual, como cualquier otro estándar, no puede cambiarse para adaptarse a nuevos escenarios. La optimización del formato en favor de file-based access, hace que el acceso via red, no sea y continúe no siendo la mejor alternativa.

Hasta la próxima!