Migração do Exchange 2010 para Office 365 com ADFS

Question

Deixe-me começar explicando nosso ambiente.

Temos um domínio AD - de***.co.uk

Independentemente do departamento em que o usuário está, cada usuário se autentica em todos os sistemas (inc exchange) usando sua conta de domínio (user@de***.co.uk) ou (de***\user), mesmo que seu endereço de e-mail é[e-mail protegido](isso é comum, eu sei)

Estamos planejando migrar gradualmente para o Office 365 E3, um departamento por vez. Temos cerca de 300 funcionários, 47 domínios de e-mail aceitos e mais de 600 caixas de correio (algumas das quais podem ser arquivadas localmente em pst). Nós da área de TI testamos o 365 E3 com um domínio de nossa propriedade de***s****.co.uk e configuramos usuários/caixas de correio manualmente

Agora estamos prontos para mover um departamento para o teste 365 (20 usuários), mas gostaríamos de vincular nosso AD local. Este subconjunto de usuários terá um domínio de endereço de e-mail @le***********.com

Pelo que percebi, acredito que estes são os passos que terei que realizar (corrija-me se estiver errado)

• Configurar ADFS
• Adicione o domínio @le***********.com à nossa conta 365 ******** (não tenho certeza de como isso atrairia os usuários) ********
• Altere os registros DNS de le***********.com para apontar para o Office 365
• Importar o pst de cada usuário para sua conta 365 ou qualquer outro método?

É a parte do ADFS que está causando confusão. Até agora, li vários tutoriais sobre as coisas de maneira diferente (um diz para instalar o ADFS em um DC, outro diz para configurar 3 novos servidores - um proxy ADFS, um servidor ADFS e um servidor DirSync) - qual é melhor?

Durante a configuração do ADFS, é dito que é necessário instalar um certificado SSL no IIS - esse certificado seria hostname.de***.co.uk ou hostname@le*********.com e um ao outro aceitou domínio de e-mail precisando de seu próprio SSL?

Os outros usuários residentes na central local seriam afetados por esse processo?

Cumprimentos

Answer 1

Com base nas informações que você forneceu, aqui estão os melhores cenários para prosseguir.

Autenticação de usuário: existem 3 modelos com os quais você pode trabalhar aqui, que são:

1. Usuários no Office 365 (contas na nuvem): o gerenciamento de usuários acontecerá inteiramente na nuvem. Você pode criar usuários desabilitar redefinir senhas e configurar todas as configurações usando o portal Office 365 você não precisa de um AD local para isso obviamente esta opção não funcionará com seu ambiente pois você já possui um AD local com Exchange e você deseja manter o gerenciamento de usuários controlado localmente no AD.
2. Usuários no AD, com sincronização unilateral com o Office 365 (contas semi-federadas): este módulo permitirá que você crie contas e faça todo o gerenciamento de usuários em seus servidores AD locais, você instalará uma ferramenta chamada "DirSync" ou a versão mais recente "ADD Sync" para criar uma cópia dos usuários de seu AD local para a nuvem, as ferramentas têm a opção de também sincronizar as senhas das contas de usuário do AD local para a nuvem, o que permitirá que seus usuários façam login em recursos locais no domínio e no Office 365 usando as mesmas credenciais de usuário, criando um experiência semi-SSO, os usuários precisarão fornecer seu nome de usuário e senha ao acessar recursos no Office 365 e a autenticação/verificação do usuário acontecerá no lado da nuvem. o requisito para este módulo é instalar as ferramentas mencionadas anteriormente em qualquer servidor da sua rede local, sem necessidade de ADFS ou ADFS Proxy, você deve escolher esta opção por ser a mais fácil de implementar e suportar.
3. Usuários no AD, com sincronização bidirecional com Office 365 (contas totalmente federadas): esta é a opção mais avançada das três, esta opção utiliza toda a configuração da opção anterior "Usuários no AD com sincronização unidirecional com o Office 365" além de adicionar a capacidade de forçar a autenticação/verificação do usuário no seu AD local servidores usando ADFS e servidor proxy ADFS, você precisará ter uma implantação de proxy ADFS/ADFS e AAD Sync em sua rede local ou em uma rede híbrida do Azure, você terá uma experiência SSO completa com esta opção como usuários no domínio será capaz de acessar o Office 365 sem a necessidade de fornecer um nome de usuário e senha, eu não recomendaria essa opção, pois instalar, configurar e oferecer suporte é uma história de terror de TI.

Você tem toneladas de informações para ler aqui para referência adicional:https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

Migração de e-mail: como você tem o Exchange 2010 na rede, aqui estão as formas suportadas de migrar seus e-mails:

1. Migração de e-mail de substituição: usando o portal do Office 365, você cria um trabalho em lote de migração, o trabalho procurará as caixas de correio do usuário usando a Descoberta Automática do Exchange, acessará as caixas de correio do usuário no servidor Exchange local e começará a copiar o conteúdo da caixa de correio para a nuvem, tudo isso pode acontecer enquanto o usuário ainda estiver usando a caixa de correio no servidor local. Depois que todos os e-mails forem copiados com sucesso para a nuvem, você interromperá o lote de migração e alterará os registros DNS para que novos e-mails/descoberta automática apontem para o servidor de e-mail na nuvem em vez daquele na rede local, os usuários precisarão ser reconfigurados para para acessar o novo servidor, e você pode remover as caixas de correio dos usuários do servidor local, pois ele não está mais sendo usado. Pessoalmente, prefiro que você use esta opção.
2. Exportação/importação em massa de arquivos .pst em nome dos usuários: você usará uma ferramenta para exportar as caixas de correio do usuário para arquivos .pst, poderá salvar esses arquivos em um disco e enviá-los à Microsoft para importação ou salvar os arquivos .pst em uma pasta local e importá-los para o Office 365 usando um assistente de migração do Office 365, eu não me incomodaria com essa opção, a menos que você tenha caixas de correio relativamente pequenas.
3. Peça aos seus usuários para realizarem a importação/exportação de .pst: em um mundo perfeito, você pode pedir ao usuário para exportar suas caixas de correio para um arquivo .pst, salvar os arquivos localmente em suas máquinas, configurar o Outlook para funcionar com a nova caixa de correio na nuvem, importar o arquivo .pst de suas máquinas para a nova caixa de correio, eu evitaria essa opção a todo custo porque... bem... usuários finais.

Você pode encontrar mais informações sobre a migração de e-mail aqui:https://support.office.com/en-us/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842

Se você selecionar a opção 2 para autenticação e a opção 1 para e-mails, não precisará do ADFS ou de um certificado para concluir a migração; os usuários finais só serão afetados durante os estágios finais da migração de transferência.

Espero que isto ajude.

EDITAR:

Suas etapas de migração devem ser fáceis. Siga estas dicas:

1. Adicione todos os domínios aceitos ao portal do Office 365 e verifique-os.
2. Use a ferramenta Microsoft IDFix para garantir que a formatação e os dados de suas contas locais sejam compatíveis com o Office 365.
3. Crie a integração ADFS (eu ainda usaria o DirSync apenas porque você pode instalá-lo em qualquer lugar e não precisa de hardware para isso, ele ainda funcionaria da mesma forma que o ADFS sem o login automático do SSO, mas parece que o ADFS é um requisito em seu caso)
4. Crie uma confiança de federação entre o servidor de email local e o Office 365.
5. (Opcional) Redirecione primeiro os e-mails recebidos para a nuvem para melhor tratamento de antivírus/spam.
6. Atribua licenças aos usuários que você deseja migrar para o Office 365.
7. Comece a mover os usuários de cada departamento conforme achar necessário.
8. Depois que todas as contas de usuário forem movidas para a nuvem, remova a confiança da federação entre o Office 365 e seu servidor de e-mail local, mantenha o ADFS ou o DirSync, embora você sempre precise que eles estejam presentes.
9. Remova o servidor de e-mail local conforme achar necessário, virtualize e mantenha-o desligado, você tem a opção.