Posts Tagged ‘Windows Update’

WSUS fubar – Microsoft Desktop Search

Saturday, October 27th, 2007

Thank you Microsoft, for once again bypassing my Windows update policies. I can now go explain to my managers why 500 workstations and 12 servers have ended up with Microsoft Desktop Search, without anyones explicit approval. To illustrate how totally stupid this is, check out these screenshots out of our WSUS box:

As you can see above, our current update policy only allows Security updates, Critical Updates and Security Roleup Packs to be automaticly installed (“Approve for Installation”) on select computer groups (most of them test groups)

All other catagory of updates are set to “detect only” for all computers. Meaning that all other update catagories, including the “update” categorie are only detected, so I can see what systems are actually asking for a non-security update, and approve them when needed. Updates under these catagories are not installed automaticly.

Just to re-itterate: Updates of the “Update” categorie, are only suppose to automaticly be “Approve for Detection”. And not “Approve for Installation”

So imagine my horror, when yesterday, after several frantic phonecalls from my support teams, I found 5 particular updates as follows:

These 5 updates where pushed on the 23rd of October, together with a bunch of Internet Explorer Security Roleup pack updates not listed here.

The alarming thing about the above list, is the Appoval column.

Its set to Install.

I never approved these updates for installation.

These updates are suppose to be automaticly set to “Approve for Detection” only. What is even worse, is that, not only are they set to “Install”, they are set to “Install” for “all computers.”, which ignored any of my predefined computer groups. You can see that here:

These 5 updates, totally and utterly ignored the settings if our WSUS server, and did its own thing, installing forcefully on every single system in WSUS, inluding servers such as SQL servers, file servers, and several domain controllers.

I didnt even think it was technicly possible that these updates could override the WSUS server settings. This proves they can, and moreover, in the largest Microsoft update fuckup to date,  that Microsoft has more control over what updates you recieve in your Enterprise, than your own administrators.

The question now is, how this could have happened. Was this a mistake on Microsofts part? Perhaps, because it was also the .net Framework 3.0 that was approved in this way. One can theorise about MS wanting to forcefuly push MS Desktop Search as some kind of play against Google desktop, sure, but .Net 3.0 too?  And at the same time?  Surely they would have known what kind of shitstorm this would cause!

So my money is on an honest-to-god mistake on Microsofts part. We can probably expect some kind of enterprise Desktop Search de-installation tool in the next week or so..  perhaps 😉

In the meantime, administators and IT managers around the world, are going to have to ask themselves weather they still trust Microsoft. Especially considdering that whatever they push can apparently override server-specific settings.



Microsoft WSUS team have responded with a post here
I responded on that post with the following:

I blogged about this happening to me here:

Now i I understand the above correctly…

There is a good chance I approved for installation, the update to Windows Desktop Search back in february.

I would have done that in the understanding that it would apply -only- to systems that already had the Windows Desktop Search tool installed.

That understanding has come from the behavior of Microsoft updates in general: -Updates- to components of Windows and other applications, only apply to systems that have that component or application installed.

Makes sense. After all: You cannot update software that isn’t installed in the first place… cause its not there yet.

Now what I understand from the post above, is that the update revision 105, released a few days ago, is not simply an update.

It is in fact the entire Windows Desktop Search installer, with the ability to also replace/update previous installations.

And because of the WSUS feature to always aprove new revisions is also turned on on my WSUS server, 105 was also, automaticly approved. Cause its a -revision- of the feb update.

However..  you changed the scope of applicability of 105.

In my opinon, this is a very dangerous sequence of events, because the logic is not apparent to most admins I am guessing (based on what I have read so far).

The combination of both a revision, -and- a scope change at the same time, seems an inherently bad choice.

For all intense and purpose, the effect of the scope change for clients that did not have the WDS previously installed, does not constitute an -update-, and it should not be presented as such.

That means it should have been presented as a completely seperate item in WSUS, and should not have included the wording “update” anywhere in the discription.

I have read on the thread here:

that exactly the same thing happened with “Client Update for Microsoft Forefront Client Security (1.0.1703.0)”, which similarly was extended in scope.

The term “update”  should mean just that. You should not be using the term so generically, and wrapping up “new” installation functionality into one and the same package.

Keep it separate. Keep the language clear to us admins who have probably very little time to devote to patch management already.


Update 2

Copy-paste of my comment on the Microsoft Update product team blog

After reading this:

I have a better understanding of what might have happened. And it seems like the behavior is by design.

However, I believe the way this update was packaged and presented, undermines the logic we have come to expect from WSUS updates.

The problem is that the package is presented internally as a revision -update-, which are by default -always- automatically approved (your other approval settings don’t override this), but it was combined with a scope change, that allowed the package to also install WDS on systems that did not have it previously.

It is the second behavior that causes the problem. Installation on systems that did not have it previously, is NOT an -update-, they should not behave as such.

Revision 105 was called “Windows Desktop Search 3.01 for Windows XP (KB917013)”.  Classification: Update

Now from the name alone, it looks like its not an update, but a complete installation (which it was). I never got to see the name before the fact of course, because it auto-approved and installed itself.

The classification is “Update”, and this is what troubles me. Surely, if this “update” can install itself on systems without previous revisions, it does not belong in the “update” classification?

This should have been split into 2 packages.

1. An -update- with new revision number 105, possibly with a slighty differnet name including the word “update”. This would have been automatically approved if the default option for revisions auto-approving was not altered by the admin. The scope would be only install on systems with previous revisions of WDS

2. A new package, called “Windows Desktop Search 3.01 for Windows XP (KB917013)”, possibly a new revision number, but certainly a different classification. I don’t have a list of all the WSUS classifications here, but I am sure there is one that is suitable, wasn’t their something for new Windows features?


Installing Windows Update client error 0x8007041d

Monday, November 14th, 2005

When installing the latest version of the Windows Update Client, you may recieve an error that references this code: 0x8007041d

0x8007041d simply refers to not being able to stop, restart or manipulate in some way, the Windows Update service.

With a recent version of the Windows Update agent installed, the C:windowsWindowsUpdate.log file will produce and error similair to the following:

Windows Update Client standalone setup : eula file path is d:72535cf0e694fc12f4c5a4eneula.rtf
2005-11-14 12:26:23 23248 68f8 Setup *************
2005-11-14 12:26:23 23248 68f8 Setup ** START **  Setup: Installing client binaries
2005-11-14 12:26:23 23248 68f8 Setup *********
2005-11-14 12:26:23 23248 68f8 Setup   * Download directory: d:72535cf0e694fc12f4c5a4
2005-11-14 12:26:23 23248 68f8 Setup   * Stop and start service: Yes
2005-11-14 12:26:53 23248 68f8 Setup FATAL: SelfUpdate: Failed to stop service wuauserv, error = 0x8007041D
2005-11-14 12:26:53 23248 68f8 Setup   * WARNING: Exit code = 0x8007041D
2005-11-14 12:26:53 23248 68f8 Setup *********
2005-11-14 12:26:53 23248 68f8 Setup **  END  **  Setup: Installing client binaries
2005-11-14 12:26:53 23248 68f8 Setup *************
2005-11-14 12:26:53 23248 68f8 Setup FATAL: InstallUpdatedBinaries failed with error 0x8007041d

This can occur with the Standalone Installer, as in the example above, but also when updating your Windows Update client though the Windows Update homepage.

On the web you will find references to Norton virusscanner possibly causing this, but its not the only reason this can happen. ( ) In fact there are any number of reasons a Windows server can fail to unload.

The Windows Update service is launched by the system, under system account credentials, and with the following command line: C:windowssystem32svchost.exe -k wugroup

If the service is trapped in the “stopping” state, you may wanna kill the process manually, however, you can only do this on a Windows 2000 machine! As I will show below…

But because the service is launced via cvchost, you might have a hard time recognising which instance of cvchost to kill.


Process Explorer has an option to show the command line with which all system processes have been started. This is simply a column you have to turn on in the main view.


The Windows XP / W2K3 command tasklist.exe will give you much the same data:

On a Windows 2000 Server:


Image Name                   PID Services
========================= ====== =============================================
svchost.exe                  636 RpcSs
svchost.exe                  780 EventSystem, Netman, NtmsSvc, RasMan, SENS
svchost.exe                 2512 TapiSrv
svchost.exe                26864 BITS
svchost.exe                30912 wuauserv

A Windows Server 2003 machine:

Image Name                   PID Services
========================= ====== ============================================
svchost.exe                 1504 DcomLaunch
svchost.exe                 1580 RpcSs
svchost.exe                 1636 Dhcp, Dnscache
svchost.exe                 1780 LmHosts, W32Time
svchost.exe                 1820 AeLookupSvc, BITS, CryptSvc, dmserver,
EventSystem, helpsvc, lanmanserver,
lanmanworkstation, Netman, Nla, sacsvr,
Schedule, seclogon, SENS, SharedAccess,
ShellHWDetection, TrkWks, winmgmt, wuauserv
svchost.exe                  692 ERSvc
svchost.exe                 1120 RemoteRegistry
svchost.exe                 2824 W3SVC
svchost.exe                 2948 TermService

A Windows XP machine:

Image Name                   PID Services
========================= ====== ============================================
SVCHOST.EXE                  940 DcomLaunch, TermService
SVCHOST.EXE                 1008 RpcSs
SVCHOST.EXE                 1104 AudioSrv, BITS, Browser, CryptSvc, Dhcp,
dmserver, ERSvc, EventSystem, helpsvc,
lanmanserver, lanmanworkstation, Netman,
Nla, RasMan, Schedule, seclogon, SENS,
SharedAccess, ShellHWDetection, srservice,
TapiSrv, Themes, TrkWks, w32time, winmgmt,
Wmi, wuauserv, WZCSVC
SVCHOST.EXE                 1196 Dnscache
SVCHOST.EXE                 1308 LmHosts, RemoteRegistry, SSDPSRV, WebClient
SVCHOST.EXE                 3320 stisvc

A funny thing to note here is the difference between Windows 2000 and Windows XP / W2K3. On Windows 2000 Server, the wuauserv service is run as a completely seperate process, with its own ID.
This means you can kill it seperatly.

But on Windows XP / W2K3, it is launched as part of the Network Services group. This is reflected in the command line in which it is launched:
C:WINDOWSsystem32svchost.exe -k netsvcs

You cant simply kill svchost.exe in this case, it will crash the system.
Recommended is to disable the service, reboot, and after reboot install the standalone Windows Update Agent.

A VB Script that checks registry for installed hotfix

Friday, October 21st, 2005

You may find this usefull!
I am quite new to scripting, so I am sure that I could have done things much better than I did in this script. So I would very much appreciate any feedback, tips and comments!

The next version of this script should allow command line input aswell, so you dont have to supply a list of servernames. Also next version will check with WMI directly, instead of checking the registry.


‘Checks the registry of each computer listed in INPUT_FILE_NAME
‘for a the hotfix listed in HOTFIX
‘It uses the WMI registry provider to do this.
‘Besides writing to the screen, it writes the output to
‘the file in OUTPUT_FILE_NAME in comma delimted format, producing 2 columns:
‘the computer name, and the result of the query

’21/10/2005 Robert Kloosterhuis: v1.0
On Error Resume Next

INPUT_FILE_NAME = “serverlist.txt”
OUTPUT_FILE_NAME = “scan_hotfix_MS05_051.csv”
HOTFIX = “KB902400”

‘objFSO.OpenTextFile method uses paramater value 8 to append to file
const HKEY_CURRENT_USER = &H80000001
Const HKEY_LOCAL_MACHINE = &H80000002

Set StdOut = WScript.StdOut

‘Set up objFSO variable for file reading and writing operations
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

‘delete OUTPUT_FILE_NAME if it already exists
Set oldfile = objFSO.GetFile(OUTPUT_FILE_NAME)

‘Set up the output file
Set objOutputFile = objFSO.OpenTextFile(OUTPUT_FILE_NAME, FOR_WRITING, true)
‘Read the input file
Set objFile = objFSO.OpenTextFile(INPUT_FILE_NAME, FOR_READING)
strComputers = objFile.ReadAll

‘Make an array out of the list it reads from the input file
arrComputers = Split(strComputers, vbCrLf)

‘setting up some initial values
DIM result
DIM noresult
result = 0
noresult = 0

‘Our main loop. Everything below this is run for every entry in the imput file
For Each strComputer In arrComputers

‘first column in the file we are writing to is the computer name.
‘Every bit of info we want to provide is ended with a comma for delimitation
objOutputFile.Write strComputer
objOutputFile.Write “,”

‘Connect to the WMI registry provider
Set objReg=GetObject(“winmgmts:{impersonationLevel=impersonate}!\” & _
strComputer & “rootdefault:StdRegProv”)
‘Error Handling If it cant connect to the WMI provider,
‘exit with the Error Description
If Err.Number <> 0 Then
Wscript.Echo strComputer & ” ” & “Error Number ” & _
Err.Number &  “: ” & Err.Description

‘The Registry path we are going to read from
strKeyPath = “SOFTWAREMicrosoftWindows NTCurrentVersionHotFix”
objReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys
‘Everytime we run though the loop, these values are reset first.
result = 0
noresult = 0

‘If it comes across the hotfix we are looking for,
‘it changed the value for this loop
For Each Subkey in arrSubKeys

IF Subkey = HOTFIX Then
result = 1
noresult = 0

noresult = 1

End IF


‘Now we have a value, lets print some text about it,
‘both to the screen, and to our output file
IF result = 1 Then

WScript.Echo strComputer & ” ” & HOTFIX & ” installed!!!”
objOutputFile.Write HOTFIX & ” installed!!!”
WScript.Echo strComputer & ” ” & HOTFIX & ” not found!”
objOutputFile.Write HOTFIX & ” not found!”
End IF
‘End with a comma for this column
objOutputFile.Write “,”

end if

‘Start a new line


Large businesses using Automatic Updates?? – Never heard of SUS?

Tuesday, August 24th, 2004

Omg. I am continuously perplexed at how corperate IT is run around the world. Here is another halarious example.

Microsoft started distributing their new Service Pack 2 via Automatic Updates last week, but had to stop short of updating Windows XP Proffesional PC’s, because as it turns out, there are rather a lot of businesses that seem to rely on Automatic Updates.

“When we designed Automatic Updates, we had consumers and small businesses in mind. We have been surprised by the number of enterprises who use Automatic Updates,” said Jon Murchinson, a program manager at Microsoft. (From, read the rest of the article here)

Now while Windows XP Home edition pc’s have been recieving SP2, MS has chosen to wait a week for XP Pro, and give admins a change to block Automatic Updates (via a registry key), until they can prepare and test properly.  I mean.. they’ve only had SINCE DECEMBER last year to prepare and test properly!!

Anyway. The reason I am rolling around the floor laughing, is that there is no valid reason I can think of, that you would want to make your corperate client park dependant on Automatic updates! its just a bad idea, and any admin with a fragment of sense should know this. I mean.. admins who use this feature for their client park, must somehow have missed the whole discussion about Automatic Updates when XP first came out!

People already expressed their concern back then, that if one relied soley on this mechanism, one risked the change of a ‘faulty’ patch, screwing things up seriously. And god knows this has happed in the past with MS hotfixes, and SP2 is of course the ultimate example.

But because this is of course a totally clear and recognized issue, Microsot came out with a totally clear and recognized solution: Software Update Services!

Now Software Update Services, better known as SUS, is basicly nothing more than a proxy server for Automatic updates, but it gives you the ability to control the distribution of updates and hotfixes, by letting you authorize patches on the server, before they are distributed to your client park. This gives you ample time to test patches and updates, before you hit the relevant checkbox.

Now SUS has been around for about as long as Windows XP has, and Microsoft extensivly supports its use and implimentation, i mean, I cant turn two pages of a Microsoft whitepaper without beign reminded about it!

So how come all these stupid businesses are not using it then! For Pete’s sake! I mean, its a FREE download! It works on Windows Server 2000 and 2003, and uses next to no resources, except perhaps hard disk space if you choose to store patches locally.

The reasons that these companies possibly have for not using SUS, may perhaps be perfectly valid reasons, involving resource management, connectivity issues, that kind of thing, even though, if anything, SUS solves more problems that it could cause, if it can cause any problems at all! (??!)

I think the main reason admins have not started using it, boils down to two reasons: A. Lazyness, B. ignorrence.

Point A: Installing SUS doesnt take 5 minutes. Anyone with half an ounce of IIS knowledge can do it, and if you are going a bit further than your average SUS implementation, and doing a multi-forward-WAN setup or something, then you might have to spend some time thinking though how your gonna deploy it.

All you need thereafter is some cool Group Policy Settings, or , if you are in the stone age and still have an NT4 domein with XP clients, some hand-made registry settings for Poledit.

And that is about it!  About a days work for the average enterprise, and you have completely streamlined your patch-management process! What could be cooler?! Cant be too hard to convince your IT manager to give you the time to do it, considdering the benefits!

But point B is trickier.

Like i have said in earlier rants, I am constantly coming across admins that seem to have burried their collective heads in the sand when it comes to IT and the developments in that field. People like that may very well never have heard of SUS, or all the work that MS is actually doing into correcting their security issues of old.

Now personally, I would like to take all these kind of admins out into the parking lot, and shoot them, but that would be rather challenging considdering that they seem to be in the majority.

Inept system admins, or IT managers, are the whole reason that worms like Blaster and Sasser are succesfull, and the reason that dispite everything MS or anyone else does for security, and exactly because it is the most used OS on the planet, it will always remain vulnerable, primairly because of human failing.