The causes of the problem remain cloudy, but the symptoms are quite clear. Starting on Nov. 18, some Server 2003, Windows Home Server 2003, and Windows XP SP3 machines suddenly refused to connect to Microsoft Update. As best I can tell, Microsoft has not responded to the problem, not documented a workaround, and is doing nothing visible to fix it.
(Keep in mind that, although Windows XP is no longer supported, Security Essentials updates for XP still go through Microsoft Update, and all old patches for XP are still available -- when Microsoft Update is working.)
The main TechNet thread on the subject says the error looks like this:
The website has encountered a problem and cannot display the page you are trying to view. The options provided below might help you solve the problem.
Error number: 0x80248015
There are also lengthy discussions on the SANS Internet Storm Center site and on the MSFN site.
Some people have reported that simply setting the system clock back a couple of weeks and re-running the update bypasses whatever devils may be lurking. For most, though, that approach doesn't work.
Alternatives range from deleting the C:\WINDOWS\SoftwareDistribution folder to running wuauclt.exe /detectnow to chasing chicken entrails. Some of the fixes work on some machines, others don't.
Poster Steve on the SANS ISC thread noted an important detail. On machines that get clobbered, when you look at the files C:\WINDOWS\SoftwareDistribution\ AuthCabs\muauth.cab and C:\WINDOWS\SoftwareDistribution\ AuthCabs\authcab.cab you see a suspicious entry:
<ExpiryDate>2014-11-17T17:27:43.5251853-08:00</ExpiryDate>
That happens to coincide, more or less, with when Microsoft Update started to fail.
I looked at a couple of machines that are still working fine, and the authcab.cab file on them has this entry:
<ExpiryDate>2018-06-01T17:27:43.5251853-08:00</ExpiryDate>
The muauth.cab file has the 2014 <ExpiryDate>.
I have no idea why the authcab.cab file on some machines has the 2014 date, while others have the 2018 date. But this may be the telltale sign differentiating machines that can still connect to Microsoft Update from those that don't.
Poster b3270791 on the MSFN thread has a solution that seems to work, but it involves replacing the muweb.dll file on the broken machines with an earlier muweb.dll file downloaded from the Internet. While that approach doesn't exactly exhibit world-class security best practices, it seems to work.
Does anybody at Microsoft give a hang, with XP already officially out to pasture and Server 2003 due to follow it to the glue farm on July 14, 2015?
Server 2003 admins have been twiddling their thumbs for a week, unable to install that out-of-band patch.
XP users are affected, too, but who cares? Microsoft's making good on its promise to deliver Security Essentials updates to XP customers. If the customers can't install them, well, that's one of those nasty implementation details, you know.