Clients not downloading updates until a deadline is set

Hi,

We have a WSUS 3.1 disconnected server running on Windows 2003 R2 in our
environment. Our clients are all XP machines that are configured through
Group Policy to update from this one WSUS server. Most of the clients are
currently sitting at about 92% installed of their required updates (all
updates are approved by a rule) but they won't now finish off downloading
the rest of their approved updates. Running "wuauclt /detectnow" fails to
move them. The agent log says that it "Found 0 updates and 45 categories in
search...".

If we set a deadline on any of the updates that are still needed and the run
"wuauclt /detectnow" the client springs into life, downloads and installs
the package. Something we've noticed is all the updates that are needed but
have not been downloaded look like they require a restart. I don't know if
this is relevant or not.

The group policy that we use to point the clients at the server looks like
this...

Do not display 'Install Updates and Shut Down' option in Shut Down Windows
dialog box = Not configured
Do not adjust default option to 'Install Updates and Shut Down' in Shut Down
Windows dialog box = Not configured
Configure Automatic Updates = Enabled
Specify intranet Microsoft update service location = Enabled
Enable client-side targeting = Disabled
Reschedule Automatic Updates scheduled installations = Not configured
No auto-restart with logged on users for scheduled automatic updates
installations = Enabled
Automatic Updates detection frequency = Enabled
Allow Automatic Updates immediate installation = Disabled
Delay Restart for scheduled installations = Not configured
Re-prompt for restart with scheduled installations = Enabled
Allow non-administrators to receive update notifications = Enabled
Enable recommended updates via Automatic Updates = Not configured
Enabling Windows Update Power Management to automatically wake up the system
to install scheduled updates = Not configured
Allow signed content from intranet Microsoft update service location = Not
configured

Does anyone know why these updates will not install without a deadline being
set?

Thanks for any help!

"SenorAlan" <> wrote in message
news:74023A27-A5F2-42CC-B936-...

> Does anyone know why these updates will not install without a deadline
> being set?

I suspect the deadline manifestation is coincidental, and there's something
else causing this -- since deadlines aren't likely to have this impact all
by themselves.

Could you please post, from the example machine:

1. The full set of entries for the detection event showing no updates
detected.

2. The detection/download/installation event that occurred as a result of
setting the deadline.



--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Hi Lawrence,

Thanks for your reply. I've attached two text files here. The "Nothing
Found" text file details the "wuauclt /detectnow" operation without setting
a deadline on any of the updates. The "DeadlineSetDetected" file shows the
same client after one update has been deadlined. Had I set a deadline on
two different updates they both would have been found.

I hope file attachments are ok, if not I'll paste the contents of the files
into the body of my reply.

Thanks again,


"Lawrence Garvin [MVP]" <> wrote in message
news:F50D9B8E-73F4-4CF9-BDBB-...
> "SenorAlan" <> wrote in message
> news:74023A27-A5F2-42CC-B936-...
>
>> Does anyone know why these updates will not install without a deadline
>> being set?
>
> I suspect the deadline manifestation is coincidental, and there's
> something else causing this -- since deadlines aren't likely to have this
> impact all by themselves.
>
> Could you please post, from the example machine:
>
> 1. The full set of entries for the detection event showing no updates
> detected.
>
> 2. The detection/download/installation event that occurred as a result of
> setting the deadline.
>
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"SenorAlan" <> wrote in message
news:...

> Thanks for your reply. I've attached two text files here. The "Nothing
> Found" text file details the "wuauclt /detectnow" operation without
> setting
> a deadline on any of the updates. The "DeadlineSetDetected" file shows
> the
> same client after one update has been deadlined. Had I set a deadline on
> two different updates they both would have been found.
>
> I hope file attachments are ok, if not I'll paste the contents of the
> files
> into the body of my reply.

Pasting into the message is preferred, but I can work with TXT attachments.

First thing I note is that this machine is not being assigned a target group
via policy.

> 2009-09-21 20:14:02:171 1080 508 Agent * WSUS server:
> http://server031:8530
> 2009-09-21 20:14:02:171 1080 508 Agent * WSUS status server:
> http://server031:8530
> 2009-09-21 20:14:02:171 1080 508 Agent * Target group: (Unassigned
> Computers)
>
> 2009-09-21 20:14:07:000 1080 ff8 PT Initializing simple targeting cookie,
> clientId = 851df5ad-8563-476f-9855-0842bd9e5a0c,
> target group = , DNS name = testpc.domain

Second thing I note is that, as you've stated, enabling the deadline causes
the update to be detected:

> 2009-09-21 20:23:04:459 1080 2dc AU Auto-approving update for download,
> updateId = {8079EF5C-B355-4C65-8888-8D708BEB2D87}.103,
> ForUx=0, IsOwnerUx=0, HasDeadline=1, IsMinor=0
> 2009-09-21 20:23:04:556 1080 170 Agent * Title = Update for Windows XP
> (KB952287)

So, at this point I'm inclined to speculate that you have approved the
deadline for "All Computers", thus causing the deadline (and forced
approval) to then be inherited to all subgroups, including "Unassigned
Computers" (where previously it was probably not approved for installation),
which is where this computer appears to be checking for available updates.



--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Noted for next time. You're right that we don't have client side targeting
so as you say all the machines do appear in the unassigned computers group,
however the unassigned is set to inherit from its parent. Earlier today I
tried selecting a few updates via the management console and approving them
for all computers manually (right click -> approve). I also set the
unassigned computers to inherit at this point too which did cause the
console to run through each selected update and approve it twice (once for
all computers and once for unassigned. Unfortunately that hasn't done the
trick.

I must admit I thought that the client side targeting was mainly for
manageability purposes. Because we only have a twenty or so clients for the
WSUS server I didn't think it was worth creating any groups. In our
environment setup we'd only really have one group but I can try this if you
think that it'll help.

Thanks for your continued help,

"Lawrence Garvin [MVP]" <> wrote in message
news:F984BA66-263D-4698-8363-...
> "SenorAlan" <> wrote in message
> news:...
>
>> Thanks for your reply. I've attached two text files here. The "Nothing
>> Found" text file details the "wuauclt /detectnow" operation without
>> setting
>> a deadline on any of the updates. The "DeadlineSetDetected" file shows
>> the
>> same client after one update has been deadlined. Had I set a deadline on
>> two different updates they both would have been found.
>>
>> I hope file attachments are ok, if not I'll paste the contents of the
>> files
>> into the body of my reply.
>
> Pasting into the message is preferred, but I can work with TXT
> attachments.
>
> First thing I note is that this machine is not being assigned a target
> group via policy.
>
>> 2009-09-21 20:14:02:171 1080 508 Agent * WSUS server:
>> http://server031:8530
>> 2009-09-21 20:14:02:171 1080 508 Agent * WSUS status server:
>> http://server031:8530
>> 2009-09-21 20:14:02:171 1080 508 Agent * Target group: (Unassigned
>> Computers)
>>
>> 2009-09-21 20:14:07:000 1080 ff8 PT Initializing simple targeting cookie,
>> clientId = 851df5ad-8563-476f-9855-0842bd9e5a0c,
>> target group = , DNS name = testpc.domain
>
> Second thing I note is that, as you've stated, enabling the deadline
> causes the update to be detected:
>
>> 2009-09-21 20:23:04:459 1080 2dc AU Auto-approving update for download,
>> updateId = {8079EF5C-B355-4C65-8888-8D708BEB2D87}.103,
>> ForUx=0, IsOwnerUx=0, HasDeadline=1, IsMinor=0
>> 2009-09-21 20:23:04:556 1080 170 Agent * Title = Update for Windows
>> XP (KB952287)
>
> So, at this point I'm inclined to speculate that you have approved the
> deadline for "All Computers", thus causing the deadline (and forced
> approval) to then be inherited to all subgroups, including "Unassigned
> Computers" (where previously it was probably not approved for
> installation), which is where this computer appears to be checking for
> available updates.
>
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"SenorAlan" <> wrote in message
news:%...
> Noted for next time. You're right that we don't have client side
> targeting so as you say all the machines do appear in the unassigned
> computers group,

"Unassigned Computers" is a group designed to hold newly found machines; you
*should* create at least one group to hold the machines you have acknowledge
as having registered. It is for this group that I would recommend approving
updates, not for "Unassigned Computers" and only in rare scenarios for "All
Computers". (The Malicious Software Removal Tool is one I find appropriate
for approving for "All Computers".)

The thing you have to keep in mind about approving updates for "All
Computers" is that if you subsequently create new groups -- all of those
approvals specified for "All Computers" will be immediately inherited by the
new group -- this may not be desirable behavior.


> I must admit I thought that the client side targeting was mainly for
> manageability purposes.

It is. :-)


> Because we only have a twenty or so clients for the WSUS server I didn't
> think
> it was worth creating any groups.

Ahhhh... now, while it may not be worth using Group Policy to assign those
group memberships, it's definitely worthwhile to create groups. At an
absolute minimum, every WSUS installation should have two groups: TEST and
PRODUCTION -- even if the only PC in the TEST group is the WSUS
Administrator's desktop machine. Updates should never be deployed,
particularly to production critical servers (Domain Controllers, Exchange,
SQL Server) without first testing them somewhere less critical.

The original question revolves around why assigning a deadline was necessary
to engage the detection/download and installation of the update. The simple
and logical answer is: Because the original approval(s) were not sufficient
to trigger recognition by the WUAgent that the update was applicable. The
specific reason(s) why the original approval did not work requires some
forensic investigation -- the first step is to confirm that the correct
group(s) were, in fact, assigned approvals for the update(s); the second
step is to confirm that the client was actually scanning the intended
group(s).

Approvals are logged in the %ProgramFiles%\Update
Services\Logfiles\Change.log, and it would be useful to extract from that
logfile all entries for KB952287, so as to confirm that the approval was
actually applied (or inherited) to the "Unassigned Computers" group.

Related to this is the necessity to confirm that the client is not working
under the false impression that it should be using client-side targeting.
The ClientTargetingEnabled registry value, normally located in the registry
key HKLM\Software\Policies\Microsoft\Windows\WindowsUp date should be set to
dword:0x0, or missing entirely. If this value is set to dword:0x1, then the
client thinks *it* is authoritative for target group assignments and will
ignore anything configured at the server.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin