Expired Security Patches

How do I get rid of expired security patches on a WSUS server? Currently I
have 76 expired Definition Updates for Windows Defender. Why are they left
in the database?

Forwarded to microsoft.public.windows.server.update_services newsgroup via
crosspost.
--
~Robear Dyer (PA Bear)
MS MVP-Windows (IE, OE, Security, Shell/User)

John <>< wrote:
> How do I get rid of expired security patches on a WSUS server? Currently
> I
> have 76 expired Definition Updates for Windows Defender. Why are they
> left
> in the database?

> John <>< wrote:
>> How do I get rid of expired security patches on a WSUS server? Currently
>> I
>> have 76 expired Definition Updates for Windows Defender. Why are they
>> left
>> in the database?

Mark them as Declined and use the PurgeUnneededFiles utility of the WSUS
Server Debug Tool to remove the unneeded content.

See http://www.wsuswiki.com/MowingTheGrass
and the links in my sig for additional information.

--
Lawrence Garvin, M.S., MCTS, MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....

"John <><" <> wrote in message
news:EB26B31B-9743-41C0-817D-...
> The following statement appears at http://www.wsuswiki.com/MowingTheGrass:
> "Don't do this if you have replica servers; this causes a problem on
> replica
> servers with EULAs."

The statement is a comment from a reply to the article. The poster of the
comment probably mis-executed what is a very complex process to perform
content maintenance in a /replica/ environment. We've seen lots of
situations where master servers were purged prior to replicas being fully
synchronized and content suddenly disappeared that the replica server still
needed. There's also potential issues around expired/revised updates.

If you have /replica/ servers in your environment, this is my recommended
procedure:

(1) Set the master server to manual synchronization.
(2) Synchronize the master server with microsoft.com.
(3) When the master server has finished synchronizing, run
'removeunneededrevisions' (if desired), and then mark updates to be purged
as "Declined".
(3) At each replica server, set the replica server to manual
synchronization, then synchronize with the master server.
(4) When the replica server has finished synchronizing (which will include
the updates now marked as "Declined"), as well as synchronizing for
revisions to be removed, and have downloaded any needed content, then run
the PurgeUnneededFiles on the replica server. (You cannot run
'removeunneededrevisions' on the replica servers, as the metadata on a
replica server cannot be "managed".)
(5) After all replica servers have been synchronized, fully downloaded, and
purged, then you can run PurgeUnneededFiles on the master server.
(6) Reset the master server to automatic synchronization. (You might also
want to run a manual synchronization if you missed a scheduled
synchronization during this purge process.)
(7) Reset the replica servers to automatic synchronization.

> When you're dealing with 38,000+ clients, you want to get it right the
> first time.

Absolutely!!! :-)

--
Lawrence Garvin, M.S., MCTS, MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....

I finally had an opportunity to run these steps on my production WSUS
servers. However, they failed to produce what I thought would be the
outcome. My (Primary) upstream server is now down to 1275 Total Updates.
However, my downstream server still has 1315 total updates. I followed the
steps exactly and expected the downstream server to have the exact same
numbers after the last synchronization. But noooo. �. One more note that I
failed to outline in my initial posting, I’m not storing the patches locally,
I’m forwarding the clients to Microsoft. That shouldn’t matter, should it?
Thanks.

"Lawrence Garvin (MVP)" wrote:

> "John <><" <> wrote in message
> news:EB26B31B-9743-41C0-817D-...
> > The following statement appears at http://www.wsuswiki.com/MowingTheGrass:
> > "Don't do this if you have replica servers; this causes a problem on
> > replica
> > servers with EULAs."
>
> The statement is a comment from a reply to the article. The poster of the
> comment probably mis-executed what is a very complex process to perform
> content maintenance in a /replica/ environment. We've seen lots of
> situations where master servers were purged prior to replicas being fully
> synchronized and content suddenly disappeared that the replica server still
> needed. There's also potential issues around expired/revised updates.
>
> If you have /replica/ servers in your environment, this is my recommended
> procedure:
>
> (1) Set the master server to manual synchronization.
> (2) Synchronize the master server with microsoft.com.
> (3) When the master server has finished synchronizing, run
> 'removeunneededrevisions' (if desired), and then mark updates to be purged
> as "Declined".
> (3) At each replica server, set the replica server to manual
> synchronization, then synchronize with the master server.
> (4) When the replica server has finished synchronizing (which will include
> the updates now marked as "Declined"), as well as synchronizing for
> revisions to be removed, and have downloaded any needed content, then run
> the PurgeUnneededFiles on the replica server. (You cannot run
> 'removeunneededrevisions' on the replica servers, as the metadata on a
> replica server cannot be "managed".)
> (5) After all replica servers have been synchronized, fully downloaded, and
> purged, then you can run PurgeUnneededFiles on the master server.
> (6) Reset the master server to automatic synchronization. (You might also
> want to run a manual synchronization if you missed a scheduled
> synchronization during this purge process.)
> (7) Reset the replica servers to automatic synchronization.
>
> > When you're dealing with 38,000+ clients, you want to get it right the
> > first time.
>
> Absolutely!!! :-)
>
> --
> Lawrence Garvin, M.S., MCTS, MVP-Software Distribution
> Everything you need for WSUS is at
> http://technet2.microsoft.com/window...s/default.mspx
> And, everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>

"John <><" <> wrote in message
news:CEF95BFE-136F-4794-96EE-...
>I finally had an opportunity to run these steps on my production WSUS
> servers. However, they failed to produce what I thought would be the
> outcome. My (Primary) upstream server is now down to 1275 Total Updates.
> However, my downstream server still has 1315 total updates.

So, your downstream server has 40 updates that are not listed on the master
server.

The only logical way this can happen is that the updates have been purged
from the master server (most likely expired revisions using
RemoveUnneededRevisions), but the replica has not properly synchronized
those changes.

(Alternatively, I could be wrong, and it could be that you =do= need to run
RemoveUnneededRevisions on the replica in this case. I need to check on this
and I would not recommend 'testing' this in your production environment.)

> I followed the
> steps exactly and expected the downstream server to have the exact same
> numbers after the last synchronization.

> But noooo. ?. One more note that I
> failed to outline in my initial posting, I'm not storing the patches
> locally,
> I'm forwarding the clients to Microsoft. That shouldn't matter, should
> it?

Well, not having local storage kinda makes this whole process pointless, to
be honest,
since the whole purpose of the procedure is to pare out unneeded =files=
from the content store.

The metadata listings will always be present, except for expired revisions,
which only take up space measured in kilobytes in the database.



--
Lawrence Garvin, M.S., MCTS, MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....

Hi Lawrence

I followed your step by step description, unfortunatelly without success.

Our environment exists out of one mster server and 3 replica servers. All
servers are running Windows Server 2003 SP2, WSUS 2.0.0.2620 (content stored
local).

Before following your procedure the master and replica servers showed 6717
updates total (about 95-100GB). After completing the procedure only the
master server went down to 3578 updates total (about 70-75 GB). Not bad,
25GB less and there are some superseeded updates I could decline also in a
next step.
The problem are the replica servers. The behaviour during the process was
different for all of those. On the first one purgeunneededfiles worked just
fine. But the following sync process (started automatic) stopped with still
3 files needed. On the second second server I had to call the
purgeunneededfiles operation 3 - 4 times to succeed. The following sync
operationen stopped with 21 files left. And I never made it to a successfull
purgeunneededfiles operation on the third server (tried about 20 times).
Nevertheless, the result is the same on all 3 replica servers. The replica
servers are still showing 6717 updates total and wsus still needs 95-100GB on
disk.

The sync settings on the master server are set to download all updates (not
approved only). There is no such configuration option on the relica servers.
Do I have to set the sync options to download approved updates only? Would
make sense since the purgeunneededfiles operation (with automatic
sync/download) is done on the replica servers before doing it on the master
server.
Or did the stopped download with 3 or 21 files left cause thsi result (not
purging the unneedeed files)? What could cause the download stopping and
what do I have to do to fix it?

Best regards
Stefan

"Lawrence Garvin (MVP)" wrote:

> "John <><" <> wrote in message
> news:CEF95BFE-136F-4794-96EE-...
> >I finally had an opportunity to run these steps on my production WSUS
> > servers. However, they failed to produce what I thought would be the
> > outcome. My (Primary) upstream server is now down to 1275 Total Updates.
> > However, my downstream server still has 1315 total updates.
>
> So, your downstream server has 40 updates that are not listed on the master
> server.
>
> The only logical way this can happen is that the updates have been purged
> from the master server (most likely expired revisions using
> RemoveUnneededRevisions), but the replica has not properly synchronized
> those changes.
>
> (Alternatively, I could be wrong, and it could be that you =do= need to run
> RemoveUnneededRevisions on the replica in this case. I need to check on this
> and I would not recommend 'testing' this in your production environment.)
>
> > I followed the
> > steps exactly and expected the downstream server to have the exact same
> > numbers after the last synchronization.
>
> > But noooo. ?. One more note that I
> > failed to outline in my initial posting, I'm not storing the patches
> > locally,
> > I'm forwarding the clients to Microsoft. That shouldn't matter, should
> > it?
>
> Well, not having local storage kinda makes this whole process pointless, to
> be honest,
> since the whole purpose of the procedure is to pare out unneeded =files=
> from the content store.
>
> The metadata listings will always be present, except for expired revisions,
> which only take up space measured in kilobytes in the database.
>
>
>
> --
> Lawrence Garvin, M.S., MCTS, MVP-Software Distribution
> Everything you need for WSUS is at
> http://technet2.microsoft.com/window...s/default.mspx
> And, everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>
>