Resources and Guidance for Patch Issues for Administrators
To better remember where the log files end up for various patches, this wiki page is an attempt to recap them in one place for the Patching Administrator.
If the failure is in installation, - what is the error message?
Here's a page of error messages that help --
Finding a log file will help greatly in giving you information about what is failing.
If Windows 2003/XP and the update is NOT .NET or SQL, the log file for the patch should be in KB######.log in the c:\windows folder. Review the log, see what it says. For Vista and later, review the CBS log file -- see
If the update problem is impacting .NET -
http://blogs.msdn.com/b/astebner/archive/2008/08/28/8904493.aspx typically removal of all .net and reinstall of .net
http://blogs.msdn.com/b/astebner/archive/2005/08/22/unified-net-framework-troubleshooting-guide.aspx is typically
the best and only patch failure fixing we've got.
.NET log file location: Look in the event log and the location of the error log should be documented. For example 974417 will be in the documents and settings folder in a temp location of the profile of the user.
Event Type: Error
Event Source: MsiInstaller
Event Category: None
Event ID: 1023
Time: 12:09:14 PM
Product: Microsoft .NET Framework 2.0 Service Pack 2 - Update 'KB974417' could not be installed. Error code 1603. Additional information is available in the log file C:\DOCUME~1\AISCER~1\LOCALS~1\Temp\Microsoft .NET Framework 2.0-KB974417_20091016_150533462-Msi0.txt.
If the update failure is impacting SQL, the log files are dependent on the version of SQL.
http://blogs.msdn.com/b/psssql/archive/2009/08/18/sql-server-cumulative-update-or-service-pack-fails-with-create-database-failed.aspx 2008 era SQL (and 2005 as I recall) are typically in a setup\bootstrap\log\hotfix\blah blah folder and it gives you clues
of what went wrong. Typically with SQL it's permissions and it's greek to me so I urge folks to call Microsoft. Older SQL's put their log files in temporary locations.
If the update failure is impacting SharePoint version 3, look for logs in %Program Files%\Common Files\Microsoft Shared\web server extensions\12\logs and review the event logs for information. Try just running the psconfig command first
and see if that alone completes the updating process.
How to troubleshoot common errors that occur when you run the SharePoint Products and Technologies Configuration Wizard on a computer that is running Windows SharePoint Services 3.0 or SharePoint Server 2007:
Sometimes the issue on a box is due to installer wrapper failures
http://msmvps.com/blogs/bradley/archive/2009/08/07/so-i-was-having-problems-getting-net-to-patch.aspx and you may
need to edit the registry like in that blog post or use the Windows Installer Cleanup utility -
In the Vista and later era you'll sometimes see the system stuck on step 3 of 3
Getting out of a no boot situation after installing updates on Windows 7-2008R2 - Ramblings of a Support Engineer - Site Home - TechNet Blogs:
If you get one of these follow up with the CheckSUR tool (sample blog post about Checksur -
For community resources for patching issues, sign up for the listserve at
www.patchmanagement.org where fellow administrators post and comment on patching issues they see in their firms. If you have issues with a security update, it is a free call to Microsoft at 1-800-Microsoft or 1-866-pcsafety
to get resolution. Microsoft wants you to get these updates installed on your systems so they will freely support you in any patching problems you have with security updates. Non security updates do not have the same level of free support. Service packs typically
have a free support window, but it's typcally limited in time. Thus apply service packs during these free support windows as a best practice.
Operating systems and applications have support timelines. The determination of the exact end of life date is too complicated for this wiki post but can be reviewed here:
http://support.microsoft.com/gp/lifepolicy Remember that if your operating system service pack is no longer supported you will no longer get security updates released for it. If you suddenly find that
you can't remember the last time you updated a particular system because you didn't get offered updates, chances are that system is no longer supported and that's why it's not being offered updates.
Ensure you reboot after patching. After you install an update, if the system alerts you that it needs to reboot, reboot immediately. If you do not reboot immediately the system is not protected from the vulnerability the patch is protecting
you from. In addition, general "wierdness" can occur on a system that has files and dlls changed but not rebooted. Support personnel will tell you that the system may be unstable in this condition. You can download updates and do not install, but please do
not download, install, and not reboot as soon as possible.
Timing of updates. Security updates are released by Microsoft on the second Tuesday of each month. On the Thursday prior to the second Tuesday, an email will be sent alerting you to the type and number of security patches to expect. If you
sign up for the comprehensive alerts from this page -
http://technet.microsoft.com/en-us/security/dd252948.aspx you will get these "heads up" emails automatically.
Details of these updates will only be posted on the second Tuesday of the month. On the fourth Tuesday of the Month, Microsoft releases non security and servicing updates. These consist of application compatibility updates and at times, .NET servicing updates.
On the Thursday prior to the fourth Tuesday,
http://support.microsoft.com/kb/894199 lists what may be released. It can change however.
Anytime you see an update on this fourth Tuesday of the month, it is not an out of band (out of cycle) update. If you see an update that is not on the second Tuesday and is not on the fourth Tuesday, it may indeed be an out of band (out of cycle) release.
Please pay extra attention to updates that don't fall in the second or fourth week releases as they may need immediate deployment.
Windows update setting changes. Microsoft never ever changes the windows update settings on your system. More often than not if you think that your system rebooted without your permission or changed the Windows update settings, it's a known
issue in the operating system.
System rebooted without your permissions - on heavy patch months, patches will download in the background. If you have "download but do not install" chosen as your update setting, the patches will trickle down, and may not make the yellow alert icon pop
up. Then as you shut down the computer, you may not notice that "install updates at shutdown" is present on the shut down button and may install updates. This was blogged about
Changed windows update settings - typically third party software, antivirus, or even Office 2007 installs may flip the settings of your windows update to automatic updates. Review the windowsupdate.log at c:\windows and you can see what has caused the change
in settings. Windows update settings never spontaneously change.