Clients Not Yet Reported

[Jmeanor]

We have set up GP to point the user computers to the WSUS server and populate
the computer groups. That is working. But most of the computers are showing
up as Not Yet Reported. This is after several days. The computer is found but
not scanned. Both 2000 and XP machines. What is preventing the scanning of
the computers?

[Lawrence Garvin]

Most likely cause of the failure of the scanning of the computers given the
data provided is that the client did not successfully selfupdate from port
80 of the WSUS server, and thus has not been able to perform a detection
cycle with the server, which would clear the "Not Yet Reported" status and
replace it with the updates "Needed".

Since it's occuring across platforms, and apparently to all of your systems,
I'd venture an educated guess that the seflupdate virtual directory is
either non existent on port 80, or that it does not have anonymous access
enabled. Inspect the %windir%\WindowsUpdate.log logfile for specific
events/errors related to the client.

Post by Jmeanor
We have set up GP to point the user computers to the WSUS server and populate
the computer groups. That is working. But most of the computers are showing
up as Not Yet Reported. This is after several days. The computer is found but
not scanned. Both 2000 and XP machines. What is preventing the scanning of
the computers?

[Kent Meyer]

I have the same thing happening but not with all the computers. I have
approximately 360 computers that are listed in WSUS but roughly 45 of them
show that they have not yet Reported. The 300 or so have reported,
downloaded, installed, and reported back successfully.

Do you have any ideas as to what would cause this?

Thanks,
Kent

Post by Lawrence Garvin
Most likely cause of the failure of the scanning of the computers given
the data provided is that the client did not successfully selfupdate from
port 80 of the WSUS server, and thus has not been able to perform a
detection cycle with the server, which would clear the "Not Yet Reported"
status and replace it with the updates "Needed".
Since it's occuring across platforms, and apparently to all of your
systems, I'd venture an educated guess that the seflupdate virtual
directory is either non existent on port 80, or that it does not have
anonymous access enabled. Inspect the %windir%\WindowsUpdate.log logfile
for specific events/errors related to the client.

Post by Jmeanor
We have set up GP to point the user computers to the WSUS server and populate
the computer groups. That is working. But most of the computers are showing
up as Not Yet Reported. This is after several days. The computer is found but
not scanned. Both 2000 and XP machines. What is preventing the scanning of
the computers?

[Lawrence Garvin]

Yep.... several ideas, but first let me explain the 'scenario' that exists
while this message is present.

When the client first contacts the WSUS server, it checks to do a
selfupdate. The presence of the "Not Yet Reported" message is a confirmation
that the client is talking to the server, and has "registered" with the
server. It's also an indication that, following this detection of the
selfupdate, something /failed/ at the client.

The next step is to inspect the %windir%\WindowsUpdate.log for the specific
cause of the failure.

Post by Kent Meyer
I have the same thing happening but not with all the computers. I have
approximately 360 computers that are listed in WSUS but roughly 45 of them
show that they have not yet Reported. The 300 or so have reported,
downloaded, installed, and reported back successfully.
Do you have any ideas as to what would cause this?
Thanks,
Kent

Post by Lawrence Garvin
Most likely cause of the failure of the scanning of the computers given
the data provided is that the client did not successfully selfupdate from
port 80 of the WSUS server, and thus has not been able to perform a
detection cycle with the server, which would clear the "Not Yet Reported"
status and replace it with the updates "Needed".
Since it's occuring across platforms, and apparently to all of your
systems, I'd venture an educated guess that the seflupdate virtual
directory is either non existent on port 80, or that it does not have
anonymous access enabled. Inspect the %windir%\WindowsUpdate.log logfile
for specific events/errors related to the client.

Post by Jmeanor
We have set up GP to point the user computers to the WSUS server and populate
the computer groups. That is working. But most of the computers are showing
up as Not Yet Reported. This is after several days. The computer is found but
not scanned. Both 2000 and XP machines. What is preventing the scanning of
the computers?

[Kent Meyer]

Here is what the WindowsUpdate.log file states... I have searched Technet
for some of the errors but couldn't find anything. Do you have any other
ideas? I have already removed the registry entries to make sure the
workstation has a unique SUS sid.

Thanks for your help!

------------------------------------

2005-09-12 09:30:29 1020 b4 AU
#############

2005-09-12 09:30:29 1020 b4 AU ## START
## AU: Search for updates

2005-09-12 09:30:29 1020 b4 AU #########

2005-09-12 09:30:29 1020 b4 AU <<##
SUBMITTED ## AU: Search for updates [CallId =
{84D9ECC1-D830-43F9-8655-73507DD8E84C}]

2005-09-12 09:30:29 1020 580 Agent
*************

2005-09-12 09:30:29 1020 580 Agent ** START **
Agent: Finding updates [CallerId = AutomaticUpdates]

2005-09-12 09:30:29 1020 580 Agent *********

2005-09-12 09:30:43 1020 580 Setup ***********
Setup: Checking whether self-update is required ***********

2005-09-12 09:30:43 1020 580 Setup * Inf
file: C:\Windows\SoftwareDistribution\SelfUpdate\Default\wusetup.inf

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\cdm.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\iuengine.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuapi.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuauclt.exe: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuauclt1.exe: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuaucpl.cpl: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuaueng.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuaueng1.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wucltui.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wups.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wups2.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup Update NOT
required for C:\Windows\system32\wuweb.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:30:43 1020 580 Setup *
IsUpdateRequired = No

2005-09-12 09:30:45 1020 580 PT
+++++++++++ PT: Synchronizing server updates +++++++++++

2005-09-12 09:30:45 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx

2005-09-12 09:30:46 1020 580 PT
Initializing simple targeting cookie, clientId =
f6f1849e-1ee8-4d38-a320-3cf1eba0883c, target group = , DNS name =
is-2.corp.srfc.com

2005-09-12 09:30:46 1020 580 PT Server
URL = http://a-ilster-dc2:8530/SimpleAuthWebService/SimpleAuth.asmx

2005-09-12 09:30:55 1020 580 PT
+++++++++++ PT: Synchronizing extended update info +++++++++++

2005-09-12 09:30:55 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx

2005-09-12 09:30:57 1020 580 Agent * Found 0
updates and 10 categories in search

2005-09-12 09:30:57 1020 580 Report WARNING:
CEventNamespaceDefinition::Init failed = 8024f002.

2005-09-12 09:30:57 1020 580 Report WARNING:
InitReportingComponents failed: 8024f002

2005-09-12 09:30:57 1020 580 Report WARNING:
CEventNamespaceDefinition::Init failed = 8024f002.

2005-09-12 09:30:57 1020 580 Report WARNING:
InitReportingComponents failed: 8024f002

2005-09-12 09:30:57 1020 580 Agent *********

2005-09-12 09:30:57 1020 580 Agent ** END **
Agent: Finding updates [CallerId = AutomaticUpdates]

2005-09-12 09:30:57 1020 580 Agent
*************

2005-09-12 09:30:57 1020 580 AU >>##
RESUMED ## AU: Search for updates [CallId =
{84D9ECC1-D830-43F9-8655-73507DD8E84C}]

2005-09-12 09:30:57 1020 580 AU # 0
updates detected

2005-09-12 09:30:57 1020 580 AU #########

2005-09-12 09:30:57 1020 580 AU ## END
## AU: Search for updates [CallId = {84D9ECC1-D830-43F9-8655-73507DD8E84C}]

2005-09-12 09:30:57 1020 580 AU
#############

2005-09-12 09:30:57 1020 580 AU AU
setting next detection timeout to 2005-09-13 10:22:47

2005-09-12 09:27:39 1020 b4 Service *********

2005-09-12 09:27:39 1020 b4 Service ** END **
Service: Service exit [Exit code = 0x240001]

2005-09-12 09:27:39 1020 b4 Service
*************

2005-09-12 09:28:26 1020 eb0 Misc
=========== Logging initialized (build: 5.8.0.2469, tz: -0500) ===========

2005-09-12 09:28:26 1020 eb0 Misc =
Process: C:\Windows\System32\svchost.exe

2005-09-12 09:28:26 1020 eb0 Misc =
Module: C:\Windows\system32\wuaueng.dll

2005-09-12 09:28:26 1020 eb0 Service
*************

2005-09-12 09:28:26 1020 eb0 Service ** START **
Service: Service startup

2005-09-12 09:28:26 1020 eb0 Service *********

2005-09-12 09:28:26 1020 eb0 Agent * WU
client version 5.8.0.2469

2005-09-12 09:28:26 1020 eb0 Agent *
WARNING: Failed to obtain SusClientId

2005-09-12 09:28:26 1020 eb0 Agent * Base
directory: C:\Windows\SoftwareDistribution

2005-09-12 09:28:26 1020 eb0 Agent * Access
type: No proxy

2005-09-12 09:28:26 1020 eb0 Agent * Network
state: Connected

2005-09-12 09:28:46 1020 aec Report WARNING:
CEventNamespaceDefinition::Init failed = 8024f002.

2005-09-12 09:28:46 1020 aec Report WARNING:
InitReportingComponents failed: 8024f002

2005-09-12 09:28:46 1020 aec Agent ***********
Agent: Initializing Windows Update Agent ***********

2005-09-12 09:28:46 1020 aec Agent ***********
Agent: Initializing global settings cache ***********

2005-09-12 09:28:46 1020 aec Agent * WSUS
server: http://a-ilster-dc2:8530

2005-09-12 09:28:46 1020 aec Agent * WSUS
status server: http://a-ilster-dc2:8530

2005-09-12 09:28:46 1020 aec Agent * Target
group: (Unassigned Computers)

2005-09-12 09:28:46 1020 aec Agent * Windows
Update access disabled: No

2005-09-12 09:28:49 1020 aec DnldMgr
Download manager restoring 0 downloads

2005-09-12 09:28:49 1020 aec AU
########### AU: Initializing Automatic Updates ###########

2005-09-12 09:28:49 1020 aec AU # WSUS
server: http://a-ilster-dc2:8530

2005-09-12 09:28:49 1020 aec AU #
Detection frequency: 22

2005-09-12 09:28:49 1020 aec AU #
Approval type: Scheduled (Policy)

2005-09-12 09:28:49 1020 aec AU #
Scheduled install day/time: Every day at 3:00

2005-09-12 09:28:49 1020 aec AU #
Auto-install minor updates: Yes (Policy)

2005-09-12 09:28:56 1020 aec AU
Triggering AU detection through DetectNow API

2005-09-12 09:28:56 1020 eb0 AU
#############

2005-09-12 09:28:56 1020 eb0 AU ## START
## AU: Search for updates

2005-09-12 09:28:56 1020 eb0 AU #########

2005-09-12 09:28:56 1020 eb0 AU <<##
SUBMITTED ## AU: Search for updates [CallId =
{B499C328-096C-4FF5-B8BB-E8A21567879D}]

2005-09-12 09:28:56 1020 580 Agent
*************

2005-09-12 09:28:56 1020 580 Agent ** START **
Agent: Finding updates [CallerId = AutomaticUpdates]

2005-09-12 09:28:56 1020 580 Agent *********

2005-09-12 09:28:59 1020 580 Setup ***********
Setup: Checking whether self-update is required ***********

2005-09-12 09:28:59 1020 580 Setup * Inf
file: C:\Windows\SoftwareDistribution\SelfUpdate\Default\wusetup.inf

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\cdm.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\iuengine.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuapi.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuauclt.exe: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuauclt1.exe: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuaucpl.cpl: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuaueng.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuaueng1.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wucltui.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wups.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wups2.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup Update NOT
required for C:\Windows\system32\wuweb.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469

2005-09-12 09:28:59 1020 580 Setup *
IsUpdateRequired = No

2005-09-12 09:29:00 1020 580 PT
+++++++++++ PT: Synchronizing server updates +++++++++++

2005-09-12 09:29:00 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx

2005-09-12 09:29:00 1020 580 PT
Initializing simple targeting cookie, clientId =
b45ddad5-cb06-4616-9ccc-de468348c6d6, target group = , DNS name =
is-2.corp.srfc.com

2005-09-12 09:29:00 1020 580 PT Server
URL = http://a-ilster-dc2:8530/SimpleAuthWebService/SimpleAuth.asmx

2005-09-12 09:29:04 1020 aec AU AU found
0 updates for install at shutdown

2005-09-12 09:29:04 1108 834 Misc
=========== Logging initialized (build: 5.8.0.2469, tz: -0500) ===========

2005-09-12 09:29:04 1108 834 Misc =
Process: C:\Windows\Explorer.EXE

2005-09-12 09:29:04 1108 834 Misc =
Module: C:\Windows\system32\wuaueng.dll

2005-09-12 09:29:04 1108 834 Shutdwn
Install at shutdown: no updates to install

2005-09-12 09:29:10 1020 580 PT WARNING:
SyncUpdates failure, error = 0x8024400D, soap client error = 7, soap error
code = 300, HTTP status code = 200

2005-09-12 09:29:10 1020 580 PT WARNING:
SOAP Fault: 0x00012c

2005-09-12 09:29:10 1020 580 PT WARNING:
faultstring:Fault occurred

2005-09-12 09:29:10 1020 580 PT WARNING:
ErrorCode:RegistrationRequired(3)

2005-09-12 09:29:10 1020 580 PT WARNING:
Message:need to call RegisterComputer.

2005-09-12 09:29:10 1020 580 PT WARNING:
Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"

2005-09-12 09:29:10 1020 580 PT WARNING:
ID:2dc196e2-18b0-4fff-a8be-ded499676cd5

2005-09-12 09:29:10 1020 580 PT
Initializing simple targeting cookie, clientId =
b45ddad5-cb06-4616-9ccc-de468348c6d6, target group = , DNS name =
is-2.corp.srfc.com

2005-09-12 09:29:10 1020 580 PT Server
URL = http://a-ilster-dc2:8530/SimpleAuthWebService/SimpleAuth.asmx

2005-09-12 09:29:10 1020 580 PT
+++++++++++ PT: Synchronizing extended update info +++++++++++

2005-09-12 09:29:10 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx

2005-09-12 09:29:11 1020 eb0 Report WARNING:
CEventNamespaceDefinition::Init failed = 8024f002.

2005-09-12 09:29:11 1020 eb0 Report WARNING:
InitReportingComponents failed: 8024f002

2005-09-12 09:29:13 1020 580 Agent * Found 0
updates and 10 categories in search

2005-09-12 09:29:13 1020 580 Report WARNING:
CEventNamespaceDefinition::Init failed = 8024f002.

2005-09-12 09:29:13 1020 580 Report WARNING:
InitReportingComponents failed: 8024f002

2005-09-12 09:29:13 1020 580 Report WARNING:
CEventNamespaceDefinition::Init failed = 8024f002.

2005-09-12 09:29:13 1020 580 Report WARNING:
InitReportingComponents failed: 8024f002

2005-09-12 09:29:13 1020 580 Agent *********

2005-09-12 09:29:13 1020 580 Agent ** END **
Agent: Finding updates [CallerId = AutomaticUpdates]

2005-09-12 09:29:13 1020 580 Agent
*************

2005-09-12 09:29:13 1020 580 AU >>##
RESUMED ## AU: Search for updates [CallId =
{B499C328-096C-4FF5-B8BB-E8A21567879D}]

2005-09-12 09:29:13 1020 580 AU # 0
updates detected

2005-09-12 09:29:13 1020 580 AU #########

2005-09-12 09:29:13 1020 580 AU ## END
## AU: Search for updates [CallId = {B499C328-096C-4FF5-B8BB-E8A21567879D}]

2005-09-12 09:29:13 1020 580 AU
#############

2005-09-12 09:29:13 1020 580 AU AU
setting next detection timeout to 2005-09-13 11:49:41

2005-09-12 10:09:55 1020 eb0 AU AU
received hibernate event

2005-09-12 11:45:22 1020 eb0 AU AU
received wakeup event

2005-09-12 11:45:22 1020 eb0 AU AU
received wakeup event

---------------------------------------

Post by Lawrence Garvin
Yep.... several ideas, but first let me explain the 'scenario' that exists
while this message is present.
When the client first contacts the WSUS server, it checks to do a
selfupdate. The presence of the "Not Yet Reported" message is a
confirmation that the client is talking to the server, and has
"registered" with the server. It's also an indication that, following this
detection of the selfupdate, something /failed/ at the client.
The next step is to inspect the %windir%\WindowsUpdate.log for the
specific cause of the failure.

Post by Kent Meyer
I have the same thing happening but not with all the computers. I have
approximately 360 computers that are listed in WSUS but roughly 45 of them
show that they have not yet Reported. The 300 or so have reported,
downloaded, installed, and reported back successfully.
Do you have any ideas as to what would cause this?
Thanks,
Kent

Post by Lawrence Garvin
Most likely cause of the failure of the scanning of the computers given
the data provided is that the client did not successfully selfupdate
from port 80 of the WSUS server, and thus has not been able to perform a
detection cycle with the server, which would clear the "Not Yet
Reported" status and replace it with the updates "Needed".
Since it's occuring across platforms, and apparently to all of your
systems, I'd venture an educated guess that the seflupdate virtual
directory is either non existent on port 80, or that it does not have
anonymous access enabled. Inspect the %windir%\WindowsUpdate.log logfile
for specific events/errors related to the client.

Post by Jmeanor
We have set up GP to point the user computers to the WSUS server and populate
the computer groups. That is working. But most of the computers are showing
up as Not Yet Reported. This is after several days. The computer is found but
not scanned. Both 2000 and XP machines. What is preventing the scanning of
the computers?

[Lawrence Garvin]

We see this error occur at 9:30:57 after the detection...

Post by Kent Meyer
CEventNamespaceDefinition::Init failed = 8024f002.
2005-09-12 09:30:57 1020 580 Report WARNING: InitReportingComponents
failed: 8024f002

and, just for the sake of documentation, I don't believe we've actually seen
this error code reported previously.

The next detection is scheduled...

Post by Kent Meyer
2005-09-12 09:30:57 1020 580 AU AU setting next detection timeout
to 2005-09-13 10:22:47

which never actually happens because the machine is "hibernating"...

Post by Kent Meyer
2005-09-12 10:09:55 1020 eb0 AU AU

received hibernate event

Post by Kent Meyer
2005-09-12 11:45:22 1020 eb0 AU AU

received wakeup event

And then, it appears here is where the SusClientId was removed, and the
service restarted...

Post by Kent Meyer
2005-09-12 09:27:39 1020 b4 Service *********
2005-09-12 09:27:39 1020 b4 Service ** END ** Service: Service exit
[Exit code = 0x240001]
2005-09-12 09:27:39 1020 b4 Service *************
2005-09-12 09:28:26 1020 eb0 Service *************
2005-09-12 09:28:26 1020 eb0 Service ** START ** Service: Service startup
2005-09-12 09:28:26 1020 eb0 Service *********
2005-09-12 09:28:26 1020 eb0 Agent * WU client version 5.8.0.2469
2005-09-12 09:28:26 1020 eb0 Agent * WARNING: Failed to obtain
SusClientId

QUESTION:... Did you also reset the SYSTEM TIME during this process????
The system appears to have lost three minutes between 9:30:57 and 9:27:39.

and the errors occur again...

Post by Kent Meyer
CEventNamespaceDefinition::Init failed = 8024f002.
2005-09-12 09:28:46 1020 aec Report WARNING: InitReportingComponents
failed: 8024f002

And here... you triggered a /detectnow, while the WUA was already trying to
run its normal detection at service startup...

Post by Kent Meyer
2005-09-12 09:28:56 1020 aec AU Triggering AU detection through
DetectNow API

Normally, you will want to wait 10-15 minutes after service startup before
forcing a /detectnow, so that the WUA can complete it's own normal service
startup detection cycle.

Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

and then logs a SOAP error...

Post by Kent Meyer
2005-09-12 09:29:10 1020 580 PT WARNING: SyncUpdates failure,
error = 0x8024400D,
soap client error = 7, soap error code = 300, HTTP status code = 200

Here's the description for the error 0x8024400d
0x8024400d - SUS E PT SOAP CLIENT
The message was malformed or incomplete

The last time we encountered this error code it was traced to mismatched
URLs in the policy...

Post by Kent Meyer
http://a-ilster-dc2:8530
http://a-ilster-dc2:8530

but that is definitely not the situation in this instance.

There's also the possibility of this error being generated when a malformed
or invalid /client/ FQDN is provided in the targeting cookie.

Check to make sure that the /domain/ corp.srfc.com is properly delegated,
and that the client's default domain is, in fact, corp.srfc.com.

I'm also considering the original message...
WARNING: CEventNamespaceDefinition::Init failed = 8024f002.
and particularly the idea that there's a NamespaceDefinition issue.

One thing is for absolute certain, though. The WUA is not making a call to
the ReportingWebService, and that's the specific reason that the client is
not appearing on the WSUS server.

This is what should be appearing in the log after the completion of a
successful detection cycle... (from my own client log)
2005-09-12 08:58:52 832 cdc AU AU setting next detection timeout to
2005-09-13 01:26:57
and then several minutes later...
2005-09-12 09:09:08 832 4f8 Report Uploading 2 events using cached
cookie,
reporting URL =
http://ented/ReportingWebService/ReportingWebService.asmx
2005-09-12 09:09:08 832 4f8 Report Reporter successfully uploaded 2
events.





If none of these ideas identify the issue, then we'll make a second pass at
it.

Post by Kent Meyer
Here is what the WindowsUpdate.log file states... I have searched Technet
for some of the errors but couldn't find anything. Do you have any other
ideas? I have already removed the registry entries to make sure the
workstation has a unique SUS sid.
Thanks for your help!
------------------------------------
2005-09-12 09:30:29 1020 b4 AU
#############
2005-09-12 09:30:29 1020 b4 AU ## START
## AU: Search for updates
2005-09-12 09:30:29 1020 b4 AU
######### 2005-09-12 09:30:29 1020 b4 AU
## SUBMITTED ## AU: Search for updates [CallId =
{84D9ECC1-D830-43F9-8655-73507DD8E84C}]
2005-09-12 09:30:29 1020 580 Agent
*************
2005-09-12 09:30:29 1020 580 Agent ** START
** Agent: Finding updates [CallerId = AutomaticUpdates]
2005-09-12 09:30:29 1020 580 Agent *********
2005-09-12 09:30:43 1020 580 Setup
*********** Setup: Checking whether self-update is required ***********
2005-09-12 09:30:43 1020 580 Setup * Inf
file: C:\Windows\SoftwareDistribution\SelfUpdate\Default\wusetup.inf
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\cdm.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\iuengine.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuapi.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuauclt.exe: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuauclt1.exe: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuaucpl.cpl: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuaueng.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuaueng1.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wucltui.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wups.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wups2.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup Update
NOT required for C:\Windows\system32\wuweb.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:30:43 1020 580 Setup *
IsUpdateRequired = No
2005-09-12 09:30:45 1020 580 PT +++++++++++
PT: Synchronizing server updates +++++++++++
2005-09-12 09:30:45 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx
2005-09-12 09:30:46 1020 580 PT Initializing
simple targeting cookie, clientId = f6f1849e-1ee8-4d38-a320-3cf1eba0883c,
target group = , DNS name = is-2.corp.srfc.com
2005-09-12 09:30:46 1020 580 PT
Server URL = http://a-ilster-dc2:8530/SimpleAuthWebService/SimpleAuth.asmx
2005-09-12 09:30:55 1020 580 PT +++++++++++
PT: Synchronizing extended update info +++++++++++
2005-09-12 09:30:55 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx
2005-09-12 09:30:57 1020 580 Agent * Found
0 updates and 10 categories in search
CEventNamespaceDefinition::Init failed = 8024f002.
InitReportingComponents failed: 8024f002
CEventNamespaceDefinition::Init failed = 8024f002.
InitReportingComponents failed: 8024f002
2005-09-12 09:30:57 1020 580 Agent *********
2005-09-12 09:30:57 1020 580 Agent ** END
** Agent: Finding updates [CallerId = AutomaticUpdates]
2005-09-12 09:30:57 1020 580 Agent
*************
2005-09-12 09:30:57 1020 580 AU >>##
RESUMED ## AU: Search for updates [CallId =
{84D9ECC1-D830-43F9-8655-73507DD8E84C}]
2005-09-12 09:30:57 1020 580 AU # 0
updates detected
2005-09-12 09:30:57 1020 580 AU
#########
2005-09-12 09:30:57 1020 580 AU ## END
## AU: Search for updates [CallId =
{84D9ECC1-D830-43F9-8655-73507DD8E84C}]
2005-09-12 09:30:57 1020 580 AU #############
2005-09-12 09:30:57 1020 580 AU AU
setting next detection timeout to 2005-09-13 10:22:47
2005-09-12 09:27:39 1020 b4 Service *********
2005-09-12 09:27:39 1020 b4 Service ** END
** Service: Service exit [Exit code = 0x240001]
2005-09-12 09:27:39 1020 b4 Service
*************
2005-09-12 09:28:26 1020 eb0 Misc ===========
Logging initialized (build: 5.8.0.2469, tz: -0500) ===========
2005-09-12 09:28:26 1020 eb0 Misc =
Process: C:\Windows\System32\svchost.exe
2005-09-12 09:28:26 1020 eb0 Misc =
Module: C:\Windows\system32\wuaueng.dll
2005-09-12 09:28:26 1020 eb0 Service
*************
2005-09-12 09:28:26 1020 eb0 Service ** START
** Service: Service startup
2005-09-12 09:28:26 1020 eb0 Service *********
2005-09-12 09:28:26 1020 eb0 Agent * WU
client version 5.8.0.2469
2005-09-12 09:28:26 1020 eb0 Agent *
WARNING: Failed to obtain SusClientId
2005-09-12 09:28:26 1020 eb0 Agent * Base
directory: C:\Windows\SoftwareDistribution
2005-09-12 09:28:26 1020 eb0 Agent *
Access type: No proxy
2005-09-12 09:28:26 1020 eb0 Agent *
Network state: Connected
CEventNamespaceDefinition::Init failed = 8024f002.
InitReportingComponents failed: 8024f002
2005-09-12 09:28:46 1020 aec Agent
*********** Agent: Initializing Windows Update Agent ***********
2005-09-12 09:28:46 1020 aec Agent
*********** Agent: Initializing global settings cache ***********
2005-09-12 09:28:46 1020 aec Agent * WSUS
server: http://a-ilster-dc2:8530
2005-09-12 09:28:46 1020 aec Agent * WSUS
status server: http://a-ilster-dc2:8530
2005-09-12 09:28:46 1020 aec Agent *
Target group: (Unassigned Computers)
2005-09-12 09:28:46 1020 aec Agent *
Windows Update access disabled: No
2005-09-12 09:28:49 1020 aec DnldMgr Download
manager restoring 0 downloads
2005-09-12 09:28:49 1020 aec AU ###########
AU: Initializing Automatic Updates ###########
2005-09-12 09:28:49 1020 aec AU #
WSUS server: http://a-ilster-dc2:8530
2005-09-12 09:28:49 1020 aec AU #
Detection frequency: 22
2005-09-12 09:28:49 1020 aec AU #
Approval type: Scheduled (Policy)
2005-09-12 09:28:49 1020 aec AU #
Scheduled install day/time: Every day at 3:00
2005-09-12 09:28:49 1020 aec AU #
Auto-install minor updates: Yes (Policy)
2005-09-12 09:28:56 1020 aec AU Triggering AU
detection through DetectNow API
2005-09-12 09:28:56 1020 eb0 AU #############
2005-09-12 09:28:56 1020 eb0 AU ##
START ## AU: Search for updates
2005-09-12 09:28:56 1020 eb0 AU
#########
2005-09-12 09:28:56 1020 eb0 AU <<##
SUBMITTED ## AU: Search for updates [CallId =
{B499C328-096C-4FF5-B8BB-E8A21567879D}]
2005-09-12 09:28:56 1020 580 Agent
*************
2005-09-12 09:28:56 1020 580 Agent ** START
** Agent: Finding updates [CallerId = AutomaticUpdates]
2005-09-12 09:28:56 1020 580 Agent *********
2005-09-12 09:28:59 1020 580 Setup
*********** Setup: Checking whether self-update is required ***********
2005-09-12 09:28:59 1020 580 Setup * Inf
file: C:\Windows\SoftwareDistribution\SelfUpdate\Default\wusetup.inf
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\cdm.dll: target version = 5.8.0.2469,
required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\iuengine.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuapi.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuauclt.exe: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuauclt1.exe: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuaucpl.cpl: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuaueng.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuaueng1.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wucltui.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wups.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wups2.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup Update
NOT required for C:\Windows\system32\wuweb.dll: target version =
5.8.0.2469, required version = 5.8.0.2469
2005-09-12 09:28:59 1020 580 Setup *
IsUpdateRequired = No
2005-09-12 09:29:00 1020 580 PT +++++++++++
PT: Synchronizing server updates +++++++++++
2005-09-12 09:29:00 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx
2005-09-12 09:29:00 1020 580 PT Initializing
simple targeting cookie, clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = , DNS name = is-2.corp.srfc.com
2005-09-12 09:29:00 1020 580 PT
Server URL = http://a-ilster-dc2:8530/SimpleAuthWebService/SimpleAuth.asmx
2005-09-12 09:29:04 1020 aec AU AU
found 0 updates for install at shutdown
2005-09-12 09:29:04 1108 834 Misc ===========
Logging initialized (build: 5.8.0.2469, tz: -0500) ===========
2005-09-12 09:29:04 1108 834 Misc =
Process: C:\Windows\Explorer.EXE
2005-09-12 09:29:04 1108 834 Misc =
Module: C:\Windows\system32\wuaueng.dll
2005-09-12 09:29:04 1108 834 Shutdwn Install
at shutdown: no updates to install
2005-09-12 09:29:10 1020 580 PT
WARNING: SyncUpdates failure, error = 0x8024400D, soap client error = 7,
soap error code = 300, HTTP status code = 200
2005-09-12 09:29:10 1020 580 PT
WARNING: SOAP Fault: 0x00012c
2005-09-12 09:29:10 1020 580 PT
WARNING: faultstring:Fault occurred
2005-09-12 09:29:10 1020 580 PT
WARNING: ErrorCode:RegistrationRequired(3)
2005-09-12 09:29:10 1020 580 PT
WARNING: Message:need to call RegisterComputer.
2005-09-12 09:29:10 1020 580 PT
Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"
2005-09-12 09:29:10 1020 580 PT
WARNING: ID:2dc196e2-18b0-4fff-a8be-ded499676cd5
2005-09-12 09:29:10 1020 580 PT Initializing
simple targeting cookie, clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = , DNS name = is-2.corp.srfc.com
2005-09-12 09:29:10 1020 580 PT
Server URL = http://a-ilster-dc2:8530/SimpleAuthWebService/SimpleAuth.asmx
2005-09-12 09:29:10 1020 580 PT +++++++++++
PT: Synchronizing extended update info +++++++++++
2005-09-12 09:29:10 1020 580 PT +
ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://a-ilster-dc2:8530/ClientWebService/client.asmx
CEventNamespaceDefinition::Init failed = 8024f002.
InitReportingComponents failed: 8024f002
2005-09-12 09:29:13 1020 580 Agent * Found
0 updates and 10 categories in search
CEventNamespaceDefinition::Init failed = 8024f002.
InitReportingComponents failed: 8024f002
CEventNamespaceDefinition::Init failed = 8024f002.
InitReportingComponents failed: 8024f002
2005-09-12 09:29:13 1020 580 Agent *********
2005-09-12 09:29:13 1020 580 Agent ** END
** Agent: Finding updates [CallerId = AutomaticUpdates]
2005-09-12 09:29:13 1020 580 Agent
*************
2005-09-12 09:29:13 1020 580 AU >>##
RESUMED ## AU: Search for updates [CallId =
{B499C328-096C-4FF5-B8BB-E8A21567879D}]
2005-09-12 09:29:13 1020 580 AU # 0
updates detected
2005-09-12 09:29:13 1020 580 AU
#########
2005-09-12 09:29:13 1020 580 AU ## END
## AU: Search for updates [CallId =
{B499C328-096C-4FF5-B8BB-E8A21567879D}]
2005-09-12 09:29:13 1020 580 AU #############
2005-09-12 09:29:13 1020 580 AU AU
setting next detection timeout to 2005-09-13 11:49:41
2005-09-12 10:09:55 1020 eb0 AU AU
received hibernate event
2005-09-12 11:45:22 1020 eb0 AU AU
received wakeup event
2005-09-12 11:45:22 1020 eb0 AU AU
received wakeup event
---------------------------------------

Post by Lawrence Garvin
Yep.... several ideas, but first let me explain the 'scenario' that
exists while this message is present.
When the client first contacts the WSUS server, it checks to do a
selfupdate. The presence of the "Not Yet Reported" message is a
confirmation that the client is talking to the server, and has
"registered" with the server. It's also an indication that, following
this detection of the selfupdate, something /failed/ at the client.
The next step is to inspect the %windir%\WindowsUpdate.log for the
specific cause of the failure.

Post by Kent Meyer
I have the same thing happening but not with all the computers. I have
approximately 360 computers that are listed in WSUS but roughly 45 of
them show that they have not yet Reported. The 300 or so have reported,
downloaded, installed, and reported back successfully.
Do you have any ideas as to what would cause this?
Thanks,
Kent

Post by Lawrence Garvin
Most likely cause of the failure of the scanning of the computers given
the data provided is that the client did not successfully selfupdate
from port 80 of the WSUS server, and thus has not been able to perform
a detection cycle with the server, which would clear the "Not Yet
Reported" status and replace it with the updates "Needed".
Since it's occuring across platforms, and apparently to all of your
systems, I'd venture an educated guess that the seflupdate virtual
directory is either non existent on port 80, or that it does not have
anonymous access enabled. Inspect the %windir%\WindowsUpdate.log
logfile for specific events/errors related to the client.

Post by Jmeanor
We have set up GP to point the user computers to the WSUS server and populate
the computer groups. That is working. But most of the computers are showing
up as Not Yet Reported. This is after several days. The computer is found but
not scanned. Both 2000 and XP machines. What is preventing the scanning of
the computers?

[Kent Meyer]

Thanks for the response Lawrence...

This machine DOES show up in WSUS, it just says Not Yet Reported. It is
indeed joined to the correct domain (the same domain as the WSUS server).

I have approx 350 PCs and all but 60 or so are working just fine. These 60
all seem to have this same problem.

After researching on the net a little I found TechNet article 898708 which
sounds somewhat like what I have. There is a HTTP status code = 200 entry in
the error log. Could IIS be causing a problem by send the HTTP 100 Continue?
Wouldn't this affect ALL machines though?

I also found a similar entry on another website with my exact error
0x8024400d. This is what it states:

http://wsus.editme.com/AgentFailedDetecting0x8024400d
SYMPTOMS
WindowsUpdate.log has multiple entries like below:

2005-04-01 13:03:27+0200 1012 768 SyncUpdates: 0x8024400d
2005-04-01 13:03:27+0200 1012 768 SOAP Fault: 0x00012c
2005-04-01 13:03:27+0200 1012 768 faultstring:Fault occurred
2005-04-01 13:03:27+0200 1012 768 ErrorCode:RegistrationRequired(3)
2005-04-01 13:03:27+0200 1012 768 Message:need to call RegisterComputer.
CAUSE
The problem may be related to the AU client being unable to collect properly
all the computer information for registration.

WORKAROUND

Try running the following command on the WSUSserver from the CMD prompt:

osql -E -S <SqlServerName> -Q "UPDATE SUSDB.dbo.tbComputerTarget SET
IsRegistered=1 where IsRegistered = 0"

where <SqlServerName> is the SQL server you are using. If you are using
WMSDE, specify %computername%\wsus.

Note that the client information will still show up as unknown in WSUS
Administrator, but the clients are able to receive updates.

STATUS

This is a known issue that will be fixed in the final release.



Do you have any other ideas as to what may cause this problem?



I have also tried reinstalling the Windows Update services on the pcs by
Removing all of the wu*.* files in the System32 directory and then
reinstalling.

Post by Lawrence Garvin
We see this error occur at 9:30:57 after the detection...

Post by Kent Meyer
CEventNamespaceDefinition::Init failed = 8024f002.
2005-09-12 09:30:57 1020 580 Report WARNING: InitReportingComponents
failed: 8024f002

and, just for the sake of documentation, I don't believe we've actually
seen this error code reported previously.
The next detection is scheduled...

Post by Kent Meyer
2005-09-12 09:30:57 1020 580 AU AU setting next detection timeout
to 2005-09-13 10:22:47

which never actually happens because the machine is "hibernating"...

Post by Kent Meyer
2005-09-12 10:09:55 1020 eb0 AU AU

received hibernate event

Post by Kent Meyer
2005-09-12 11:45:22 1020 eb0 AU AU

received wakeup event
And then, it appears here is where the SusClientId was removed, and the
service restarted...

Post by Kent Meyer
2005-09-12 09:27:39 1020 b4 Service *********
2005-09-12 09:27:39 1020 b4 Service ** END ** Service: Service exit
[Exit code = 0x240001]
2005-09-12 09:27:39 1020 b4 Service *************
2005-09-12 09:28:26 1020 eb0 Service *************
2005-09-12 09:28:26 1020 eb0 Service ** START ** Service: Service startup
2005-09-12 09:28:26 1020 eb0 Service *********
2005-09-12 09:28:26 1020 eb0 Agent * WU client version 5.8.0.2469
2005-09-12 09:28:26 1020 eb0 Agent * WARNING: Failed to obtain
SusClientId

QUESTION:... Did you also reset the SYSTEM TIME during this process????
The system appears to have lost three minutes between 9:30:57 and 9:27:39.
and the errors occur again...

Post by Kent Meyer
CEventNamespaceDefinition::Init failed = 8024f002.
2005-09-12 09:28:46 1020 aec Report WARNING: InitReportingComponents
failed: 8024f002

And here... you triggered a /detectnow, while the WUA was already trying
to run its normal detection at service startup...

Post by Kent Meyer
2005-09-12 09:28:56 1020 aec AU Triggering AU detection through
DetectNow API

Normally, you will want to wait 10-15 minutes after service startup before
forcing a /detectnow, so that the WUA can complete it's own normal service
startup detection cycle.
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

and then logs a SOAP error...

Post by Kent Meyer
2005-09-12 09:29:10 1020 580 PT WARNING: SyncUpdates failure,
error = 0x8024400D,
soap client error = 7, soap error code = 300, HTTP status code = 200

Here's the description for the error 0x8024400d
0x8024400d - SUS E PT SOAP CLIENT
The message was malformed or incomplete
The last time we encountered this error code it was traced to mismatched
URLs in the policy...

Post by Kent Meyer
http://a-ilster-dc2:8530
http://a-ilster-dc2:8530

but that is definitely not the situation in this instance.
There's also the possibility of this error being generated when a
malformed or invalid /client/ FQDN is provided in the targeting cookie.
Check to make sure that the /domain/ corp.srfc.com is properly delegated,
and that the client's default domain is, in fact, corp.srfc.com.
I'm also considering the original message...
WARNING: CEventNamespaceDefinition::Init failed = 8024f002.
and particularly the idea that there's a NamespaceDefinition issue.
One thing is for absolute certain, though. The WUA is not making a call to
the ReportingWebService, and that's the specific reason that the client is
not appearing on the WSUS server.
This is what should be appearing in the log after the completion of a
successful detection cycle... (from my own client log)
2005-09-12 08:58:52 832 cdc AU AU setting next detection timeout to
2005-09-13 01:26:57
and then several minutes later...
2005-09-12 09:09:08 832 4f8 Report Uploading 2 events using cached
cookie,
reporting URL =
http://ented/ReportingWebService/ReportingWebService.asmx
2005-09-12 09:09:08 832 4f8 Report Reporter successfully uploaded 2
events.
If none of these ideas identify the issue, then we'll make a second pass
at it.

[Lawrence Garvin]

Post by Kent Meyer
Thanks for the response Lawrence...
This machine DOES show up in WSUS, it just says Not Yet Reported.

Correct. The "Not Yet Reported" status is logged at the WSUS server when the
legacy AU client first communicates with the WSUS server and initiates the
selfupdate of itself to the WUA. This status will not be cleared until the
/WUA/, after being installed, properly calls the ReportingWebService web
service, which is how the WSUS server gets the actual status information
from the WUA. The WUA is /not/ calling this service, and that's most likely
a direct result, or a direct manifestation of, whatever the core malfunction
is.

Post by Kent Meyer
It is indeed joined to the correct domain (the same domain as the WSUS
server).

My comment was not about Windows domains... but about the /DNS/ domain...k
and the proper configuration of the DNS /service/.

Post by Kent Meyer

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and ".com".
In normal configurations there are three labels. The hostname, the company
name, and ".com". In essence, what you have indicated here is that there is
a /subdomain/ of corp.srfc.com.

If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA will
complain when it tries to process the name "is-2.corp.srfc.com" if it cannot
properly resolve the name.

Post by Kent Meyer
I have approx 350 PCs and all but 60 or so are working just fine. These 60
all seem to have this same problem.

Well.. that would be an indication of a /systemic/ problem, then, not a
specific problem with the individual clients. Any chance that these 60
systems exhibiting this problem are all in the "corp.srfc.com" subdomain?

Post by Kent Meyer
After researching on the net a little I found TechNet article 898708 which
sounds somewhat like what I have. There is a HTTP status code = 200 entry
in the error log. Could IIS be causing a problem by send the HTTP 100
Continue? Wouldn't this affect ALL machines though?

It would affect all machines. Furthermore, it would manifest itself by the
presentation of the 0x8024400a error code, at least, that has been the
observation in every instance to date. Also, that issue only occurs on
Windows Server 2003 SP1 systems.

Post by Kent Meyer
I also found a similar entry on another website with my exact error
http://wsus.editme.com/AgentFailedDetecting0x8024400d
SYMPTOMS
2005-04-01 13:03:27+0200 1012 768 SyncUpdates: 0x8024400d
2005-04-01 13:03:27+0200 1012 768 SOAP Fault: 0x00012c
2005-04-01 13:03:27+0200 1012 768 faultstring:Fault occurred
2005-04-01 13:03:27+0200 1012 768 ErrorCode:RegistrationRequired(3)
2005-04-01 13:03:27+0200 1012 768 Message:need to call RegisterComputer.
CAUSE
The problem may be related to the AU client being unable to collect
properly all the computer information for registration.

Yep... like an invalid FQDN??? :-)

Post by Kent Meyer
WORKAROUND
osql -E -S <SqlServerName> -Q "UPDATE SUSDB.dbo.tbComputerTarget SET
IsRegistered=1 where IsRegistered = 0"
where <SqlServerName> is the SQL server you are using. If you are using
WMSDE, specify %computername%\wsus.
Note that the client information will still show up as unknown in WSUS
Administrator, but the clients are able to receive updates.
STATUS
This is a known issue that will be fixed in the final release.

I would only try this 'workaround' /after/ we've eliminated all other
/possible/ causes... including confirming that the subdomain "corp.srfc.com"
is properly delegated in the DNS.

Post by Kent Meyer
Do you have any other ideas as to what may cause this problem?

Not at the moment.... but we've not finished ruling out everything on the
current list. :-)

Post by Kent Meyer
I have also tried reinstalling the Windows Update services on the pcs by
Removing all of the wu*.* files in the System32 directory and then
reinstalling.

The problem, as noted above, if affecting /60/ systems is not a client-side
problem, it is a /systemic/ problem, so individual efforts at the PCs will
probably not produce any positive results.

Post by Kent Meyer

Post by Lawrence Garvin
We see this error occur at 9:30:57 after the detection...

Post by Kent Meyer
CEventNamespaceDefinition::Init failed = 8024f002.
2005-09-12 09:30:57 1020 580 Report WARNING: InitReportingComponents
failed: 8024f002

and, just for the sake of documentation, I don't believe we've actually
seen this error code reported previously.
The next detection is scheduled...

Post by Kent Meyer
2005-09-12 09:30:57 1020 580 AU AU setting next detection timeout
to 2005-09-13 10:22:47

which never actually happens because the machines "hibernating"...

Post by Kent Meyer
2005-09-12 10:09:55 1020 eb0 AU

AU received hibernate event

Post by Kent Meyer
2005-09-12 11:45:22 1020 eb0 AU

AU received wakeup event
And then, it appears here is where the SusClientId was removed, and the
service restarted...

Post by Kent Meyer
2005-09-12 09:27:39 1020 b4 Service *********
2005-09-12 09:27:39 1020 b4 Service ** END ** Service: Service exit
[Exit code = 0x240001]
2005-09-12 09:27:39 1020 b4 Service *************
2005-09-12 09:28:26 1020 eb0 Service *************
2005-09-12 09:28:26 1020 eb0 Service ** START ** Service: Service startup
2005-09-12 09:28:26 1020 eb0 Service *********
2005-09-12 09:28:26 1020 eb0 Agent * WU client version 5.8.0.2469
2005-09-12 09:28:26 1020 eb0 Agent * WARNING: Failed to obtain
SusClientId

QUESTION:... Did you also reset the SYSTEM TIME during this process????
The system appears to have lost three minutes between 9:30:57 and 9:27:39.
and the errors occur again...

Post by Kent Meyer
CEventNamespaceDefinition::Init failed = 8024f002.
2005-09-12 09:28:46 1020 aec Report WARNING: InitReportingComponents
failed: 8024f002

And here... you triggered a /detectnow, while the WUA was already trying
to run its normal detection at service startup...

Post by Kent Meyer
2005-09-12 09:28:56 1020 aec AU Triggering AU detection through
DetectNow API

Normally, you will want to wait 10-15 minutes after service startup
before forcing a /detectnow, so that the WUA can complete it's own normal
service startup detection cycle.
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

and then logs a SOAP error...

Post by Kent Meyer
2005-09-12 09:29:10 1020 580 PT WARNING: SyncUpdates failure,
error = 0x8024400D,
soap client error = 7, soap error code = 300, HTTP status code = 200

Here's the description for the error 0x8024400d
0x8024400d - SUS E PT SOAP CLIENT
The message was malformed or incomplete
The last time we encountered this error code it was traced to mismatched
URLs in the policy...

Post by Kent Meyer
http://a-ilster-dc2:8530
http://a-ilster-dc2:8530

but that is definitely not the situation in this instance.
There's also the possibility of this error being generated when a
malformed or invalid /client/ FQDN is provided in the targeting cookie.
Check to make sure that the /domain/ corp.srfc.com is properly delegated,
and that the client's default domain is, in fact, corp.srfc.com.
I'm also considering the original message...
WARNING: CEventNamespaceDefinition::Init failed = 8024f002.
and particularly the idea that there's a NamespaceDefinition issue.
One thing is for absolute certain, though. The WUA is not making a call
to the ReportingWebService, and that's the specific reason that the
client is not appearing on the WSUS server.
This is what should be appearing in the log after the completion of a
successful detection cycle... (from my own client log)
2005-09-12 08:58:52 832 cdc AU AU setting next detection timeout to
2005-09-13 01:26:57
and then several minutes later...
2005-09-12 09:09:08 832 4f8 Report Uploading 2 events using cached
cookie,
reporting URL =
http://ented/ReportingWebService/ReportingWebService.asmx
2005-09-12 09:09:08 832 4f8 Report Reporter successfully uploaded 2
events.
If none of these ideas identify the issue, then we'll make a second pass
at it.

[Kent Meyer]

Post by Lawrence Garvin

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and
".com". In normal configurations there are three labels. The hostname, the
company name, and ".com". In essence, what you have indicated here is that
there is a /subdomain/ of corp.srfc.com.
If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA will
complain when it tries to process the name "is-2.corp.srfc.com" if it
cannot properly resolve the name.

We do not have any subdomains defined. Our main DNS domain name is
"corp.srfc.com". ALL of the machines on the network belong to this same DNS
domain. We do have different subnets defined across the network for
different sites but we have machines in all subnets that have properly
registered with WSUS and updated correctly and machines that say Not Yet
Reported. I haven't been able to find any one commonality to help explain
the problem.

Thanks!
Kent

[Lawrence Garvin]

Post by Kent Meyer

Post by Lawrence Garvin

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and
".com". In normal configurations there are three labels. The hostname,
the company name, and ".com". In essence, what you have indicated here is
that there is a /subdomain/ of corp.srfc.com.
If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA will
complain when it tries to process the name "is-2.corp.srfc.com" if it
cannot properly resolve the name.

We do not have any subdomains defined.

Then /THAT/ is exactly the cause of your problem.

Post by Kent Meyer
"Our main DNS domain name is "corp.srfc.com".

Hmmm..... then we need to go back to DNS 101... "corp.srfc.com" is not a
valid root level domain name. Though you may have configured your active
directory with that name, when /clients/ attempt to resolve a name, such as
is-2.corp.srfc.com, they'll first try to find the DNS server for srfc.com,
in order to find the DNS server for corp.srfc.com. If you don't have a
domain established and resolvable for srfc.com, the whole thing will be
severely dysfunctional.

I strongly suspect this is the root cause of the recorded WUA errors.

The period is a reserved character in a domain name and you /cannot/ use it
as a normal separator or punctuation mark, or as part of a string of
characters that is intended to represent a root level domain -- "corp.srfc"
is an invalid domain label.

No doubt this is a major issue for you as it's likely going to involve
renaming your AD domain.

Post by Kent Meyer
ALL of the machines on the network belong to this same DNS domain. We do
have different subnets defined across the network for different sites but
we have machines in all subnets that have properly registered with WSUS
and updated correctly and machines that say Not Yet Reported. I haven't
been able to find any one commonality to help explain the problem.

The "subnets" (vis a vis IP Addressing) are irrelevant to this issue.

Post by Kent Meyer
Thanks!
Kent

[Kent Meyer]

I don't find this to be a reasonable answer though because why does it work
on 80% of the machines without any problems?

Post by Lawrence Garvin

Post by Kent Meyer

Post by Lawrence Garvin

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple targeting
cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and
".com". In normal configurations there are three labels. The hostname,
the company name, and ".com". In essence, what you have indicated here
is that there is a /subdomain/ of corp.srfc.com.
If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA will
complain when it tries to process the name "is-2.corp.srfc.com" if it
cannot properly resolve the name.

We do not have any subdomains defined.

Then /THAT/ is exactly the cause of your problem.

Post by Kent Meyer
"Our main DNS domain name is "corp.srfc.com".

Hmmm..... then we need to go back to DNS 101... "corp.srfc.com" is not a
valid root level domain name. Though you may have configured your active
directory with that name, when /clients/ attempt to resolve a name, such
as is-2.corp.srfc.com, they'll first try to find the DNS server for
srfc.com, in order to find the DNS server for corp.srfc.com. If you don't
have a domain established and resolvable for srfc.com, the whole thing
will be severely dysfunctional.
I strongly suspect this is the root cause of the recorded WUA errors.
The period is a reserved character in a domain name and you /cannot/ use
it as a normal separator or punctuation mark, or as part of a string of
characters that is intended to represent a root level domain --
"corp.srfc" is an invalid domain label.
No doubt this is a major issue for you as it's likely going to involve
renaming your AD domain.

Post by Kent Meyer
ALL of the machines on the network belong to this same DNS domain. We do
have different subnets defined across the network for different sites but
we have machines in all subnets that have properly registered with WSUS
and updated correctly and machines that say Not Yet Reported. I haven't
been able to find any one commonality to help explain the problem.

The "subnets" (vis a vis IP Addressing) are irrelevant to this issue.

Post by Kent Meyer
Thanks!
Kent

[Lawrence Garvin]

Well, Kent, I accept your dissatisfaction with the answer. I agree the fact
that it seems to work perfectly on 80% of other machines does cast a
questionable shade on the answer.

However, it's an undisputable fact that your domain name is non-conformant,
and if not this product, I promise that there will be products in the future
that choke on the naming scheme.

As for me, I'm willing to continue to help in any way I can, but lacking any
alternative evidence, what I see is a SOAP error complaining about the
format of the message, and an non-conformant FQDN on the client, which has
been, to date, the most common cause of this particular SOAP error. I'm not
sure I can be much more help with this particular issue unresolved, but I
will if I can.

Post by Kent Meyer
I don't find this to be a reasonable answer though because why does it work
on 80% of the machines without any problems?

Post by Lawrence Garvin

Post by Kent Meyer

Post by Lawrence Garvin

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple
targeting cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and
".com". In normal configurations there are three labels. The hostname,
the company name, and ".com". In essence, what you have indicated here
is that there is a /subdomain/ of corp.srfc.com.
If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA will
complain when it tries to process the name "is-2.corp.srfc.com" if it
cannot properly resolve the name.

We do not have any subdomains defined.

Then /THAT/ is exactly the cause of your problem.

Post by Kent Meyer
"Our main DNS domain name is "corp.srfc.com".

Hmmm..... then we need to go back to DNS 101... "corp.srfc.com" is not a
valid root level domain name. Though you may have configured your active
directory with that name, when /clients/ attempt to resolve a name, such
as is-2.corp.srfc.com, they'll first try to find the DNS server for
srfc.com, in order to find the DNS server for corp.srfc.com. If you don't
have a domain established and resolvable for srfc.com, the whole thing
will be severely dysfunctional.
I strongly suspect this is the root cause of the recorded WUA errors.
The period is a reserved character in a domain name and you /cannot/ use
it as a normal separator or punctuation mark, or as part of a string of
characters that is intended to represent a root level domain --
"corp.srfc" is an invalid domain label.
No doubt this is a major issue for you as it's likely going to involve
renaming your AD domain.

Post by Kent Meyer
ALL of the machines on the network belong to this same DNS domain. We do
have different subnets defined across the network for different sites
but we have machines in all subnets that have properly registered with
WSUS and updated correctly and machines that say Not Yet Reported. I
haven't been able to find any one commonality to help explain the
problem.

The "subnets" (vis a vis IP Addressing) are irrelevant to this issue.

Post by Kent Meyer
Thanks!
Kent

[Kent Meyer]

Don't get me wrong, I appreciate your help.

Out network was converted to AD by a Microsoft Gold Partner and used
Microsoft's Best Practices for domain creation and DNS setup. We do not host
our own Internet website which uses the srfc.com domain. Microsoft does not
recommend both and external domain and an internal domain to be the same.

In any case, I am still looking for answers and if anyone has any further
insight I would be glad to hear it. If I find out anything I will let you
know.

Thanks again,
Kent

Post by Lawrence Garvin
Well, Kent, I accept your dissatisfaction with the answer. I agree the
fact that it seems to work perfectly on 80% of other machines does cast a
questionable shade on the answer.
However, it's an undisputable fact that your domain name is
non-conformant, and if not this product, I promise that there will be
products in the future that choke on the naming scheme.
As for me, I'm willing to continue to help in any way I can, but lacking
any alternative evidence, what I see is a SOAP error complaining about the
format of the message, and an non-conformant FQDN on the client, which has
been, to date, the most common cause of this particular SOAP error. I'm
not sure I can be much more help with this particular issue unresolved,
but I will if I can.

Post by Kent Meyer
I don't find this to be a reasonable answer though because why does it
work on 80% of the machines without any problems?

Post by Lawrence Garvin

Post by Kent Meyer

Post by Lawrence Garvin

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple
targeting cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and
".com". In normal configurations there are three labels. The hostname,
the company name, and ".com". In essence, what you have indicated here
is that there is a /subdomain/ of corp.srfc.com.
If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA
will complain when it tries to process the name "is-2.corp.srfc.com"
if it cannot properly resolve the name.

We do not have any subdomains defined.

Then /THAT/ is exactly the cause of your problem.

Post by Kent Meyer
"Our main DNS domain name is "corp.srfc.com".

Hmmm..... then we need to go back to DNS 101... "corp.srfc.com" is not a
valid root level domain name. Though you may have configured your
active directory with that name, when /clients/ attempt to resolve a
name, such as is-2.corp.srfc.com, they'll first try to find the DNS
server for srfc.com, in order to find the DNS server for corp.srfc.com.
If you don't have a domain established and resolvable for srfc.com, the
whole thing will be severely dysfunctional.
I strongly suspect this is the root cause of the recorded WUA errors.
The period is a reserved character in a domain name and you /cannot/ use
it as a normal separator or punctuation mark, or as part of a string of
characters that is intended to represent a root level domain --
"corp.srfc" is an invalid domain label.
No doubt this is a major issue for you as it's likely going to involve
renaming your AD domain.

Post by Kent Meyer
ALL of the machines on the network belong to this same DNS domain. We
do have different subnets defined across the network for different
sites but we have machines in all subnets that have properly registered
with WSUS and updated correctly and machines that say Not Yet Reported.
I haven't been able to find any one commonality to help explain the
problem.

The "subnets" (vis a vis IP Addressing) are irrelevant to this issue.

Post by Kent Meyer
Thanks!
Kent

[Lawrence Garvin]

I'm going to take some time this weekend and refresh my 'education' about
using delegated subdomains as the root of an Active Directory domain tree,
but my gut feeling is that something is 'missing' in the configuration of
the srfc.corp.com domain as the root of the DNS tree, and it's impacting the
ability of the clients and/or resolvers and/or WSUS server to properly trace
the chain.

But thank you for the additional background on the setup of your network.
Now I understand how and why it is what it is, and I understand where the
rationale came from for doing this; however, we need to make sure it's
functioning correctly in light of this particular error.

Post by Kent Meyer
Don't get me wrong, I appreciate your help.
Out network was converted to AD by a Microsoft Gold Partner and used
Microsoft's Best Practices for domain creation and DNS setup. We do not
host our own Internet website which uses the srfc.com domain. Microsoft
does not recommend both and external domain and an internal domain to be
the same.
In any case, I am still looking for answers and if anyone has any further
insight I would be glad to hear it. If I find out anything I will let you
know.
Thanks again,
Kent

Post by Lawrence Garvin
Well, Kent, I accept your dissatisfaction with the answer. I agree the
fact that it seems to work perfectly on 80% of other machines does cast a
questionable shade on the answer.
However, it's an undisputable fact that your domain name is
non-conformant, and if not this product, I promise that there will be
products in the future that choke on the naming scheme.
As for me, I'm willing to continue to help in any way I can, but lacking
any alternative evidence, what I see is a SOAP error complaining about
the format of the message, and an non-conformant FQDN on the client,
which has been, to date, the most common cause of this particular SOAP
error. I'm not sure I can be much more help with this particular issue
unresolved, but I will if I can.

Post by Kent Meyer
I don't find this to be a reasonable answer though because why does it
work on 80% of the machines without any problems?

Post by Lawrence Garvin

Post by Kent Meyer

Post by Lawrence Garvin

Post by Lawrence Garvin
Here the system generates a targeting cookie...

Post by Kent Meyer
2005-09-12 09:29:00 1020 580 PT Initializing simple
targeting cookie,
clientId = b45ddad5-cb06-4616-9ccc-de468348c6d6,
target group = ,
DNS name = is-2.corp.srfc.com

Here we see /four/ labels in the FQDN... "is-2", "corp", "srfc" and
".com". In normal configurations there are three labels. The
hostname, the company name, and ".com". In essence, what you have
indicated here is that there is a /subdomain/ of corp.srfc.com.
If this /subdomain/ is not properly delegated in the DNS, WSUS/WUA
will complain when it tries to process the name "is-2.corp.srfc.com"
if it cannot properly resolve the name.

We do not have any subdomains defined.

Then /THAT/ is exactly the cause of your problem.

Post by Kent Meyer
"Our main DNS domain name is "corp.srfc.com".

Hmmm..... then we need to go back to DNS 101... "corp.srfc.com" is not
a valid root level domain name. Though you may have configured your
active directory with that name, when /clients/ attempt to resolve a
name, such as is-2.corp.srfc.com, they'll first try to find the DNS
server for srfc.com, in order to find the DNS server for corp.srfc.com.
If you don't have a domain established and resolvable for srfc.com, the
whole thing will be severely dysfunctional.
I strongly suspect this is the root cause of the recorded WUA errors.
The period is a reserved character in a domain name and you /cannot/
use it as a normal separator or punctuation mark, or as part of a
string of characters that is intended to represent a root level
domain -- "corp.srfc" is an invalid domain label.
No doubt this is a major issue for you as it's likely going to involve
renaming your AD domain.

Post by Kent Meyer
ALL of the machines on the network belong to this same DNS domain. We
do have different subnets defined across the network for different
sites but we have machines in all subnets that have properly
registered with WSUS and updated correctly and machines that say Not
Yet Reported. I haven't been able to find any one commonality to help
explain the problem.

The "subnets" (vis a vis IP Addressing) are irrelevant to this issue.

Post by Kent Meyer
Thanks!
Kent