AstroSkipper

I don't think so, KB3072630 is an update of MSI Installer of 2015.

This link works http://thehotfixshare.net/board/index.php?/files/file/10247-windowsxp-kb968730-x86-enuexe/

@Dave-H Look at this one http://thehotfixshare.net/board/index.php?/files/file/10247-windowsxp-kb968730-x86-enuexe/. It's an update of crypt32.dll, version 5.131.2600.5779 of 2009. The version in my systen32 folder is more recent, it's version 5.131.2600.6459 of 2013.

Maybe in Explorer options you have hidden system files and extensions.

Sorry, I can't see the mentioned files in your folders. I see only the file wsus3setup.cab in first screenshot but in second one none of them. And don't hide your extensions of files. They are important to have a look at.

Error code 0x8007000D means Error_invalid_data. Therefore I think using the XP version won't fix it probably. You have to find another version if it exists at all. Did you copy wsus3setup.cat too? Without it won't work. Both files wsus3setup.inf and wsus3setup.cat are included in cab file wsus3setup.cab.

@maile3241 I've checked the location of wsus3setup.inf once again. The file exists in two folders, one copy is in folder WINDOWS\SoftwareDistribution\SelfUpdate\Default\ and the other in WINDOWS\SoftwareDistribution\WebSetup\. Both files have been accessed by WU. Maybe you missed one location.

Maybe the file version of wsus3setup.inf is incorrect. Search for a version related to Windows 7. Maybe within a normal Window 7 system. wsus3setup.inf is located in folder SoftwareDistribution. But I've never used MU web site in Windows 7 so it is only a guess.

Error code 0x80070002 means ERROR_FILE_NOT_FOUND i.e. the System cannot find the file specified. You have to check your Windows Update Log to see which file can't be found and why.

What is your current error code? Is it 0x80070002?

Where did you read in MDL that KB3072630 should fix "the certificate error"? And which certificate error do you mean? The only post I could find mentioning the update KB3072630 is: But it's referring to Server 2003 or XP x64 and KB3072630 is an older update related to MSI Installer of 2015. The last update of the files msi.dll, msiexec.exe and msihnd.dll was in 2019. Therefore I wonder what this old MSI Installer update should do to fix @Dave-H's Windows Update error code 0x80072f8f.

Maybe you really used it before. I already recommended it some posts before:

You're absolutely right. I mixed up the date with Windows ME. I've checked my earliest image and it must have been created in 2004 but it doesn't exist any more. I had deleted all old images below Service Pack SP3. So my earliest version is of 2009. It had been a long time ago. Sorry for causing confusion!

By the way I have to tell you that the last time I had reinstalled Windows XP Professional was in 2004. Most of all errors I fixed in my system by myself. I hate errors and I have to get rid of them.That's my philosophy. Since 2004 I used constantly images to restore system partition only if nothing helped. Maybe that is a reason I've got some certificates and files in my system you do not have.

If you extract winUpRestore!v28.exe you see what it does. After performing you have to set up Trusted Zone once again. Only the three mentioned urls related to MU. The tool is the latest one. The web site of the author doesn't exist anymore. I think that too but I am not absolutely sure.

Did you use it before? I thought you did only the manual way I posted under "Manually reset Windows Update components (KB971058)".

Ok, due to the fact I've never had this error I forgot the exact wording of the displayed message. Have you tried the method "Turning back time" more than once? Maybe MU actually considers a certificate as invalid and we need the date and time where it was valid. Go back to my provided date in April of 2019 and try once again! If it doesn't work turn back to 2018. Try it more times. And I agree the wording "an update certificate" is misleading and can be interpreted in different ways. I have to think about that. And there is nothing to lose. Try the tool winUpRestore!v28! I have used that and it helped me. Then install the latest WU agent and after that Restore_WU_XP_2003. Only a few steps if "Turning back time" doesn't work again. While researching internet articles related to error code 0x80072F8F I've read consistently this error appears due to invalid SSL certificates used by the Windows Update site and therefore it is suggested to reregister some dll files I posted before. Here is a quotation from original Microsoft knowledge base document: Hope will never die!

Where did you see the message "an update certificate"? I am a bit confused. Here is the link of winUpRestore!v28 if interested: https://web.archive.org/web/20120711072701/http://download.mshelper.de/mshregs/winUpdRestore!v28.exe

Yes, I have all POSReady updates installed. My system had always been updated by Windows Update and if any necassary update wasn't offered I downloaded and installed it. I had some problems to get MU working again but now it is working flawlessly. No error codes. But for resetting Windows Update I used the tool winUpRestore!v28.

@Dave-H Very disappointing! I'd almost have bet on it that this last solution would work for you. But alright. Either you've missed one or more steps which had to be performed or your system is more defective than I previously assumed. Anyway you said you couldn't click the button "Check updates". Maybe due to a misconfigured Internet Explorer. MU web site has been called up as a http web site. Check your settings in Internet Zone, set it to lowest security level and unselect SmartScreen Filter in Advanced tab. Check all other settings of your Internet Explorer. At this point I don't want to conceal what the most effective method is to get rid of error code 0x80072f8f. Most of affected users performed a complete reinstallation of Windows XP and they reported it would have worked. A lot of them were assisted by remote connection to Microsoft and their experts couldn't find the cause of the problem. And what did they do? Of course a complete reinstallation of Windows XP. So what does it tell us? Microsoft itself is the causer of error code 0x80072f8f. What would I do if I were you? At first I'd create an image of my system partition, replace CMOS battery, set up BIOS settings including date and time, clean my registry to get rid of all waste due to incomplete uninstallations and so on, clean complete system and all caches, reset Internet Explorer and Windows Update, perform all steps once again (and when I say all I mean all, regardless of steps or installations I did before) and execute all solutions I've posted here if necessary. If that didn't work I'd reinstall Windows XP or better I'd restore an image which was the last working one. I do have such images. If my system fails seriously I'll restore my system partition in less than 30 minutes and my computer is a very, very old one. Cheers!

@Dave-H Have you already tried this new solution?

@Dave-H And check in form of a binary comparison one more time if the correct patched version of wuaueng.dll still exists in relevant folders. I assume in your system is SFC enabled. Just to be sure.

Of course and definitely not! And I am not omniscient. But I decide what is promising by reading, analyzing, checking facts, concluding and if possible proving. I am mathematician and that's the way these strange people like me do it.

@Dave-H Ok, here is a final solution. If that doesn't work too I'll be out of ideas related to error code 0x80072f8f. You can't find any other solutions in the World Wide Web, nay, despite a very deep research I couldn't find any other reasonable solutions related to this error code except those I've already posted. Before performing this backup the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and the folder WINDOWS\SoftwareDistribution completely or better create an image of your system partition! Here it is: This is a fix if client machines are not reporting to WSUS properly: Client-Side Script: From an administrative command prompt on your system, run: net stop bits net stop wuauserv reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f rd /s /q "%SystemRoot%\SoftwareDistribution" net start bits net start wuauserv wuauclt /resetauthorization /detectnow PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() Explanation: What is this Doing? Should I be Afraid of Running this? This client-side script is something you should not be afraid of. Let’s walk through what is happening and why we’re doing it. We stop the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services because we’re working with items that are in use by these services. We remove the following registry keys if they exist: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\AccountDomainSid (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\PingID (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId (This is what is responsible for most issues – duplicate SusClientId entries across multiple clients) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientIDValidation (This also is responsible with SusClientId) We remove the SoftwareDistribution folder from the Windows folder on the system drive – represented using a dynamic variable. This folder contains the history of Windows Update locally on the machine, but it also includes things like the cache of the downloads and temporary files that Windows Update uses. We remove this folder so that it will be recreated by the Windows Update Agent the next time it checks for updates, creating a corruption-free cache. We start the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services. We run the Windows Update Client (wuauclt) and tell it to reset the authorization to re-create the SusClientId and SusClientIDValidation registry keys. We’ve also stuck on the /detectnow switch on the end of that command to initiate a detection for updates for Windows 8.1 systems and lower. We’ve run the PowerShell equivalent of /detectnow for Windows 10 systems and Server 2016+ systems as they no longer use /detectnow as it has been deprecated. (We can also use UsoClient.exe StartScan instead of the PowerShell line however, Microsoft never intended UsoClient.exe to be used by anything other than the system itself through the orchestrator so your mileage may vary. The correct way is the PowerShell API). Background: What is SusClientId and What Symptoms Does Having Duplicate SusClientId Entries have? WSUS servers use the SusClientId to identify unique devices and then associate the computer’s hostname to the unique identifier for easy recognizable display purposes. Because more than 1 system has the exact same SusClientId, the WSUS server replaces the computer object’s hostname with the latest hostname that communicated with the server. This gives the appearance of a magician’s disappearing act with computers objects. More than 75% of the time that clients have issues, it is due to cloning or imaging computers. Systems that are the ‘golden’ image are often created in an environment that allows the system to communicate with any WSUS server, including Microsoft’s Windows Update. The moment a client system communicates with a Windows Update server, it creates 2 registry keys that are essentially a security identifier (SID) [SusClientId] and a validation key [SusClientIDValidation] that gives a unique hardware identifier in a binary form. The Windows Update Agent is supposed to use a hardware validation routine to determine whether the current client hardware has changed since the SusClientId value was created, and if it has, it is “supposed to” regenerate both the SusClientId and the SusClientIDValidation. “Supposed to” doesn’t always equate to “does” and this is where the problem lies. Note: In my system the subkeys AccountDomainSid and PingID don't exist probably due to the fact that my computer is a stand-alone one. In your system I could see in a screenshot that the subkeys PingID, SusClientId and SusClientIDValidation are present. Therefore I've crossed out all unnecessary steps and explanations including steps for Operation Systems except Windows XP.

I don't believe that this has an effect. In my system I have same date and time format in this key although my regional settings have been set to German DE and nonetheless MU is working flawlessly. @Dave-H Any news? Does changing services mode have any effect? Here is another change to Internet Options of IE, Advanced: unselect "Check for publisher's certificate revocation" too. Note: in my system it is selected at the moment. The entry "Check for server certificate revocation" should already be unselected in any case.