Migrando Servidor de Arquivos em Grupo de Trabalho (File Server Workgroup) com Storage Migration Service
Olá pessoal, tudo bem?
Estou feliz em entregar este artigo para vocês depois de tirar todas as dúvidas direto com o time de engenharia da Microsoft. Agora eu posso ensinar detalhadamente sobre migração de servidor em grupo de trabalho (Workgroup) utilizando o Storage Migration Service.
É normal que pequenas empresas mundo afora tenham um Windows Server como File Server – Servidor de Arquivos. O que elas não costumam ter é o famoso AD (Active Directory) – Active Directory Domain Services (AD DS) – Serviços de Domínio Active Directory (AD DS) configurado, seja por falta de um profissional qualificado para executar a implantação de forma correta ou por desconhecimento mesmo.
O que o dono da empresa às vezes não sabe é que todo o acesso no servidor que não se encontra ingressado em um domínio está em Workgroup. Isso significa que, para acessar os compartilhamentos criados neste servidor de arquivos, cada computador necessita ter senha e usuário local. Em alguns casos o colaborador possui até a senha de administrador do servidor. Isso é um risco para empresa, pois o colaborador tem acesso direto ao servidor de arquivos, onde todos os dados estão armazenados.
Uma pesquisa realizada ano passado pela Microsoft com alguns clientes aponta o seguinte: mesmo com servidores ingressados em um domínio, 39% dos clientes afirmam ter usado pelo menos um grupo ou usuário local para acessar dados em seus servidores.
Para facilitar o acesso aos arquivos, alguém cria usuários e grupos com nomes iguais no servidor e nas estações de trabalho. Isso facilita muito o acesso ao compartilhamento. Assim, é possível criar usuários não administradores do sistema operacional, melhorando um pouco a segurança do acesso.
O problema começa quando a empresa cresce e surge a necessidade de fazer uma migração do servidor de arquivo, seja porque o sistema operacional já não possui mais suporte da Microsoft ou por falta de espaço mesmo.
Solução
Nesse outro artigo aqui, foi demonstrado como utilizar o Storage Migration Service com todas as suas etapas e requisitos de utilização, mas na época que que o artigo foi escrito, em 2018, o Storage Migration Service ainda estava “engatinhando”. Era uma versão preview. Vários aprimoramentos foram adicionados e hoje o Storage Migration Service já está bem “maduro”.
Um dos novos recursos do Storage Migration Service é a possibilidade de migrar servidores de arquivos que estão em Workgroup (Grupo de Trabalho). Uma “mão da roda”! Já vi muitos cenários assim no Brasil. Chega uma hora que não tem mais jeito: o servidor de arquivos precisa migrar para um servidor ingressado em um domínio.
Quando utilizamos o Storage Migration Service para migrar um servidor que esteja em workgroup, acontece uma “mágica”. Ele permite recriar quaisquer usuários e grupos locais nos servidores de destino. Assim, as permissões de arquivo ou compartilhamento definidas para usuários e grupos locais não são perdidas.
Este recurso do Storage Migration Service inventará todos os usuários e grupos locais e os recriará no destino durante a migração, localizando e substituindo os SIDs em todos os arquivos transferidos e ACL das pastas. Ao migrar manualmente usando ferramentas como Robocopy, toda essa segurança é perdida. Qualquer permissão de arquivo ou compartilhamento proveniente de uma entidade de segurança local desaparece. Isso acontece porque este SID não existe no novo servidor de destino. Isso torna as migrações de máquinas sem ingresso em domínio particularmente problemáticas, mas também afeta os usuários do Active Directory.
Aqui estão as opções ao migrar usuários e grupos locais:
- Renomear contas com o mesmo nome, selecionadas por padrão, e migrar todos os usuários e grupos locais do servidor de origem. Se o Storage Migration Service encontrar usuários ou grupos locais com o mesmo nome na origem e no destino, ele os renomeará no destino, a menos que eles sejam internos (por exemplo, o usuário administrador e o grupo Administradores). Não use essa configuração se o servidor de origem ou de destino for um controlador de domínio.
- Reutilizar contas com o mesmo nome, além de mapear usuários e grupos com nomes idênticos na origem e no destino. Não use essa configuração se o servidor de origem ou de destino for um controlador de domínio.
- Não transferir usuários e grupos. Ignorar a migração de usuários e grupos locais é necessário quando sua origem ou destino é um controlador de domínio ou ao propagar dados para replicação do DFS (a replicação do DFS não dá suporte a grupos e usuários locais).
Nova opção de migrar usuários e grupos
Como você pode ver, os usuários locais migrados para o servidor de destino estão desativados. Isso é intencional. As senhas não são copiadas. Ao invés disso, será atribuída uma nova senha aleatória de 127 caracteres. A conta será desativada para que os administradores possam intencionalmente definir a senha nova e ativá-la.
Usuários locais migrados desativados no servidor de destino
É possível também executar um backup. Se o servidor de destino tiver pastas com o mesmo nome do servidor de origem, o Storage Migration Service irá realizar o backup dessas pastas do servidor de destino.
Nova opção de backup de pastas
Backup realizado com sucesso das pastas iguais no servidor de destino
Alerta de opção de backup ao executar a transferência de arquivos
Também é possível gerar logs em arquivos CSV de transferências de arquivos, pastas de erros, usuários e grupos migrados.
Criação de logs em CSV
Cenários
Cenários Servidor de arquivos em Grupo de trabalho (File Server Workgroup)
O Storage Migration Service em servidores de arquivos em grupo de trabalho pode ser utilizado nos seguintes cenários:
- File Server em Workgroup para File Server em Workgroup: Neste cenário, é possível executar a transferência total. Isto é, o servidor de destino vai assumir o papel do servidor de origem, assumindo até o hostname do servidor de origem. Após a transição, é possível ingressar o servidor de destino em um domínio.
- File Server em Workgroup para File server em Domínio: Neste cenário, é possível somente executar a transferência de arquivos. Isto é, o servidor de arquivos de origem que está em workgroup envia a cópia dos arquivos e pastas para um servidor de arquivos de destino que está em um domínio.
Requisitos
Os requisitos são os mesmos informados no artigo anterior sobre Storage Migration Service, tanto para sistemas operacionais quanto para portas do firewall que deve serem abertas. Você pode acessar o artigo anterior aqui.
Vídeo
Agora, vou demonstrar de forma clara e objetiva todos os passos para fazer a migração de um servidor de arquivos em grupo de trabalho. Isso serve tanto para um servidor de arquivos em grupo de trabalho quanto para um servidor de arquivos em domínio.
Também vou demonstrar um cenário de migração para ambiente pequeno sem utilizar um servidor orquestrador. Vou utilizar somente um Windows 10 com Windows Admin Center instalado e servidor de origem e destino em Workgroup.
O sistema operacional utilizado como origem será o Windows Server 2008 R2, por se tratar de um sistema operacional que já está com o seu ciclo de vida de suporte encerrado pela Microsoft. O servidor de destino será o Windows Server 2019. Você também pode utilizar como servidor de destino Windows Server 2012 R2 e Windows Server 2016.
Referências
https://docs.microsoft.com/pt-br/windows-server/storage/storage-migration-service/overview
Agora é só colocar a “mão na massa” e fazer a migração do seu servidor de arquivos. Enquanto aguarda a transferência ser concluída, eu tenho a trilha sonora perfeita pra você. Liga o som e aproveita!
Há 10 anos atuo na área de TI focado em suporte e administração de infraestrutura, especializado em plataformas Microsoft. Tenho grande experiência em troubleshooting, implantação, configuração e administração de funções e recursos de tecnologia Microsoft. Formado em Redes de Computadores pela faculdade Estácio de Sá de Belo Horizonte.
Comecei a compartilhar o meu conhecimento no ano de 2012, fazendo artigos e vídeos para o meu Blog. Em 2017 comecei a escrever artigos para o portal Cooperati, em 2020 fui premiado como Microsoft MVP, na categoria Cloud and Datacenter Management.
Sou apaixonado em compartilhar o meu conhecimento. Meu lema é: O conhecimento só é válido quando compartilhado.