Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
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. – 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 4: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 4:35

Maybe this 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.

share|improve this answer
Thanks. Just saw that earlier today, tried it. Failed miserably... but I got that KB from and that has more steps so I'll continue... – ETL Feb 24 '14 at 22:33
up vote 1 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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