Windows Update error - 0x80072f8f

Hey guys, I figured it was finally time to register with this forum...

I get this error while trying to update a copy of windows7 professional. My time IS correct, syncronized to the windows time server.

I work as a navy contractor. I hardened this machine per DISA's hardening requirements. This means some things get disabled, like "automatic updates" Lots of netowork protocol stuff gets edited in the secuirty policy also. I should (i think) still be able to update the machine by clicking the windows update button though. "BITS" works, and the "windows update" service is up, but no worky.

Second thing it may be... The install is not-yet activated. We have a number of identical machines here and I'm trying to make a depolyable image. After I deploy the image, I can activate each with a seperate license. Would the system NOT being activated be an issue? I'm trying to eliminate this variable as we speak by re-imaging the origional install from before I hardened it.

Third thing - As we do work for the governmnet, there is no "internet" here. We have government networks that require a number of accreditations to allow them to be put on the network. So I have this computer accessing the internet through a shared connection on my laptop's Verizon 3g air card. My boss is doing a YUM update on his linux test computer right now, so I know it physically WORKS. Internet works on this computer also.

Any ideas? Please tell me you have ideas.

Edit: Just finished loading the pre-hardened image and it seems to be working, so there's a setting SOMEWHERE

The date / time on your computer is too different from the date / time of the SSL (Secure Sockets Layer) certificates used by the Windows Update site.

Check you have the correct time and date and time zone.

How do you get updates if you don't have internet access?

If this is fed via satellite etc then maybe wherever this link is coming from should be the date time you use (and whether the daylight savings time flag is checked or not).

It's not a clock issue. Maybe it's an SSL issue on the computer, but as I just said, the time is syncronized with the microsoft time server.
Also, when I loaded a base install of windows7 (not hardened) windows update works fine.

We get updates via the air card I have in the laptop. It's a verizon 3g card with internet connection sharing on. It's shared to the ethernet port, which goes to a switch, which goes to the computer.

Also some sites suggest registering your DLLs ...

Register Softpub.dll, Wintrust.dll, Initpki.dll, and Mssip32.dl Files

Open Start menu, select Run, and then run this for each of the four DLLs: regsvr32 filename where filename is the dll


(I haven't tried this so I don't know if you need the DLLs full path or just the short filename so if you get an error I suppose you would try it with the full path)

Okay so maybe I'm getting somewhere.

The first and fourth dlls registered without issue.
wintrust.dll and Initpki.dll both had errors.
wintrust failed with error 0x80070005
Initpki.dll says "make sure the binary is sotred at the specified path or debug it to check for plobles with the binary or dependant .dll files"

edit: looks like wintrust was a permissions issue, ran as admin and it worked

So I rebooted and it still doesn't work ;-(

Only things I saw said it has to do with your clocks being too far out of sync with what the windows update site SSL certificates timestamps are. As I said, I don't understand how you can get to the updates server w/o internet connection anyway.

we have the internet. Like I said twice, we have a verizon broadband card on a laptop with a shared ethernet connection.

The computer needs to be updated, scanned with the network vulnerabilty scanner (eEye retina) and DISA's gold-disk.

So a recent development, if I put in the department of defense's WSUS server in gpedit... it works. Clearly the DoD's WSUS lacks some security protocol that Microsoft's has and is disabled/limited by my procedures.

So is it solved, can you leave the DOD server in there?

I dunno if I'd call it solved... I got it working, but regular WSUS still doesn't work