Tag Archive | wsus

Find a bug in Windows, wait 6 months for a fix

I’ve been following the progress of a bug in Windows 7 SP1 that was reported back in February, and today Microsoft finally gave an estimated release date for a fix:

A public release of this fix would be made available around August 31, 2011. Please do not treat this as precise official release date, but an announcement & release might move by a week on either side. Microsoft has already initiated public release process and started working on this fix.


So, bug reported end of February. Fix expected end of August.

Time to fix: 6 months.

The bug in question is this one, and in a nutshell, means that you cannot install any large (~ 400MB+) update through WSUS. This breaks any system that relies on WSUS to deploy updates and software, including System Center Essentials deployments of programs such as, say, Microsoft’s own flagship productivity suite, Office 2010. As a result, I have still not deployed Windows 7 SP1, because it would destroy my ability to roll out any new software I might need if it happens to be a large install.

I switched away from SCE to Local Update Publisher a few months ago, for a variety of reasons that I listed at the time. What I didn’t mention is that this bug was one of them. I didn’t mention it at the time because LUP is equally affected by the bug, as it too relies on WSUS, but there is an important difference between the two in that at least I am now using a broken deployment system for free, instead of paying for it. If there was ever a compelling case for why paying for support is a waste of time, this is it.

Quite simply, it should not take Microsoft (or anyone else) 6 months to fix an enterprise feature in their flagship operating system. My school paid good money for System Center, and purchased Software Assurance, and it did us no good whatsoever in getting the problem resolved – we’ve simply had to wait, just like everyone else affected. I feel like we wasted money on System Center, and I know I’m not the only one.

Are you listening, Microsoft?

Goodbye SCE – I never liked you anyway

Last summer, I started using Microsoft System Center Essentials 2010, primarily for its software distribution functions. Aimed at small- to medium-sized networks, it’s ideally placed for use in school. Like almost every System Center product I’ve used, it wasn’t the simplest thing in the world to set up, but once working, it works reasonably well.

Well, except for…

How to get a list of every WSUS update using PowerShell

Recently I needed to get a list of every update on my WSUS server, due to a bug in System Center Essentials which leaves orphaned folders on the server even when locally-published updates have been removed using the console (the Server Cleanup tool doesn’t get rid of these files either – see this post on TechNet.

The folders in question were all in the WSUS\UpdateServicesPackages directory, and are named according to the GUID of the update in WSUS. The WSUS console doesn’t provide any way to get a list of GUIDs that are valid updates, but you can do it using the WSUS .NET API, which is accessible via PowerShell.

Update: If you’re only interested in which folders to delete, without any additional information, you can run wsusutil listunreferencedpackagefolders from the %Program Files%\Update Services\Tools directory. This command is mysteriously missing from any online documentation from MS.

Here’s a sample script to get the GUIDs. You’ll need to customise line 2 to reflect the FQDN of your WSUS server, along with whether to use SSL and the port number. You’ll either need to run the script using an account with admin rights to WSUS, either on the WSUS server itself, or on a workstation with the WSUS console installed.

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer('updates.angrytech.internal',$False,80)
#Get all updates
$updates = $wsus.GetUpdates()
#Iterate every update and output some basic info about it
ForEach ($update in $updates) {
New-Object PSObject -Property @{
Id = $update.Id.UpdateId.ToString()
Title = $update.Title
Source = $update.UpdateSource.ToString()

(With thanks to Boe Prox’s excellent series of articles on managing WSUS with PowerShell)

This will spit out a (very long) list of every update update GUID on the server, the source of the update (either MicrosoftUpdate or Other for local packages), and its Title (which will probably be truncated).

How you then use this list is up to you, but I went with importing it into Excel, then using VLOOKUP with a list of folders that were on the server and seeing which folders matched up to updates and which didn’t. If I had taken the time I could have automated the whole thing, but I chose not to because I wanted to manually check the contents of each folder anyway before deleting it. Whatever method you choose, do so at your own risk.

In all, I found more than 8GB of orphaned files spread across more than 70 packages that I had previously removed from the SCE console over the last year. That amounted to nearly 20% of the total space used by WSUS, so we’re not talking about small amounts of wastage here.

The TechNet post I mentioned above is from nearly 3 years ago, and originally referred to SCE 2007. That this bug hasn’t been fixed after 3 years and a whole major version later is frankly pitiful.

The torture of installing System Center Essentials 2010

Last week I decided to add System Center Essentials (SCE) to my network, having decided a little while ago that the full System Center Configuration Manager and its associated sister products were slightly overkill for my network. This opinion was not helped by the fact that a 3-day attempt to get System Center Configuration Manager 2007 installed a few years ago resulted in nothing more than a near mental breakdown and 3 days of my life wasted that I will never get back. So, SCE seemed like it might be a less stressful choice.

Like hell it was.

Little did I know that within minutes, trying to install this on my WSUS server (since SCE cannot be on a different server from WSUS) would fail dismally when it tried to move the WSUS database from the Windows Internal Database system to a proper SQL Server instance:

13:10:36:CreateShareForBackup: Failed to create the share for the WSUS backup.: Threw Exception.Type: Microsoft.SystemCenter.Essentials.Configuration.Common.EssentialsShareException, Exception Error Code: 0x80131500, Exception.Message: Failed to create the share.
13:10:37:StackTrace: at Microsoft.SystemCenter.Essentials.Configuration.Common.ReadOnlyTemporaryShare..ctor(String shareName) at Microsoft.SystemCenter.Essentials.SetupFramework.HelperClasses.MoveUpdateServicesDatabase.CreateShareForBackup.Execute(MoveUpdateServicesDatabaseItem item)
13:10:37:SystemCenterEssentialsPreinstallProcessor: SUSDB move failed.
13:10:37:ProcessInstalls: Running the PreprocessDelegate for SCE failed.... This is a fatal item. Setting rollback.

That log snippet very quickly led me to a post titled “Upgrade from WSUS to SCE 2010 fails, Cannot move WSUS DB“. The process by which the author arrived at this error was slightly different, but the resolution was the same. Despite that last line talking about a rollback, the installer doesn’t completely undo all of the actions it’s performed up to this point. If you want to try again, you have to remove the sceWsusBackupShare yourself. In fact, there is so much that doesn’t get rolled back that the developers added a tool to the System Center Essentials 2010 Resource Kit called Essentials Server Cleanup Tool, which apparently does the job that the hopelessly installer always should have.

Of course, doing this is no guarantee the damned thing will then work the second time around. My install failed again almost immediately, again while trying to move the WSUS database onto an SQL Server instance. This time the logs only spoke cryptically of a server timeout.

“Sod this for a game of soldiers,” I thought. I knew how to perform this migration myself, having several times consulted the TechNet documentation on Migrating from Windows Internal Database to SQL Server. I tried the procedure, only to be denied because something was locking the database open. Suspecting that once again the SCE installer had not relinquished its vice-like grip on the system. I rebooted, and was met with success the second time around.

Once done, the SCE installer continued unabated, and everything ran smoothly.

Well, apart from this about 20 minutes later:

I suppose I should count myself lucky that I spotted this early and was still at a point where a reinstall was even remotely palatable. However, it didn’t help dismiss my consistent opinion that most of System Center is too damned complicated for its own good – especially when all I really wanted from it is the ability to be able to deploy .exe files, since the Microsoft Office team decided they were too good for GPO deployment ever since 2007…

1, 2, 3, Many

In Terry Pratchett’s Discworld series, trolls count in a base 4-like system whose main cardinals are One, Two, Three, and Many (there is also Lots, which is equal to 16 in decimal).

It is a little known fact that Windows Server Update Services counts in a similar fashion, only it uses a much simpler system with only two numbers: Some and Many.

Observe this amazing numerical system in action:

Log Name:      Application
Source:        Windows Server Update Services
Date:          05/08/2010 12:50:30
Event ID:      13021
Task Category: 6
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      updates.angrytech.internal
Some client computers are not reporting their inventory. 1 have been detected so far.

Log Name:      Application
Source:        Windows Server Update Services
Date:          05/08/2010 14:30:36
Event ID:      13022
Task Category: 6
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      updates.angrytech.internal
Many client computers are not reporting their inventory. 2 have been detected so far.

This is why whenever I look at the Role Health Summary page, I get a dirty great red × next to WSUS; apparently just two computers not checking in counts as ‘many’.

So, if someone would someone please teach the WSUS developers how to count higher than 2, I would be very grateful.

The irony of having to block the EU browser choice screen – and how to do it

i·ro·ny n. Incongruity between what might be expected and what actually occurs.

Example: championing the freedom to choose, then forcing people to make a choice even if they don’t want to. Specifically, this.

It’s annoying. If you’re in the EU and you’re a home user, a small business, or even a medium or large business that isn’t using Windows Server Update Services, it’s difficult to escape your computers (and those you manage on behalf of your users) from presenting this stupid box. The worst part is that Microsoft have made it intrusive intentionally, even though they almost certainly never wanted to do it in the first place. The EU’s army of legal drones clearly lack the self-awareness to realise the hypocrisy of what they’ve done. It’s one thing to force Microsoft to offer a choice. To force users to take that offer, without so much as a ‘Cancel’ button as an escape route, is missing the point somewhat, and has annoyed far more people than will ever be pleased by it.

According to Rob Wier, who knows more about randomisation algorithms than I do, it’s also flawed and does not present the choices in a random order as it is supposed to.

OK, rant over. Here’s how to block the blighter.
Read More…