Mailing List Archive

Windows update fails with ISATAP-like addresses
Hi,

if anyone within MSFT could contact me on- or off-list about this issue
I would be very grateful.

we run a reasonably large on-campus deployment of ISATAP for Windows
clients in areas where native IPv6 is not possible. This has worked fine
for years and still is. I'm well aware of all the pros and cons of
ISATAP and I don't want a religious debate about using tunnels right now.

A couple of months ago we started hearing about stray Windows update
issues on Windows 8.1 hosts that had ISATAP connectivity. If the host
has native IPv6, VPN-tunneled IPv6 or no IPv6 at all it works just fine.

The issue has now become more prevalent (also with Windows 7) and I had
the chance to debug this issue. The client displays an error code
80072F76 (unknown error)

This is what the log says:

2014-09-08 16:17:20:850 840 b00 AU Triggering AU detection through
DetectNow API
2014-09-08 16:17:20:850 840 b00 AU Triggering Online detection
(interactive)
2014-09-08 16:17:20:865 840 af8 AU #############
2014-09-08 16:17:20:865 840 af8 AU ## START ## AU: Search for updates
2014-09-08 16:17:20:865 840 af8 AU #########
2014-09-08 16:17:20:865 840 af8 AU <<## SUBMITTED ## AU: Search for
updates [CallId = {AEF34078-5F95-45A7-A8E1-41F1C92E12D2}]
2014-09-08 16:17:20:865 840 be0 Agent *************
2014-09-08 16:17:20:865 840 be0 Agent ** START ** Agent: Finding
updates [CallerId = AutomaticUpdates]
2014-09-08 16:17:20:865 840 be0 Agent *********
2014-09-08 16:17:20:865 840 be0 Agent * Online = Yes; Ignore download
priority = No
2014-09-08 16:17:20:865 840 be0 Agent * Criteria = "IsInstalled=0 and
DeploymentAction='Installation' or IsPresent=1 and
DeploymentAction='Uninstallation' or IsInstalled=1 and
DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0
and DeploymentAction='Uninstallation' and RebootRequired=1"
2014-09-08 16:17:20:865 840 be0 Agent * ServiceID =
{9482F4B4-E343-43B6-B170-9A65BC822C77} Windows Update
2014-09-08 16:17:20:865 840 be0 Agent * Search Scope = {Machine}
2014-09-08 16:17:20:897 840 be0 Setup Checking for agent SelfUpdate
2014-09-08 16:17:20:897 840 be0 Setup Client version: Core:
7.6.7600.320 Aux: 7.5.7601.17514
2014-09-08 16:17:20:897 840 be0 Misc Validating signature for
C:\Windows\SoftwareDistribution\WuRedir\9482F4B4-E343-43B6-B170-9A65BC822C77\wuredir.cab
with dwProvFlags 0x00000080:
2014-09-08 16:17:20:897 840 be0 Misc Microsoft signed: NA
2014-09-08 16:17:20:897 840 be0 Misc Validating signature for
C:\Windows\SoftwareDistribution\WuRedir\9482F4B4-E343-43B6-B170-9A65BC822C77\TMP4FCB.tmp
with dwProvFlags 0x00000080:
2014-09-08 16:17:20:912 840 be0 Misc Microsoft signed: NA
2014-09-08 16:17:21:053 840 be0 Misc WARNING: WinHttp:
SendRequestToServerForFileInformation failed with 0x80190194
2014-09-08 16:17:21:053 840 be0 Misc WARNING: WinHttp:
ShouldFileBeDownloaded failed with 0x80190194
2014-09-08 16:17:21:053 840 be0 Misc WARNING: DownloadFileInternal
failed for
http://ds.download.windowsupdate.com/v11/2/windowsupdate/redir/v6-win7sp1-wuredir.cab:
error 0x80190194
2014-09-08 16:17:21:162 840 be0 Misc WARNING: WinHttp:
SendRequestToServerForFileInformation failed with 0x80190194
2014-09-08 16:17:21:162 840 be0 Misc WARNING: WinHttp:
ShouldFileBeDownloaded failed with 0x80190194
2014-09-08 16:17:21:162 840 be0 Misc WARNING: DownloadFileInternal
failed for
http://download.microsoft.com/v11/2/windowsupdate/redir/v6-win7sp1-wuredir.cab:
error 0x80190194
2014-09-08 16:17:21:505 840 be0 Misc WARNING: WinHttp:
WinHttpQueryHeaders(WINHTTP_QUERY_LAST_MODIFIED) failed. error 0x80072f76
2014-09-08 16:17:21:505 840 be0 Misc WARNING: GetServerFileTime failed.
error 0x80072f76
2014-09-08 16:17:21:505 840 be0 Misc WARNING: WinHttp:
IsFileToBeDownloaded failed with 0x80072f76
2014-09-08 16:17:21:505 840 be0 Misc WARNING: WinHttp:
ShouldFileBeDownloaded failed with 0x80072f76
2014-09-08 16:17:21:677 840 be0 Misc WARNING: WinHttp:
WinHttpQueryHeaders(WINHTTP_QUERY_LAST_MODIFIED) failed. error 0x80072f76
2014-09-08 16:17:21:677 840 be0 Misc WARNING: GetServerFileTime failed.
error 0x80072f76
2014-09-08 16:17:21:677 840 be0 Misc WARNING: WinHttp:
IsFileToBeDownloaded failed with 0x80072f76
2014-09-08 16:17:21:677 840 be0 Misc WARNING: WinHttp:
ShouldFileBeDownloaded failed with 0x80072f76
2014-09-08 16:17:21:848 840 be0 Misc WARNING: WinHttp:
WinHttpQueryHeaders(WINHTTP_QUERY_LAST_MODIFIED) failed. error 0x80072f76
2014-09-08 16:17:21:848 840 be0 Misc WARNING: GetServerFileTime failed.
error 0x80072f76
2014-09-08 16:17:21:848 840 be0 Misc WARNING: WinHttp:
IsFileToBeDownloaded failed with 0x80072f76
2014-09-08 16:17:21:848 840 be0 Misc WARNING: WinHttp:
ShouldFileBeDownloaded failed with 0x80072f76
2014-09-08 16:17:22:020 840 be0 Misc WARNING: WinHttp:
WinHttpQueryHeaders(WINHTTP_QUERY_LAST_MODIFIED) failed. error 0x80072f76
2014-09-08 16:17:22:020 840 be0 Misc WARNING: GetServerFileTime failed.
error 0x80072f76
2014-09-08 16:17:22:020 840 be0 Misc WARNING: WinHttp:
IsFileToBeDownloaded failed with 0x80072f76
2014-09-08 16:17:22:020 840 be0 Misc WARNING: WinHttp:
ShouldFileBeDownloaded failed with 0x80072f76
2014-09-08 16:17:22:020 840 be0 Misc WARNING: DownloadFileInternal
failed for
http://fe2.update.microsoft.com/v11/2/windowsupdate/redir/v6-win7sp1-wuredir.cab:
error 0x80072f76
2014-09-08 16:17:22:020 840 be0 Setup FATAL: GetIdentUrlFromRedirector,
err = 0x80072F76
2014-09-08 16:17:22:020 840 be0 Setup WARNING: SelfUpdate check failed
to download package information, error = 0x80072F76
2014-09-08 16:17:22:020 840 be0 Setup FATAL: SelfUpdate check failed,
err = 0x80072F76
2014-09-08 16:17:22:020 840 be0 Agent * WARNING: Skipping scan,
self-update check returned 0x80072F76
2014-09-08 16:17:22:020 840 be0 Agent * WARNING: Exit code = 0x80072F76
2014-09-08 16:17:22:020 840 be0 Agent *********
2014-09-08 16:17:22:020 840 be0 Agent ** END ** Agent: Finding
updates [CallerId = AutomaticUpdates]
2014-09-08 16:17:22:020 840 be0 Agent *************
2014-09-08 16:17:22:020 840 be0 Agent WARNING: WU client failed
Searching for update with error 0x80072f76
2014-09-08 16:17:22:020 840 a60 AU >>## RESUMED ## AU: Search for
updates [CallId = {AEF34078-5F95-45A7-A8E1-41F1C92E12D2}]
2014-09-08 16:17:22:020 840 a60 AU # WARNING: Search callback failed,
result = 0x80072F76
2014-09-08 16:17:22:020 840 a60 AU # WARNING: Failed to find updates
with error code 80072F76
2014-09-08 16:17:22:020 840 a60 AU #########
2014-09-08 16:17:22:020 840 a60 AU ## END ## AU: Search for updates
[CallId = {AEF34078-5F95-45A7-A8E1-41F1C92E12D2}]
2014-09-08 16:17:22:020 840 a60 AU #############
2014-09-08 16:17:22:020 840 a60 AU Successfully wrote event for AU
health state:0
2014-09-08 16:17:22:020 840 a60 AU AU setting next detection timeout to
2014-09-08 19:17:22
2014-09-08 16:17:22:020 840 a60 AU Setting AU scheduled install time to
2014-09-09 01:00:00
2014-09-08 16:17:22:020 840 a60 AU Successfully wrote event for AU
health state:0
2014-09-08 16:17:22:020 840 a60 AU Successfully wrote event for AU
health state:0
2014-09-08 16:17:27:027 840 be0 Report REPORT EVENT:
{575B9911-08B9-494F-84DB-3CCDC258D82F} 2014-09-08
16:17:22:020+0200 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1
80072f76 SelfUpdate Failure Software Synchronization Windows Update
Client failed to detect with error 0x80072f76.
2014-09-08 16:17:27:043 840 be0 Report CWERReporter::HandleEvents - WER
report upload completed with status 0x8
2014-09-08 16:17:27:043 840 be0 Report WER Report sent: 7.6.7600.320
0x80072f76 D67661EB-2423-451D-BF5D-13199E37DF28 Scan 101 Unmanaged
2014-09-08 16:17:27:043 840 be0 Report CWERReporter finishing event
handling. (00000000)

Looking at the Wireshark trace of that request I see the client requesting

HEAD /v11/2/windowsupdate/redir/v6-win7sp1-wuredir.cab?1409080857 HTTP/1.1
Connection: Keep-Alive
Accept: */*
User-Agent: Windows-Update-Agent
Host: fe2.update.microsoft.com

four times in a row, which is always answered with

HTTP/1.1 200 OK
Content-Length: 0
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 08 Sep 2014 08:57:55 GMT

You might already see the possible problem. This is the answer when
coming from native IPv6 for the same URL (Linux host):

% curl -I
'http://fe2.update.microsoft.com/v11/2/windowsupdate/redir/v6-win7sp1-wuredir.cab?1409080857'
HTTP/1.1 200 OK
Content-Length: 23603
Content-Type: application/octet-stream
Last-Modified: Mon, 12 May 2014 21:56:34 GMT
Accept-Ranges: bytes
ETag: "115695a2d6ecf1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 08 Sep 2014 14:36:45 GMT

This is the very same Linux host using a real ISATAP tunnel

% curl --interface is0 -I
'http://fe2.update.microsoft.com/v11/2/windowsupdate/redir/v6-win7sp1-wuredir.cab?1409080857'

HTTP/1.1 200 OK
Content-Length: 0
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 08 Sep 2014 14:38:49 GMT

As you see it looks vastly different. The content-length is 0, no
Content-Type, no Last-Modified, no Etag.

The same issue appears when I set an address on the native ethernet
interface to _look_ like an ISATAP address (<prefix>:5efe:...), so the
problem is not even related to using tunnels but to the address format.

2001:4ca0:0:f000:eef4:bbff:fe12:4bb6 works, native ethernet
2001:4ca0:0:f000:200:5efe:81bb:f41 does not work, native ethernet
2001:4ca0:0:fe00:200:5efe:81bb:f41 does not work, real ISATAP

if I had to guess I would say that something in the Webserver stacks
maps the address back to <prefix>:5efe:200:129.187.15.65 and something
parsing the address barfs at that.

Bernhard
Re: Windows update fails with ISATAP-like addresses [ In reply to ]
Hi Everyone,
>
> if anyone within MSFT could contact me on- or off-list about this issue
> I would be very grateful.
>
> we run a reasonably large on-campus deployment of ISATAP for Windows
> clients in areas where native IPv6 is not possible. This has worked fine
> for years and still is. I'm well aware of all the pros and cons of
> ISATAP and I don't want a religious debate about using tunnels right now.
>
> A couple of months ago we started hearing about stray Windows update
> issues on Windows 8.1 hosts that had ISATAP connectivity. If the host
> has native IPv6, VPN-tunneled IPv6 or no IPv6 at all it works just fine.
>
> The issue has now become more prevalent (also with Windows 7) and I had
> the chance to debug this issue. The client displays an error code
> 80072F76 (unknown error)

I'm happy to report that the MSRC (Microsoft Security Response Center)
followed up on this and Windows Update for ISATAP hosts is fixed since
at least September 17th. According to them the fix is not final yet, but
I can confirm that all our issues are resolved.

Best Regards,
Bernhard
Re: Windows update fails with ISATAP-like addresses [ In reply to ]
Hi,

> Hi Everyone,
>>
>> if anyone within MSFT could contact me on- or off-list about this issue
>> I would be very grateful.
>>
>> we run a reasonably large on-campus deployment of ISATAP for Windows
>> clients in areas where native IPv6 is not possible. This has worked fine
>> for years and still is. I'm well aware of all the pros and cons of
>> ISATAP and I don't want a religious debate about using tunnels right now.
>>
>> A couple of months ago we started hearing about stray Windows update
>> issues on Windows 8.1 hosts that had ISATAP connectivity. If the host
>> has native IPv6, VPN-tunneled IPv6 or no IPv6 at all it works just fine.
>>
>> The issue has now become more prevalent (also with Windows 7) and I had
>> the chance to debug this issue. The client displays an error code
>> 80072F76 (unknown error)
>
> I'm happy to report that the MSRC (Microsoft Security Response Center)
> followed up on this and Windows Update for ISATAP hosts is fixed since
> at least September 17th. According to them the fix is not final yet, but
> I can confirm that all our issues are resolved.

We are getting reports that this has been broken for at least four
weeks, again. ISATAP clients are broken, normal native clients work fine.

It is harder to trace from the outside this time since they are using
HTTPS this time. WindowsUpdate.log says

2015-07-24 07:09:51:479 936 e80 DnldMgr Contacting regulation server
for 2 updates.
2015-07-24 07:09:51:494 936 e80 IdleTmr WU operation (Regulator
Refresh) started; operation # 177; does use network; is at background
priority
2015-07-24 07:09:51:557 936 e80 EP Got
7971F918-A847-4430-9279-4A52D1EFE18D redir Client/Server URL:
"https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx"
2015-07-24 07:09:51:573 936 e80 PT WARNING: Cached cookie has expired
or new PID is available
2015-07-24 07:09:51:838 936 bd4 Service UpdateNetworkState Ipv6,
cNetworkInterfaces = 4.
2015-07-24 07:09:59:133 936 e80 IdleTmr WU operation
(CAgentProtocolTalker::GetCookie_WithRecovery) started; operation # 178;
does use network; is at background priority
2015-07-24 07:09:59:894 936 e80 WS WARNING: Nws Failure:
errorCode=0x803d0000
2015-07-24 07:09:59:894 936 e80 WS WARNING: Fehler bei der
Kommunikation mit dem Endpunkt bei
"https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx".
2015-07-24 07:09:59:894 936 e80 WS WARNING: In der Antwort des Servers
fehlt der HTTP-Header für den Inhaltstyp.
2015-07-24 07:09:59:894 936 e80 WS WARNING: MapToSusHResult mapped Nws
error 0x803d0000 to 0x80240439
2015-07-24 07:09:59:894 936 e80 WS WARNING: Web service call failed
with hr = 80240439.
2015-07-24 07:09:59:894 936 e80 WS WARNING: Current service auth
scheme='None'.
2015-07-24 07:09:59:894 936 e80 WS WARNING: Proxy List used: '(null)',
Bypass List used: '(null)', Last Proxy used: '(null)', Last auth Schemes
used: 'None'.
2015-07-24 07:09:59:894 936 e80 WS FATAL: OnCallFailure failed with
hr=0X80240439

The german error message in the middle says "Missing Content-Type HTTP
header".

I don't see a Content-Type header when trying with curl at all, but
again the headers are vastly different between IPv4/native IPv6 on one
side and ISATAP on the other.

% sudo curl -I --interface eth0 -k
https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Length: 0
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 24 Jul 2015 06:31:31 GMT

% sudo curl -4 -I --interface eth0 -k
https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Length: 0
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 24 Jul 2015 06:31:50 GMT

% sudo curl -I --interface is0 -k
https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx
HTTP/1.1 200 OK
Content-Length: 0
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Fri, 24 Jul 2015 06:32:00 GMT

I will try to reactivate my Microsoft case I had back then.

Regards,
Bernhard