As caixas de correio têm de existir antes de o correio ser encaminhado para elas. Por isso este passo vem antes do MX — e não depois, como é tentador fazer.
Cinco minutos de decisões antes do primeiro utilizador poupam horas mais tarde. Estas três convenções são caras de mudar depois.
Confirme primeiro o método de migração. Nem todos os cenários querem as caixas criadas à mão neste passo.
Se o domínio é novo, se a migração vai ser feita por IMAP, ou se a ferramenta escolhida exige caixas de destino já existentes, crie e licencie os utilizadores aqui.
Se vai fazer uma migração de transição (cutover) a partir de um Exchange no local, não crie previamente caixas do Exchange Online com os mesmos endereços: o próprio processo de migração cria os utilizadores na cloud, e criá-los antes provoca conflitos com os objetos que ele tenta criar. Nesse caso, as licenças são atribuídas no momento indicado pelo procedimento de migração, depois de verificada — é a sequência documentada pela Microsoft. O passo 5 detalha-a.
| Decisão | Porque importa |
|---|
| Formato do endereço (nome.apelido, inicial+apelido…) | Aparece em cada email enviado e mudá-lo deixa endereços antigos a funcionar indefinidamente |
| Nomenclatura dos grupos | Com 30 grupos sem convenção, ninguém sabe qual é para quê |
| Quem é o responsável de cada grupo | Grupos sem dono acumulam membros que já saíram da empresa |
Escreva a convenção escolhida, para a aplicar de forma consistente.
Crie os utilizadores e atribua as licenças quando o método de migração o exigir, seguindo a convenção definida. Nas migrações de transição a partir de Exchange, siga antes a sequência própria apresentada no passo seguinte.
Numa implementação manual, a caixa de um utilizador é normalmente aprovisionada quando lhe é atribuída uma licença que inclui Exchange Online. Alguns métodos de migração — como a transição a partir de Exchange — criam os utilizadores durante a própria migração e exigem uma sequência diferente.
Acrescente os endereços secundários que já existiam (geral@, faturacao@, antigos endereços de pessoas) como aliases ou caixas partilhadas, para não perder correio depois do corte.
Caixas partilhadas. Ao contrário das caixas de utilizador, uma caixa partilhada normalmente não precisa de licença própria, até aos limites suportados. Em contrapartida, não deve ser usada para início de sessão direto: quem lhe acede fá-lo a partir da sua própria conta, e essa precisa de uma caixa do Exchange Online licenciada.
Este é o erro estrutural mais comum e o mais difícil de desfazer: usar o mesmo grupo para colaborar e para licenciar. Uma equipa de Marketing no Teams não deve ser a mesma coisa que determina quem tem Business Premium, que políticas do Intune se aplicam ou quem está abrangido pelo Acesso Condicional.
| Tipo | Para que serve | Exemplo |
|---|
| Grupos de colaboração | Representam equipas, departamentos e projetos em Teams e SharePoint | COL-Microsoft365-Marketing |
| Grupos de segurança e licenciamento | Representam perfis técnicos: quem tem determinada licença, quem está sujeito a determinada política | LIC-BusinessPremium, CA-Utilizadores-Padrao, INTUNE-Dispositivos-Piloto |
Crie um grupo de colaboração por equipa real da empresa — não um grupo por aplicação — e defina um responsável para cada um.
Crie grupos de segurança separados para licenciamento e políticas, com uma nomenclatura própria. A atribuição de licenças por grupo é suportada em grupos de segurança, grupos de segurança com email e grupos Microsoft 365.
Atribua licenças e políticas ao grupo técnico, não pessoa a pessoa nem à equipa de colaboração. Assim, ninguém perde a licença ou fica fora de uma política de segurança só porque saiu de uma equipa de Marketing.
Cada pessoa consegue iniciar sessão em office.com com o endereço novo e vê as aplicações a que tem direito. Tirar alguém de um grupo de colaboração não lhe retira a licença.
