18

I recently inherited the management of a Windows 2012 server at a remote site.

I checked Windows Update and it has not been updating since March. When I tell Windows to check for updates, it acts like it is checking, but it seems to say that for hours. If I attempt to restart the windows update service, it seems to never be able to shut down. My only remedy seems to be rebooting to get back to the point where I can tell Windows Update to check for new updates.

The last successful check for updates says March 20.

The last time updates were installed says March 17 (failed).

The update history shows that one update failed for March 17, a printer driver update, but the history shows 13 failed updates for Feb 17.

Not sure what else to try.

  • Is it pulling the updates directly from Microsoft, WSUS, or SCCM? – Davidw Aug 31 '14 at 16:49
  • 1
    Directly from Microsoft. – Scot Sep 1 '14 at 2:05
  • Stop wuauserv (Windows Update Service), delete \Windows\WindowsUpdate.log, start service, check for update and check WindowsUpdate.log. (it tends to grow rapidly, so it's easier to clean it up before reading). – Somescout Dec 19 '14 at 2:47
  • 1
    What is the exact error in \Windows\WindowsUpdate.log? See support.microsoft.com/kb/938205 for error codes – xXhRQ8sD2L7Z Mar 5 '15 at 23:28
  • It is answered here: serverfault.com/a/830047/398329 I found it helpful. – niveshsaharan Feb 2 '17 at 5:51
19

Two of my three 2012R2 machines exhibited this behavior last April. They would hang at Checking for updates... forever.

I never learned exactly what caused the problem, but I did get it resolved by doing the following:

  1. Stop the Windows Update service.

    net stop wuauserv
    
  2. Delete the Windows Update cache directory C:\Windows\SoftwareDistribution.

    Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution
    
  3. Restart the computer. (On one machine it required several restarts to actually get everything deleted from this directory, so keep trying if necessary.)

  4. Run Windows Update manually again. It will fail almost instantly and offer to run a diagnostic tool. Download the tool and allow it to run.

  5. The tool will find and fix some problems. At this point, run Windows Update manually again. Windows Update worked fine at this point.

  • 3
    Got to step 4, but it did not fail instantly or offer to run a diagnostic tool. It just keeps running with the progress bar cycling over and over, never getting any updates. – Scot Sep 6 '14 at 21:38
  • 1
    Try the linked Windows Update Diagnostic tool at that point, whether Windows offers it or not. – Michael Hampton Nov 13 '15 at 12:55
  • 6
    @MichalSokolowski "There is NO reason, on a properly functioning system, why this folder should ever need to be touched." Indeed, but we are not discussing properly functioning systems here. – Michael Hampton Nov 23 '16 at 17:37
  • 1
    I wanted to underline something else here; destroying Windows Update Agent patch history is really bad idea, because after deletion it lose capability to determine what was patched and what was not. In a nutshell conclusion are (according to that thread): 1) deleting softwaredistribution should be treated as last resort before reformating the box, 2) deleting it need to be preceded by proper diagnosis - i.e. broken DataStore.EDB, desynchronized DataStore.EDB and Download folder - those are most common. Deleting DataStore\Logs contents will destroy patch history. – Michal Sokolowski Nov 23 '16 at 19:26
  • 1
    @MichalSokolowski You probably are right. Still - on every one of my systems, Windows 2k3, 2012, 2012R2, 7, 8, 8.1 (not 10 yet) I have had the same problem. So.. proper analysis is a little difficult unless you want to make a full time job out of it. I am having same problem on other people's machines too, so it cannot be just my fault but must be some general Windows Update problem (especially fresh installs of older OSs). – Andreas Reiff Jan 3 '17 at 21:08
7

i found this great answer here and it worked beautifully for me. Just want to share in case someone is searching:

Try this at an elevated command-prompt:

netsh winhttp import proxy source=ie

and reboot

another solution which worked for me as well was to set update mode to "Never check for updates"

  • What does this do? – GlennG Aug 19 at 9:41
0

I used the System Update Readiness Tool and DISM. It worked for me. You can get it here: http://support.microsoft.com/kB/947821

  • I've used the System Update Readiness Tool recently, and successfully, as well. – Mitch Dec 19 '14 at 0:46
0

I've had been playing around with a 2012 VM and I had this issue. My solution (quick, insecure, etc etc) was to disable the IE Enhanced security on the server and it happily started talking to MS Windows Update. Not a solution for a real server, but it's a toy dev server and I'm ok with that.

Presumably the windows update site just needs to be added to some trusted sites somewhere for a real solution?

0

My fix on a newly Installed on Windows Server 2012 R2 on Citrix 6.5 VM, and as Marcus Greasly posted, disable IE Enchanced Security... worked immediately...

To disable IE enhanced security in windows server 2012 R2, launch the Server Manager, on the left hand side click on Local Server. On the right hand side click on the On link next to IE Enhanced Security Configuration. You will now see the Internet Explorer Enhanced Security Configuration box.

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

0

I have recently have the same issues on my Server 2012 and all I did was disabled the Malwarebytes Service and updates downloaded right away. Try disabling any malware or anti-virus software you have because that could be the root caused.

0

Overview

We had this issue on some virtual servers migrated from a "cloud" provider back to our internal data center. The root cause was permissions to the %SystemRoot%\System32\catroot2 folder. There were a number of differences between the permissions on that folder on a healthy server vs those on the migrated server. I believe the key one was that TrustedInstaller didn't have full access.

Additional Symptoms

Looking at the Application log in the event viewer, we saw a number of errors:

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).

The clue is in the ESENT error's text; i.e. permissions issue accessing a file under the catroot2 folder.

Resolution

Give the Trusted Installer account full control to the catroot2 folder and its children.

In case that's not enough, for comparison, running icacls %systemroot%\system32\catroot2 on a healthy server gives this:

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: To add Trusted Installer, you'll need to search on the local computer accounts for nt service\trustedinstaller.

After replacing permissions on catroot2, ensure you click the replace permissions on child objects & containers checkbox to ensure that child items have their permissions resolved also.

No reboot is required for the fix itself (though obviously, once updates start working again, you'll likely need to reboot for those).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.