Clients are not contacting the Updates Server Clientdiag 0x801901f4 Selfupdate 500.19

At the beginning of this year, we replaced the server that was running WSUS
with a new server with the same domain name, but instead of WS2003R2 x86 it
is running WS2008 x64. It has WSUS 3.0 SP1 installed on it. It was all set
up from scratch and it downloaded all the updates from scratch. This server
is a domain controller, and I remember that we tried to get PHP running
under it on IIS7 but that was a failure. The other DC is Windows Server
2003.

When the WS2008x64 server was built it was joined onto the domain, where the
other domain controller was running WS2003 R1 SP2 and held all the master
roles. Then, the WS2008 DC was promoted to all the master roles. Then the
WS2003 DC was taken offline and completely rebuilt from scratch, new disks,
new installation of WS2003 R2, and it was rejoined to the domain, but was
not restored to the master roles.

This is what I wrote down about trying to get PHP 5.1 running on the WS2008
DC:

"At this stage trying to load a simple php file got me to a HTTP 404.17
error message, "The requested content appears to be script and will not be
served by the static file handler". I did a bit of poking around, and then
tried going to Application Pools and enabling 32 bit applications on the
advanced settings of the DefaultAppPool.
This now gets me a "HTTP 500.19 - Internal Server Error. The requested page
cannot be accessed because the related configuration data for the page is
invalid."
Microsoft suggested giving IIS_IUSRS group permissions to read the config
file for the server. I set this up, but it hasn't changed the error message
from 500.19"

So the error message at that stage was 500.19 from the IIS7 server.

So at that stage I gave up trying to run PHP and let IIS7 just run WSUS. We
had no trouble running PHP on the previous server of the same name that was
running WS2003. And I was also able to run PHP on another WS2008 server
that wasn't a DC. No errors, no problems.

So, a few months later, running WSUS I am aware that at least 50% of our 140
computers are not registered in the Updates server at all. As our policies
have not changed I picked a computer that had not connected because it does
not appear at all in the WSUS console. I found first of all its
WindowsUpdate.log file contained only four lines of entries dated last
December (before we installed our new updates server). And when I ran
wuauaclt /detectnow on it, it logged an entry in that same log file for a
connection straight through to windowsupdate.com

I got clientdiag and ran it on this PC and it passed everything except right
at the end it shows an error like this:

WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
&downloadBuffer) failed with hr=0x801901f4

I looked up that error and didn't find much except someone in a message said
something like, the self update tree on Port 80 might not be working. So I
try going to the home page of the server, on Port 80 of course, and I get a
500 Server Configuration Error ( http://servername/ ). I looked up the
logs, and nearly every entry in the first log file I looked at, looked like
one of these lines:

2009-05-14 03:55:41 ::1 GET /selfupdate/iuident.cab - 80 - ::1 - 500 19 126
3
2009-05-14 04:02:25 192.168.1.254 GET
/selfupdate/au/x86/xp/en/wuaucomp.cab - 80 - 192.168.0.15
Windows-Update-Agent 500 19 64 61

Now I think that 500 19 is the same as 500.19 which of course is just the
same error I was getting when I tried to run a PHP web page back there.

I have to be fair, though, and say that not all computers have this
connection problem, and I don't know why the results come out differently
for different computers. I can only think that the computers that are having
problems are trying to access the self update tree and when that doesn't
work, they stop trying to connect. It is a little bit odd seemingly that
WindowsUpdate.log doesn't contain anything that would tell me about this
error and there is nothing in the Event logs of affected computers either.
There seems to be some strange design issue with the WSUS client that it
doesn't log this kind of problem except for the entry that IIS puts into its
own logs.

Apparently the 500.19 is something to do with running WSUS (or just about
any type of web site) on a DC. I don't know whether WSUS was installed first
before the DC was promoted to the domain or if it happened the other way
around. I just know, now, that this is a production domain controller, and
taking it offline to reinstall WSUS would be a big problem. So I figure that
the solution is to fix the 500.19 and that will also fix PHP, if I still
want to run it then.




--

OK this is all a bit mixed up because there are actually 2 separate problems
happening.

I discovered there are actually TWO log files for Windows Update. One is
called Windows Update.log and the other is called WindowsUpdate.log
And I just discovered when I started out I looked at the wrong file.

Now what is being logged in the right log file is this:
Service ** END ** Service: Service exit [Exit code = 0x240001]

This is consistent across two computers I looked at. One of them is
reporting in the WSUS console and the other isn't. Apart from that
everything seems to be happening properly. The events are all being logged
in the log and they look fairly normal. The one that is reporting is
currently 43 updates behind. Even when I run wuauclt /detectnow on it, it
isn't reporting any updates available for installation.
It has logged into the IIS7 event log some entries like this:
2009-05-14 06:53:47 192.168.1.254 GET
/selfupdate/au/x86/xp/en/wuaucomp.cab - 80 - 192.168.0.19
Windows-Update-Agent 500 19 64 5

That is its actual IP address right now.

The one that isn't reporting seems to be doing much the same thing. Its
entries in IIS7 log look like this:
2009-05-14 04:03:28 192.168.1.254 GET
/selfupdate/au/x86/xp/en/wuaucomp.cab - 80 - 192.168.0.15
Windows-Update-Agent 500 19 64 3

Again, that is its actual IP address.

The main difference between the two computers in their WindowsUpdate.LOg
files is this section:

Computer that reports to the WSUS server:
===========================
2009-05-14 18:50:18:741 3852 f04 Setup *********** Setup: Checking whether
self-update is required ***********
2009-05-14 18:50:18:741 3852 f04 Setup * Inf file:
c:\364d7ccf51c688fd9101d4195bc4c6\wusetup.inf
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\cdm.dll: target version = 7.1.6001.65, required version
= 7.0.6000.374
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuapi.dll: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuapi.dll.mui: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuauclt.exe: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuaucpl.cpl: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuaucpl.cpl.mui: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:756 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuaueng.dll: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuaueng.dll.mui: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wucltui.dll: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wucltui.dll.mui: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wups.dll: target version = 7.1.6001.65, required version
= 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wups2.dll: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup Update NOT required for
C:\WINDOWS\system32\wuweb.dll: target version = 7.1.6001.65, required
version = 7.0.6000.374
2009-05-14 18:50:18:772 3852 f04 Setup * IsUpdateRequired = No
2009-05-14 18:50:18:787 3852 f04 Setup Windows Update Client standalone
setup : eula file path is c:\364d7ccf51c688fd9101d4195bc4c6\en\eula.rtf
2009-05-14 18:50:21:568 3852 f04 Setup wusetup has finished. Exit code is
0. Reboot is NOT needed

Note: This computer had the latest version of WindowsUpdateAgent manually
installed from this download:
architecture name="x86" clientVersion="7.2.6001.788"
downloadUrl="http://download.windowsupdate.com/WindowsUpdate/redist/standalone/7.2.6001.788/WindowsUpdateAgent30-x86.exe"

And in fact, this computer has always been reporting to the WSUS server even
before I made sure this WindowsUpdateAgent update had been installed.

Computer that doesn't report to the WSUS server:
================================
2009-05-14 19:16:43:412 1156 bc8 Setup *********** Setup: Checking whether
self-update is required ***********
2009-05-14 19:16:43:412 1156 bc8 Setup * Inf file:
C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default \wsus3setup.inf
2009-05-14 19:16:43:428 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\cdm.dll: target version = 7.1.6001.65, required version
= 7.1.6001.65
2009-05-14 19:16:43:428 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuapi.dll: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:444 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuapi.dll.mui: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:444 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuauclt.exe: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:444 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuaucpl.cpl: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:444 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuaucpl.cpl.mui: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:444 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuaueng.dll: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuaueng.dll.mui: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wucltui.dll: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wucltui.dll.mui: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wups.dll: target version = 7.1.6001.65, required version
= 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wups2.dll: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup Update NOT required for
C:\WINDOWS\system32\wuweb.dll: target version = 7.1.6001.65, required
version = 7.1.6001.65
2009-05-14 19:16:43:459 1156 bc8 Setup * IsUpdateRequired = No

Now these two computers are identical hardware and they were both built from
the same sysprepped image. They are even logging on with the same user
profile.

On a hunch I went to 192.168.0.15, ran the WindowsUpdateAgent3.0 update on
it, and ran wuauclt /detectnow on it, and checked the log again. This time,
nearly the same except at the bottom there was
"Setup Callback ReportProgress failed: 0x8007000d".

--


"NZSchoolTech" <> wrote in message
news:eFHb0#...
> At the beginning of this year, we replaced the server that was running
> WSUS with a new server with the same domain name, but instead of WS2003R2
> x86 it is running WS2008 x64. It has WSUS 3.0 SP1 installed on it. It was
> all set up from scratch and it downloaded all the updates from scratch.
> This server is a domain controller, and I remember that we tried to get
> PHP running under it on IIS7 but that was a failure. The other DC is
> Windows Server 2003.
>
> When the WS2008x64 server was built it was joined onto the domain, where
> the other domain controller was running WS2003 R1 SP2 and held all the
> master roles. Then, the WS2008 DC was promoted to all the master roles.
> Then the WS2003 DC was taken offline and completely rebuilt from scratch,
> new disks, new installation of WS2003 R2, and it was rejoined to the
> domain, but was not restored to the master roles.
>
> This is what I wrote down about trying to get PHP 5.1 running on the
> WS2008 DC:
>
> "At this stage trying to load a simple php file got me to a HTTP 404.17
> error message, "The requested content appears to be script and will not be
> served by the static file handler". I did a bit of poking around, and then
> tried going to Application Pools and enabling 32 bit applications on the
> advanced settings of the DefaultAppPool.
> This now gets me a "HTTP 500.19 - Internal Server Error. The requested
> page cannot be accessed because the related configuration data for the
> page is invalid."
> Microsoft suggested giving IIS_IUSRS group permissions to read the config
> file for the server. I set this up, but it hasn't changed the error
> message from 500.19"
>
> So the error message at that stage was 500.19 from the IIS7 server.
>
> So at that stage I gave up trying to run PHP and let IIS7 just run WSUS.
> We had no trouble running PHP on the previous server of the same name that
> was running WS2003. And I was also able to run PHP on another WS2008
> server that wasn't a DC. No errors, no problems.
>
> So, a few months later, running WSUS I am aware that at least 50% of our
> 140 computers are not registered in the Updates server at all. As our
> policies have not changed I picked a computer that had not connected
> because it does not appear at all in the WSUS console. I found first of
> all its WindowsUpdate.log file contained only four lines of entries dated
> last December (before we installed our new updates server). And when I ran
> wuauaclt /detectnow on it, it logged an entry in that same log file for a
> connection straight through to windowsupdate.com
>
> I got clientdiag and ran it on this PC and it passed everything except
> right at the end it shows an error like this:
>
> WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
> &downloadBuffer) failed with hr=0x801901f4
>
> I looked up that error and didn't find much except someone in a message
> said something like, the self update tree on Port 80 might not be working.
> So I try going to the home page of the server, on Port 80 of course, and I
> get a 500 Server Configuration Error ( http://servername/ ). I looked up
> the logs, and nearly every entry in the first log file I looked at, looked
> like one of these lines:
>
> 2009-05-14 03:55:41 ::1 GET /selfupdate/iuident.cab - 80 - ::1 - 500 19
> 126 3
> 2009-05-14 04:02:25 192.168.1.254 GET
> /selfupdate/au/x86/xp/en/wuaucomp.cab - 80 - 192.168.0.15
> Windows-Update-Agent 500 19 64 61
>
> Now I think that 500 19 is the same as 500.19 which of course is just the
> same error I was getting when I tried to run a PHP web page back there.
>
> I have to be fair, though, and say that not all computers have this
> connection problem, and I don't know why the results come out differently
> for different computers. I can only think that the computers that are
> having problems are trying to access the self update tree and when that
> doesn't work, they stop trying to connect. It is a little bit odd
> seemingly that WindowsUpdate.log doesn't contain anything that would tell
> me about this error and there is nothing in the Event logs of affected
> computers either. There seems to be some strange design issue with the
> WSUS client that it doesn't log this kind of problem except for the entry
> that IIS puts into its own logs.
>
> Apparently the 500.19 is something to do with running WSUS (or just about
> any type of web site) on a DC. I don't know whether WSUS was installed
> first before the DC was promoted to the domain or if it happened the other
> way around. I just know, now, that this is a production domain controller,
> and taking it offline to reinstall WSUS would be a big problem. So I
> figure that the solution is to fix the 500.19 and that will also fix PHP,
> if I still want to run it then.
>
>
>
>
> --
>
>

Oops, even more confused.

In the reply I just posted to this message, the computer that ____IS___
reporting into WSUS is the computer which has the IP address
192.168.0.15
It is running Windows XP Service Pack 3

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The 43 updates that it has not got are all shown as "Not Approved" in spite
of the fact that the computer is in a group that automatically approves
every update.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

And the computer that ____IS____NOT____ reporting into WSUS is the computer
which has the IP address
192.168.0.19
It is also running Windows XP Service Pack 3.

Apart from that everything in that message is correct, the right log files
etc.

I guess if I want to detect any more possible causes I might have to try
running MSBA across the two of them to see what the actual differences are
because WSUS seems to be having a few problems...

Still if I can just get the self update tree working that might solve a few
issues.

Even the DC that is running WSUS is failing the selfupdate. The log entry
looks like

2009-05-14 06:25:42 ::1 GET /selfupdate/iuident.cab - 80 - ::1 - 500 19 126
5
where that odd IP address is IPv6 even though the protocol is disabled.

--


"NZSchoolTech" <> wrote in message
news:eFHb0#...
> At the beginning of this year, we replaced the server that was running
> WSUS

Found a solution for the 500.19 here:
http://forums.iis.net/t/1149768.aspx


--


"NZSchoolTech" <> wrote in message
news:eFHb0#...
> At the beginning of this year, we replaced the server that was running
> WSUS with a new server with the same domain name, but instead of WS2003R2
> x86 it is running WS2008 x64. It has WSUS 3.0 SP1 installed on it. It was
> all set up from scratch and it downloaded all the updates from scratch.
> This server is a domain controller, and I remember that we tried to get
> PHP running under it on IIS7 but that was a failure. The other DC is
> Windows Server 2003.
>
> When the WS2008x64 server was built it was joined onto the domain, where
> the other domain controller was running WS2003 R1 SP2 and held all the
> master roles. Then, the WS2008 DC was promoted to all the master roles.
> Then the WS2003 DC was taken offline and completely rebuilt from scratch,
> new disks, new installation of WS2003 R2, and it was rejoined to the
> domain, but was not restored to the master roles.
>
> This is what I wrote down about trying to get PHP 5.1 running on the
> WS2008 DC:
>
> "At this stage trying to load a simple php file got me to a HTTP 404.17
> error message, "The requested content appears to be script and will not be
> served by the static file handler". I did a bit of poking around, and then
> tried going to Application Pools and enabling 32 bit applications on the
> advanced settings of the DefaultAppPool.
> This now gets me a "HTTP 500.19 - Internal Server Error. The requested
> page cannot be accessed because the related configuration data for the
> page is invalid."
> Microsoft suggested giving IIS_IUSRS group permissions to read the config
> file for the server. I set this up, but it hasn't changed the error
> message from 500.19"
>
> So the error message at that stage was 500.19 from the IIS7 server.
>
> So at that stage I gave up trying to run PHP and let IIS7 just run WSUS.
> We had no trouble running PHP on the previous server of the same name that
> was running WS2003. And I was also able to run PHP on another WS2008
> server that wasn't a DC. No errors, no problems.
>
> So, a few months later, running WSUS I am aware that at least 50% of our
> 140 computers are not registered in the Updates server at all. As our
> policies have not changed I picked a computer that had not connected
> because it does not appear at all in the WSUS console. I found first of
> all its WindowsUpdate.log file contained only four lines of entries dated
> last December (before we installed our new updates server). And when I ran
> wuauaclt /detectnow on it, it logged an entry in that same log file for a
> connection straight through to windowsupdate.com
>
> I got clientdiag and ran it on this PC and it passed everything except
> right at the end it shows an error like this:
>
> WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
> &downloadBuffer) failed with hr=0x801901f4
>
> I looked up that error and didn't find much except someone in a message
> said something like, the self update tree on Port 80 might not be working.
> So I try going to the home page of the server, on Port 80 of course, and I
> get a 500 Server Configuration Error ( http://servername/ ). I looked up
> the logs, and nearly every entry in the first log file I looked at, looked
> like one of these lines:
>
> 2009-05-14 03:55:41 ::1 GET /selfupdate/iuident.cab - 80 - ::1 - 500 19
> 126 3
> 2009-05-14 04:02:25 192.168.1.254 GET
> /selfupdate/au/x86/xp/en/wuaucomp.cab - 80 - 192.168.0.15
> Windows-Update-Agent 500 19 64 61
>
> Now I think that 500 19 is the same as 500.19 which of course is just the
> same error I was getting when I tried to run a PHP web page back there.
>
> I have to be fair, though, and say that not all computers have this
> connection problem, and I don't know why the results come out differently
> for different computers. I can only think that the computers that are
> having problems are trying to access the self update tree and when that
> doesn't work, they stop trying to connect. It is a little bit odd
> seemingly that WindowsUpdate.log doesn't contain anything that would tell
> me about this error and there is nothing in the Event logs of affected
> computers either. There seems to be some strange design issue with the
> WSUS client that it doesn't log this kind of problem except for the entry
> that IIS puts into its own logs.
>
> Apparently the 500.19 is something to do with running WSUS (or just about
> any type of web site) on a DC. I don't know whether WSUS was installed
> first before the DC was promoted to the domain or if it happened the other
> way around. I just know, now, that this is a production domain controller,
> and taking it offline to reinstall WSUS would be a big problem. So I
> figure that the solution is to fix the 500.19 and that will also fix PHP,
> if I still want to run it then.
>
>
>
>
> --
>
>