Sysprep fatal error 0x80070003 en Windows Server 2019 clonado: causa y solución definitiva

Tras clonar una máquina virtual con Windows Server 2019 Standard, el Asistente de preparación del sistema (Sysprep) puede detenerse con un “fatal error” inmediatamente después de iniciar la fase de limpieza. Este artículo explica — de forma práctica y en profundidad — por qué sucede el fallo 0x3/0x80070003 y cómo resolverlo sin perder tiempo.

Síntomas del problema

• Sysprep se ejecuta correctamente hasta la fase Generalize, pero finaliza con el mensaje “Sysprep was not able to validate your Windows installation” y un código genérico de error.
• En C:\Windows\System32\Sysprep\Panther\setupact.log se registra el evento:
  SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'Microsoft-Windows-EventLog-EvtIntSysprepCleanup', returned exit code 0x3
• El archivo setuperr.log no reporta errores adicionales.
• Los diagnósticos clásicos — sfc /scannow, comprobación de antivirus, contador de rearmes, servicios dependientes — no encuentran irregularidades.

¿Qué es Sysprep y por qué es crítico?

Objetivo de Sysprep

Sysprep “generaliza” la instalación de Windows eliminando identificadores únicos (SID, GUID de red, tokens de activación, etc.) y reinicia varios subsistemas para que la misma imagen pueda desplegarse en múltiples equipos sin colisiones de identidad ni violaciones de licencia.

Fases internas

1. Initialize: comprueba que el equipo pueda generalizarse (contador de rearmes > 0, versión de SO soportada, etc.).
2. Specialize: elimina SIDs, restablece la caché de WinSxS y borra claves de activación.
3. Cleanup: los componentes de Windows ejecutan tareas propias de limpieza; aquí actúa el módulo Microsoft‑Windows‑EventLog.
4. Shutdown: apaga la máquina lista para capturar como imagen.

Cuando cualquiera de esas fases detecta un obstáculo, Sysprep aborta inmediatamente para proteger la integridad de la imagen generada.

Análisis del error 0x80070003 en la fase Cleanup

Interpretación del código

En Windows, 0x80070003 equivale a ERRORPATHNOT_FOUND. Sysprep no localiza la ruta que necesita uno de sus módulos — en este caso, el servicio de registro de eventos (Event Log).

Desglose del log

[SysprepCleanup] EvtIntSysprepCleanup entered
[SysprepCleanup] Querying log location...
[SysprepCleanup] WARNING: Log path D:\EventLogs\System.evtx not found
[SysprepCleanup] ERROR: 0x3 (ERRORPATHNOT_FOUND)
ActionPlatform::LaunchModule: ErrorCode 0x3
Sysprep: SysprepCleanup returned 0x3

La pista esencial está en la advertencia: Sysprep busca los archivos de registro en D:\EventLogs, pero esa carpeta ya no existe o no está disponible durante la operación.

Causa raíz: redirección de Event Logs mediante GPO

Muchas organizaciones trasladan los registros de eventos a un volumen distinto del disco del sistema para:

• Evitar llenar la partición %SystemDrive%.
• Aislarlos en discos de mayor rendimiento.
• Protegerlos con políticas de retención separadas.

La redirección suele aplicarse con la directiva de grupo:

Configuración del equipo ▸ Directivas ▸ Configuración de Windows ▸ Configuración de seguridad ▸ Directivas de auditoría avanzada ▸ Ruta y tamaño de archivo de registro

Durante la ejecución de Sysprep, el servicio EventLog intenta vaciar, recrear o mover los archivos *.evtx. Si la GPO apunta a un volumen que no está montado o que se desmonta dinámicamente, Sysprep detiene la generalización para evitar inconsistencias de auditoría.

Solución paso a paso

1. Ubica la GPO responsable
   Usa gpresult /h gpo.html o la consola GPMC para identificar la directiva “Ruta y tamaño de archivo de registro”.
2. Aísla temporalmente la VM
   
   # PowerShell $ou = "OU=Laboratorio,DC=contoso,DC=local" Move-ADObject -Identity "CN=SRV-CLON,CN=Computers,DC=contoso,DC=local" -TargetPath $ou También puedes deshabilitar o desvincular la GPO si el entorno lo permite.
3. Reinicia la máquina virtual
   Durante el arranque, sin la directiva aplicada, el servicio Event Log regresa los archivos a %SystemRoot%\System32\winevt\Logs.
4. Ejecuta de nuevo Sysprep
   
   sysprep /generalize /oobe /shutdown El proceso se completa sin errores.
5. Vuelve a aplicar la GPO
   Después de capturar la imagen o desplegar la VM, restaura la pertenencia de la máquina a su OU original. La redirección volverá a activarse, pero ya no interfiere con Sysprep.

Medidas que no resuelven este escenario

En foros y KBs encontrarás las siguientes sugerencias. Funcionan para otros fallos, pero no cuando la ruta de los logs es el problema:

Acción propuesta	Motivo de su ineficacia
Modificar CleanupState en HKLM\SYSTEM\Setup\Status\SysprepStatus	Solo rehace el paso fallido; la ruta sigue siendo incorrecta y volverá a fallar.
Deshabilitar el servicio Event Log (GUI o registro)	Sysprep necesita el servicio para cerrar y regenerar los archivos de log; si está detenido, aborta igualmente.
Reiniciar en Modo Seguro	No carga GPOs, pero tampoco ejecuta Sysprep completo.

Buenas prácticas antes de generalizar una imagen

• Verifica con wevtutil gl <NombreLog> que los logFilePath apuntan a %SystemRoot% o a una unidad permanente.
• Confirma que el contador de rearmes (SkipRearm) no está en cero.
• Comprueba que no existan actualizaciones en estado pendiente de reinicio, ya que algunas reescriben SIDs durante la fase Specialize.
• Desactiva o desinstala software con drivers de filtrado (antivirus, DLP, EDR) que puedan bloquear accesos de escritura.
• Vacía %TEMP% y elimina perfiles locales huérfanos para reducir el tamaño de la imagen.

Checklist rápida (descargable)

- [ ] Event Logs en ruta por defecto
- [ ] Contador de rearmes > 0
- [ ] No hay actualizaciones pendientes
- [ ] BitLocker desactivado o máquina en llave automática
- [ ] Antivirus deshabilitado temporalmente
- [ ] Servicios de terceros detenidos
- [ ] Perfiles temporales eliminados
- [ ] Sysprep ejecutado con privilegios de administrador local

Detección automática con PowerShell

El siguiente script escanea los registros configurados y alerta si alguno reside fuera de %SystemRoot%. Incorpóralo a tu pipeline de DevOps para validar plantillas de VM:

#Requires -RunAsAdministrator
$logs = wevtutil el
$err  = @()
foreach ($l in $logs) {
    $info = wevtutil gl "$l" 2>$null
    if ($info -match 'logFilePath\s+:\s+([^\r\n]+)') {
        $path = $Matches[1]
        if ($path -notlike "$env:SystemRoot*") {
            $err += "$l --> $path"
        }
    }
}
if ($err.Count) {
    Write-Error "Registros redirigidos detectados:`n$($err -join \"`n\")"
    exit 1
} else {
    Write-Host 'OK: Todos los registros están en la ruta predeterminada.'
}

Preguntas frecuentes

¿Puedo mantener la redirección y aun así usar Sysprep?

Sí. Aplica la GPO después de desplegar la imagen generalizada (mediante un script de arranque, Intune o un paso de tarea en MDT/SCCM).
¿El problema afecta solo a Windows Server 2019?

No. Cualquier versión de Windows que soporte la configuración de ruta personalizada corre el mismo riesgo si Sysprep necesita acceder a una ubicación inexistente.
¿Cómo valido el contador de rearmes?

Ejecuta slmgr /dlv y verifica que “Remaining Windows Rearm Count” sea mayor que cero.

Conclusión

Cuando Sysprep falla con 0x80070003 en una VM clonada, la causa más probable es que la ruta de los archivos .evtx haya sido redirigida a un volumen inaccesible mediante GPO. El remedio es tan simple como retirar la directiva, reiniciar y volver a ejecutar Sysprep. Con este procedimiento, podrás capturar imágenes limpias y reutilizables, manteniendo la gobernanza sobre los registros de eventos una vez desplegadas.