Windows Update no funciona en Windows 2012 R2 Standard


18

Recientemente heredé la administración de un servidor Windows 2012 en un sitio remoto.

Revisé Windows Update y no se ha actualizado desde marzo. Cuando le digo a Windows que busque actualizaciones, actúa como si lo estuviera haciendo, pero parece decirlo durante horas. Si intento reiniciar el servicio de actualización de Windows, parece que nunca se puede cerrar. Parece que mi único remedio es reiniciar para volver al punto en que puedo decirle a Windows Update que busque nuevas actualizaciones.

La última verificación exitosa de actualizaciones dice el 20 de marzo.

La última vez que se instalaron actualizaciones dice el 17 de marzo (falló).

El historial de actualizaciones muestra que una actualización falló el 17 de marzo, una actualización del controlador de la impresora, pero el historial muestra 13 actualizaciones fallidas para el 17 de febrero.

No estoy seguro de qué más probar.


¿Extrae las actualizaciones directamente de Microsoft, WSUS o SCCM?
Davidw

1
Directamente de Microsoft.
Scot

Detenga wuauserv (Servicio de actualización de Windows), elimine \ Windows \ WindowsUpdate.log, inicie el servicio, busque actualizaciones y compruebe WindowsUpdate.log. (tiende a crecer rápidamente, por lo que es más fácil limpiarlo antes de leerlo).
Somescout

1
¿Cuál es el error exacto en \ Windows \ WindowsUpdate.log? Consulte support.microsoft.com/kb/938205 para ver los códigos de error
xXhRQ8sD2L7Z

Aquí se responde: serverfault.com/a/830047/398329 Lo encontré útil.
niveshsaharan

Respuestas:


20

Dos de mis tres máquinas 2012R2 exhibieron este comportamiento en abril pasado. Se quedarían en Comprobando actualizaciones ... para siempre.

Nunca supe exactamente qué causó el problema, pero lo resolví haciendo lo siguiente:

  1. Detenga el servicio de actualización de Windows.

    net stop wuauserv
    
  2. Elimine el directorio de caché de Windows Update C:\Windows\SoftwareDistribution.

    Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution
    
  3. Reinicia la computadora. (En una máquina, se requirieron varios reinicios para eliminar todo de este directorio, así que siga intentándolo si es necesario).

  4. Ejecute Windows Update manualmente nuevamente. Fallará casi al instante y ofrecerá ejecutar una herramienta de diagnóstico. Descargue la herramienta y permita que se ejecute.

  5. La herramienta encontrará y solucionará algunos problemas. En este punto, ejecute Windows Update manualmente nuevamente. Windows Update funcionó bien en este punto.


3
Llegué al paso 4, pero no falló al instante ni ofreció ejecutar una herramienta de diagnóstico. Simplemente sigue funcionando con la barra de progreso ciclando una y otra vez, sin obtener actualizaciones.
Scot

1
Pruebe la herramienta de diagnóstico de actualización de Windows vinculada en ese momento, ya sea que Windows la ofrezca o no.
Michael Hampton

66
@MichalSokolowski "No hay ninguna razón, en un sistema que funcione correctamente, por la que esta carpeta debería ser tocada". De hecho, pero no estamos discutiendo los sistemas que funcionan correctamente aquí.
Michael Hampton

1
Quería subrayar algo más aquí; destruir el historial de parches del Agente de Windows Update es realmente una mala idea, porque después de la eliminación pierde la capacidad de determinar qué se parchó y qué no. En pocas palabras, las conclusiones son (de acuerdo con ese hilo): 1) la eliminación de la distribución softwared debe tratarse como último recurso antes de reformatear el cuadro, 2) la eliminación debe ir precedida de un diagnóstico adecuado, es decir, DataStore.EDB roto, DataStore.EDB desincronizado y Descargar carpeta: esos son los más comunes. Eliminar el contenido de DataStore \ Logs destruirá el historial de parches.
Michal Sokolowski el

1
@MichalSokolowski Probablemente tengas razón. Aún así, en cada uno de mis sistemas, Windows 2k3, 2012, 2012R2, 7, 8, 8.1 (aún no 10) he tenido el mismo problema. Entonces ... el análisis adecuado es un poco difícil a menos que quieras hacer un trabajo a tiempo completo. También tengo el mismo problema en las máquinas de otras personas, por lo que no puede ser solo culpa mía, sino que debe ser un problema general de Windows Update (especialmente nuevas instalaciones de sistemas operativos más antiguos).
Andreas Reiff

7

Encontré esta gran respuesta aquí y funcionó muy bien para mí. Solo quiero compartir en caso de que alguien esté buscando:

Pruebe esto en un símbolo del sistema elevado:

netsh winhttp import proxy source=ie

y reiniciar

otra solución que también funcionó para mí fue establecer el modo de actualización en "Nunca buscar actualizaciones"


Que hace esto?
GlennG


0

He estado jugando con una VM 2012 y tuve este problema. Mi solución (rápida, insegura, etc.) fue deshabilitar la seguridad mejorada de IE en el servidor y felizmente comenzó a hablar con MS Windows Update. No es una solución para un servidor real, pero es un servidor de desarrollo de juguetes y estoy de acuerdo con eso.

Presumiblemente, el sitio de actualización de Windows solo necesita agregarse a algunos sitios confiables en algún lugar para una solución real


0

Mi solución en un recién instalado en Windows Server 2012 R2 en Citrix 6.5 VM, y como Marcus Greasly publicó, deshabilitar IE Enchanced Security ... funcionó de inmediato ...

Para deshabilitar la seguridad mejorada de IE en Windows Server 2012 R2, inicie el Administrador del servidor, en el lado izquierdo, haga clic en Servidor local. En el lado derecho, haga clic en el enlace Activado junto a Configuración de seguridad mejorada de IE. Ahora verá el cuadro Configuración de seguridad mejorada de Internet Explorer.

https://prajwaldesai.com/disable-ie-enhanced-security-in-windows-server-2012-r2/


0

Recientemente tuve los mismos problemas en mi servidor 2012 y todo lo que hice fue deshabilitar el servicio Malwarebytes y las actualizaciones se descargaron de inmediato. Intente deshabilitar cualquier software malicioso o antivirus que tenga porque esa podría ser la raíz.


0

Visión general

Tuvimos este problema en algunos servidores virtuales migrados de un proveedor "en la nube" a nuestro centro de datos interno. La causa raíz fueron los permisos a la %SystemRoot%\System32\catroot2carpeta. Hubo una serie de diferencias entre los permisos en esa carpeta en un servidor en buen estado frente a los del servidor migrado. Creo que la clave fue que TrustedInstallerno tenía full access.

Síntomas adicionales

Al observar el registro de la aplicación en el visor de eventos, vimos una serie de errores:

Source: CAPI2
EventId: 257
Text: The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.

Source: ESENT
EventId: 490
Text: Catalog Database (416) Catalog Database: An attempt to open the file "C:\Windows\system32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\catdb" for read / write access failed with system error 5 (0x00000005): "Access is denied. ".  The open file operation will fail with error -1032 (0xfffffbf8).

La pista está en el texto del error ESENT; es decir, problema de permisos al acceder a un archivo en la carpeta catroot2.

Resolución

Dele a la cuenta de Trusted Installer control total sobre la carpeta catroot2 y sus elementos secundarios.

En caso de que eso no sea suficiente, en comparación, la ejecución icacls %systemroot%\system32\catroot2en un servidor en buen estado da esto:

C:\Windows\system32\catroot2 NT SERVICE\CryptSvc:(F)
                         NT SERVICE\CryptSvc:(OI)(CI)(IO)(F)
                         NT SERVICE\TrustedInstaller:(I)(F)
                         NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                         NT AUTHORITY\SYSTEM:(I)(F)
                         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Administrators:(I)(F)
                         BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Users:(I)(RX)
                         BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                         CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

NB: para agregar Trusted Installer, deberá buscar en las cuentas de computadoras locales nt service\trustedinstaller.

Después de reemplazar los permisos catroot2, asegúrese de hacer clic en la replace permissions on child objects & containerscasilla de verificación para asegurarse de que los elementos secundarios también tengan sus permisos resueltos.

No se requiere reiniciar para la corrección en sí (aunque, obviamente, una vez que las actualizaciones comiencen a funcionar nuevamente, es probable que deba reiniciarlas).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.