Você iniciou a captura de uma imagem Windows Server 2025 (24H2 Build 26100.2314) em Audit Mode, executou o Sysprep e recebeu o temido erro 0x80073cf2 apontando para o pacote Microsoft.Winget.Source. A falha interrompe o processo de generalização e impede a criação do WIM final. Este guia detalhado explica o motivo, mostra como corrigir o problema com PowerShell e oferece práticas recomendadas para evitar que o erro volte a ocorrer.
Visão geral do erro Sysprep 0x80073cf2 no Windows Server 2025
O Sysprep precisa garantir que todos os aplicativos UWP provisionados na imagem existam em cada perfil de usuário. Quando um app é instalado ou atualizado apenas para o usuário de auditoria (Administrator), mas não está “provisionado” globalmente, ocorre um descompasso entre os perfis e o Sysprep falha. Na build 26100.2314, o componente Windows Package Manager (Microsoft.Winget.Source) costuma ser baixado silenciosamente pela Microsoft Store logo após a primeira conexão à internet, gerando a mensagem:
Package Microsoft.Winget.Source… was installed for a user, but not provisioned for all users.
SYSPRP Failed to remove apps for the current user: 0x80073cf2Por que o Sysprep exige apps provisionados?
O objetivo do Sysprep é entregar uma imagem limpo, consistente e preparada para o OOBE. Se um pacote existe apenas em um perfil:
- Outro usuário pode não ter as dependências exigidas pelo sistema.
- O app pode tentar se instalar novamente no primeiro logon, atrasando o processo de instalação.
- A remoção seletiva de apps deixa resíduos no registro e no diretório
%ProgramFiles%\WindowsApps.
Para evitar essas situações, o Sysprep aborta caso encontre discrepâncias.
Diagnóstico rápido
Abra o PowerShell elevado e execute:
Get-AppxPackage -AllUsers |
Where-Object { $_.PackageFullName -like 'Winget.Source' }Caso o comando retorne uma linha, você confirmou que o pacote existe para o usuário mas não está provisionado globalmente. Para validar o provisionamento:
Get-AppxProvisionedPackage -Online |
Where-Object { $_.DisplayName -like 'Winget.Source' }Se não retornar nada, o app não foi provisionado, tornando-se o culpado do erro.
Correção passo a passo
1 Detectar o pacote problemático
No exemplo abaixo, adaptamos o comando para procurar qualquer app responsável pela falha, substituindo o curinga conforme necessário:
$Suspect = 'Winget.Source'
Get-AppxPackage -AllUsers |
Where-Object { $_.PackageFullName -like $Suspect } |
Select PackageFullName, InstallLocation2 Remover o app para todos os perfis
Com o nome exato em mãos, remova o pacote de todos os usuários já existentes:
Get-AppxPackage -Name Microsoft.Winget.Source -AllUsers |
Remove-AppxPackage -AllUsers3 Desprovisionar o app da imagem
Agora elimine a entrada de provisionamento para que usuários futuros não recebam o app automaticamente:
Get-AppxProvisionedPackage -Online |
Where-Object { $_.DisplayName -like 'Microsoft.Winget.Source*' } |
Remove-AppxProvisionedPackage -Online4 Bloquear a Microsoft Store durante o Audit Mode (opcional, mas recomendado)
Qualquer atualização posterior da Store recriará o problema. Para garantir uma imagem estável:
- Desconecte o adaptador de rede antes de iniciar o Audit Mode ou
- No app Store, abra Settings › App settings e desative Update apps automatically.
Se usar configuração unattended, você pode definir a política DisableStoreApps no arquivo unattend.xml ou via GPO localizada em Computer Configuration › Administrative Templates › Windows Components › Store.
5 Executar novamente o Sysprep
Com o pacote removido e a Store bloqueada, execute:
sysprep /generalize /oobe /shutdownO utilitário deve finalizar sem erros, permitindo capturar o WIM via Dism /Capture-Image ou a ferramenta de sua preferência.
Automatizando a detecção e correção
Para equipes que gerenciam múltiplas linhas de produção, uma abordagem programática economiza tempo. O script abaixo procura todos os pacotes instalados que não aparecem na lista de provisionados e remove ambos:
# Detectar pacotes desprovisionados
$Installed = Get-AppxPackage -AllUsers
$Provisioned = Get-AppxProvisionedPackage -Online
$Mismatch = $Installed |
Where-Object { $prov = $Provisioned | ? { $.PackageName -eq $.Name }
-not $prov }
foreach (\$pkg in \$Mismatch) {
Write-Host "Removendo \$(\$pkg.Name)..."
Remove-AppxPackage -Package \$pkg.PackageFullName -AllUsers -ErrorAction SilentlyContinue
Remove-AppxProvisionedPackage -Online -PackageName \$pkg.Name -ErrorAction SilentlyContinue
}Inclua esse script antes de chamar o Sysprep em seu processo de build automatizado (Task Sequence, Packer, DevOps Pipeline etc.).
Tabela de códigos de erro Sysprep relacionados a UWP
| Código | Mensagem típica | Causa principal | Solução resumida |
|---|---|---|---|
| 0x80073cf2 | Failed to remove apps for the current user | App instalado para usuário, não provisionado | Remover app + provisionamento |
| 0x0f0070 | Failed to remove the staged package | Pacote removido manualmente da pasta WindowsApps | Reinstalar e remover por PowerShell |
| 0x80073cfb | Package failed because either resources or manifest are invalid | Atualização incompleta de app UWP | Reparar com DISM e remover app |
| 0x80073cfa | Package or dependency missing | Dependência UWP ausente | Instalar dependência ou remover app |
Perguntas frequentes
Posso simplesmente desabilitar a Microsoft Store? Sim. Definir a política DisableStoreApps impede atualizações de UWP e garante consistência, mas alguns componentes de sistema (por exemplo Web Experience Pack) também deixam de receber correções. O problema ocorre apenas com Microsoft.Winget.Source? Não. Qualquer aplicativo UWP — Outlook (Mail), Clipchamp, BingSearch, Teams (Preview) e outros — pode acionar o erro se for atualizado durante o Audit Mode. Funciona no Windows 11 24H2? Sim. A mesma estratégia de remoção e desprovisionamento vale para Windows 11 24H2, que compartilha a base de pacotes da plataforma WCO. Sysprep não é mais necessário com cloud‑managed devices? Embora o Autopilot simplifique implantações, muitos datacenters ainda necessitam de imagens personalizadas para cumprir requisitos de compliance, hardening ou apps legados. Portanto, Sysprep permanece relevante.
Considerações específicas para Windows Server 2025
O Windows Server tradicionalmente não inclui a Microsoft Store, mas a edição 24H2 traz componentes Inbox Apps de gerenciamento moderno (Clipchamp, Telephone, Photos). Mesmo sem UI gráfica, serviços em segundo plano podem baixar atualizações. Recomenda‑se:
- Aplicar a política Turn off Automatic Download and Install of updates no WSUS ou Intune.
- Criar um arquivo
setupcomplete.cmdque execute o script de limpeza de UWP antes de desligar o servidor base. - Validar a imagem com
DISM /Online /Cleanup‑Image /AnalyzeComponentStorepara detectar pacotes pendentes.
Boas práticas para evitar futuras falhas do Sysprep
- Mantenha o ambiente offline durante todo o Audit Mode ou use proxy/firewall para bloquear storeedgefd.dsx.mp.microsoft.com e domínios de conteúdo.
- Execute validação automática com o script acima sempre que abrir a imagem para manutenção.
- Documente alterações no repositório de configurações para rastrear inclusões de UWP.
- Atualize a imagem‑mestre regularmente, reduzindo a janela de tempo em que apps podem ficar desatualizados e gerar conflitos.
Conclusão
O erro 0x80073cf2 durante o Sysprep no Windows Server 2025 (24H2) é causado, na maioria das vezes, por apps UWP que foram instalados ou atualizados apenas para o usuário de auditoria. Identificar o pacote, removê‑lo de todos os perfis e desprovisioná‑lo elimina o bloqueio e permite concluir a generalização. Ao adotar controles de atualização da Store, scripts de limpeza e validação contínua, você garante imagens estáveis e prontas para implantação em larga escala, sem surpresas em ambientes críticos.