|
|
I have a question that I could not find an answer to in this group
(sorry if I missed it).
I have downstream server the is successfully synchronizing with the
upstream server (setup as a replica server).
It gets the list of updates, groups, etc. from the upstream server.
The computers check in with the downstream server, download and apply
updates, and update their status on the downstream server.
When I look on the upstream server at the status of those same
computers, it shows different information on the number of updates
needed, failed, installed etc. on some of the computers. Some of the
computers show the correct numbers. The date/time of the last status
report and last contact are correct for all the computers. So some of
the computers that are up to date are not displayed as being up to date.
Has anyone seen this or have any suggestions?
Thanks
|
|
"Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
news:O8CuoqdrHHA.3276[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] >I have a question that I could not find an answer to in this group (sorry
>if I missed it).
>
> I have downstream server the is successfully synchronizing with the
> upstream server (setup as a replica server).
>
> It gets the list of updates, groups, etc. from the upstream server.
>
> The computers check in with the downstream server, download and apply
> updates, and update their status on the downstream server.
>
> When I look on the upstream server at the status of those same computers,
> it shows different information on the number of updates needed, failed,
> installed etc. on some of the computers. Some of the computers show the
> correct numbers. The date/time of the last status report and last contact
> are correct for all the computers. So some of the computers that are up to
> date are not displayed as being up to date.
>
> Has anyone seen this or have any suggestions?
There is a natural time lag between the time you approve updates on the
upstream server, and the time the downstream server synchronizes those
approvals, and the time the clients detect and install those approvals, and
the time the clients report those installations to the downstream server,
and then the downstream server reports those installations to the upstream
server.
Assuming once daily synchronization, and daily installation at the clients,
that time lag could be as much as 72 hours (or more).
Consider this worst case (normal) scenario:
Downstream server is configured to synchronize daily at 9am.
At 10am Wednesday you approve updates on the upstream server.
At 9am Thursday, the downstream server synchronizes with the upstream
server.
The client just executed a scheduled detection (a random event) at 8am,
and the next one is not scheduled until 6am Friday.
At 6am Friday, the client detects/downloads the update(s).
This client is scheduled to use the daily default installation time of
3am, so updates are installed at 3am Saturday.
The client sends reporting data to the downstream server shortly after
the restart,
But the downstream server doesn't send that reporting data to the
upstream server until the next server synchronization,
which would be 9am Saturday.
Total time elapsed from 10am Wednesday to 9am Saturday is 71 hours.
If the PC were powered off during that period of time, the installation
could actually be delayed until the start of the workday on Monday, which
*might* get to the downstream server in time to be synchronized to the
upstream server at 9am Monday, but depending on the success of that event,
it could be Tuesday morning before the reporting data actually gets there.
SIX DAYS!
Now, having explained all of that, this is one place where server-to-server
synchronization can be beneficial if performed 2x or 4x daily, and properly
scheduled to coincide with your normal WSUS administration activities.
Consider the same scenario, except server sync is now every 6 hours at 10am,
4pm, 10pm, and 4am and scheduled to occur shortly *after* the normal
scheduled installation event (at 3am).
At 9am Wednesday you approve updates on the upstream server.
At 10am Wednesday the downstream server synchronizes with the upstream
server.
Again, the client just executed the detection before 10am, so the next
detection occurs around 8am Thursday.
At 8am Thursday the client detects/downloads the update(s).
This client is scheduled to use the daily default installation time of 3am,
so updates are installed at 3am Friday morning.
The client sends reporting data to the downstream server shortly after the
restart,
And the downstream server synchronizes that reporting data to the upstream
server at 4am Friday morning.
Total elapsed time from approval to upstream server reporting >>> less than
48 hours.
In the event the PC was powered off overnight, updates would be installed at
power up Friday morning, and the downstream server would synchronize the
reporting status at the 4pm synchronization on Friday. Elapsed time less
than 56 hours.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > "Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
> news:O8CuoqdrHHA.3276[ at ]TK2MSFTNGP04.phx.gbl...
>> I have a question that I could not find an answer to in this group (sorry
>> if I missed it).
>>
>> I have downstream server the is successfully synchronizing with the
>> upstream server (setup as a replica server).
>>
>> It gets the list of updates, groups, etc. from the upstream server.
>>
>> The computers check in with the downstream server, download and apply
>> updates, and update their status on the downstream server.
>>
>> When I look on the upstream server at the status of those same computers,
>> it shows different information on the number of updates needed, failed,
>> installed etc. on some of the computers. Some of the computers show the
>> correct numbers. The date/time of the last status report and last contact
>> are correct for all the computers. So some of the computers that are up to
>> date are not displayed as being up to date.
>>
>> Has anyone seen this or have any suggestions?
>
> There is a natural time lag between the time you approve updates on the
> upstream server, and the time the downstream server synchronizes those
> approvals, and the time the clients detect and install those approvals, and
> the time the clients report those installations to the downstream server,
> and then the downstream server reports those installations to the upstream
> server.
>
> Assuming once daily synchronization, and daily installation at the clients,
> that time lag could be as much as 72 hours (or more).
>
> Consider this worst case (normal) scenario:
> Downstream server is configured to synchronize daily at 9am.
>
> At 10am Wednesday you approve updates on the upstream server.
> At 9am Thursday, the downstream server synchronizes with the upstream
> server.
> The client just executed a scheduled detection (a random event) at 8am,
> and the next one is not scheduled until 6am Friday.
> At 6am Friday, the client detects/downloads the update(s).
> This client is scheduled to use the daily default installation time of
> 3am, so updates are installed at 3am Saturday.
> The client sends reporting data to the downstream server shortly after
> the restart,
> But the downstream server doesn't send that reporting data to the
> upstream server until the next server synchronization,
> which would be 9am Saturday.
>
> Total time elapsed from 10am Wednesday to 9am Saturday is 71 hours.
>
> If the PC were powered off during that period of time, the installation
> could actually be delayed until the start of the workday on Monday, which
> *might* get to the downstream server in time to be synchronized to the
> upstream server at 9am Monday, but depending on the success of that event,
> it could be Tuesday morning before the reporting data actually gets there.
> SIX DAYS!
>
>
> Now, having explained all of that, this is one place where server-to-server
> synchronization can be beneficial if performed 2x or 4x daily, and properly
> scheduled to coincide with your normal WSUS administration activities.
>
> Consider the same scenario, except server sync is now every 6 hours at 10am,
> 4pm, 10pm, and 4am and scheduled to occur shortly *after* the normal
> scheduled installation event (at 3am).
>
> At 9am Wednesday you approve updates on the upstream server.
> At 10am Wednesday the downstream server synchronizes with the upstream
> server.
> Again, the client just executed the detection before 10am, so the next
> detection occurs around 8am Thursday.
> At 8am Thursday the client detects/downloads the update(s).
> This client is scheduled to use the daily default installation time of 3am,
> so updates are installed at 3am Friday morning.
> The client sends reporting data to the downstream server shortly after the
> restart,
> And the downstream server synchronizes that reporting data to the upstream
> server at 4am Friday morning.
>
> Total elapsed time from approval to upstream server reporting >>> less than
> 48 hours.
>
> In the event the PC was powered off overnight, updates would be installed at
> power up Friday morning, and the downstream server would synchronize the
> reporting status at the 4pm synchronization on Friday. Elapsed time less
> than 56 hours.
>
>
>
Thanks for the reply...obviously the status of the computers on either
server depends a lot on timing of events.
With that being said, would one expect the 2 servers to show identical
information immediately after a synchronization (either manual or
automatic) regardless of the status reported?
If I run a manual sync and refresh the display on the upstream server,
it shows different data...to me, at that point in time, the 2 servers
should show identical info as the downstream server just sent its data
to the upstream server.
Its not that its a major problem, the computers are getting updates in a
timely manner and thats the main thing. Sometimes I get picky on some
minor issues and didn't know if I was having a problem with the way I
set things up, or if there was a possible bug that had not been seen to
this point.
|
|
"Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
news:uMdjlhorHHA.4768[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > Thanks for the reply...obviously the status of the computers on either
> server depends a lot on timing of events.
>
> With that being said, would one expect the 2 servers to show identical
> information immediately after a synchronization (either manual or
> automatic) regardless of the status reported?
Not necessarily. Because the reporting server (whether the report is coming
from a client, or coming from a replica server), kicks that reporting data
into an asynchronous queue, and processes it into the database on a 'cpu
cycles available basis'. So it might still be several minutes after the
completion of the synchronization before either machine is consistent with
one another.
> Its not that its a major problem, the computers are getting updates in a
> timely manner and thats the main thing. Sometimes I get picky on some
> minor issues and didn't know if I was having a problem with the way I set
> things up, or if there was a possible bug that had not been seen to this
> point.
Not a problem, not a bug, just part of the design. :-)
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > "Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
> news:uMdjlhorHHA.4768[ at ]TK2MSFTNGP02.phx.gbl...
>
>> Thanks for the reply...obviously the status of the computers on either
>> server depends a lot on timing of events.
>>
>> With that being said, would one expect the 2 servers to show identical
>> information immediately after a synchronization (either manual or
>> automatic) regardless of the status reported?
>
> Not necessarily. Because the reporting server (whether the report is coming
> from a client, or coming from a replica server), kicks that reporting data
> into an asynchronous queue, and processes it into the database on a 'cpu
> cycles available basis'. So it might still be several minutes after the
> completion of the synchronization before either machine is consistent with
> one another.
>
>> Its not that its a major problem, the computers are getting updates in a
>> timely manner and thats the main thing. Sometimes I get picky on some
>> minor issues and didn't know if I was having a problem with the way I set
>> things up, or if there was a possible bug that had not been seen to this
>> point.
>
> Not a problem, not a bug, just part of the design. :-)
>
>
Thanks for the additional info. This brings up another question then. I
have several machines that never show the same info even days later. I
would think that the reporting data should have been "processed" even a
few hours later. Is there any way to verify that the correct info was
"merged" into the upstream server db? The dates/times are showing the
same as the downstream server, just not the correct numbers for
installed/needed updates.
Sorry to keep harping on this...I did find that I can choose not to
display the downstream server info...I will probably do that...just so
that I don't see those computers.
|
|
"Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
news:uWfBoV2rHHA.3884[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > Thanks for the additional info. This brings up another question then. I
> have several machines that never show the same info even days later.
This may be a bona fide issue. Can you give me a specific example of what
exists, and what you believe it should be?
> I would think that the reporting data should have been "processed" even a
> few hours later.
It should have, after a few hours, for sure.
> Is there any way to verify that the correct info was "merged" into the
> upstream server db?
I imagine there is, Tom, but it's beyond my skill set.
Maybe Cecil or Matthew can provide some additional info on this question?
> The dates/times are showing the same as the downstream server, just not
> the correct numbers for installed/needed updates.
Hmmm...... so we're led to believe the data is being transferred. It just
doesn't match. :-/
> Sorry to keep harping on this...
No apology necessary!!!
If something isn't working the way it should be, then definitely "harp" as
loud and long as it takes to get a resolution, or a satisfactory answer as
to why it can't be fixed.
> I did find that I can choose not to display the downstream server info...I
> will probably do that...just so that I don't see those computers.
Yeah.. suppressing bad information is sometimes a workable solution. :-)
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > "Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
> news:uWfBoV2rHHA.3884[ at ]TK2MSFTNGP04.phx.gbl...
>
>> Thanks for the additional info. This brings up another question then. I
>> have several machines that never show the same info even days later.
>
> This may be a bona fide issue. Can you give me a specific example of what
> exists, and what you believe it should be?
>
>> I would think that the reporting data should have been "processed" even a
>> few hours later.
>
> It should have, after a few hours, for sure.
>
>> Is there any way to verify that the correct info was "merged" into the
>> upstream server db?
>
> I imagine there is, Tom, but it's beyond my skill set.
>
> Maybe Cecil or Matthew can provide some additional info on this question?
>
>> The dates/times are showing the same as the downstream server, just not
>> the correct numbers for installed/needed updates.
>
>
> Hmmm...... so we're led to believe the data is being transferred. It just
> doesn't match. :-/
>
>
>> Sorry to keep harping on this...
>
> No apology necessary!!!
>
> If something isn't working the way it should be, then definitely "harp" as
> loud and long as it takes to get a resolution, or a satisfactory answer as
> to why it can't be fixed.
>
>> I did find that I can choose not to display the downstream server info...I
>> will probably do that...just so that I don't see those computers.
>
> Yeah.. suppressing bad information is sometimes a workable solution. :-)
>
>
Sorry I didn't get back until today....other more pressing work
I tried to upload screen shots, but it did not let me upload attachments.
The specific example is that the 2 machines show up on both the upstream
server and the downstream server and the dates/times of the last
contact and last status report are exactly the same. The downstream
server shows 100% up to date (no updates needed) and the upstream server
shows 1 update needed which is KB890830 (windows malicious software
removal tool). The downstream server shows that that update is
installed. The upstream server shows need with a status of "downloaded".
I have a few machines doing this, and it is not always the same updates.
I thought maybe it incorrect on the same update, but some machines show
several updates needed. I have one that has 10 updates to MS Office 2003
needed on the upstream server, but shows 100% up to date on the
downstream server.
Thanks again..hopefully this is the info you were looking for.
|
|
"Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
news:%23sYF%23zBtHHA.3732[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >> If something isn't working the way it should be, then definitely "harp"
>> as loud and long as it takes to get a resolution, or a satisfactory
>> answer as to why it can't be fixed.
>>
>>> I did find that I can choose not to display the downstream server
>>> info...I will probably do that...just so that I don't see those
>>> computers.
>>
>> Yeah.. suppressing bad information is sometimes a workable solution. :-)
>>
>>
> Sorry I didn't get back until today....other more pressing work
>
> I tried to upload screen shots, but it did not let me upload attachments.
You may email them to me at: l r g a r v i n a t s w
b e l l d o t n e t
> The specific example is that the 2 machines show up on both the upstream
> server and the downstream server and the dates/times of the last contact
> and last status report are exactly the same.
And you've confirmed that the source of this client data is exactly the same
machine?
> The downstream server shows 100% up to date (no updates needed) and the
> upstream server shows 1 update needed which is KB890830 (windows malicious
> software removal tool).
> The downstream server shows that that update is installed. The upstream
> server shows need with a status of "downloaded".
Suggesting the reports might not be the same computer!
> I have a few machines doing this, and it is not always the same updates.
Further suggesting you might have some duplications.
> I thought maybe it incorrect on the same update, but some machines show
> several updates needed. I have one that has 10 updates to MS Office 2003
> needed on the upstream server, but shows 100% up to date on the downstream
> server.
It certainly gives us a definitive direction to investigate! :-)
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > "Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
> news:%23sYF%23zBtHHA.3732[ at ]TK2MSFTNGP02.phx.gbl...
>
>>> If something isn't working the way it should be, then definitely "harp"
>>> as loud and long as it takes to get a resolution, or a satisfactory
>>> answer as to why it can't be fixed.
>>>
>>>> I did find that I can choose not to display the downstream server
>>>> info...I will probably do that...just so that I don't see those
>>>> computers.
>>> Yeah.. suppressing bad information is sometimes a workable solution. :-)
>>>
>>>
>> Sorry I didn't get back until today....other more pressing work
>>
>> I tried to upload screen shots, but it did not let me upload attachments.
>
> You may email them to me at: l r g a r v i n a t s w
> b e l l d o t n e t
>
>
>
>> The specific example is that the 2 machines show up on both the upstream
>> server and the downstream server and the dates/times of the last contact
>> and last status report are exactly the same.
>
> And you've confirmed that the source of this client data is exactly the same
> machine?
>
>
>> The downstream server shows 100% up to date (no updates needed) and the
>> upstream server shows 1 update needed which is KB890830 (windows malicious
>> software removal tool).
>
>> The downstream server shows that that update is installed. The upstream
>> server shows need with a status of "downloaded".
>
> Suggesting the reports might not be the same computer!
>
>
>> I have a few machines doing this, and it is not always the same updates.
>
>
> Further suggesting you might have some duplications.
>
>
>> I thought maybe it incorrect on the same update, but some machines show
>> several updates needed. I have one that has 10 updates to MS Office 2003
>> needed on the upstream server, but shows 100% up to date on the downstream
>> server.
>
> It certainly gives us a definitive direction to investigate! :-)
>
Thanks again Lawrence...I have sent off the screen shots.
I'm fairly certain the reports are from the same computer.
Is there a definitive method to check to if they are duplicates?
|
|
"Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
news:%23boApE0tHHA.1204[ at ]TK2MSFTNGP03.phx.gbl...
Hmmm.. now that I'm looking at the thread in the newsgroup, and not trying
to "remember" the thread while replying to an email.... ;-)
[Quoted Text] >>> The specific example is that the 2 machines show up on both the upstream
>>> server and the downstream server and the dates/times of the last contact
>>> and last status report are exactly the same.
The reason for this is because the Replica Reporting Rollup is enabled, and
you're looking at the *downstream* server's client status data in the
upstream server's computer group node.
>>> The downstream server shows 100% up to date (no updates needed) and the
>>> upstream server shows 1 update needed which is KB890830 (windows
>>> malicious software removal tool).
There are a number of possible scenarios that could explain this in a
replica reporting rollup scenario, all of which have to do with the various
time lags between synchronizations, client reporting, and replica reporting
rollup.
>>> The downstream server shows that that update is installed. The upstream
>>> server shows need with a status of "downloaded".
>>
>> Suggesting the reports might not be the same computer!
Or, simply a natural lag in the processing of replica synchronization,
client reporting, and reporting rollup. The upstream server simply does not
have the *latest* status report, whereas the downstream server does.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > "Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
> news:%23boApE0tHHA.1204[ at ]TK2MSFTNGP03.phx.gbl...
>
> Hmmm.. now that I'm looking at the thread in the newsgroup, and not trying
> to "remember" the thread while replying to an email.... ;-)
>
>
>>>> The specific example is that the 2 machines show up on both the upstream
>>>> server and the downstream server and the dates/times of the last contact
>>>> and last status report are exactly the same.
>
> The reason for this is because the Replica Reporting Rollup is enabled, and
> you're looking at the *downstream* server's client status data in the
> upstream server's computer group node.
>
>
>>>> The downstream server shows 100% up to date (no updates needed) and the
>>>> upstream server shows 1 update needed which is KB890830 (windows
>>>> malicious software removal tool).
>
> There are a number of possible scenarios that could explain this in a
> replica reporting rollup scenario, all of which have to do with the various
> time lags between synchronizations, client reporting, and replica reporting
> rollup.
>
>
>>>> The downstream server shows that that update is installed. The upstream
>>>> server shows need with a status of "downloaded".
>>> Suggesting the reports might not be the same computer!
>
> Or, simply a natural lag in the processing of replica synchronization,
> client reporting, and reporting rollup. The upstream server simply does not
> have the *latest* status report, whereas the downstream server does.
>
>
Hi Lawrence....I have some more info on this issue that I just came
across this morning. I don't know if it is related or not. Maybe its a
different issue or just more fuel for the original fire.
I have several updates listed on the downstream server that were
"declined" on the upstream server many months ago. Microsoft "expired"
the updates and they disappeared on the upstream server.
Now I notice that they are showing up on the downstream server as "Not
Approved". It is showing that some machines "need" these updates. A
couple of updates specifically are an older IE 7 upgrade, that were
never approved. KB926874 dated 11/01/06 and 11/21/06. They have a note
that they are expired, but since its a downstream server, I can't
approve, decline etc.
As a test, I declined another update on the upstream server, did a
manual sync and the change was mirrored on the downstream server
immediately.
I don't get any errors in the synchronization logs on either server..it
just seems that these servers are just not truly in sync.
Is the DB on the downstream server a little out of whack, and would it
be best to recreate it to give it a fresh start? If so, what would be
the best steps to accomplish this?
|
|
"Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
news:%23zvFsXMvHHA.3640[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > Hi Lawrence....I have some more info on this issue that I just came across
> this morning. I don't know if it is related or not. Maybe its a different
> issue or just more fuel for the original fire.
>
> I have several updates listed on the downstream server that were
> "declined" on the upstream server many months ago. Microsoft "expired" the
> updates and they disappeared on the upstream server.
>
> Now I notice that they are showing up on the downstream server as "Not
> Approved".
Yep.... another manifestation of the Server Cleanup Wizard in a replica
environment. Running the SCW on the master server caused all of those
expired/declined updates to be removed from the database, and now the
replica has no way to get status.
Running the SCW (based on your previous experiences) should also eliminate
these items from the replica server.
> It is showing that some machines "need" these updates.
Ahh, yes, now this will be probematic, because the SCW won't remove any
content that is Needed. But, since these are expired/declined updates, the
real question would be: Why haven't the clients installed the *superceding*
update(s)??? -- After which time these updates would ceased to be "needed".
> A couple of updates specifically are an older IE 7 upgrade, that were
> never approved. KB926874 dated 11/01/06 and 11/21/06. They have a note
> that they are expired, but since its a downstream server, I can't approve,
> decline etc.
Okay..what is the approval and installation status of the *latest* IE7
update? (Should be KB933566.)
> As a test, I declined another update on the upstream server, did a manual
> sync and the change was mirrored on the downstream server immediately.
As expected. It's only when those declined/expired updates are removed from
the upstream server before the replica properly synchronizes that you'll
have issues. In general the order of performance should be:
[a] Synchronize the master server. Set synchronization to manual.
[b] Synchronize the replica server(s). Set synchronization to manual.
[c] Verify that all replica server(s) have downloaded all needed content.
[d] Run the Server Cleanup Wizard on the replica server(s).
[e] Run the Server Cleanup Wizard on the master server.
[f] Re-enable scheduled synchronization.
> Is the DB on the downstream server a little out of whack, and would it be
> best to recreate it to give it a fresh start? If so, what would be the
> best steps to accomplish this?
If you're not able to remediate the anomalies on the replica server(s) using
the Server Cleanup Wizard, then you've got two options:
[1] With WSUS3, a replica server can be converted back to an autonomous
server. Convert the replica to autonomous, do whatever manual housekeeping
is necessary to make it match the master, and then convert it back to
replica and execute a synchronization.
[2] If the SCW or the above manual process are not successful, or if the
work in the manual process appears to be too complex, then the easiest way
to restore consistency would be to trash the replica server(s) including the
database (but not the content store), and reinstall WSUS3.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > "Tom Svehla" <tsvehla[ at ]lincoln.ne.gov> wrote in message
> news:%23zvFsXMvHHA.3640[ at ]TK2MSFTNGP05.phx.gbl...
>
>> Hi Lawrence....I have some more info on this issue that I just came across
>> this morning. I don't know if it is related or not. Maybe its a different
>> issue or just more fuel for the original fire.
>>
>> I have several updates listed on the downstream server that were
>> "declined" on the upstream server many months ago. Microsoft "expired" the
>> updates and they disappeared on the upstream server.
>>
>> Now I notice that they are showing up on the downstream server as "Not
>> Approved".
>
> Yep.... another manifestation of the Server Cleanup Wizard in a replica
> environment. Running the SCW on the master server caused all of those
> expired/declined updates to be removed from the database, and now the
> replica has no way to get status.
>
> Running the SCW (based on your previous experiences) should also eliminate
> these items from the replica server.
>
>
>> It is showing that some machines "need" these updates.
>
> Ahh, yes, now this will be probematic, because the SCW won't remove any
> content that is Needed. But, since these are expired/declined updates, the
> real question would be: Why haven't the clients installed the *superceding*
> update(s)??? -- After which time these updates would ceased to be "needed".
>
>
>> A couple of updates specifically are an older IE 7 upgrade, that were
>> never approved. KB926874 dated 11/01/06 and 11/21/06. They have a note
>> that they are expired, but since its a downstream server, I can't approve,
>> decline etc.
>
> Okay..what is the approval and installation status of the *latest* IE7
> update? (Should be KB933566.)
>
>
>> As a test, I declined another update on the upstream server, did a manual
>> sync and the change was mirrored on the downstream server immediately.
>
>
> As expected. It's only when those declined/expired updates are removed from
> the upstream server before the replica properly synchronizes that you'll
> have issues. In general the order of performance should be:
> [a] Synchronize the master server. Set synchronization to manual.
> [b] Synchronize the replica server(s). Set synchronization to manual.
> [c] Verify that all replica server(s) have downloaded all needed content.
> [d] Run the Server Cleanup Wizard on the replica server(s).
> [e] Run the Server Cleanup Wizard on the master server.
> [f] Re-enable scheduled synchronization.
>
>
>> Is the DB on the downstream server a little out of whack, and would it be
>> best to recreate it to give it a fresh start? If so, what would be the
>> best steps to accomplish this?
>
> If you're not able to remediate the anomalies on the replica server(s) using
> the Server Cleanup Wizard, then you've got two options:
>
> [1] With WSUS3, a replica server can be converted back to an autonomous
> server. Convert the replica to autonomous, do whatever manual housekeeping
> is necessary to make it match the master, and then convert it back to
> replica and execute a synchronization.
>
> [2] If the SCW or the above manual process are not successful, or if the
> work in the manual process appears to be too complex, then the easiest way
> to restore consistency would be to trash the replica server(s) including the
> database (but not the content store), and reinstall WSUS3.
>
>
Thanks again....You hit it right on the head...If I would have had a
chance to catch up on my reading, I would have found your answer to
another person with same issue. I ran the SCW and it did in fact clean
up the replica server..things look much better now. I still have the
same issue with the workstations still showing different numbers on
needed updates, but I'm going to let things shake out here for a few
days, now that I have the updates in sync again.
Sorry to have hijacked my own thread, but as usual your expertise on
this is priceless!
|
|
|