Preguntas y respuestas sobre ExchangeTiempos de espera de OWA, solución de problemas de cmdlet y mucho más

KC Lemson and Nino Bilic

P Recientemente realizamos la migración de Exchange Server 2003 a Exchange Server 2007. Ahora recibimos mensajes que dicen que Outlook® Web Access (OWA) ha excedido el tiempo de espera para los usuarios restringidos que seleccionaron la opción "This is a private computer" al iniciar sesión en OWA 2007. ¿Cuál es el comando apropiado del Shell de administración de Exchange para comprobar el tiempo de espera en equipos privados?

R Retrocedamos un poco. Primero explicaré por qué hay una opción para equipos privados y otra para equipos públicos (consulte la figura 1) y le mostraré el diferente comportamiento de estas opciones. El objetivo es permitir que el usuario indique a Exchange el nivel de seguridad necesario; si inicia sesión en OWA desde un quiosco multimedia público de un aeropuerto, por ejemplo, o desde su equipo personal. El administrador de Exchange puede tratar esos tipos de sesión de forma distinta. Por ejemplo, el administrador puede hacer que el tiempo de espera de las sesiones autenticadas sea menor en los equipos públicos (por ejemplo, cuestión de minutos) que en los equipos privados (hasta un máximo de tres días). El administrador también puede configurar otros valores de manera diferente según la selección de usuario. Puede, por ejemplo, establecer que el acceso a las bibliotecas de documentos de SharePoint® y los recursos compartidos de archivos de Windows® sólo sea posible en el inicio de sesión privado. Por supuesto, esto depende de que el usuario especifique la opción correcta. Si los administradores no confían en que los usuarios marquen la opción adecuada, pueden darle a todas las opciones los mismos valores de tiempo de espera y otras opciones de configuración.

Figura 1** Los tipos de sesión de equipo público y privado permiten tener configuraciones de tiempo de espera y otras opciones de configuración diferentes. **(Hacer clic en la imagen para ampliarla)

La opción en cuestión la trasladamos de Exchange 2003, cuando se introdujo la autenticación basada en formularios en OWA por primera vez. (Nota histórica: La primera implementación de la autenticación basada en formularios la diseñó, en parte, un excelente administrador de programas. No revelaré su identidad, pero diré que, más adelante, encontró la fama y la fortuna como autora de una columna bimestral para TechNet Magazine.)

En realidad, la configuración se almacena en el Registro, pero dado que Windows Power­Shell™ cuenta con una interfaz para actualizar el Registro, puede configurar este valor con el Shell de administración de Exchange. En el ejemplo siguiente se establece el tiempo de espera en 1.440 minutos (un día) cuando los usuarios eligen la opción de equipo privado al iniciar sesión:

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

Por supuesto, dado que la configuración está en el Registro, puede actualizar la clave mediante regedit, si así lo desea:

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

De cualquier manera, tendrá que reiniciar IIS para asegurarse de que OWA adopte la nueva configuración. Debería poder hacer esto seleccionando Inicio | Ejecutar y, a continuación, ejecutando iisreset /noforce.

P Animamos a todos los trabajadores a que usen los clientes MAPI de Outlook completos para archivar todos los elementos necesarios que no sean urgentes en archivos de carpetas personales (.pst). Pero, después, los elementos archivados no están disponibles cuando los usuarios inician una sesión en Outlook Web Access desde sus casas. ¿Cómo podemos hacer que estos archivos .pst estén disponibles a través de la interfaz de OWA?

R Lo siento, pero OWA no admite el acceso a archivos .pst. OWA se creó desde cero como un cliente únicamente en línea. Hemos trabajado mucho para asegurarnos de que no dejamos rastros de datos personales en el equipo local. Esto incluye características como el mecanismo de cierre de sesión seguro que se incluyó por primera vez en Exchange 2003 y la Presentación de documentos WebReady en Exchange 2007, que garantiza que las copias en caché de datos adjuntos no se dejan en el disco duro. De modo que el acceso a archivos .pst desde OWA no encaja en nuestro objetivo de un cliente sólo en línea de fácil implementación.

Dicho eso, el uso de .pst en general es un escenario interesante que nos gustaría tratar. El otoño pasado conocimos a un cliente que tenía usuarios con capacidades de buzón de unos 200 MB y casi todos los usuarios tenían, como mínimo, un archivo .pst. Esta organización tenía una directiva que permitía eliminar y reemplazar equipos de usuario con el mínimo esfuerzo, por lo que todos los usuarios tenían que almacenar los archivos .pst en un recurso compartido de red. Ese recurso compartido de red, a su vez, tenía una copia de seguridad en un sistema central.

En primer lugar, el acceso a archivos .pst desde recursos de red compartidos presenta problemas conocidos. Al igual que OWA se diseñó desde el principio para ser un cliente sólo en línea, los archivos .pst se diseñaron originalmente para su almacenamiento local. Por muy buena que sea su red, es susceptible de latencia y otros problemas que pueden complicar el almacenamiento remoto de datos (a los que los usuarios también tengan que obtener acceso de manera simultánea).

En segundo lugar, esta organización tenía lo que llamaríamos una capacidad de buzón bastante pequeña (debo admitir que nosotros tenemos el lujo de un buzón corporativo de unos 2 GB) porque no quería tener todos esos datos en Exchange, ya que tendría que hacerse cargo de realizar copias de seguridad de todos los datos. Aún así, con los usuarios almacenando los datos en archivos .pst en un recurso compartido de red con copia de seguridad, los administradores no se ahorraban ningún trabajo. De hecho, probablemente se creaba más trabajo debido a varios de factores, por ejemplo: falta de almacenamiento de sesión única en varios archivos .pst; costos del departamento de soporte técnico relacionados con problemas de los archivos .pst (tal como contraseñas olvidadas e incongruencia general de la red); dificultad para limpiar los mensajes de los archivos .pst después de un virus; dificultad para encontrar los mensajes de los archivos .pst cuando surge un asunto legal; costo general de mantener un sistema de copia de seguridad diferente; etcétera.

Así que le recomendamos que tenga en cuenta todos los costos que implican sus decisiones de configuración. Es posible que los costos se vayan acumulando y que, al final, sea mejor optar por otra configuración.

P Tengo un problema con un comando del Shell de administración de Exchange. Simplemente no funciona. ¿A qué se puede deber?

R No podemos contestar a esa pregunta, pero sí podemos decirle que para obtener la mejor ayuda posible (dondequiera que esté buscando) debe usar el cmdlet integrado en Windows PowerShell llamado start-transcript para registrar los comandos que está probando y los resultados que obtiene. Esto le permite pegar los detalles exactos en un mensaje de correo electrónico, entrada de blog o pregunta de un foro.

Abra una sesión del Shell de administración de Exchange y escriba start-transcript, tal como se muestra en la figura 2. El Shell de administración de Exchange empezará automáticamente a registrar todos los comandos futuros en un archivo de texto como el que se muestra en la figura 3 (no se preocupe, la aplicación le indicará la ubicación del archivo de texto). Para detener el registro, simplemente escriba stop-transcript.

Figura 2** Use el cmdlet start-transcript para registrar los comandos usados y sus resultados  **(Hacer clic en la imagen para ampliarla)

Figura 3** Windows PowerShell guarda una trascripción de los comandos usados y la almacena en un archivo .txt **(Hacer clic en la imagen para ampliarla)

La lista completa de los comandos usados y sus resultados es de gran ayuda para cualquiera que vaya a solucionar el problema. No obstante, antes de compartir el registro con alguien que no conozca o de quien no se fíe, compruebe que no tiene datos confidenciales.

P Veo que la configuración de Exchange 2007 crea una unidad organizativa (OU) nueva en el dominio raíz. Se llama Grupos de seguridad de Microsoft Exchange y tiene cinco grupos de seguridad de Exchange 2007 nuevos. ¿Estos grupos se pueden trasladar a una unidad organizativa diferente? ¿Y a un dominio diferente?

R Esta pregunta se refiere a los cinco grupos de seguridad universales (USG) que se crean en el dominio raíz durante la fase de preparación de Active Directory. Los grupos en cuestión son:

• Administradores de organización de Exchange
• Administradores de destinatarios de Exchange
• Administradores de sólo visualización de Exchange
• Servidores de Exchange
• ExchangeLegacyInterop

En Exchange 2000 y Exchange 2003, se limitó la capacidad de mover los grupos de seguridad predeterminados (servidores de dominio de Exchange y servidores empresariales de Exchange). Más claramente, se podían mover, pero este proceso estropearía otros aspectos. (Consulte el sitio support.microsoft.com/kb/260914 para obtener más detalles acerca de este problema.) Así que era una opción muy limitada en realidad.

En Exchange 2007, las cosas son diferentes. Se pueden mover los cinco grupos predeterminados. Se pueden mover a una unidad organizativa diferente dentro del mismo dominio o a un dominio diferente.

Si, por alguna razón, "pierde" estos cinco grupos y no sabe dónde los colocó (unidad organizativa o dominio), siempre puede comprobar el valor del atributo otherWellKnownObjects en el contenedor siguiente:

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

Cuando se mueven los grupos, su ubicación se actualiza en este atributo, de manera que siempre puede averiguar dónde se encuentran. ¡Fantástico!

P Encontré un grupo de seguridad global llamado "Servidores de dominio de instalación de Exchange" en mi dominio. ¿Para qué sirve?

R Sin duda, está examinando Active Directory® a fondo. De hecho, habrá un grupo llamado Servidores de dominio de instalación de Exchange en todos los dominios que tengan servidores de Exchange 2007 instalado. Este grupo se crea en la unidad organizativa de objetos de sistema de Microsoft Exchange (MESO). Si examina este grupo, verá que es miembro del grupo de servidores Exchange del dominio raíz, que es un grupo de seguridad universal.

En resumen, Servidores de dominio de instalación de Exchange es un grupo que se usa para arreglar de forma provisional los posibles ciclos de replicación largos de Active Directory si se ejecuta la instalación de Exchange 2007 en uno de los dominios secundarios. Por ejemplo, supongamos que tiene un dominio raíz llamado Root, un dominio secundario llamado Child y un dominio secundario de Child llamado Grandchild. (Lo sabemos, el esquema de denominación es genial. ¿cree que puede adivinar nuestras contraseñas?)

Para empezar a configurar Exchange 2007 en esta organización, primero debe ampliar el esquema y preparar el dominio raíz. Esto crea los cinco grupos de seguridad universales originales que comentamos en la respuesta anterior.

Ahora, por ejemplo, tiene que ejecutar la instalación en el dominio Grandchild. Para poder iniciar los servicios de Exchange 2007 en el dominio local, la instalación coloca una cuenta de equipo del equipo de Exchange 2007 en el grupo Servidores Exchange desde el dominio Root. Ahora se encuentra en el dominio Grandchild, por lo que la pertenencia al grupo Servidores Exchange puede tardar en replicarse.

Servidores Exchange es un grupo universal y su pertenencia se replica en todo el bosque. Dada la potencial latencia de replicación, es posible que la instalación en el dominio Grandchild no inicie los servicios, ya que los permisos no estaban replicados al realizar la instalación. Por eso, la primera vez que se instala un servidor de Exchange 2007 en un dominio, se creará el grupo Servidores de dominio de instalación de Exchange en el dominio local.

La cuenta del equipo de Exchange se colocará como un miembro de ese grupo durante la instalación. Una pertenencia a este grupo proporciona a los servicios los permisos suficientes para iniciarse al final de la instalación, aunque la pertenencia al grupo Servidores Exchange todavía no se haya replicado desde el dominio raíz. Tenga en cuenta que esa replicación local del dominio es, por lo general, más rápida que la replicación entre dominios.

P La documentación de Exchange 2007 dice que debo ejecutar la instalación con el conmutador /PrepareLegacyExchangePermissions, incluso antes de ampliar mi esquema para Exchange 2007. ¿Por qué? (Por cierto, ¿podrían haber asignado un nombre más largo para este conmutador?)

R Nos alegra saber que lee la documentación antes de ejecutar la instalación. ¿Qué le parece?

/PrepareLegacyExchangePermissions (o /pl, abreviado) es un conmutador que, en tantas palabras, otorga a los servicios de actualización de destinatarios (RUS) de Exchange 2000 y Exchange 2003 los permisos para escribir en los conjuntos de propiedades de información personal e información de Exchange. Durante el proceso de ampliación del esquema de Exchange 2007, se mueven varios atributos (como las direcciones proxy) del conjunto de propiedades de información pública de Active Directory al conjunto de propiedades de información de Exchange. De forma predeterminada, los servicios RUS de Exchange 2000 y Exchange 2003 no tienen los derechos necesarios para escribir en el conjunto de propiedades de información de Exchange. En la vida real, esto significa que si ejecuta primero la ampliación del esquema de Exchange 2007, interrumpirá los servicios RUS de Exchange 2000 y Exchange 2003, pues no podrán registrar los destinatarios nuevos. (Si desea obtener más información acerca de esos conjuntos de propiedades, visite nuestro blog en msexchangeteam.com.)

Por lo tanto, es muy importante que ejecute el conmutador /pl antes de ampliar el esquema de Exchange 2007. También debe asegurarse de que este cambio se replica en todos los dominios con destinatarios de Exchange 2000 o Exchange 2003 (existen servicios RUS para esos dominios). Si, más adelante, se agregan dominios nuevos al bosque y necesita colocar los servicios RUS de Exchange 2000 o Exchange 2003 en ellos, deberá ejecutar el conmutador /pl en esos dominios también.

Cuando ejecute un conmutador /pl por primera vez, le resultará mucho más sencillo si lo ejecuta con una cuenta que tenga derechos de administrador de la organización. A continuación, la instalación desde el dominio raíz identificará los dominios que necesitan la ejecución de /pl y ejecutará este conmutador en todos esos dominios. Si no usa una cuenta de administrador de la organización, deberá ejecutar el conmutador /pl con un administrador de dominio para cada dominio por separado. Afortunadamente, la documentación de Exchange 2007 presenta todos los requisitos de permisos.

Por último, nos preguntó si podríamos haber hecho este conmutador más largo. Intente decir /PrepareLegacyExchangePermissions tres veces muy rápido:

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

En un principio, pensamos en usar /PrepareLegacyExchangePermissionsWOWThisIsaReallyLongname, pero al final optamos por /PrepareLegacyExchangePermissions, más corto y más sencillo.

Bueno, eso es un invento; pero siempre puede usar /pl, que es mucho más corto. ¡Le juramos que esta forma es de verdad!

KC Lemson es la administradora de experiencias del usuario para Exchange Server. En su tiempo libre, espera la llegada de mensajes de correo electrónico que le indiquen dónde debe invertir los ahorros para la universidad de sus hijos

Nino Bilicun jefe técnico de Exchange Server, ocupa su tiempo calculando el número de juegos de Halo que puede superar durante una jornada de trabajo típica.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.