forums.wsusoffline.net

Hi Folks,

This has probably been a long standing issue, I know it has been from MS's perspective - but they've never fixed it, thus, it presents in WSUS as well.

KB3000850 is a massive cumulative update and its caused me issues in the past with "C0190003" stop errors after rebooting. So much so that I blacklisted this update from my own manual update process (before I discovered WSUS Offline). Despite this KB having had any number of revisions, the problems it causes are still present.

The reason I'm posting here is that Offline WSUS's primary objective, if I understand correctly, is to assist people to update fresh installs, and a fresh Windows Server 2012R1 or R2 install will almost certainly drag in KB 3000850 and immediately after reboot the user will be left with an unusable system (because the post update reboot will almost always trigger the "C0190003" stop error).

The workaround for this problem, as presented by MS themselves is this:

fsutil resource setlog maxextents 100 C:\

The original link is: https://support.microsoft.com/en-au/kb/3074603

It may not be feasible to add this to the update script - if not, perhaps KB3000850 should be flagged in some way or even perhaps blacklisted (though this is not ideal as its pretty important). In any event, something might be done to warn a user that without using the workaround the chances are extremely high that they will be left with a non working server after this KB's application.

wsusou does not work as it shoukd without KB3000850.

Could you add the workaround as an InitializationHook.cmd (see the faq for a HowTo)?

I forgot to mention it in my last post - but of course this KB problem also hits Windows 8.1 in the same way.

I don't know the ramifications of adjusting the max containers in the NTFS filesystem over the long term. There must be a tradeoff here somehow or otherwise MS would have set it themselves to a high figure. The MS workaround doesnt mention anything and also doesn't indicate that one should set the value back to its original after installing the KB update.

If indeed it was safe and didn't impact the system by leaving this value high (at 100 or even possibly higher) then yes, I'm sure checking for and setting this in the initializationhook.cmd would be the way to go. Check that the figure is not already set higher than the minimum required (as the user might have set it themselves for some reason unknown to us), then set it if its a low figure.

I'll have a mess around and report back.