A junção de pasta ProgramData é interrompida após a atualização para 1709

Temos uma imagem personalizada em centenas de PCs em todo o país que usa proteção de disco e, para que nosso software da plataforma de gerenciamento seja atualizado e funcione corretamente, tivemos que criar uma junção a uma unidade que não é protegida por proteção de disco.

O problema é o seguinte: quando uma das atualizações de nosso PC para 1709, ele quebra as junções que configuramos e, portanto, não podemos acessar o PC para corrigir as outras quebras do 1709 (como substituir nosso ambiente de recuperação personalizado, redefinição de programas padrão etc.) porque a pasta de dados do programa é então bloqueada para que nosso software de gerenciamento não possa funcionar corretamente.

Eu queria saber se alguém encontrou um problema semelhante e encontrou uma correção, pois não podemos poupar o horário de funcionamento para atualizar 100 dos PCs para 1709 e, em seguida, corrigir manualmente o que está quebrado.

windows-10 windows-10-v1709

— ztnd13
fonte

Com toda a probabilidade, é uma mudança não suportada. Um exemplo de como corrigi-lo seria implantar um script ou usar algo como o PowerShell remoto. Com tão pouca informação, é difícil dizer quais opções você tem disponível. Como é, não permita que eles atualizem e preparem uma imagem 1709 e a implantem em seu lugar?

— Seth

Em ambientes normais, essa honestidade seria provavelmente a melhor solução. No entanto, esses são computadores independentes, usados como máquinas de quiosque. Nós os atualizamos / mantemos por meio de procedimentos que configuramos em nossa plataforma de gerenciamento. Portanto, quando os atualizamos para 1709, e a junção quebra, perdemos todo o controle de gerenciamento por meio de nossa plataforma e precisamos usar um aplicativo remoto de terceiros (semelhante ao TeamViewer) para conectar-se novamente e corrigir os problemas manualmente. Se somos capazes de impedir / consertar a quebra de junções, o resto é fácil.

— Ztnd13

Esta junção estava em vigor com a última grande atualização ou você mudou para o Win10 depois disso? Pessoalmente, eu espero que ele rompa com as principais atualizações. Parece que o movimento ProgramDataé realmente suportado , estou assumindo que está no mesmo tipo de unidade? relacionados .

— Seth

Aqui está o cenário: PC executando o Windows 10 Pro x64, (versão 1607 ou 1703), junção C: \ programdata \ Oursoftware no local, vinculada a D: \ Programdata \ Oursoftware. Quando o PC é atualizado para 1709, essa junção é interrompida.

— Ztnd13

Então você não moveu a pasta ProgramData como um todo, OK. Qual proteção de disco você está usando? Como isso funciona em conjunto com a atualização? Você o desativa antes e depois depois?

— Seth

Um script de inicialização que refaz a junção não deve funcionar para recuperar seu aplicativo?

O DeepFreeze funciona tirando uma captura instantânea do sistema e restaurando-o a cada inicialização, mas se você descongelar o sistema, configure um script de inicialização para refazer a junção e, em seguida, refazer a atualização, que deve sobreviver à atualização.

Para criar um script de inicialização, basta iniciar o editor de Diretiva de Grupo local (ou implantar um GPO de inicialização via Diretiva de Grupo a partir de um Controlador de Domínio) via 'gpedit.msc'> Configuração do Computador> Configurações do Windows> Scripts> Inicialização> Adicionar> Criar um arquivo .bat no local C: \ em algum lugar com o seguinte conteúdo:

mklink / j C: \ ProgramData \ myapp D: \ ProgramData \ myapp

Por ser um script de inicialização do computador, é executado como a conta local do SISTEMA com permissões totais e será executado antes que a tela de logon apareça.

Obviamente, você deseja que o sistema seja congelado no DeepFreeze ao adicionar isso e, em seguida, congele novamente assim que a alteração for feita.

Além disso, você pode substituir um arquivo .wim do ambiente de recuperação com bastante facilidade por outro script de inicialização que execute: pushd \ server \ path \ to \ winrefile \

Clique em T: \ Recovery \ WindowsRE xcopy / h Winre.wim T: \ Recovery \ WindowsRE

Nota: Se a partição de recuperação não tiver uma letra de unidade atribuída, você poderá executar um script diskpart para atribuir uma letra de unidade primeiro: diskpart / s scriptname.txt

com scriptname.txt contendo algo como: selecione o disco 0 selecione a partição 2 designe a letra = R

No entanto, isso pode ser perigoso se nem todos os seus sistemas forem particionados da mesma forma, com a partição 2 sendo a partição de recuperação.

Além disso, sim, a instalação da versão 1709 está literalmente instalando um sistema operacional totalmente novo, como a atualização do Windows 8.1 para o Windows 10. Menos alterações, mas o processo é o mesmo. Honestamente, a melhor coisa a fazer é provavelmente recriar a imagem dos sistemas usando o MDT (Microsoft Deployment Toolkit), que possui uma boa etapa de script de parte do disco que permitirá re-particionar a unidade da maneira que desejar e instalar qualquer imagem do ambiente de recuperação que desejar. isto. O MDT pode ser executado remotamente e pode ser configurado para fazer backup de qualquer arquivo, implantar a nova imagem e reiniciar o sistema posteriormente na nova imagem e, em seguida, restaurar esses arquivos. Depois de familiarizar-se com o MDT, você pode se perguntar por que precisa do DeepFreeze em primeiro lugar. :)

— Nate Cartwright
fonte