Compartir a través de

O365 – Tipos de migração e nota sobre o processo de descomissionamento

  • Artículo

By: Caio Ribeiro César

Este post faz referência aos artigos localizados nos links abaixo:

Nossa equipe de suporte recebeu ao longo do tempo algumas mensagens mencionando um texto de um post anterior. Hoje, iremos explicar melhor o que foi informado:

Conforme já discutido em outros artigos, é importante ressaltar que a utilização da ferramenta “adsiedit” para a gerência de objetos do Exchange/Exchange Online não é algo suportado pela Microsoft. Temos um índice de clientes que efetuam o decommission do Exchange On-Premises após a migração para a nuvem e, logo após, solicitam a suportabilidade para a gerência de objetos com o adsiedit – ou até o cenário descrito abaixo. É uma prática que pode ser efetuada por administradores, porém a equipe de suporte não irá atuar em chamados com a utilização de AdsiEdit para o gerenciamento de objetos.

Recomendamos a instalação de ao menos um Exchange Server on-premises para a edição de atributos via Exchange Management Console / Exchange Control Panel.

Vamos primeiro analisar os tipos de migrações disponí­veis para o Exchange Online:

  • Migração IMAP: Suporta uma variedade de plataformas diferentes, migração de dados (e-mail somente - não migramos calendários, contatos ou tarefas). Alguns exemplos são: Exchange Servers (com IMAP implementado), provedores de terceiros (Notes, GroupWise, Gmail, etc).
  • Migração Cutover: Rápida e simples, não é necessário atualizar o ambiente on-premises para novas versões ou instalação de AADConnect. Suportada em ambientes de até 2.000 mailboxes nas versões de Exchange 2003, 2007, 2010, 2013 ou 2016.
  • Migração Staged/em lotes: Nos dias atuais, raramente utilizada devido ao baixo número de clientes com 2.000 mailboxes migrando de versões 2003 ou 2007 que também possuem AADConnect.
  • Migração Hí­brida: Método mais utilizado para a migração de mailboxes. Feita em etapas, esta migração é a opção caso o administrador queira gerenciar seus usuários on-premise e online. Possui funcionalidades adicionais tais como o acesso Cross-Premise, migração aperfeiçoada com melhor gerência de batches, simples offboard e Free/Busy. Geralmente escolhida por empresas com +2000 mailboxes - porém não é uma regra (desde que o ambiente esteja atualizado).
  • Migração PST: Geralmente não listamos pst como um "métido" de migração em si. Alguns clientes optam pelo pst import, o motivo principal sendo o 3rd party não suportar IMAP. Recomendamos outros métodos, porém caso não exista a possibilidade, o upload utilizando um blob de Azure é o mais indicado.

Agora que sabemos um pouco mais sobre as opções, vamos ao cenário:

 


Ambiente Híbrido de Exchange 2013/2016, com a maior parte das mailboxes migradas para o Exchange Online. Assim que o último batch de migração terminar, o administrador deseja remover por completo o ambiente de Exchange On-Premises (eliminando assim os custos de servidores físicos).

As discussões mais comuns no suporte para este ambiente são:

1) Se o objetivo sempre foi um ambiente “full cloud” e a organização tiver um número de mailboxes inferior a 2.000, a melhor escolha inicial de migração seria cutover.
2) Caso o ambiente possua um número maior de 2.000 mailboxes, o método escolhido foi o rich mailbox move (Híbrido). Para que o ambiente se torne full cloud, o decommission é necessário. Antes de efetuar o decommission, algumas funcionalidades que serão perdidas: Archive On-Premises, Free Busy entre organizações e principalmente a possibilidade de gerenciar os objetos via Active Directory (AADConnect) .

Caso o administrador do ambiente mencionado acima não precise da gerência de seus objetos no AD (ou seja, elas serão feitas diretamente no portal do O365), basta confirmar que todas as mailboxes/Public Folders já estão migradas e então remover o sincronismo de objetos e posteriormente o Exchange OnPremises seguindo o procedimento detalhado aqui.

E as organizações que precisam remover o ambiente On-Premises e ainda precisam da gerência de objetos no AD? Tais ambientes, como uma empresa que utiliza o ADFS para a federação, terão o sincronismo de objetos como um pré-requisito.

A recomendação para todos os clientes que ainda devem usar o AADConnect é de ter a instalação de ao menos um Exchange Server on-premises para a edição de atributos via Exchange Management Console / Exchange Control Panel.

Qual o motivo?

As organizações que implementaram um ambiente Híbrido, inicialmente utilizaram o AADConnect para o sincronismo de objetos: atributos de Exchange definem o status de objetos para migrações de mailboxes, mailflow e até de conectividade de Outlook.

Os ambientes de Federação seguem o mesmo padrão: o single sign on de um objeto só irá funcionar se o ADFS o identificar – para isto temos o sincronismo de dados onpremises e na cloud (object matching).

A implementação do sincronismo de objetos, efetua a alteração do Source of Authority (SoA): quando falamos de um ambiente sincronizado, o AD é o dono das informações que são populadas para os objetos no Azure Active Directory (AAD). Temos a necessidade uma gerência de objetos simples e objetiva com o AD, e por isso habilitamos os objetos como “sincronizados”.

Motivo: as alterações de objetos não podem ser feitas diretamente no Exchange Online (já que o SoA é o Active Directory). Caso o último Exchange Server seja removido, perdemos também a gerência de objetos nas ferramentas On-Premises (EAC/EMC) e a utilização de Adsiedit para tarefas administrativas não é suportada.

A equipe de suporte também entende o lado do administrador, que deseja cortar os gastos de servidores físicos. Para este fator, recomendamos a utilização do Azure como solução cloud (assim como possivelmente utilizado para o servidor AADConnect, ADFS, WAP).

A Microsoft oferece sem custos adicionais uma chave de Hybrid Server para as organizações - https://support.microsoft.com/en-us/help/2939261/how-to-obtain-an-exchange-hybrid-edition-product-key-for-your-on-premi