The gist of it is that .NET 4 updates fail to install due to trust issues and the only way around it is to either install them as a local admin who was created before the machine was joined to the domain or to manually install a cert from the standalone installer and then muddy through it that way.

There's a .NET update preparation tool that you can download from Microsoft that eventually fixed this issue on one of my PCs. You can find it by following the troubleshooting links from Windows Update.

After some searching I found out that it had to do with the Group Policy Object of our domain. So a security policy verifies the certificate for some reason. I still don't know which policy it is. I am even Administrator on my machine.

Yeah, but I can't log in as it due to the fingerprint solution we have in place. It doesn't allow logins to the local machine, only the domain. So I guess I could boot into safe mode to try. Or, I can use the main MAIN domain admin since it's the same non-standard name as the initial local admin we use to set up the machine.

But I'd rather us use our "admin" accounts which are special IT staff accounts that are also domain admins rather than the generic main domain admin account. As it is, I have a workaround, kinda, but I'd rather find out what the issue is. If it's our domain causing a problem, that should be fixed!

It's nothing with the firewall. Stuff not on the domain on the inside network can update just fine. So it's definitely related to the domain and I guess the GPO. But why just .NET 4 updates? And only some of 'em? I started trolling through the event viewer and got a bunch of pain.

But from what I read, this was in the NoProxy action container (or whatever) so it shouldn't have been looking for a proxy anyway? We don't use any web proxy 'ere. I also see a few:

[Result value="80092013"]The revocation function was unable to check revocation because the revocation server was offline.[/Result] [Result value="800B010E"]The revocation process could not continue - the certificate(s) could not be checked.[/Result]

Ok we use a MSUS server for managing our updates. Still not sure why the original/domain admin logging in would skip that since it's a machine policy and should still be downloading/checking from our MSUS server regardless, but perhaps this is the problem.

I find senseless breakage like this to be extremely frustrating/aggravating. Makes me really glad that there's a new guy at the office who has taken over some of the day-to-day Windows sysadmin stuff, so I don't have to do all of it myself any more.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

Now look here, son, everything is pointing towards some GPO issue, not a DLL registration issue. So why don't you...

...what's this now? It fixed it on one of the XP machines? The hell? But but but... ARGH! What's going on here?

Thanks for the heads up with this. I can deploy that as part of a login.bat to most of the machines in the organization if it works on other XP machines as well. Doesn't seem to help with Win7, though, and initpki.dll isn't there for Win7 (or not where it's expecting it to be). I'll take a looksee in the morn and see what more I can discern.

Well, I've been using that as a batch file for years, which is why it still calls for initpki.dll. I would suggest that you try running the update package found in the "Windows 7, Windows Vista or Windows Server 2008" section in the link that I posted.

Also, as a last resort, you can try to uninstall .NET and reinstall. That can be a bit of a pain sometimes, especially if you have software installed that is dependent on .NET. Link.

Heavy is good, heavy is reliable. If it doesn't work, you can always hit them with it.

More failures on KB2604121 and KB2656406 today. I'm doing some more testing and it seems like initpki.dll is the main culprit. Yeah, I was hoping to get around the Win7-specific "fix" because it's a 300 MB .msu I'll have to run. Ugh.

Just the client profile. I don't believe I did 3 and 3.5 but this is an organization-wide thing and I don't really want to have to do this for each machine, know what I mean?

regsvr32 initpki.dll /s

This seems to be the key. It does not seem to last, though. I don't know if the next .NET 4 update kills it or if it dies on a reboot. I do know that I have to run it again for the next round of .NET 4 updates. I also ran it and had an office 2010 update and the malicious software update fail, 16 out of 18 worked, then upon reboot I had 18 again to do and this time it was the 2 .NET updates that failed. Another reboot, re-register that dll, run the updates, and it worked fine.

So for my particular scenario, it seems like I have to install the .NET updates by themselves after they fail lest I somehow jack up the rest of the update process. Still doing some testing but these aren't the fastest machines anymore so it's takin' a bit o' time.

Last edited by Scrotos on Tue Jan 08, 2013 11:00 am, edited 1 time in total.

I don't understand exactly how this bitmask works. It hurts my head with the negative values. I guess the baseline is 0x20300 instead of 0x00.

At some point someone who set up the domain said, "these values are for SECURITY!" and for only .NET 4 it jacks up the updates. I might take a gander at something like http://www.nsa.gov/ia/_files/app/I731-008R-2006.pdf to see if I can understand more about what these settings do and what risks are involved with our current default settings.

It's Microsoft's version of JAVA (write managed code to a virtual machine target, right?) and programs use it. I think even ATI's Catalyst Control Center uses/requires it as well? So at some point you'll want SOME version of it installed.

Well, I need to fix the security bitmask in the GPO one day, but for now when we get random .NET 4 install fails, I have a .bat I run:

@echo offsetreg 5 true

Run it then re-try the install/updates. Or, run it first and then do the updates. It's temporary so next reboot or GPO refresh it'll set back to the previous value.

You get SETREG from a previous post in here, I think it's in .NET 1.1 or .NET 1.1 SDK, I forget offhand. I think maybe only 4 times I've run into this on WinXP and Win7 in the last year or two.

I would also like to note that the SETREG method is the least invasive to your system to try out. The other possible solutions involve reinstalling or deregistering/reregistering DLLs and such. I'd give that a shot first and then see where you go from there.