Atualmente estou tendo um bom tempo com o que parece ser um projeto bastante simples.
Basicamente, $employer tem vários sites remotos com hardware antigo representando os servidores reais e eles estão sendo substituídos por servidores reais. Ou, mais precisamente, eles estão comprando novos servidores e fazendo com que eu faça o trabalho de substituí-los. Os sites são geralmente pequenos, então nada é muito complexo - basicamente estamos apenas fornecendo um servidor de arquivos, serviços de impressão e um servidor de controlador de domínio / DHCP para todos os sites.
O problema, claro, vem do redirecionamento do perfil do usuário. Todos os nossos usuários têm seu diretório My Documents redirecionado para o servidor de arquivos, por exemplo, para: \[crappy-old-server]\users\%username% . Como estamos tentando fazer as coisas direito, estamos configurando o DFS nos novos servidores e mudando isso para: \[not-crappy-DFS-root]\[sitename]\users\%username% .
Essa parte está funcionando muito bem e, depois da migração do servidor de arquivos com o servidor de arquivos da Microsoft kit de ferramentas de migração , executamos csccmd para apontar o compartilhamento nas máquinas clientes para o novo local, alterar algumas coisas no Active Directory e na Diretiva de Grupo (unidades mapeadas, impressoras etc.) e chame um dia.
O problema, no entanto, é que enquanto a ferramenta csccmd move algumas das referências de registro para o servidor antigo, o registro do cliente ainda é ruim com os links ruins (MRUs, caminho do Bit Bucket Recycler, impressoras, padrões de aplicativos, pontos de montagem, pastas do Shell, cache de rede, etc.) e como resultado, os usuários não podem abrir o menu iniciar sem receber tempos limite de rede porque alguma configuração está procurando algo em \[crappy-old-server]\users\%username% em vez de %código%. Leva literalmente pelo menos 30 segundos para fazer quase tudo, o que não é aceitável.
Para resolver isso, eu tenho manualmente, em cada máquina cliente, abrindo o regedit, pesquisando na cadeia do servidor antigo e, quando localizado, excluindo a chave ou substituindo o antigo nome do servidor pelo novo caminho DFS. Isso, obviamente, é uma porcaria, e eu estou pensando que simplesmente tem que haver uma maneira melhor, porque a minha solução atual simplesmente não é escalável, e migrações de usuários maiores devem ter usado uma abordagem mais automatizada. para este problema.
Então, qual é a melhor maneira de fazer isso que não envolve a busca manual de registros de clientes?
Você pode colocar uma máquina em cada site que responda por \[crappy-old-server]\users como uma raiz DFS autônoma, com users sendo um link DFS para a nova pasta \[not-crappy-DFS-root]\[sitename]\users . Você pode usar o servidor que está implantando em cada site usando OptionalNames , supondo que você ainda não tenha um compartilhamento chamado users .