Una migración «sencillita» a Office 365

Para migrar a Office 365 con garantías hay que acudir a un partner que tenga técnicos especialistas en las diferentes materias implicadas.

Puede que todo vaya sobre ruedas, pero a veces las cosas se complican.

Como lo mejor es un ejemplo, a continuación recogemos algunas de las acciones que hemos tenido que realizar en este proyecto aparentemente sencillo para que la migración pudiera completarse:

• La revisión inicial de la infraestructura detectó un problema de replicación de los controladores de dominio, a nivel de base de datos del Directorio Activo, que hubo que corregir.
• Otro análisis de los registros de eventos detectó a su vez problemas de replicación a nivel de carpeta SYSVOL. Hubo que poner en marcha dos procedimientos distintos para designar una de las réplicas como copia autoritativa a nivel de DFS, y para reanudar el funcionamiento de esa réplica autoritativa.
• Como el cliente había dado de alta por su cuenta un tenant de Office 365 antes del proyecto, hubo que desarrollar un script de powershell para desasignar todas las licencias del plan a cada usuario, excepto la de Office de escritorio, que ya estaban utilizando.
• Como los usuarios habían sido creados manualmente en O365 antes de empezar el proyecto, pero con UPN interno solamente, fue necesario cambiarlo por powershell para que cuando se hiciera la sincronización con AADConnect no se duplicasen los usuarios.
• El UPN de las cuentas en AD no era enrutable, por lo que se añadió el sufijo UPN correcto al AD y se realizó un script de Powershell para cambiar de forma masiva el atributo en todos los objetos.
• A la hora de configurar el AADConnect para la sincronización del Directorio Activo local con el Azure AD, fue necesario establecer un filtro en los conectores para que se excluyeran de la sincronización los objetos que en el AD local estaban deshabilitados, ya que es política de la empresa no borrar los objetos y generaban muchísimos usuarios en Office 365, complicando la administración.
• En algunos casos la migración automática falló y hubo que hacer rollback, modificando manualmente el atributo TargetAddress de la cuenta de usuario en el Directorio Activo con ADSIEdit.
• Inicialmente algunos lotes de migración daban timeouts y errores. Parte del diagnóstico implicó analizar a bajo nivel los log de migración, adaptando procedimientos de Exchange Server al Powershell de Office 365.
• Para ese diagnóstico también fue necesario hacer un análisis de rendimiento del servidor de Exchange, activando un mayor nivel de registro y monitorizando los contadores de rendimiento relacionados con el componente RPC Proxy.
• Hubo que investigar y cambiar en el firewall diversos parámetros, como el TCPMAXSessions y una opción que hacía drop de los paquetes con número de secuencia fuera de un determinado rango, pues estaban causando problemas según vimos en los log.
• Hubo que actualizar Exchange Server al último Update Rollup para solventar un problema de reintentos múltiples al exportar buzones, lo que implicó parada del servicio temporal y un cierto riesgo.
• Hubo que poner en marcha el autodiscover basado en registros SRV, ya que no estaba configurado inicialmente y el certificado usado no era el adecuado.
• Hubo que modificar la configuración de Outlook Anywhere en Exchange, ya que era parcialmente incorrecta. Esto incluyó cambiar claves de registro para RCP Proxy en el Exchange y las correspondientes en los DC del bosque.
• Hubo que corregir una configuración incompleta de los directorios virtuales de Exchange.
• Hubo que corregir una configuración de las tarjetas de red del servidor de Exchange, que al estar más de una tarjeta en la misma subred con diferentes funciones, provocaba problemas intermitentes en el Proxy RPC de Outlook Anywhere.
• Se encontró un problema de enrutamiento del correo, por el que los usuarios no migrados veían rechazados sus correos a los ya migrados. Para solucionar el problema, hubo que resolver un nuevo episodio de problemas de replicación del AD, que a su vez estaba provocado por un registro incorrecto de las direcciones IP de los DC en los DNS que hubo que descubrir y arreglar.
• El problema anterior se había agravado porque la libreta de direcciones sin conexión (OAB) de Exchange se generaba correctamente pero no se publicaba, ya que estaba configurada para hacerlo mediante carpetas públicas solamente y el almacén de carpetas públicas se encontraba desactivado, situación que hubo que corregir.
• Con dos usuarios se produjo un problema de sincronización del Azure AD que impedía la migración del buzón, que hubo que corregir eliminando con ADSI Edit el GUID del buzón de Exchange en el AD local, forzando una sincronización el AADConnect, modificando manualmente el atributo TargetAddress en AD y lanzando dos scripts de powershell para convertir el buzón antiguo en usuario habilitado para correo y que se poblaran los atributos adecuados de la cuenta del Azure AD, como el LegacyExchangeDN.

Además, en este cliente no hizo falta porque ya estaba instalada, pero en otros casos hay que desarrollar una estrategia para la distribución de la suite ofimática de Office 365, lo que generalmente implica la creación de un punto de instalación administrativo y la modificación de ficheros XML que controlan el proceso de instalación y actualización, además de scripts o tareas de SCCM para su instalación. Tampoco en este caso el cambio de UPN de los usuarios del Directorio Activo tenía consecuencias, pero hace poco nos encontramos un caso donde hubo que modificar una aplicación que se conectaba al AD para que funcionase. Tampoco hubo grandes problemas a nivel de red, pero no es extraño tener que sacar un sniffer para comprobar a bajo nivel lo que está provocando problemas de conectividad a Office 365.

En nuestra opinión, este ejemplo demuestra que para poder llevar a cabo con garantías un proyecto de migración de correo a Office 365, el equipo debe tener como mínimo conocimientos técnicos suficientes en:

• Directorio Activo
• DNS
• Exchange Server (o el sistema de origen equivalente)
• PowerShell
• Networking básico

Y aquí sólo estamos hablando de conocimientos técnicos, pero para afrontar correctamente un proyecto de migración hay que tener experiencia en las áreas de comunicación, coordinación, gestión del cambio, gestión de las expectativas de usuario, formación, etc., que no todas las empresas tienen.

¿Y qué pasa con el soporte de Microsoft? ¿No pueden ellos ayudar con estos problemas?

La teoría es que sí, pero la práctica nos dice que su acción es muy limitada. En parte porque estás a expensas del técnico que te toque, que como en todos sitios hay buenos y malos. Pero también porque, si miráis las acciones que hemos tenido que hacer en el cliente, parece complicado que a distancia y sin conocer el entorno del cliente pudieran haber encontrado solución de un modo eficaz. En nuestra experiencia, el soporte sirve para solucionar los problemas más típicos y obvios, pero no va mucho más allá y ralentiza todo.

La conclusión evidente, al menos para nosotros, es que es imprescindible contar con un partner que sepa lo que hace, y tenga experiencia con estos proyectos. Lógicamente esta cualificación hay que pagarla, por lo que en principio habría que desconfiar de los “partner” demasiado baratos.

Además en muchos casos Microsoft subvenciona el proyecto de migración a Office 365, por lo que contar con un partner de calidad no implica coste para el cliente.

En fin, esta es nuestra experiencia. ¿Y la vuestra? Podéis dejar vuestra opinión en los comentarios más abajo.