Se o Sysprep no Windows Server 2019 está falhando com erro fatal envolvendo o componente Microsoft‑Windows‑EventLog e códigos 0x80070003 / 0x3, a causa mais comum é o redirecionamento de logs via GPO para outro volume. Abaixo trago o diagnóstico completo e a correção definitiva, com comandos prontos.
Visão geral do cenário
Após clonar uma VM de Windows Server 2019 para criar uma imagem golden, o Sysprep /generalize encerrava com erro fatal. No setupact.log (caminho típico: %WINDIR%\System32\Sysprep\Panther\setupact.log), as validações avançavam até a etapa de limpeza do serviço de logs:
... Validate pass success ...
... SysprepGeneralize: Enter
... Processing component Microsoft-Windows-EventLog
... EvtIntSysprepCleanup (wevtapi.dll) started
... dwRet = 0x3, hr = 0x80070003
... Fatal error encountered during sysprep ...
As tentativas comuns — sfc /scannow, ajustar a chave CleanupState no Registro ou desativar o serviço de logs — não surtiram efeito.
O que os códigos de erro significam
| Origem | Código | Significado | Interpretação prática |
|---|---|---|---|
| Retorno interno | dwRet = 0x3 | ERRORPATHNOT_FOUND | O caminho de arquivo/diretório referenciado não existe. |
| HRESULT | hr = 0x80070003 | Path not found (erro Win32 convertido) | O Windows não encontrou o local configurado para os Event Logs. |
| Componente | Microsoft‑Windows‑EventLog | Limpeza de logs do Sysprep | A biblioteca wevtapi.dll tenta acessar/limpar arquivos nos caminhos ativos dos canais. |
Causa raiz comprovada
Os Event Logs estavam redirecionados por GPO/Registro para uma unidade persistente (por exemplo, D:\), prática comum em VMs non‑persistent e ambientes VDI/RDS. Durante a fase Cleanup do Sysprep, o Windows tenta acessar e higienizar os arquivos de log nos caminhos vigentes de cada canal. Se esses caminhos estiverem fora do local padrão (%SystemRoot%\System32\winevt\Logs) e:
- o volume não existir no momento do Sysprep;
- o diretório estiver inacessível;
- ou as ACLs impedirem acesso do serviço Windows Event Log,
o cleanup falha e o Sysprep retorna 0x80070003.
Por que as tentativas comuns não funcionam
sfc /scannow: valida binários do sistema, mas não corrige caminhos de logs definidos por políticas.- Alterar
CleanupState: “apaga o fogo” em uma rodada, mas mantém o caminho inválido; o erro retorna. - Desativar o serviço de logs: o Sysprep depende do Windows Event Log; desativá-lo provoca outras falhas.
Diagnóstico rápido e certeiro
Antes de qualquer alteração, confirme quais canais estão fora do diretório padrão.
Listar canais com caminho fora do padrão
PowerShell
Get-WinEvent -ListLog * |
Where-Object { $.LogFilePath -and ($.LogFilePath -notlike "$env:SystemRoot\System32\winevt\Logs*") } |
Select-Object LogName, LogFilePath |
Format-Table -AutoSize
Se algum LogFilePath aparecer em D:\ (ou outro volume), você encontrou o motivo do erro.
Correção efetiva e segura
Remova o redirecionamento dos logs antes de rodar o Sysprep para que os caminhos voltem ao padrão.
- Mova temporariamente o servidor para uma OU sem a GPO de redirecionamento, ou
- ajuste as chaves de canal para apontar para
%SystemRoot%\System32\winevt\Logs\*.evtx.
Passo a passo recomendado
- Reverter o caminho dos logs para o padrão Remova/ignore a GPO que altera o caminho dos logs ou redefina os principais canais:
PowerShell foreach ($log in 'Application','System','Security','Setup') { wevtutil sl $log /lfn:$env:SystemRoot\System32\winevt\Logs\$log.evtx }Em seguida, atualize políticas:cmd gpupdate /force - Verificar os caminhos atuais
PowerShell Get-WinEvent -ListLog * | Where-Object { $.LogFilePath -and ($.LogFilePath -notlike "$env:SystemRoot\System32\winevt\Logs*") } | Select-Object LogName, LogFilePath | Format-Table -AutoSizeSe ainda houver canais fora do padrão, redefina-os individualmente. Para canais “clássicos”, use os nomes acima. Para canais sobMicrosoft-*/Operational, recomendo primeiro inspecionar o caminho atual:PowerShell wevtutil gl "Microsoft-Windows-GroupPolicy/Operational" | Select-String logFileName Use o valor exibido para criar o .evtx no diretório padrão, se necessário: wevtutil sl "Microsoft-Windows-GroupPolicy/Operational" /lfn:"$env:SystemRoot\System32\winevt\Logs\Microsoft-Windows-GroupPolicy%4Operational.evtx" - Garantir que o serviço Windows Event Log esteja ativo
PowerShell Get-Service EventLog | Set-Service -StartupType Automatic Start-Service EventLog - Executar o Sysprep novamente
cmd %WINDIR%\System32\Sysprep\Sysprep.exe /generalize /oobe /shutdown
Automatização para imagens golden
Para padronizar o processo em laboratórios e pipelines de captura, use o trecho abaixo. Ele faz backup dos caminhos, normaliza os principais canais para o diretório padrão e registra o que foi alterado.
PowerShell
Executar em sessão elevada (Administrador).
$stamp = Get-Date -Format "yyyyMMdd-HHmmss"
$report = "C:\Temp\EventLogs-Paths-$stamp.csv"
New-Item -ItemType Directory -Force -Path (Split-Path $report) | Out-Null
\$logs = Get-WinEvent -ListLog \* | Where-Object { $\_.LogFilePath }
\$logs | Select-Object LogName, LogFilePath | Export-Csv -NoTypeInformation -Path \$report
Redefinir apenas os canais clássicos para o padrão conhecido
'Application','System','Security','Setup' | ForEach-Object {
\$default = Join-Path \$env\:SystemRoot "System32\winevt\Logs\$*.evtx"
Write-Host "Definindo \$* para \$default"
wevtutil sl $\_ /lfn:"\$default"
}
Write-Host "Relatório salvo em \$report" Dica: para canais “Microsoft‑*/Operational”, utilize wevtutil gl <canal> para descobrir o nome de arquivo “oficial” (com %4 no meio) antes de mover.
Onde a GPO costuma alterar o caminho
Administrações variam: algumas usam Preferências de Registro; outras, modelos ADMX/customização. Dois locais que frequentemente carregam o caminho do arquivo:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels<Canal>\FileHKLM\SYSTEM\CurrentControlSet\Services\EventLog<Log clássico>\File
Se uma GPO estiver gravando esses valores para D:\ (ou similar), o Sysprep herdará esses caminhos durante o generalize.
Tabela de verificação rápida
| Verificação | Como fazer | Resultado esperado |
|---|---|---|
| Listar logs fora do padrão | Get-WinEvent -ListLog * com filtro por LogFilePath | Nenhum caminho fora de %SystemRoot%\System32\winevt\Logs |
| Reverter caminhos essenciais | wevtutil sl Application|System|Security|Setup /lfn:<padrão> | Quatro logs clássicos no local padrão |
| Serviço de logs ativo | Get-Service EventLog | Running e Automatic |
| Executar Sysprep | Sysprep.exe /generalize /oobe /shutdown | Conclui sem erros |
Considerações importantes para VMs non‑persistent
- Aplique a GPO de redirecionamento após a captura: deixe a imagem golden no padrão e, somente depois de selada, mova o computador para a OU com redirecionamento.
- Se o redirecionamento for obrigatório já na imagem: assegure que o volume/diretório exista e tenha ACLs apropriadas para o serviço EventLog durante o Sysprep.
- Snapshots são seus aliados: antes de mexer em canais, tire um snapshot da VM.
Boas práticas para evitar recorrência
- Padrão até a selagem: mantenha o caminho default dos logs até concluir o Sysprep.
- Documente canais especiais: alguns produtos criam canais próprios com caminhos customizados; audite antes da captura.
- Evite desativar o Event Log: é pré‑requisito para o Sysprep e para o diagnóstico do próprio sistema.
- Auditoria preventiva: inclua o comando de inventário de
LogFilePathno roteiro de preparação da imagem.
Exemplos de correção para canais específicos
Alguns canais usam nomes de arquivo padronizados com “%4” separando o provedor e o canal. Exemplos:
PowerShell
Política de Grupo (Operational)
wevtutil sl "Microsoft-Windows-GroupPolicy/Operational" `
/lfn:"$env:SystemRoot\System32\winevt\Logs\Microsoft-Windows-GroupPolicy%4Operational.evtx"
Windows Update (Operational)
wevtutil sl "Microsoft-Windows-WindowsUpdateClient/Operational" \`
/lfn:"\$env\:SystemRoot\System32\winevt\Logs\Microsoft-Windows-WindowsUpdateClient%4Operational.evtx" Erros frequentes e como evitá-los
- Assumir que “apenas os quatro clássicos” bastam: em muitos ambientes é suficiente, mas soluções de segurança/backup criam canais extras; verifique todos os
LogFilePath. - Permissões insuficientes: se insistir em armazenar logs fora do sistema, garanta que a conta do serviço Event Log possa criar e escrever arquivos no diretório.
- Montagem tardia de volumes: volumes anexados por script no startup podem não existir durante o Sysprep; resultará em
0x80070003.
Como ler o setupact.log de forma objetiva
Procure por trechos próximos a “EventLog” e “Cleanup” para focar no ponto da falha:
PowerShell
Select-String -Path "$env:WINDIR\System32\Sysprep\Panther\setupact.log" `
-Pattern "EventLog|Cleanup|wevtapi|0x80070003" -Context 2,2
Em paralelo, verifique o setuperr.log no mesmo diretório para mensagens resumidas do erro.
Resumo em termos operacionais
Problema: o Sysprep falha na limpeza do componente Microsoft‑Windows‑EventLog com 0x80070003 porque os caminhos dos Event Logs apontam para um local inexistente/inacessível.
Solução: remover o redirecionamento antes do Sysprep, restaurando os logs para %SystemRoot%\System32\winevt\Logs, garantir o serviço Event Log ativo e então executar o Sysprep.
Perguntas frequentes
Posso manter os logs em D:\ e ainda assim rodar o Sysprep?
Sim, desde que durante o Sysprep o volume e o diretório existam e permitam escrita pelo serviço Event Log. Na prática, é mais seguro manter o padrão até a selagem e aplicar o redirecionamento depois.
Preciso reiniciar para que o wevtutil sl tenha efeito?
Para os logs clássicos, normalmente não. Para alguns canais, a mudança é aplicada imediatamente; para outros, ocorre na próxima inicialização. Como o Sysprep reinicia/desliga ao final, isso não costuma ser um problema.
E se o erro continuar após voltar ao padrão?
Revise se algum canal “Microsoft-*/Operational” continua apontando para outro volume, verifique permissões no diretório padrão, limpe arquivos .evtx corrompidos (renomeie-os) e confira se a GPO não está reaplicando o caminho inesperadamente.
Conclusão
Quando o Sysprep do Windows Server 2019 para em EvtIntSysprepCleanup com 0x80070003, quase sempre o culpado é um caminho de Event Log fora do padrão. Reverter temporariamente para %SystemRoot%\System32\winevt\Logs, garantir o serviço em execução e só depois selar a imagem elimina o erro de forma definitiva. Caso precise redirecionar novamente, faça-o após capturar o golden image — ou crie as condições para que o caminho alternativo exista durante o processo. Esse cuidado simples economiza horas de tentativas e reforça a confiabilidade do seu pipeline de imagens.