Migración de Exchange 2010 a Office 365 con ADFS

Question

Permítanme comenzar explicando nuestro entorno.

Tenemos un dominio AD: de***.co.uk

Independientemente del departamento en el que se encuentre un usuario, cada usuario se autentica en todos los sistemas (incluido el intercambio) utilizando su cuenta de dominio (user@de***.co.uk) o (de***\user), incluso si su dirección de correo electrónico es[correo electrónico protegido](esto es común, lo sé)

Estamos planeando pasar gradualmente a Office 365 E3, un departamento a la vez. Tenemos ~300 empleados, 47 dominios de correo electrónico aceptados y >600 buzones de correo (algunos de los cuales pueden archivarse en pst localmente). En TI hemos probado 365 E3 con un dominio de nuestra propiedad de***s****.co.uk y hemos configurado usuarios/buzones de correo manualmente

Ahora estamos listos para mover un departamento a la prueba 365 (20 usuarios); sin embargo, nos gustaría vincularlo con nuestro AD local. Este subconjunto de usuarios tendrá un dominio de dirección de correo electrónico @le**********.com

Por lo que he recopilado, creo que estos son los pasos que tendré que realizar (corríjanme si me equivoco)

• Configurar ADFS
• Agregue el dominio @le************.com a nuestra cuenta 365 ******** (no estoy seguro de cómo atraería a los usuarios) *********
• Cambie los registros DNS de le***********.com para que apunten a Office 365
• ¿Importar pst de cada usuario a su cuenta 365 o cualquier otro método?

Es la parte de ADFS la que está causando confusión. Hasta ahora he leído varios tutoriales que tratan las cosas de manera diferente (uno dice instalar ADFS en un DC, otro dice configurar 3 servidores nuevos: un proxy ADFS, un servidor ADFS y un servidor DirSync) - ¿cuál es el mejor?

Durante la configuración de ADFS, se dice que se necesita un certificado SSL para instalarlo en IIS. ¿Este certificado sería hostname.de***.co.uk o hostname@le*********.com? ¿Y cada uno aceptó un dominio de correo electrónico que necesitaba su propio SSL?

¿Se verían afectados por este proceso los demás usuarios que residen en el intercambio local?

Saludos

Answer 1

Según la información que ha proporcionado, estos son los mejores escenarios para continuar.

Autenticacion de usuario: hay 3 modelos con los que puedes trabajar aquí, que son:

1. Usuarios en Office 365 (Cuentas en la nube): la gestión de usuarios se realizará íntegramente en la nube. Puede crear usuarios, deshabilitar, restablecer contraseñas y configurar todas las configuraciones usando el portal de Office 365, no necesita un AD local para esto, obviamente esta opción no funcionará con su entorno ya que ya tiene un AD local con Exchange y desea mantener la administración de usuarios controlada localmente en AD.
2. Usuarios en AD, con sincronización unidireccional con Office 365 (Cuentas semifederadas): este módulo le permitirá crear cuentas y realizar toda la administración de usuarios en sus servidores AD locales, instalará una herramienta llamada "DirSync" o la versión más reciente "ADD Sync" para crear una copia de los usuarios de su AD local a la nube, las herramientas tienen la opción de sincronizar también las contraseñas de las cuentas de usuario desde AD local a la nube, lo que permitirá a sus usuarios iniciar sesión en los recursos locales en el dominio y en Office 365 usando las mismas credenciales de usuario, creando una experiencia semi-SSO, los usuarios deberán proporcionar su nombre de usuario y contraseña cuando accedan a los recursos en Office 365 y la autenticación/verificación del usuario se realizará en el lado de la nube. Los requisitos para este módulo son instalar las herramientas mencionadas anteriormente en cualquier servidor de su red local, no necesita ADFS o ADFS Proxy, debe optar por esta opción ya que es la más fácil de implementar y soportar.
3. Usuarios en AD, con sincronización bidireccional con Office 365 (Cuentas federadas completas): esta es la opción más avanzada de las tres, esta opción utiliza toda la configuración de la opción anterior "Usuarios en AD con sincronización unidireccional con Office 365" además agrega la capacidad de forzar que la autenticación/verificación del usuario se realice en su AD local servidores que usan ADFS y un servidor proxy ADFS, necesitará tener una implementación de proxy ADFS/ADFS y AAD Sync ya sea en su red local o en una red híbrida de Azure, obtendrá una experiencia SSO completa con esta opción como usuarios en el dominio. podrá acceder a Office 365 sin la necesidad de proporcionar un nombre de usuario y contraseña, no recomendaría elegir esta opción ya que instalarla, configurarla y brindar soporte es una historia de terror de TI.

Tiene toneladas de información para leer aquí para obtener más referencias:https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

Migración de correo electrónico: dado que tiene Exchange 2010 en la red, estas son las formas compatibles para migrar sus correos electrónicos:

1. Migración completa de correo electrónico: al utilizar el portal de Office 365, crea un trabajo por lotes de migración, el trabajo buscará los buzones de correo de los usuarios mediante la detección automática de Exchange, accederá a los buzones de correo de los usuarios en el servidor Exchange local y comenzará a copiar el contenido de los buzones a la nube, todo esto puede Esto sucede mientras el usuario todavía está usando el buzón en el servidor local. Una vez que todos los correos electrónicos se hayan copiado correctamente en la nube, detendrá el lote de migración y cambiará los registros DNS para que los nuevos correos electrónicos/descubrimiento automático apunten al servidor de correo de la nube en lugar del de la red local; los usuarios deberán reconfigurarse en orden. para acceder al nuevo servidor, y puede eliminar los buzones de correo de los usuarios del servidor local ya que ya no se utiliza. Personalmente prefiero que uses esta opción.
2. Exportación/importación masiva de archivos .pst en nombre de los usuarios: utilizará una herramienta para exportar los buzones de correo de los usuarios a archivos .pst, puede guardar esos archivos en un disco y enviarlos a Microsoft para importarlos, o guardar los archivos .pst en una carpeta local y luego importarlos a Office. 365 usted mismo usando un asistente de migración de Office 365, no me molestaría con esta opción a menos que tenga buzones de correo relativamente pequeños.
3. Pida a sus usuarios que realicen la importación/exportación de .pst: en un mundo perfecto, puede pedirle a su usuario que exporte sus buzones de correo a un archivo .pst, guarde los archivos localmente en sus máquinas, configure Outlook para que funcione con el nuevo buzón en la nube, importe el archivo .pst desde sus máquinas a el nuevo buzón, evitaría esta opción a toda costa porque... bueno... usuarios finales.

Puede encontrar más información para la migración de correo electrónico aquí:https://support.office.com/en-us/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842

Si selecciona la opción 2 para la autenticación y la opción 1 para los correos electrónicos, no necesitará ADFS ni un certificado para completar la migración; los usuarios finales solo se verán afectados durante las etapas finales de la migración total.

Espero que esto ayude.

EDITAR:

Sus pasos de migración deberían ser fáciles, siga estos consejos:

1. Agregue todos los dominios aceptados al portal de Office 365 y verifíquelos.
2. Utilice la herramienta Microsoft IDFix para asegurarse de que el formato y los datos de sus cuentas locales sean compatibles con Office 365.
3. Cree la integración de ADFS (todavía elegiría DirSync solo porque puede instalarlo en cualquier lugar y no necesita hardware para ello, aún se ejecutaría igual que ADFS sin el inicio de sesión automático de SSO, pero parece que ADFS es un requisito en Tu caso)
4. Cree una confianza de federación entre su servidor de correo local y Office 365.
5. (Opcional) Redirigir primero el correo electrónico entrante a la nube para un mejor manejo del antivirus/spam.
6. Asigne licencias a los usuarios que desee trasladar a Office 365.
7. Comience a mover los usuarios de cada departamento como mejor le parezca.
8. Una vez que todas las cuentas de usuario se hayan movido a la nube, elimine la confianza de federación entre Office 365 y su servidor de correo local, mantenga ADFS o DirSync, aunque siempre necesitará que estén presentes.
9. Elimina el servidor de correo local como mejor te parezca, virtualízalo y mantenlo apagado, tienes la opción.