4

I am updating a whole bunch of server which are running Windows 2008R2 SP1. There are about 120 updates to install. I found that if I run all of the updates, it takes hours and hours, then fails and takes hours and hours backing things out.

I started doing updates in small batches. The same updates which earlier failed, worked. But then sometimes the small batches (5-10) error... but if I run the updates one by one, then they work.

The error code is 80070643. I could post the windowsupdate.log but I did not see anything else in there that was helpful.

MS has a KB on this ( http://support.microsoft.com/kb/976982 ) but I tried doing what they suggests... at first seemed like it was going to solve it, but then I still ran into the same error again and again and again.

Is everyone running into this? Surely others install new servers, whack on Windows and then do updates.

My updates come from my local WSUS server but I don't think that matters - I was getting similar trouble doing it from MS server directly.

ETL
  • 6,443
  • 1
  • 26
  • 47
  • Yeah, I've seen this, and (not sure how helpful this is, so comment, not answer) ended up using trial and error to isolate the update causing the problem. Excluded it, installed everything else in a big batch, and success. Installed another round or two of updates the same way, and after all the updates were installed, it wasn't available anymore, so it must have been superseded by one of the other installed updates. Grr. – HopelessN00b Feb 19 '14 at 21:13
  • I noticed it yesterday as well. I think it was a .NET framework update, possibly 4.5. – Davidw Feb 19 '14 at 21:21
  • @Davidw - yeah Ms has a KB on that but I still run into it constantly even after following their advice. http://support.microsoft.com/kb/976982 – ETL Feb 19 '14 at 21:23
  • @HopelessN00b - you gave me an idea. I'm going to try this out - I think I need to clean up WSUS of the superseeded updates. I thought WinUpdates would handle this on its own but I think it doesn't. As I'm going through painfully installing 1 or 2 update at a time right now, I sometime see package disappear even though I did not install them (or so it seems). – ETL Feb 20 '14 at 04:30
  • @ETL Best of luck, but I've seen updates that are not "simply" superseded. As in update A **or** update B are prereqs to update C, so installing update C will remove both, but neither is removed as superseded, because, strictly speaking, it's not superseded by update C. ... Well, in any event, I'd be interested in whether or not this works for you, as it would be useful to me as well. – HopelessN00b Feb 20 '14 at 04:35
  • @HopelessN00b - yeah, I'm doing it but I also noticed some updates with error have no superseding updates... been spending a whole week updating a couple server, tiny bit at a time, trying to get all updates done to see if I can get more stability in my Remote Desktop Session hosts... – ETL Feb 20 '14 at 04:38
  • @HopelessN00b - ok so last night, I declined 7 updates but had to go, so I started another server on windows update - selected all 130 updates and let it run. I also set it to "install updates automatically at 3AM". Came in the morning, all good, all updates (but 1) done. Now, here I have two changes, I set it to automatic and I declined 7 updates. I doubt the decline made much difference. Also, this server only has Windows installed, unlike the others I have been updating. It's a DC so only has Windows components, no additional .Net, Office, etc. Will try some more... – ETL Feb 20 '14 at 14:44
  • @HopelessN00b - did not go too well on those 2 servers I did today. I let it do the installs automatically (43 or so) and a whole bunch were rollbacked and failed. What I see as being the big difference is that on the one that went super smoothly, it's a future DC so doesn't have any special apps other than Windows Features installed. On the other that are problematic, they are Terminal Servers with Office, .Net 4, .Net 3.5, whole bunch of stuff. I think .Net is the problem, specifically that it's mentioned in the KB page related to the error code. – ETL Feb 23 '14 at 01:28
  • One more possible solution resource: http://technet.microsoft.com/en-us/library/ee619779%28WS.10%29.aspx – ETL Mar 05 '14 at 03:31
  • I had the same issue, all I needed to do was run the MS .NET repair tool, then installed the updates in groups of 2-3 at a time, starting from the oldest one. – dodgy_coder Oct 10 '14 at 03:38
  • @HopelessN00b - I added some new development to this in the accepted answer. You may be interested. – ETL Jan 31 '15 at 23:55

2 Answers2

1

Maybe this http://support.microsoft.com/kb/947821 can help?

It say: Fix Windows Update corruption errors such as 0x80070002 and 0x80070057
Windows Update corruption errors prevent Windows updates and service packs from installing. For example, an update might not install if a system file is damaged. If the error you see is in the following list, try the solution in this article.

Max
  • 153
  • 2
  • 7
  • Thanks. Just saw that earlier today, tried it. Failed miserably... but I got that KB from http://support.microsoft.com/kb/2509997 and that has more steps so I'll continue... – ETL Feb 24 '14 at 22:33
1

After much work, research and exchanges with different people, here is the summary of what I found works and what was tried.

  • Updating Windows 2008R2 servers from WSUS is not a problem if the Remote Desktop Services were never installed. For example, I was able to update 2 servers which I had set up as domain controllers from Windows 2008R2 SP1 fresh install. That required applying about 150 updates. Took a few reboots and everything installed nicely. A few failed but they did not show up after as being needed - so they were superseded by other updates which worked.

  • A server which had RDS installed is basically doomed. Installing the updates are going to be a pain. Here is the comments from some MVP guy on this. But even in single-user mode, it's a pain.

RDS Servers require special handling for patch installation. Researching "Patching Terminal Servers" will turn up conversations from back in the 2005-2007 time frame when this scenario was first discussed with respect to WSUS v2. In short, you need to drain the user sessions from the RDS server and place the server into single-user mode to successfully install those updates.

So the moral of the story - when you plan to set up a RDS server, install Windows but not RDS, do all the Windows updates. Then install RDS and do any further updates required.

And the second moral of the story - keep your RDS servers updated regularly so you don't have to suffer pain months down the road with hundred of updates to manually install.

--- More to it - later ---

Today, my team found something that has been helping - setting the following Registry Key: HKLM\SYSTEM\CurrentControlSet\services\TrustedInstaller\BlockTimeoutIncrement to a higher value (say 36000). This can be done also through group policy using the "Increase Win Update Timeout".

We found this because we found the windows update log stating that the update had timed out and thus it was rolling back.

Setting this let Windows Update finish installing after many hours and the updates installed.

Does not tell us why it's taking so long - that's still not normal. But at least we were able to do the updates.

Even more

Seems like we have it solved! We started getting other errors on our servers and all this lead to finding that the Administrator NTUSER.DAT file was 1.5GB and using a lot of the resources available to load registry files. This was causing regular users to be unable to log on (when the Administrator was logged on, which was... basically always).

Anyway, so I deleted the local profile of the Administrator user, recreated it by logging on. NTUSER.DAT is less than 1MB.

Ok, so we had a thought - could this solve our Windows Updates issues... well, seems like it did. We can now install Windows Updates like on our non-RDP servers.

So looks like because the registry of the Administrator user was bloated, and this is the user we were logged on with when doing Windows Updates (or installing Hot Fixes), the install took too long and timed out.

ETL
  • 6,443
  • 1
  • 26
  • 47