Quando o erro Sysprep 0x80073cf2 aparece junto de um pacote de aplicativo da Microsoft Store nos logs, comece identificando esse pacote e a conta em que ele está instalado. Depois confira seu estado de provisionamento, faça as alterações direcionadas necessárias e tente novamente. Remover todos os aplicativos da Store não é o primeiro passo.
Este guia aborda instalações do Windows 11 e 10 cujos logs atuais do Sysprep identificam um problema de pacote Appx. Antes de alterar pacotes, salve uma cópia restaurável do ambiente de referência e dos dados de aplicativos necessários. Nosso Wittytool Disk Clone para clonagem e implantação do Windows pode criar uma imagem do sistema para preservar a configuração antes do diagnóstico.
Confirme o erro de aplicativo da Store nos logs do Sysprep
Leia setupact.log e setuperr.log da tentativa mais recente
Abra esta pasta no computador de referência:
%WINDIR%\System32\Sysprep\Panther\
Examine setupact.log e setuperr.log no horário da falha mais recente. Procure 0x80073cf2, 0x3cf2, uma falha relacionada a Appx e um identificador de pacote. Uma mensagem especialmente útil é:
was installed for a user, but not provisioned for all users
Copie o identificador completo do pacote dessa tentativa, incluindo versão e arquitetura. Salve os logs separadamente antes de tentar novamente. Um nome de pacote de uma falha antiga pode já não identificar o bloqueio atual.
Se os registros mais recentes apontarem outro componente ou erro, investigue essa causa. Uma caixa de diálogo genérica de falha de validação não comprova que o reparo de aplicativos da Store se aplica.
Identifique o pacote e as contas afetadas
Abra o Windows PowerShell como administrador para a inspeção abaixo. Substitua o marcador em maiúsculas pelo nome completo do pacote copiado do log:
$packageFullName = 'PASTE_EXACT_PACKAGE_FULL_NAME_FROM_LOG'
Get-AppxPackage -AllUsers -PackageTypeFilter Main,Framework,Resource,Bundle |
Where-Object { $_.PackageFullName -eq $packageFullName } |
Format-List Name,PackageFullName,PackageUserInformation
Esta consulta é somente de leitura. Confira PackageUserInformation para saber quais contas têm o pacote instalado. Registre também o campo Name; você usará essa identidade mais curta para consultar o provisionamento.
Get-AppxPackage -AllUsers lista informações de pacotes entre as contas, sem desinstalar nada. Acrescentar -AllUsers a um comando de remoção tem um efeito diferente e mais amplo; não transfira o parâmetro automaticamente da inspeção para a limpeza.
Por que aplicativos da Store podem causar o erro Sysprep 0x80073cf2
Aplicativos instalados e provisionados são estados diferentes
Um aplicativo da Store pode ter uma instalação associada a um usuário existente e um pacote provisionado na imagem do Windows. São registros relacionados, mas com finalidades distintas:
| Estado | O que verificar | Consulta no PowerShell |
|---|---|---|
| Instalado para um usuário | Pacote registrado em um perfil de usuário existente | Get-AppxPackage |
| Provisionado na imagem | Pacote preparado para instalação quando novos usuários forem criados | Get-AppxProvisionedPackage -Online |
O aplicativo abrir normalmente na sua conta não comprova que os dois estados são consistentes. Nesses comandos DISM, -Online significa a instalação do Windows em execução, não um serviço de internet.
Atualizações e remoções parciais podem deixar os estados inconsistentes
Por exemplo, um usuário pode atualizar um aplicativo enquanto a imagem mantém outra versão provisionada. Também é possível remover o provisionamento e deixar a instalação de um usuário. As orientações da Microsoft para aplicativos da Store descrevem como essas situações podem interromper o processamento de Appx pelo Sysprep.
Identifique quais estados de pacote entram em conflito neste computador de referência. Não presuma que todo aplicativo instalado por usuário é inválido nem que um único aplicativo integrado causa todas as falhas 0x80073cf2.
Corrija o erro Sysprep 0x80073cf2 sem remover todos os aplicativos
Preserve o ambiente de referência antes de alterar pacotes
Desinstalar um aplicativo modifica o ambiente de origem e pode afetar seus dados. Confirme que possui um backup utilizável e sabe como restaurar os aplicativos necessários antes de prosseguir. Use um instantâneo somente quando seu processo de preparação do computador de referência permitir.
Registre o pacote com falha, as contas afetadas, a compilação do Windows e as alterações já feitas. Durante o período de captura, impeça que downloads e atualizações da Store introduzam novas versões de pacotes. Desconectar temporariamente a internet do computador de referência pode atender ao processo; isso não significa deixar computadores implantados sem atualizações.
Remova somente o pacote identificado da conta afetada
Use as informações de conta obtidas na inspeção. Para uma remoção direcionada por usuário, entre na conta afetada e abra o Windows PowerShell no contexto dessa conta. Usar credenciais de outro administrador para iniciar o PowerShell muda a conta atingida por uma operação de usuário atual.
Se abriu uma nova sessão, defina novamente o nome exato do pacote. Confirme a identidade atual e consulte a instalação correspondente:
whoami
$packageFullName = 'PASTE_EXACT_PACKAGE_FULL_NAME_FROM_LOG'
Get-AppxPackage -PackageTypeFilter Main,Framework,Resource,Bundle |
Where-Object { $_.PackageFullName -eq $packageFullName } |
Format-List Name,PackageFullName
Se o pacote pretendido estiver presente e você confirmou que pode removê-lo, execute:
Remove-AppxPackage -Package $packageFullName -Confirm
Para várias contas afetadas, trate as instalações identificadas na consulta. Não exclua contas de usuário como atalho rotineiro. Antes de escolher uma remoção mais ampla, o administrador precisa considerar todos os usuários atingidos.
Se a remoção falhar, guarde o erro completo e use a orientação correspondente abaixo. Não tente compensar apagando manualmente os arquivos do aplicativo.
Confira o provisionamento da imagem antes de remover a entrada correspondente
Volte a uma sessão de Windows PowerShell como administrador. Substitua pelo Name registrado na listagem do pacote instalado:
$appName = 'PASTE_NAME_FROM_INSTALLED_PACKAGE_LIST'
Get-AppxProvisionedPackage -Online |
Where-Object { $_.DisplayName -eq $appName } |
Select-Object DisplayName,PackageName
Examine a saída antes de outra alteração. Se existir uma entrada provisionada correspondente e removê-la fizer parte do reparo escolhido, copie seu PackageName real para este comando:
Remove-AppxProvisionedPackage -Online -PackageName 'PASTE_EXACT_PROVISIONED_PACKAGE_NAME'
Use o identificador retornado pela consulta de provisionamento. Sua versão pode ser diferente da instalação do usuário; por isso, os dois comandos de remoção podem exigir valores distintos. Se os nomes exibidos não corresponderem diretamente, examine a lista completa de provisionamento e confirme a identidade do aplicativo antes de selecionar qualquer pacote.
A referência Remove-AppxProvisionedPackage da Microsoft explica que remover o provisionamento impede a instalação desse pacote em novas contas; isso não substitui a desinstalação nas contas existentes.
Se não houver um pacote provisionado correspondente, não há uma entrada para remover por esse comando. Continue investigando a instalação restante do usuário e o log mais recente, sem ampliar o filtro até atingir pacotes sem relação com a falha.
Se o aplicativo for necessário na imagem final, planeje sua reinstalação ou seu reprovisionamento compatível e valide o resultado antes da captura. Não entregue uma imagem sem um aplicativo necessário sem que isso tenha sido planejado.
Tente novamente e leia o novo log antes de outra alteração
Após concluir as alterações direcionadas, tente novamente executar o Sysprep ou capturar a imagem. Leia o novo log para identificar o resultado:
- O erro do pacote original desapareceu: confira se a operação termina.
- Outro pacote foi identificado: examine esse pacote e seus usuários separadamente.
- O mesmo pacote continua aparecendo: confira novamente contas instaladas, versão e provisionamento.
- Outro componente falhou: investigue esse erro em vez de repetir a remoção de Appx.
Quando a preparação funcionar, capture uma nova imagem do estado resultante e valide-a em um computador de teste. Uma imagem capturada anteriormente não recebe as alterações feitas agora no sistema de referência.
Se o pacote não aparece ou não pode ser removido
Use o estado observado para decidir a próxima verificação. Limite as alterações às evidências da falha atual.
| Resultado encontrado | Próxima verificação |
|---|---|
| A consulta do usuário atual está vazia, mas a consulta de todos os usuários encontra o pacote | Confira a conta listada e a identidade que executa o PowerShell. |
| A consulta exata não retorna nada | Compare o identificador completo com o log mais recente, incluindo versão e arquitetura. Revise os tipos e registros de pacotes disponíveis antes de remover qualquer item. |
| Nenhuma entrada provisionada correspondente aparece | Confira as instalações dos usuários existentes. Um aplicativo sem provisionamento ainda pode estar instalado para um usuário. |
| Aparecem várias versões ou registros do pacote | Relacione cada registro à identidade e à conta corretas. Nomes semelhantes não são intercambiáveis. |
| O Windows informa que o pacote não pode ser removido | Salve o erro e investigue o componente e a compilação do Windows. Restaure o ambiente de referência se novas alterações comprometerem funções necessárias. |
| Outro pacote bloqueia a tentativa seguinte | Repita a identificação para o novo pacote em vez de apagar os aplicativos restantes em massa. |
Evite assumir a propriedade de WindowsApps, apagar bancos de dados de pacotes ou editar registros de estado do Sysprep para forçar a aprovação. Isso contorna as verificações de estado que você precisa entender e dificulta avaliar o ambiente resultante.
Evite mudanças da Store durante o período de captura
Depois de obter um ambiente de referência funcional, controle o intervalo entre as verificações finais e a captura. Conclua as mudanças planejadas, registre os pacotes necessários e evite abrir sessões da Store ou criar perfis extras de teste nesse período.
Separe a preparação da imagem da manutenção normal dos dispositivos. O controle temporário da atividade da Store durante a captura não deve se tornar uma política permanente de deixar aplicativos implantados sem correções.
Guarde com a imagem um registro breve: compilação do Windows, aplicativos necessários, mudanças de pacotes, data da captura e resultado do teste. Se o problema voltar após uma atualização da imagem, esse registro ajudará a identificar o que mudou.
Em um destino representativo, entre com a conta pretendida e abra os aplicativos necessários. Uma captura bem-sucedida é uma verificação; um ambiente de aplicativos utilizável no destino é outra.
Precisa implantar a configuração existente do Windows com seus aplicativos?
Se sua prioridade é reproduzir um ambiente Windows que já contém os aplicativos e as contas necessários, o Wittytool Disk Clone oferece um procedimento de implantação sem executar o Sysprep antes. Você pode fazer backup da origem configurada e implantar a imagem em vários computadores, com alteração opcional dos SIDs do Windows dos destinos.
Nossa implantação pode transferir aplicativos, contas locais, configurações e conteúdo de aplicativos da Microsoft Store presentes na imagem de origem. Ativação, entradas em nuvem e registros de dispositivos ainda precisam ser conferidos nos destinos. Esse procedimento reproduz o ambiente capturado; ele não repara um aplicativo que já apresentava falha na origem.
Para manter a configuração já preparada, baixe o Wittytool Disk Clone e crie um backup do sistema de origem antes de preparar o próximo lote. Depois, avalie o ambiente capturado e as configurações de SID dos destinos em uma pequena implantação de teste.
Antes de conectar os destinos para implantação, faça backup dos arquivos necessários e confira o disco de destino. A implantação exclui as partições existentes do disco selecionado e grava a imagem. Preservar aplicativos da origem não preserva arquivos que já estão nesse disco de destino.
O procedimento resumido é criar uma imagem de sistema com Wittytool Disk Clone, configurar o servidor de implantação, conectar os clientes, confirmar as configurações de destino e validar os sistemas restaurados. Use uma imagem gerada pelo Wittytool Disk Clone. Nosso guia para implantar o ambiente Windows configurado sem Sysprep apresenta todas as etapas.
Perguntas frequentes
O que causa o erro Sysprep 0x80073cf2?
Quando o log mais recente do Sysprep identifica um pacote Appx, o erro pode indicar uma incompatibilidade entre o aplicativo instalado de um usuário e o provisionamento da imagem. Confira o pacote exato e as contas afetadas antes de escolher o reparo.
Preciso remover todos os aplicativos da Microsoft Store?
Não. Comece pelo pacote identificado no log atual. Examine os usuários em que ele está instalado e seu provisionamento e faça alterações direcionadas. Remover aplicativos sem relação com a falha pode modificar o ambiente de referência sem resolver o bloqueio real.
Por que o aplicativo não aparece em Get-AppxProvisionedPackage?
Um aplicativo pode continuar instalado para um usuário existente depois que seu provisionamento foi removido da imagem. Confira também se está comparando o nome e a versão corretos. A ausência de uma entrada provisionada não comprova que a instalação do usuário foi removida.
Por que o Sysprep falha novamente depois de remover um pacote?
Outro pacote pode bloquear a próxima tentativa, ou o pacote original ainda pode existir para outra conta. Leia o log mais recente e compare os registros reais antes de fazer outra alteração.
Posso implantar o ambiente Windows atual sem remover seus aplicativos antes?
O Wittytool Disk Clone pode criar uma imagem do sistema configurado e implantá-la sem executar o Sysprep antes, preservando aplicativos e contas da origem. Faça backup dos dados dos destinos e confira funcionamento, ativação e entradas nos aplicativos dos computadores restaurados.