Hi Folks -
I wanted to get back to you with more information and guidance around the Windows Desktop Search (WDS) issue and the results of our investigation today.
As you know, Windows Desktop Search was published last February 07, as an optional update that was only applicable to systems which had WDS previously installed. Then on Tuesday of this week we revised that update package to be applicable (but still optional) to Windows XP SP2 and Windows Server 2003 SP1+ systems which did not have WDS installed. Unfortunately, in revising this update, the decision to re-use the same update package had unintended consequences to our WSUS customers. Namely many of you who had approved the initial update package for a limited number of machines, had Tuesdays' WDS revision 105 automatically install on all clients because of the expanded applicability scope and because by default, WSUS is set to automatically approve update revisions. We sincerely regret the inconvenience this has caused and extend a sincere apology to all impacted customers.
For those of you who want to uninstall the WDS update revision released Tuesday of this week, this can be done via
1. Add/remove programs
2. Invoking spunisnts: %windir%\$NtUninstallKB917013$\spuninst\spuninst.exe /q /promptrestart
3. Using System Restore on Windows XP (not available on Windows Server 2003). This option will leave some software on the machine, but the invocation effectively removes WDS 3.01. This should only be used for conditions where the /noback switch was used.
I want you to know we are working now to correct the issue and have temporarily suspended the distribution of the Windows Desktop Search through WSUS. The current package will remain available through the Microsoft Download Center. We will make a new package available for WSUS in the near future, but not as an update revision, so that you can rely on predictable update behavior with auto-approval settings. We are also working on improving our internal publishing processes to ensure this does not happen again in the future.
Again, our sincere apologies for this publishing process error.
Program Manager, WSUS
Here's a classic example of just what I'm talking about: MS07-057.
I look at my WSUS screen today after a week on leave and I see that MS07-057, the October 10th cumulative security update for Internet Explorer, has mysteriously been revised and reissued as of October 24.
All seven versions of it that I track are now showing as 'Not approved' because I've got 'automatically accept revisions' off. That's IE7/Vista, IE5.01SP5, IE6/2003, IE6/XP, IE6SP1, IE7/2003, and IE7/XP.
The 'revisions' tab in WSUS2 simply says there is a revision as of 24/10/2007. No details.
The 'more information' URL on the 'details' tab points to http://go.microsoft.com/fwlink/?LinkId=95045, which resolves to http://www.microsoft.com/technet/security/bulletin/ms07-057.mspx
The header for this, the official MS07-057 bulletin page, says:
Microsoft Security Bulletin MS07-057 - Critical
Cumulative Security Update for Internet Explorer (939653)
Published: October 9, 2007 | Updated: October 10, 2007
Updated OCTOBER 10. Which was the date of the FIRST REVISION. And yet I know, because WSUS is telling me, that there was a SECOND REVISION ON OCTOBER 24. But there's no mention of this in the bulletin.
Nothing in the revision history at the bottom of the page either:
• V1.0 (October 9, 2007): Bulletin published.
• V1.1 (October 10, 2007): Bulletin revised to correct the "What does the update do?" section for CVE-2007-3893.
Still October 10th.
Okay, let's look at the download page for one of the actual update binaries: IE6 on XP SP2.
What do we see about update dates?
File Name: WindowsXP-KB939653-x86-ENU.exe
Security Bulletins: MS07-057
Knowledge Base (KB) Articles: KB939653
Date Published: 10/9/2007
What's the mysterious secret change to MS07-057 on October 24, and why should I put it on my systems if Microsoft can't anywhere document what's now in it?
Sorry, that last date would be October 9, not 10, I'm guessing, if it's using US date format.
This weird stealth revision stuff has happened every month for about three months now.
Really not impressed.
I really like WSUS, so thanks for the free tool. The goof was a big one and it was a treat to get to explain to all of my users what WDS was. ha.
I am thankful for the explaination and apology, at least I am not going completely crazy. I just sat there thinking "I know I didn't approve WDS."
As has been mentioned previously, a real help would be a way to use WSUS to remove WDS in all of its flavors.
I know you all are working on a fix and I appreciate it.
>How can we (WSUS Admins) be assured that this won't happen again in the future?
You can't, in fact you can almost be assured it will happen again. This is illegal activity that Microsoft is very accustomed to doing, and will repeat itself whenever it suits Microsoft to do so.
This will be much easier to deploy once Windows 2008 is more widespread, and don't confuse Windows Deployment Services (WDS) with Windows Desktop Search (WDS), because they are not the same thing. Unfortunately the buzzword bingo namespace has a collisio
The command %windir%\$NtUninstallKB917013$\spuninst\spuninst.exe /q /promptrestart does not work in our login scripts. Could it be that the user does not have enough rights?
Please help me with an efficient tool to uninstall desktop search.
MS, fix this problem! Release a "uninstall WDS malware" "patch" and please don't auto approve this patch for me... or any other patches, upgrades or what ever you'd like to call them. Your backhanded apology is not accepted or acceptable. I too have taken advantage of the advanced features in AD to control what my users have access to. They don't have access to any of the stuff they'd need to uninstall WDS and I would never want them to. They live in a controlled environment where, for the most part, things don't just sneak on or off there computer. That is, unless you decide to backdoor me like this and slip one in.
I do feel your frustration though. Google makes all these great apps that people love. The pressure from the higher ups at MS to dominate every market must be overwhelming at times. I can almost understand why someone would think it would be a good idea to use your domination in other areas to slip some of your under preforming software software onto users desktops. You think WDS is great and "hey, why wouldn't everyone want it" but your wrong. It's only sad that someone didn't stop who ever thought this was acceptable. This is what is truly sad. No one in the decision making process stopped to think if this was a good idea for US, the people on the ground, the admins fighting to keep systems updated and working day in and day out. We rely on your services for help and this is how you treat us.
Shame on you, apology NOT accepted! Release an uninstall for WDS that WE can APPROVE for install with WSUS!
Please issue a removal patch that can be automatically deployed via WSUS or GP that does not require user to be an admin user.
Nate Cull: This is the link that provides the information you want (albeit not for all updates).
Tuesday, October 23, 2007 [...] Changes to existing security content [...]
• MS07-057: Cumulative Security Update for Internet Explorer for Windows (KB939653)
• Updated MoreInfoURL.
• Binaries have not changed.
• This update does not have to be reinstalled.
HarryJohnston: Thanks, that's the missing information I was looking for.
I'm still not happy that I can't set up any automatic process to tell the difference between a (presumably) harmless package revision such as 'Updated MoreInfoURL' and an extremely dangerous one like 'Updated detection metadata', but this at least gives me a cumbersome manual process which (hopefully) can avoid disasters like KB917013.
Oh, and what about this one:
Windows Server 2003 Service Pack 2 (32-bit x86)
"The binaries have changed due to repackaging, but they are functionally equivalent to original version."
Is this harmless? Dangerous? What exactly does 'functionally equivalent' mean? I mean, a binary linked against a new library could be considered 'functionally equivalent' until it turns out to have been a security flaw.
It's interesting looking at some of the historical updates too.
MS07-057: Cumulative Security Update for Internet Explorer 6 for Windows XP x64 Edition (KB939653)
• Updated detection metadata.
So, detection metadata updates happen quite often, do they? And do all of these have the potential to force a site-wide install?
MS05-004: Security Update for Microsoft .NET Framework, Version 1.1 Service Pack 1 (KB886903)
• Added support for Windows Server 2003 Service Pack 2 and Windows Vista.
Okay, what does 'Added support for <entire new operating systems'> mean? Is that like updating the detection metadata? Could approving a revision of a patch I've previously approved for one operating system only, now force it to install sitewide?
MS07-040: Security Update for Microsoft .NET Framework, Version 2.0 (KB928365)
• Updated metadata to add supersedence of MS06-033 and MS06-056.
I presume 'adding supersedence' is harmless and only supercedes old patches, and doesn't force an install on new systems?
MS07-053: Security Update for Windows Vista and Windows Server 2003 (KB939778)
• Updated text and changed metadata.
'Changed metadata'. Has that changed the *detection* metadata, or only text and URLs? How would I find out?
Update for Windows Vista (KB938979)
• Changed metadata to remove supersedence of update 933928.
Wait, so does this mean a patch can supersede a patch, let me disable the superseded patch... then change its mind?
• Updated targeting metadata for Chinese Traditional.
I don't automatically install Service Packs and we don't have Chinese language... but what's 'targeting metadata' versus 'detection metadata'?
MS06-078: Security Update for Windows XP (KB923689)
• Updated metadata to resolve file version discrepancy in detection logic.
That could be dangerous, and should be re-tested by us as a new update, right?
MS07-038: Security Update for Windows Vista (KB935807)
• Released new package to address an installation failure on systems missing a %windir%\system32\LogFiles\Firewall directory.
MS07-040: Security Update for Microsoft .NET Framework, Version 1.0 Service Pack 3 (KB928367)
• Updated detection to resolve incorrect reporting in WSUS.
Both harmless, I'm guessing?
MS07-038: Security Update for Windows Vista (KB935807)
• Updating the targeting detection.
But that one could be dangerous, right?
Our environment is tightly controlled (or so we'd like to think anyway). We have installed WDS on IT workstations for testing and control it via group policy, however there were good reasons why we selected the WDS 2.X client as opposed to the later 3.x release - mostly due to the availability of ADM files and policy controls.
All of a sudden I came in and found that I have a new WDS installed, that policy is not being applied, and that my indexes have disappeared - I'd say this is pretty serious!!! I too have to now find a way to remove 100's of WDS installs from unweary users .
I completely agree with a previous comment I saw - where does it end? Will Microsoft now decide for us when XP SP3 gets installed because SP2 was approved previously? Someone needs to be held accountable for these stuff-ups.
One more thing - can anyone explain why an updated version of the "supposed" same program no is no longer controlled by group policy and also wipes out previous indexes?
uhh... Bobbie, your minions are awaiting a word (ANY WORD) from you and your group.
While I'm asking, a blog is not an official corporate statement. When is MS going to issue a real statement on this fiasco.
Hello.... is there anybody in there? just nod if you can hear me. Is there anybody home?
El equipo de WSUS se disculpa por la instalacion no autorizada del software Windows Desktop search en uno de sus paquetes de actualizacion.
use linux and you won't have to worry about this kind of stuff
Put the script in your Active Directory Computer Startup GPO and this runs with the necessary rights, also /norestart if you don't want it to retart the PC
[ instead of /promptrestart ]
%windir%\$NtUninstallKB917013$\spuninst\spuninst.exe /q /promptrestart