This technical note addresses errors encountered while using Windows Update and/or Microsoft Update where your computers sit behind an ISA firewall. You may be getting any of the followings error messages:

	[Error number: 0x8024402C] or [Error number: 0x80072EFE] or [Error number: 0x80072f78] or [Error number: 0x8024502D]
	The website has encountered a problem and cannot display the page you are trying to view.

Most people will encounter the error number 0x8024402C for XP workstations that sit behind ISA firewalls. The error number 0x80072EFE is new to Microsoft Update. You may also see the error number 0x80072f78 and/or the error message 0x8024402C. All these error messages are related to the inability of Windows Update and/or Microsoft Update to communicate properly to the Microsoft support sites for these system tools. This Technical note may help you solve your problem.

After resolving the 0x8024402C (or the 0x80072EFE) error and then 0x80072f78 error, you may then see the 0x8024502D error. The best way I can describe this error is as a client side proxy setting incongruency. For a solution to this issue view the technical note located at:

  http://www.electrosonics.net/technotes/xperror0x8024502d.htm

Microsoft ISA server is actually two proxies in one. The first proxy is ISA Web proxy services that handles clients like IE when they have the "use proxy" check box checked. Generally speaking, the rules on ISA server that control the Web Proxy behavior are called "Site and Content Rules". See http://www.isaserver.org/tutorials/Understanding_Site_and_content_rules.html for more information on "Site and Content Rules".

The second type of proxy service provided by the ISA server is that provided by the ISA firewall client software (sometimes also called winsock services). The ISA firewall client services applications that ignore the IE settings for proxy services, and/or applications that contain their own proxy settings, and/or applications that do not support proxy server settings at all. Generally speaking, the rules on the ISA server that control the ISA firewall client behavior are called "Protocol Rules". See http://www.isaserver.org/tutorials/Understanding_protocol_rules.html for more information on "Protocol Rules".

Now that we have a better understanding of how ISA should be working, we can now begin to discover where the problem lies. To simplify this issue, I disabled the ISA firewall client on the XP workstation so that only true proxy requests are being processed by the ISA server. Upon review of the Web Proxy log files, I discovered that the Windows Update Control request received an authentication error (error 12209) and was denied access to the requested update site do to a local authentication issue. It appears that the Windows Update Control only uses the "anonymous" user to access and download the XP updates. If you have disabled "anonymous" access of your ISA proxy services, then Windows Update and Microsoft Update will fail as the credentials of the logged in user are not sent by the Update Control to the ISA server when the ISA server returns a failed authentication response. 

The solution seems to be simple: Just create a rule in the "Site and Content Rules" to allow anyone (anonymous) to access the Microsoft update sites. But that solution will not work at this time (I am sure Microsoft will fix it sooner or later).

On further inspection, the Windows Update Control and its replacement Microsoft Update makes a special type of request (HEAD http://v5.windowsupdate...[snip for brevity]). It appears that ISA server begins to process the "HEAD" request and applies the "Site and Content Rules" rules for anonymous request hence the need to create a rule to allow anonymous access to the Microsoft update sites. But then, ISA server pulls a fast one and also looks at the "Protocol Rules" for permission to honor the anonymous access request.

Until this day, I have never seen a HTTP request from a client computer using only proxy services that required the ISA servers "Site and Content Rule" and a "Protocol Rule" in order to process the client request. It appears that there is more to learn about the workings of ISA server or that ISA server may have a problem.

There appears to be two problems here. The first being that the Windows Update Control and the Microsoft Update Control needs to retry the update request with the logged in users credentials. This may solve the second problem. The second problem is that the Windows Update Control needs to submit the request in a manner that ISA server can handle correctly. Maybe ISA server will require an update too. Either way, until Microsoft fixes this, the Windows Update and/or the Microsoft Update service for XP will continue to fail for those users who sit behind an ISA server unless they implement the work around listed above.

At one point, before making any changes to the ISA server settings, in the midst of trying all the known suggestions and KB's on the XP workstation, the update server could be accessed successfully! But after rebooting the workstation as instructed by the ISA firewall client install/repair/remove debugging steps and without downloading any updates, the XP workstation was unable to reconnect to the update servers. It continued to get the 0x8024402C error and/or the 0x80072f78 error. The good news is that after installing the workaround detailed above, Window Update is rock solid on my XP workstations.

10/4/2004	Discovered Microsoft KB article 885819
8/4/2005	Updated article for issues with Microsoft Update. Added new  url to destination set