Examen analítico finalMigración desde Exchange 5.5
Whitney Roberts
EL PROYECTO
El Departamento de educación de Kentucky necesitaba migrar su implementación de Microsoft® Exchange Server 5.5 actual a Exchange Server 2003. El sistema incluye aproximadamente 600.000 profesores, empleados y estudiantes durante un año escolar.
LOS JUGADORES
El proyecto lo llevó a cabo la Oficina de tecnología educativa (OET) del Departamento de educación de Kentucky con el soporte de consultores de KiZAN Technologies. El personal de OET supervisó la administración de la implementación existente de Exchange 5.5. El personal local de los distritos escolares era el responsable de la ejecución diaria de los servidores Exchange.
LOS DESAFÍOS
El Departamento de educación proporciona instrucciones técnicas a los 178 distritos escolares de la mancomunidad de Kentucky. Estos distritos escolares están conectados entre sí mediante una WAN, pero cada uno cuenta con su propio servidor Exchange 5.5 administrado localmente, que había que actualizar de manera individual. Esta actualización permitiría la compatibilidad con los clientes del modo de caché de Outlook® 2003, una experiencia mejorada de Outlook Web Access (OWA), un esquema de direcciones de correo electrónico estandarizado, etc.
Además de un servidor de correo electrónico y una infraestructura de cliente nuevos, muchos de los distritos escolares querían agregar acceso al correo electrónico para los estudiantes. Tanto la normativa estatal como la federal exigían la protección de la información del estudiante, que no fuese visible fuera del distrito correspondiente.
EL PLAN
Dado que no se podía usar un conector de Active Directory® (ADC), creamos una nueva organización de Exchange y realizamos la migración a ella. La estandarización de direcciones de correo electrónico implicaba la creación de nuevos subdominios de identificación para cada distrito escolar y más de 400 directivas de destinatarios nuevas. La protección de las direcciones de los estudiantes requería la construcción de un sistema de listas globales de direcciones (GAL) y listas personalizadas de direcciones para cada distrito escolar.
La migración real incluía el montaje de hardware nuevo, la creación y configuración de buzones basadas en la pertenencia a un distrito y el tipo de usuario, y el establecimiento de atributos de extensión basado en la pertenencia a un distrito y el tipo de usuario, de manera que el usuario apareciese en la lista de direcciones correspondiente.
Creamos una aplicación basada en Visual Basic® para detectar y corregir los atributos de cuenta o las pertenencias a grupos mal configurados y para asignar buzones nuevos correctamente para asegurar que se mantenían los requisitos de visibilidad. La aplicación se implementó en los 178 distritos y se ejecuta según una programación desde todos los servidores del distrito escolar.
Información previa
Desde fuera, no parece un trabajo difícil técnicamente o que pueda suponer un reto. Sin embargo, tal como se me ha recordado humildemente, los requisitos empresariales mandan, y los de este proyecto fueron reveladores.
A lo largo de los años, una administración descentralizada y un revoltijo de estándares crearon varios "silos" de soporte que, la mayoría de las veces, tenía que administrar la OET. Además, la OET también tuvo que comprobar si la implementación de Exchange 5.5 satisfacía los requisitos de los distritos escolares y el Departamento de educación al mismo tiempo. De esta manera, en los distritos que usaban el correo electrónico de estudiantes, la información del estudiante estaba protegida y no era visible fuera del distrito correspondiente, tal como exigían las directrices estatales y federales (consulte ed.gov/policy/gen/guid/fpco/ferpa/index.html).
En Exchange 5.5, estas directrices implicaban que la información de los estudiantes del distrito no podía replicarse en los demás distritos escolares ni en otras agencias estatales que compartiesen datos de la lista GAL. Específicamente, tenía que pasar por un proceso de exportación/importación manual para cada uno de los 178 sitios de Exchange 5.5: ocultar los estudiantes, replicar la lista, mostrar los estudiantes y, por último, volver a importar la lista de direcciones. De esta manera, los demás distritos podían ver únicamente los datos del personal y el distrito escolar correspondiente podía ver todos sus datos, pero sólo los datos del personal de los otros distritos escolares.
Dados los puntos fuertes y débiles del sistema existente, la actualización de la infraestructura de mensajería debía satisfacer algunos criterios específicos. En primer lugar, el Departamento de educación de Kentucky quería estandarizar un esquema de denominación SMTP común y legible para toda la empresa. El esquema tenía que proporcionar espacio de direcciones SMTP separados para el personal docente y los estudiantes.
El nuevo sistema también tenía que proporcionar un servicio administrado centralmente que eliminase la responsabilidad y la administración de mensajería para que estuviese disponible desde el distrito. Esto significaba una administración centralizada de la recuperación de desastres, el flujo de correo y la resolución de llamadas al departamento de soporte. Como tal, el nuevo sistema tenía que proporcionar un método centralizado para estandarizar la configuración del usuario en todos los distritos, independientemente de la ubicación geográfica o la pertenencia a un distrito de un usuario determinado.
Además, el nuevo sistema debía ofrecer un acceso seguro a dispositivos móviles y basado en Web al correo electrónico en un espacio de nombres común y unificado para todos los distritos.
Dados estos requisitos, muchos de los cuales todavía no estaban implementados en el sistema Exchange 5.5 existente, la actualización a Exchange 2003 era bastante intimidante.
Bloques de creación de soluciones
Para satisfacer los requisitos empresariales, se optó por varias opciones específicas de Exchange para la implementación.
Debido a la falta de estandarización y a la magnitud del entorno de Exchange 5.5, no se pudo usar un ADC. En su lugar, creamos una organización de Exchange y realizamos la migración a ella.
La limpieza y estandarización de las direcciones de correo electrónico del personal y los estudiantes de cada distrito llevó a la creación de más 400 directivas de destinatarios nuevas. Los requisitos exigían un subdominio de identificación único para cada distrito, incluida una designación de distrito identificadora para los estudiantes. Por ejemplo, en el caso del condado de Shelby, el subdominio principal sería shelby.kyschools.us. Los estudiantes de cada distrito reciben una designación de subdominio stu., por lo que los estudiantes del condado de Shelby podrían tener direcciones stu.shelby.kyschools.us.
Otra de las limitaciones era que las direcciones de los estudiantes fuesen visibles únicamente en el distrito del estudiante y las direcciones del personal, en todos los distritos. Para que esto fuese posible, tuvimos que crear un sistema elaborado de listas GAL y listas personalizadas de direcciones, tal como se muestra en la figura 1 y la figura 2. El traslado a Exchange 2003 nos permitió proteger las listas de direcciones con permisos y controlar el acceso a cada lista de direcciones individual mediante la pertenencia a grupos. Usamos esta característica para crear dos grupos de seguridad por distrito (uno para el personal y otro para los estudiantes) y, a continuación, protegimos las listas de direcciones y GAL correspondientes al personal y los alumnos para que sólo las cuentas de usuario de un distrito específico tuviesen acceso a determinadas listas de direcciones. Al eliminar las listas de direcciones y GAL predeterminadas y, después, asegurarnos de que los grupos Todos y Usuarios autenticados no estaban incluidos en la lista de control de acceso (ACL) de cada lista de direcciones, pudimos realizar una selección previa de la lista de direcciones que un tipo específico de usuarios vería en un distrito específico.
Figura 1** Listas personalizadas de direcciones basadas en funciones **(Hacer clic en la imagen para ampliarla)
Sin embargo, los permisos sólo resolvieron una parte del problema de visibilidad. Tuvimos que buscar una manera de controlar quién era visible y en qué lista de direcciones. Creamos una consulta LDAP (Protocolo ligero de acceso a directorios) base que nos permitía consultar la visibilidad del personal y los estudiantes; a continuación, adaptamos ligeramente la consulta para cada lista de direcciones y GAL. Por ejemplo, la consulta LDAP para la lista GAL de personal de Shelby sólo mostraría el personal y los estudiantes de Shelby y todo el personal (pero no los estudiantes) de cada distrito del estado. La lista GAL de estudiantes de Shelby sólo mostraría el personal y los estudiantes de Shelby, no mostraría el personal ni los estudiantes de otros distritos del estado. Repetimos esta consulta en todos los distritos de la organización. En la figura 3 se muestran ejemplos de algunas consultas LDAP usadas en esta migración compleja.
Figure 3 Consultas LDAP en la lista de direcciones
Consulta LDAP en la lista GAL de personal
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Consulta LDAP en la lista de direcciones del distrito
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
Consulta LDAP en la lista de direcciones de estudiantes del distrito
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
Consulta LDAP en la lista de direcciones sin conexión de personal del distrito
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Figura 2** Listas globales de direcciones que separan el personal de los estudiantes **(Hacer clic en la imagen para ampliarla)
Los valores personalizados para las propiedades de usuario de Exchange extensionAttribute14 y extensionAttribute15 fueron los mecanismos de distinción entre las consultas LDAP. Todos los estudiantes y el personal del estado usaron un valor específico en extensionAttribute14 para designar el tipo de usuario y un valor único en extensionAttribute15 para mostrar la pertenencia a un distrito. Al usar valores únicos para cada distrito y los mismos valores para cada tipo de usuario, las listas de direcciones mostraban exactamente la información necesaria para cada tipo de usuario de cada distrito.
Estas listas de direcciones funcionaron bastante bien para los usuarios que tenían acceso al correo electrónico a través de Outlook en modo sin caché o a través de OWA. Dirigimos cada uno de los usuarios a la lista de direcciones adecuada de OWA mediante el atributo msExchQueryBaseDN. Sin embargo, los usuarios que ejecutaban Outlook en modo de caché presentaban otro problema. Outlook no acepta una lista GAL personalizada como Libreta de direcciones sin conexión (OAB) designada, por lo que tuvimos que crear listas de direcciones adicionales que eran duplicados de las listas GAL. Después, configuramos todos los almacenes del buzón del distrito con la lista de direcciones OAB adecuada para sus usuarios en modo de caché. Con todo, esta solución llegó a un tope de 1.500 listas de direcciones para proporcionar todas las funciones a los diferentes tipos de usuarios de los 178 distritos.
Garantía de conformidad
Para garantizar que la estructura que se iba a implantar funcionaría correctamente, era primordial el cumplimiento de los estándares recién establecidos. Había varias tareas de alto nivel que tenían que efectuarse en cada usuario habilitado para Exchange de la organización. El motivo de esto es que todos los usuarios tienen que estar ubicados correctamente en todos los servidores Exchange del distrito, así como ser visibles en las listas de direcciones apropiadas.
El usuario tenía que ser un miembro del grupo de seguridad correspondiente del dominio del distrito, ya que el grupo de seguridad es el encargado de otorgar permisos para abrir la lista de direcciones adecuada. Además, debía tener el atributo msExchQuerybaseDN establecido correctamente de acuerdo con su distrito y pertenencia a una unidad organizativa (OU). La OU del usuario determinaba el tipo de usuario.
El próximo paso era crear el buzón del usuario en el almacén correcto del servidor adecuado, en función de la pertenencia a un distrito y el tipo de usuario. Estos requisitos repercutían en los niveles de servicio, los límites de tamaño del buzón y las listas de direcciones de la libreta de direcciones sin conexiones para que el modo de caché de Outlook funcionase correctamente. Los atributos de extensión se establecieron de acuerdo con la pertenencia a un distrito y el tipo de usuario para que el usuario se mostrase en las listas de direcciones adecuadas y no fuese visible en las otras.
Por último, teníamos que facilitar una manera de corregir automáticamente los atributos de la cuenta o las pertenencias a grupos en el caso de que estuviesen mal configurados (o modificados) en valores inadecuados. Si un usuario pasa de una unidad organizativa a otra dentro del dominio del distrito, la clasificación del usuario cambia, y la ubicación del buzón, la selección de la lista GAL y la visibilidad en la lista de direcciones deben actualizarse.
Teníamos que ofrecer un sistema que efectuase estas tareas y garantizase la coherencia y la precisión de Active Directory. Creamos una aplicación de consola basada en Visual Basic que se ejecuta según una programación desde los servidores Exchange 2003 del distrito escolar. La aplicación, que comprueba el cumplimiento de directivas y estándares, además de controlar la creación y el suministro de objetos nuevos, se implementó en los 178 distritos.
Las tareas que teníamos al alcance nos parecían demasiado complejas para ejecutar de manera rápida y confiable un conjunto de secuencias de comandos . La aplicación basada en Visual Basic pareció ser la solución adecuada, ya que era eficaz, proporcionaba un soporte estructurado para el control de errores y excepciones y su código interno era fácil de adaptar al código de extensión de Microsoft Identity Integration Server (MIIS) con una reescritura mínima.
Dado que estábamos realizando la migración a una organización nueva, era necesario encontrar algún método de coexistencia. Había más de 178 dominios SMTP heredados que debían ser compatibles con el nuevo entorno, algunos distritos ya tenían dominios de correo electrónico para los estudiantes, y otros no, pero tuvimos la suerte de poder migrar los distritos uno por uno y pasar sus direcciones y mensajes heredados al nuevo sistema sin tocar los otros distritos. No obstante, teníamos que evitar la interrupción del flujo de correo electrónico durante la migración en un distrito de Exchange 5.5 a Exchange 2003. Para ello, era necesario algún tipo de sincronización de directorios entre el directorio Active Directory de Exchange 2003 y el directorio heredado de Exchange 5.5. Microsoft concedió al Departamento de educación de Kentucky un uso limitado de MIIS sólo para el período que durase la migración, por lo que el código de extensión personalizado se desarrolló y se usó para sincronizar las organizaciones de Exchange mediante MIIS antes, durante y después de la migración.
Naturalmente, el traslado a una nueva organización de Exchange afecta a la configuración del cliente MAPI. El Departamento de educación se encontró con la realidad de, literalmente, decenas de miles de perfiles MAPI por distrito que tenían que volver a configurarse durante la migración. Afortunadamente, Microsoft lanzó al mercado la herramienta para actualización de perfiles de Exchange (ExProfRe.exe), de la cual hicimos uso para la migración de perfiles en los distritos. Creamos un instalador de paquetes que ejecutaba ExProfRe.exe con valores cargados previamente para que la migración de perfiles por distrito se realizase de manera automatizada. El programa se invocaba mediante una directiva de grupo. La migración de perfiles automatizada entre organizaciones tuvo casi un 100% de éxito.
Actualizaciones de hardware
Los nuevos servidores Exchange 2003 iban a sustituir a los servidores Exchange 5.5 dispersos geográficamente, por lo que el aspecto de hardware de esta solución tenía que admitir la misma cantidad de usuarios que la implementación de Exchange 5.5, además de la carga de las cuentas de estudiantes adicionales. Los servidores tendrían que alojarse localmente en el distrito, pues la topología WAN estaba diseñada de manera que todo el tráfico entre distritos (de Internet e interno) fluyese por una línea T1 privada (en algunos distritos, varias líneas T1).
Debido a limitaciones presupuestarias, de administración y de alojamiento de equipos, los servidores Exchange no tendrían almacenamiento conectado a una red de área de almacenamiento (SAN), de manera que todo el almacenamiento tendría que ser interno o de conexión directa. Puesto que la mayoría de los distritos no tienen centros de datos con almacenamiento en bastidor ni refrigeración centralizada, los servidores tenían que ser lo más independientes posible. Afortunadamente, la mayoría de los distritos tenían menos de 5.000 usuarios, lo que permitía realizar implementaciones de un solo servidor. En los distritos que tenían más usuarios, se usaron servidores más eficaces (o varios servidores) y almacenamiento adicional, a veces con servidores de aplicaciones independientes para separar más el tráfico del personal del de los estudiantes.
En la mayoría de los distritos, pudimos implementar servidores de procesador dual bien equipados que estaban configurados con una cantidad máxima de unidades Ultra320 SCSI a 15.000 RPM, varios controladores RAID y 4 GB de RAM. Los distritos más grandes tenían uno o más servidores de procesador quad, que usan servidores de aplicaciones más pequeños si es necesario. Las pruebas de referencia y rendimiento previas a la implementación no mostraron problemas de uso ni de carga. No obstante, los diferentes grados de patrones de uso locales serían el factor determinante en el rendimiento general del servidor.
Prueba de concepto
A pesar de que el entorno de producción incluye un bosque de Active Directory de 178 dominios, el laboratorio de prueba de concepto (POC) se redujo a 13 dominios de distrito y un dominio raíz vacío. Todos los dominios de prueba se llenaron con exportaciones de los dominios de producción. Los servidores Virtual Exchange 5.5 se crearon y configuraron con copias de las bases de datos de los distritos seleccionados, de manera que pudiésemos comprobar el proceso de migración y la adición del entorno planeado. Todo el laboratorio de pruebas POC se construyó con máquinas virtuales para permitir la creación de líneas de referencia del entorno, poder bloquearlo y, a continuación, volver a implementarlo cuando fuera necesario.
Se diseñaron, codificaron, probaron y finalizaron varias combinaciones de secuencias de comandos (mediante VBScript), paquetes del instalador de Systems Management Server (SMS) y aplicaciones de consola. Por último, hicimos que las secuencias de comandos realizasen la instalación y configuración inicial de Exchange 2003, incluidas las directivas de destinatarios, las listas personalizadas de direcciones y las GAL y los permisos. Las secuencias de comandos también administraron la configuración del grupo administrativo, la configuración de dominios del distrito (creación de grupos de seguridad y delegación de permisos) y la configuración posterior a la implementación para la migración.
El almacenamiento provisional de los servidores Exchange 2003 fue un desafío importante. Teníamos que instalar todos los servidores Exchange correctamente en los 178 dominios sin poner en peligro el resto de la migración. Exchange 2003 se diferencia de Exchange 2000 en que el grupo de servidores de dominio Exchange específico del dominio no se agrega a la lista ACL de la organización hasta que se instala el primer servidor Exchange 2003 en el dominio. En Exchange 2000, el grupo se agrega al ejecutar el proceso DomainPrep. Para asegurarnos que teníamos todos los grupos de seguridad necesarios incluidos en el objeto de organización de Active Directory, tuvimos que instalarlo en un dominio determinado, replicar Active Directory manualmente desde el dominio en el concentrador de replicaciones de Active Directory y, a continuación, pasar esta replicación al siguiente distrito para su instalación. La instalación en el siguiente distrito no se pudo comenzar de forma segura hasta que se confirmó que la lista ACL del objeto de organización tenía el grupo de servidores de dominio Exchange del distrito anterior. Si este proceso se completaba sin seguir un orden ni en un solo dominio, tendría que volver a realizarse la instalación en dicho distrito (como mínimo) u otros distritos no podrían comunicarse entre ellos debido a una lista ACL del objeto de organización que no incluía el resto de distritos correctamente.
Comprobamos la implementación, la configuración, el almacenamiento en servidores y la migración varias veces, hasta que estuvimos seguros de que el proceso funcionaba correctamente en el entorno POC.
La migración y otros quebraderos
Una vez que el equipo del proyecto aprobó los procedimientos y los resultados de la POC, la migración estaba lista para empezar. La OET decidió realizar primero su migración, para poder observar el proceso y sus consecuencias de primera mano. En el momento de la migración, ya habían almacenado todos los servidores y se había verificado el entorno inicial. Todos los servidores del protocolo de aplicaciones y los servidores de buzones estaban en su sitio y listos para pasar al entorno de producción con los usuarios.
La ejecución del plan de migración se realizó correctamente y, después de 21 largas horas de transferencia de contenido de un servidor a otro, la OET tenía en marcha Exchange 2003. Afortunadamente, no hubo problemas importantes en la migración de perfiles de Outlook de Exchange 5.5 a Exchange 2003. Empaquetamos un archivo por lotes que invocaba a ExProfRe.exe en diferentes configuraciones de acuerdo con una lógica simple. A continuación, distribuimos el archivo por lotes y ExProfRe.exe en el recurso compartido Netlogon de un controlador de dominio (DC) de cada distrito y usamos la directiva de grupo para ejecutar el lote en todos los clientes al final de la migración. Esta operación funcionó correctamente en la OET, por lo que estábamos seguros de que el proceso avanzaría.
En este punto, revisamos y volvimos a aprobar el plan de migración según nuestra experiencia en la implementación en la OET. Siguiendo con la migración, elegimos seis distritos como primeros sitios de producción. Antes de migrar cada uno de los distritos, MIIS leía la información más reciente sobre los buzones del distrito de Exchange 5.5 y actualizaba los usuarios correspondientes en el dominio del distrito. Usamos el Asistente para migración de Exchange (Mailmig.exe) para trasladar los datos de los buzones entre organizaciones. Mientras el asistente trasladaba los datos de los buzones, se extrajeron y actualizaron todas las direcciones proxy a partir de lo que MIIS exportó originalmente a Active Directory. Durante la migración, el correo se puso en cola en los servidores SMTP de aplicaciones y, después, se entregó al distrito, cuando la migración, la configuración del servidor posterior a la migración y la comprobación de usuarios hubieron concluido; el distrito estaba preparado para realizar una migración de clientes a gran escala mediante ExProfRe.exe.
Problemas con el servicio RUS
Para que los clientes de Outlook funcionasen correctamente, era necesario asegurarse de que la solución de suministro fuese la máxima autoridad en establecer valores de atributos. También era necesario que el Servicio de actualización de destinatarios (RUS) terminase el trabajo, por decirlo de alguna manera, en la configuración de la cuenta. No obstante, el servicio RUS sólo debía ejecutarse cuando el suministro hubiese terminado. Para conseguir esto, las programaciones de las instancias del RUS para los distritos (los 178) se establecieron en Nunca y la solución de suministro usó un código que activase el servicio RUS para su inicio tras la finalización del suministro.
La mayoría de los distritos tenía menos de 5.000 usuarios y muchas menos actualizaciones diarias, así que el servicio RUS terminó rápido, pues el sistema de suministro inició una actualización en lugar de una reconstrucción al final de su ejecución diaria. Pero había varios distritos con más de 10.000 usuarios. Las actualizaciones en estos entornos requerían más tiempo y, si era necesaria una reconstrucción completa del servicio RUS en estos dominios de gran tamaño, podía estar ejecutándose durante una semana o más. Dado que el servicio RUS evalúa todos los tipos de objetos cuando se ejecuta, el efecto de una reconstrucción en un dominio tan grande sería menguante.
No conseguimos encontrar una estrategia de mitigación (y eso que trabajamos con miembros del grupo de productos Exchange para intentar obtener una solución), pero mejoramos el código de suministro para administrar gran parte de las tareas que suele realizar el servicio RUS. Los usuarios obtienen atributos showInAddressBook y proxyAddresses completados en el suministro inicial, de manera que pueden registrarse inmediatamente en lugar de esperar a que el servicio RUS termine su trabajo. También creamos una tarea manual que se ejecuta en uno de los servidores del protocolo de aplicaciones de Exchange 2003. Esta tarea realiza una importación LDIFDE programada y borra las direcciones gatewayProxy del servicio RUS, de manera que si se aplica accidentalmente una directiva de destinatario en el entorno, no se agrega a la lista de tareas pendientes de cada servicio RUS de la empresa.
Problemas de categorizador
Uno de los aspectos interesantes de impedir que los datos de los estudiantes saliesen fuera del distrito escolar era la implementación de controles para evitar que los usuarios enviasen mensajes de correo electrónico fuera de su distrito o a direcciones de Internet externas del sistema. En lugar de trabajar mediante un sistema elaborado de conectores y elementos relacionados, decidimos implementar una característica menos conocida de Exchange 2003 y aplicar restricciones de conector en el conector de grupo de enrutamiento existente desde el distrito al concentrador central donde residen los servidores del protocolo de aplicaciones. Se crearon dos grupos de seguridad en cada dominio, uno para el personal y otro para los estudiantes, y se agregaron a las restricciones del conector.
Tras habilitar la comprobación de restricciones de conector en el registro, empezamos a apreciar algunos problemas que afectaban al rendimiento. Los mensajes se atascaban en el categorizador y las colas de entrega locales durante horas, incluso en el caso de los mensajes dirigidos a destinatarios del mismo servidor. Estos problemas empeoraron a medida que se migraban distritos adicionales. Como solución a corto plazo, desactivamos la comprobación de restricciones de conector y el rendimiento de la entrega de correo mejoró. Más tarde, descubrimos que el categorizador no estaba comprobando únicamente la pertenencia a grupos de los dos grupos de su dominio tras el envío del mensaje, si no también la pertenencia a grupos de los mismos dos grupos en los otros 177 dominios. Esta operación la repetía con todos los mensajes entrantes y salientes del servidor.
Posteriormente, abrimos un caso de soporte en Microsoft. Tras su evaluación, Microsoft se encuentra en proceso de generar una revisión para mitigar este problema y permitir que el categorizador funcione en un modo de complejidad de topología reducida. Actualmente, no disponemos de más detalles sobre dicha revisión, pero el objetivo es proporcionar un valor que permita al categorizador realizar determinadas suposiciones sobre la topología de enrutamiento y que no compruebe la pertenencia a grupos en todos los conectores.
Lecciones aprendidas
Si hay algo que he aprendido en este proyecto, es que los requisitos empresariales controlan todo nuestro trabajo como consultores. En muchas ocasiones, tuvimos que valorar la viabilidad de los requisitos empresariales en comparación con la complejidad de la solución. En esta columna he descrito las decisiones y opciones que me parecieron más apropiadas para nuestro entorno (incluidos los elementos que no he podido comentar aquí), nuestros recursos y nuestros requisitos empresariales. Es posible que para usted las decisiones sean diferentes, aunque espero que esta columna le haya hecho reflexionar sobre ciertos aspectos. Afortunadamente, Exchange 2003 y Active Directory nos proporcionaron la suficiente flexibilidad para satisfacer todos los requisitos de esta compleja migración. Una vez superada la increíble magnitud de la implementación del Departamento de educación de Kentucky, la solución es bastante más simple y se basa en características, a mi parecer, poco usadas de Active Directory y Exchange 2003.
La segunda gran lección ha sido la puesta en práctica de un enfoque equilibrado de la solución de problemas y la administración de riesgos/problemas. En algunas ocasiones es preferible una solución de problemas local, mientras que en otras son necesarios los recursos avanzados de los servicios de soporte técnico de Microsoft.
Mirando hacia el futuro
No cabe duda de que el entorno del Departamento de educación de Kentucky es único. Durante el curso de esta implementación, se usaron o personalizaron casi todas las características de Exchange para satisfacer los requisitos del departamento. Ahora que se ha implementado y migrado correctamente todo el entorno, está preparada la base para implementar funciones adicionales. El Departamento de educación ya ha visto el interés de los distritos escolares en la plataforma Windows Mobile® y espera que esta tendencia hacia los dispositivos móviles continúe.
La consolidación de servidores puede agregar un valor significativo. Actualmente, el Departamento de educación de Kentucky está pensando en virtualizar algunos aspectos del entorno de Active Directory. Con Exchange 2007 en el horizonte, el departamento ha empezado a considerar los requisitos necesarios para una actualización de los sistemas de mensajería.
El Departamento de educación de Kentucky también está buscando ofertas de colaboración adicionales en Live Communication Server, Live Meeting Server, etc. Actualmente, Microsoft Operations Manager 2005 también se está implementando para la administración y supervisión de los servidores de Exchange y Active Directory.
Los resultados
Todos los niños del sistema escolar público de Kentucky disfrutarán de la calidad y la presencia de esta implementación, incluidos mis hijos y los hijos de otras personas con las que he trabajo en este proyecto. Esta implementación ha animado al Departamento de educación de Kentucky a avanzar en lo que se refiere a tecnología, de manera segura y estandarizada, más que nunca. Me siento orgulloso de haber formado parte de este proyecto.
Whitney Roberts es un consultor principal de KiZAN Technologies (www.kizan.com) y trabaja con Exchange desde la versión de Exchange 4.0.
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.