I have a Windows Server Update Services Server and recently an update came out to update the updater.
Unfortunately, the updater didn’t like the update, and has for the last days (spread over a few hours) taken a lot of time off me and got no where close to a resolution.
I started by just upgrading, believing that Microsoft surely would have tested this in house prior to chucking it up on the net for the collective groups of update servers to download and spread over networks.
Very wrong assumption, what happened next proved to be a very tiring issue, and one that I was nearly ready to can after going through a lot of google search results.
For those unfamiliar with WSUS, it’s a Windows Update server for your local network, it does exactly the same as the automated updates, except it doesn’t suffer the same issues that the regular system does, it caches updates for all machines to get, so that you save on bandwidth (and in Australia, you are nuts to be running a network with more than 2 machines without WSUS, the savings are worth it). The other incentive for those who have WGA issues is that the WSUS server is designed generally for corporate, but you don’t actually have those issues with WSUS, as corporate machines would be too much of a nightmare from users who see the popups and so forth from the issues associated with Microsoft’s failed attempts at forcing users to validate correctly.
Anyway, that’s the general features of WSUS, it’s a bandwidth saver, and it saves corporate networks the hassles associated with update rollouts that could be problematic.
WSUS itself is a free unsupported Microsoft offering.
The issues I was having after the upgrade were: WSUS3 wasn’t installed, installing WSUS2 meant that the database would “appear empty”, but lucky me, it made a backup in C:\WSUS\SUSDB.bak.
With no database, the 20GB of update files on my server were all going to go to waste because WSUS would go and redownload them the next time it syncronised.
Because this is Australia, and Telstra have royally screwed everyone with excessive prices on bandwidth, the redownloading of 20GB was not an option.
I tried every imaginable way to get this working again, that is, installed WSUS2, and tried to swap the database over to the other database, but that didn’t work, WSUS would respond with a message that there was an error connecting to the database.
I searched the MS newsgroups and posted there, but during the 6+ hours I worked on it today, no resolution was in sight from anyone.
Then at the last moment, I thought, I wonder if I could just dump the SQL file from the database, like you would with MySQL and reimport it..
That idea quickly went no where after I couldn’t find any export option in Enterprise Manager that would work.
I mounted the database in Visual Studio 2008 Beta 2 (also Free) and took a look to find the tables and saw that the database it wasn’t reading was all intact and reading through Visual Studio fine.
So I came to the solution I could try and do a database file swap in SQL Server 2005, and if that didn’t work, I’d still have SQL Server 2005 Express Edition to install it all in, in future and that would have backup functionality so I can export / import SQL files in case such issues came up again.
After discovering the attach database option in SQL Server 2005 express edition, I mounted the database, installed WSUS 2, and viola, we were cooking with gas again.
The installation process is simply, remove the WSUS SQL Desktop that is installed with WSUS (backup DB first).
Install SQL Server 2005 Express (free).
Use Enterprise Manager 2005 Express (free) to Attach your SUSDB.mdf file to the SQL server.
Run WSUS2 setup to install WSUS, when asked about the database, point it to SQLEXPRESS, Keep current database (DO NOT CREATE NEW, read the warning, don’t be a n00b).
After installing WSUS2, on the server execute wuauclt.exe /detectnow to get some action happening.
One of the updates offered should be WSUS3, try to install it as an upgrade again (hey, I wanted to see if it would work again), and it should fail (it did for me).
After WSUS3 upgrade fails the second time (you shouldn’t have any SQL issues etc, as the SQL server is more of a “boss” then the install process is) and just leave it at that. WSUS2, it works, its headache free, and should be fine for some more time until Microsoft get WSUS 3 right.
So the solution? Don’t upgrade to WSUS3, it’s another Microsoft didn’t get it right release, but if you do, just do as is stated above, and it should be promising results for many more updates to come.
I should tell you my carefactor dropped considerably after I factored into account the server I am currently running it on is soon to be retired and my old beast is soon to take its job over, after I finish getting my NEW beast upgraded and ready to roll, so I didn’t put much care into borking the server (i figure if its not going to work, then stuff it, when I install again I’ll just redownload on our Exetel connection when we piss Netspace off!).
As a sidenote, it wouldn’t hurt Microsoft to develop a database rebuild method to rebuild the database of updates if the database bombs out (but the update structure is fully intact). Not as important, databases rarely should fail.
As an additional note, this issue could have likely been solved so much quicker on Linux, config files show usernames and passwords, no tricky renaming to cover up update names, and of course, rebuilding a database is easier to some degree with mysql (at least dumping an SQL file is easy enough that the time spent stuffing around getting WSUS and a database back into bed with each other wouldn’t have taken as long).