I have spent all day patching servers, workstations and trying to find a direct download for the 958644 patch that got released last night. I was amazed when Microsoft even called us to join in a webconference for Microsoft partners about this patch – that is something new.
I was not so pleased when I called PSS to ask for a direct download to the patch as kb958644 does not have direct links, windows update services was timing out and the catalog website is badly broken. PSS informed me that as it was not a hotfix they could not provide me with the file and there was an 8-12 hour delay on callback from the server team. So instead I’ve been configuring wsus for servers (that were not already configured), approving patches and downloading by visiting windows updates – a VERY time consuming.
Anyway, without wasting more time – here are the download locations – I’d grab them before the server falls over too.
Thanks to Larry and Derek for the help in finding these.
So Microsoft update a patch today to do with Adobe flash player and I quote “Caveats: This bulletin is for customers using Macromedia Flash Player version 6 from Adobe. Customers that have followed the guidance in Adobe Security Bulletin APSB06-11, issued September 12, 2006, are not at risk from these vulnerabilities. Vulnerable versions of Macromedia Flash Player from Adobe are redistributed with Microsoft Windows XP Service Pack 2, Microsoft Windows XP Service Pack 3, and Microsoft Windows XP Professional x64 Edition.”
Now XP sp3 has only been out a couple of weeks, if that, Adobe released their bulletin in September 2006 so how on earth is WindowsXP sp3 vulnerable – surely flash should have been updated in the xpsp3 release! This seems to make a mockery of the security focus that Microsoft are meant to be working hard on and coming on the heels of the recent snafu’s with Windows updates and genuine advantage, it’s no wonder people are not very happy with patching.
I had a client pc that was not updating with Windows Updates in our WSUS server. Looking through the logs I was receiving the error “FATAL: WUAutoUpdateAtShutdown failed, hr=80240FFF”. On looking through the services, the automatic updates service was missing. Running regsvr32 wuaueng.dll added the service back in but I was unable to start the service with the message “Error 1083: The executable program that this service is configured to run does not implement the service””
I also found that I was unable to start the BITS service. Googling on that came up with the Helpsvc fix application that fixes errors with the help and support service. Downloading and running this application, although seemingly unrelated to my problem fixed both BITS and Windows Updates on the machine. Thanks to the newsgroup posting by Greg Kirkpatrick
One of my WSUS boxes had a log file in the C:\Program Files\Update Services\LogFiles directory that was 60MB big – normally these are deleted by WSUS itself, with a backup copy of the previous log kept as SoftwareDistribution.log.old. However the permissions on the folder were set such that Network Service (which WSUS runs under) did not have permissions to create new files in the directory. As it could not create files, it was unable to move the existing file to .old and create a new logfile to start writing entries in. By granting Network Service change permissions to the C:\Program Files\Update Services\LogFiles directory and then restarting the Update Services directory, the SoftwareDistribution.log file was renamed to .old and a new file created. Inspiration for this was found at EventID
I noticed that client machines hadn’t been checking into some of the WSUS servers since the server was upgraded to version 3. Checking the log files of the desktop pc’s had errors such as “Reporter failed to upload events with hr = 80244016”
After a bit of digging and looking at the IIS console, I noticed that the wsus directories were now listening on port 8530 instead of the normal port 80. To fix this I changed the Group Policy setting “Set the intranet update service for detecting updates” and “Set the intranet statistics server” to read http://servername:8530 instead of http://servername, ran gpupdate on the desktop, restarted Automatic Update service, dropped to a command prompt and ran “wuauclt /detectnow” to ensure the desktop checked in *now* rather than later on.
Looks like the problem that I mentioned earlier with iisworker crashing happens every 29 hours. Cecil on the wsus newsgroups has asked for logs from people who have this problem. I’ve contacted him to ask where to send the logs to. I’m going to apply the registry changes in 918041 to see if this fixes my problem.
Fixed! One of my servers has been failing to backup with the error “0xe00084af The directory or file was not found, or could not be accessed. Final error category: Job Errors. For additional information refer to link V-79-57344-33967” I spent ages troubleshooting the errors and trying to work out what was going on and found that it would fail to backup any file on the local hard disk of the machine.
I posted a note in the symantec forums and didn’t hear anything back, but did find a post that upgrading to 10d might fix it (not a current solution as this would mean purchasing an upgrade of the software for the exchange agent and the exchange agent is currently working)
The other solution was to stop SQL servers on the box. This server was the WSUS box and I had also recently upgraded it to version 3 of WSUS. This created (at least) two new services – SQL Server VSS Writer and Windows Internal Database (Microsoft ##SSEE). Through trial and error I discovered that stopping the SQL Server VSS Writer service meant the backup would work, which is weird as why this should affect me backing up something like c:\jobs\fred.bat which has nothing to do with SQLI don’t know.
I’m hoping that my forum posting about the problem will get a better solution but for now I’m just pleased to be able to backup my file server.
On the two boxes that I’ve upgraded to WSUS version 3 this week I have received errors with the IIS Worker process crashing. One of the boxes has DEP intervening with the process and the other box just comes up with a message asking me to send the data to Microsoft.
Eventvwr shows event 1009, Source W3SVC with the error message being “A process serving application pool ‘WsusPool’ terminated unexpectedly. The process id was ‘4652’. The process exit code was ‘0xc0000005’.”
The DEP error states “To help protect your computer, Windows has closed this program”,
Name: IIS Worker Process. Clicking on Change Settings gives me the DEP Screen,
which shows the IIS Worker process already allowed. Clicking close then offers to send a report to Microsoft (again). Oddly enough, the mmc console seems to work ok when launched so at the moment I’m not sure what is causing it. Seems too much of a coincidence for it NOT to be wsus3 though.
Not had too much time to look at the main cause for this – it could be due to the fact that the pc’s haven’t been rebooted since the install (and may need .net patches installed)
WSUS3 is out. I’m probably going to install it on a site where version2 isn’t working properly due to the dreaded selfupdatetree problem (and yes I have run the vbs script to patch it)
Had a customer whose wsus box wouldn’t download updates from microsoft with event id 364 – Content download failed. Reason: Access is denied. Source File < snip > destination File: d:\wsus\wsuscontent……
It looks like the permissions on the root of d: (in this case) are not correct – Network Service needs read access – unfortunately Network Service does not appear in the list of users to add to the drive (and you can’t right click d: to assign permissions).
Fortunately by using cacls you can change permissions – note that cacls is very powerful and you need to understand what you are doing before running this – take it from me, cacls going wrong can really mess with your system and your sanity and your job security!
If you are still with me, you need to do the following:
From a dos prompt:-
calcs . <--- this provides you with the current state before you change it
cacls . /e /g "NT AUTHORITY\NETWORK SERVICE":r
Then in wsus console, double click a client that needs an update, click on the status, click on an update that has failed. Click retry download. Look at the eventvwr and you should see event id 361 - Content synchronization started. A quick glance back at your wsus homepage should show the files being downloaded.