Returning the Users folder of Windows 10 the original location with Sysprep – Problems and Solutions

When SSDs have emerged, they were still too expensive, and only low capacity models were reasonably accessible. Therewith, only the installation of Windows and programs was enough to take the entire space of a 128GB SSD, or even 256GB, depending on the amount and size of installed programs.

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, or 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. kept the \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 or 2017.

So, 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. The 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, call 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>

Then, loguei na conta Dummy e executei os seguintes comandos:

net stop wmpnetworksvc
%windir%\system32\sysprep\sysprep.exe /oobe /reboot /unattend:and:\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 hours! Foram algumas horas enquanto o sysprep fazia umalimpeza de plugins” ou something, I do not remember exactly. 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 has 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, but it's worth, 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.

But, 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 🙂 . The Skooter Blog needs your help in spreading to continue existing.

0 0 vote
Article Rating

Permanent link to this article: https://www.skooterblog.com/2020/01/20/voltando-a-pasta-users-do-windows-10-ao-local-original-com-o-sysprep-problemas-e-solucoes/

Sign up
Notify about
guest
0 Comments
Inline Feedbacks
See all reviews
×
0
We would like to know what you think, Leave your commentx
()
x
Enable Notifications    Ok No thanks