Voltando a pasta Users do Windows 10 ao local original com o Sysprep – Problemas e Soluções

Quando os SSDs surgiram, eles ainda eram muito caros, e apenas modelos de baixa capacidade eram razoavelmente acessíveis. Com isso, apenas a instalação do Windows e programas já era suficiente para tomar todo o espaço de um SSD de 128GB, ou até mesmo de 256GB, dependendo da quantidade e do tamanho dos programas instalados.

Uma solução que eu adotava na época era mover a pasta \Users do Windows para uma outra partição, em um HDD, logo durante a instalação. Isto é algo que o Windows 10 suporta nativamente, com uma ferramenta chamada sysprep, ou System Preparation Tool, que já vem com o sistema. Porém esta é uma alternativa um tanto escondida. Eu sempre seguia o tutorial do Kari para fazer isso, e dava tudo certo.

Mas agora os SSDs estão se tornando mais acessíveis, e um SSD de 512 GB ou até mesmo 1 TB já estão se tornando opções razoáveis. Com isso eu deixei de usar o \Users em uma partição separada.

No meu PC eu já migrei há mais de um ano de um SSD de 256 GB para um SSD de 1 TB, passando todos os dados de um  para o outro. Mantive o \Users no HDD e decidi que o passaria para o SSD apenas quando tivesse que reinstalar o sistema.

Reinstalar o sistema era algo trivial nos Windows mais antigos, eventualmente algo quebrava de maneira irremediável e uma instalação limpa do sistema era inevitável. Mas com o tempo isso foi se tornando menos e menos frequente, e hoje eu ainda estou com a mesma instalação que fiz em 2016 ou 2017.

Assim, eu decidi migrar o \Users de volta para junto das outras pastas do Windows 10, pois ela estava se tornando o gargalo do meu sistema.

Essa mudança foi simples, e envolve passos semelhantes ao que moveu o \Users para outra partição inicialmente. O tutorial do Kari  também cobre isso, mas acho importante eu notar aqui minhas observações.

Para fazer o processo eu criei uma nova conta com privilégios de administrador, chamada Dummy, apenas para fazer o processo. Criei então o arquivo relocate.xml à seguir:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FolderLocations>
<ProfilesDirectory>C:\Users</ProfilesDirectory>
</FolderLocations>
</component>
</settings>
</unattend>

Em seguida, loguei na conta Dummy e executei os seguintes comandos:

net stop wmpnetworksvc
%windir%\system32\sysprep\sysprep.exe /oobe /reboot /unattend:e:\relocate.xml

E é só isso mesmo, depois disso o processo é todo automático, mas vai aqui um grande alerta: o processo todo demorou mais de 24 horas! Foram algumas horas enquanto o sysprep fazia uma “limpeza de plugins” ou algo parecido, não lembro exatamente. Depois disso o Windows reinicia e fica horas e horas na tela de carregamento do sistema operacional, apenas com os pontinhos que formam um círculo girando e girando, sem qualquer indicação de andamento do processo. Mas o LED do gabinete ficou indicando atividade de HDD/SSD o tempo todo, por isso esperei pacientemente.

Tudo indica que nesse tempo ele está copiando os arquivos do HDD para o SSD, então quanto mais arquivos existirem, mais vai demorar. A minha pasta \Users tem 417 GB, espelhados por 746.886 arquivos e 86.872 pastas. É muita coisa, o que deve ser o motivo da demora.

No final, o Windows reinicia novamente e então é preciso criar uma nova conta (Dummy2) apenas para passar pelo processo de finalização de instalação do Windows. Uma vez completado o processo podemos voltar a logar com nossa conta principal e excluir as duas contas criadas no processo.

É um processo demorado, mas vale a pena, pois a grande maioria dos programas continua funcionando normalmente após a mudança. É melhor 24 horas do computador trabalhando sozinho do que 24 horas ou mais pra reinstalar e configurar tudo novamente.

Porém, há algumas exceções de programas que deixaram de funcionar corretamente após a mudança, e precisaram de intervenção. Isso normalmente ocorre porque eles estão linkando para o %appdata% através do caminho real, em vez de usar o atalho.

No meu caso os programas problemáticos foram esses:

• Genie Timeline Pro: O programa perdeu todas as configurações e o registro, mas bastou desinstala-lo e reinstala-lo novamente que ele voltou a funcionar.
• Duplicati: Este também fica procurando pelos banco de dados dos backups na localização antiga. Nesse caso eu optei por apenas copia-los de volta para lá e deixa-lo usando o HDD mesmo.
• WinEdt: Nesse caso só precisei recolocar o código de registro e reajustar algumas opções.
• MiKTeX: Ficou com uns atalhos um tanto zoados, então optei por apagar sua pasta inteira e instala-lo novamente. O MiKTeX fica inteiro na pasta %appdata%.
• Anaconda: De maneira similar ao MiKTeX, o Anaconda também instala tudo no %appdata%, e fica com os links quebrados após a mudança. Optei também por reinstala-lo.
• Syncback Pro: Perdeu os agendamentos feitos no Gerenciador de Tarefas do Windows. Eles ainda ficam lá, mas não funcionam. Apaguei os agendamentos e os refiz.

É possível que outros programas também tenham quebrado com a mudança do \Users de lugar. Não abri todos os programas que uso para ter certeza, mas dentre os mais usados os afetados foram esses aí que listei. Se aparecer mais algum eu atualizo este artigo.

Compartilhe o artigo com seus amigos se você gostou 🙂 . O Skooter Blog precisa de sua ajuda na divulgação para continuar existindo.