|
|
I think I have found a bug in the downstream replica mode. Currently,
I have WSUS configured so manually select where PCs are sitting in
each group.
I have also enabled the reporting option to roll up status from
downstream servers.
So here's my situation:
Downstream servers get new computers hitting the WSUS, and the
computers get placed in the "Unassigned Computers" group.
The downstream servers then update and replicate that information to
the upstream server.
On the upstream server, I can see the computer in the "Unassigned
Computers" group with no issue because of the roll up reporting.
Here's where the problem starts:
On the downstream server, I move the computer into a different group
that I assign it to. I refresh that groups view to verify the computer
is placed there. Then I syncronize the downstream server to the
upstream server.
On the upstream server, the computer that was moved on the downstream
server nevers gets placed into the new group, nor does it ever leave
the "Unassigned Computers" group.
I can replicate this situation all the time. To get the computers to
properly show up in the proper group on the upstream server, I have to
always follow these steps.
1) Delete the computer from the upstream server
2) On the downstream server, force an update
3) On the PC, issue a: wuauclt /detectnow
4) On the downstream server, move the computer into the new group
5) Force an update on the downstream server.
6) The upstream server will then see the computer in the proper group
It seems to me that the downstream servers will only report the
computer's group once, even if its moved from a different group, and
will never get properly reflected on the upstream server.
Anyone else see this issue?
--
Jason Chambers
|
|
I am having a similiar issue with my servers. Sometimes it takes quite a few
sync's over the days to get it right. My master server has about 2 dozen PCs
that are in the wrong categories, but are right on other servers. However,
any other updates or changes, such as Upgrade to SP2 from SP1, the PC will
now show the correct info but not change groups.
"Jason Chambers" wrote:
[Quoted Text] > I think I have found a bug in the downstream replica mode. Currently,
> I have WSUS configured so manually select where PCs are sitting in
> each group.
>
> I have also enabled the reporting option to roll up status from
> downstream servers.
>
>
> So here's my situation:
>
> Downstream servers get new computers hitting the WSUS, and the
> computers get placed in the "Unassigned Computers" group.
>
> The downstream servers then update and replicate that information to
> the upstream server.
>
> On the upstream server, I can see the computer in the "Unassigned
> Computers" group with no issue because of the roll up reporting.
>
>
> Here's where the problem starts:
>
> On the downstream server, I move the computer into a different group
> that I assign it to. I refresh that groups view to verify the computer
> is placed there. Then I syncronize the downstream server to the
> upstream server.
>
> On the upstream server, the computer that was moved on the downstream
> server nevers gets placed into the new group, nor does it ever leave
> the "Unassigned Computers" group.
>
> I can replicate this situation all the time. To get the computers to
> properly show up in the proper group on the upstream server, I have to
> always follow these steps.
>
> 1) Delete the computer from the upstream server
> 2) On the downstream server, force an update
> 3) On the PC, issue a: wuauclt /detectnow
> 4) On the downstream server, move the computer into the new group
> 5) Force an update on the downstream server.
> 6) The upstream server will then see the computer in the proper group
>
>
> It seems to me that the downstream servers will only report the
> computer's group once, even if its moved from a different group, and
> will never get properly reflected on the upstream server.
>
>
> Anyone else see this issue?
>
>
>
> --
> Jason Chambers
>
>
|
|
Now that I check again, I am now noticing that updates that are
applied do not appear to replicate upwards properly either. I
understand it may take a while for that information to go through. But
I have less than 150 PCs managed by WSUS. Reporting shouldn't take 3+
hours to update that information if I have downstream servers syncing
every hour, should it?
On Jun 27, 2:52 pm, James Foe <James...[ at ]discussions.microsoft.com>
wrote:
[Quoted Text] > I am having a similiar issue with my servers. Sometimes it takes quite a few
> sync's over the days to get it right. My master server has about 2 dozen PCs
> that are in the wrong categories, but are right on other servers. However,
> any other updates or changes, such as Upgrade to SP2 from SP1, the PC will
> now show the correct info but not change groups.
>
> "Jason Chambers" wrote:
> > I think I have found a bug in the downstream replica mode. Currently,
> > I have WSUS configured so manually select where PCs are sitting in
> > each group.
>
> > I have also enabled the reporting option to roll up status from
> > downstream servers.
>
> > So here's my situation:
>
> > Downstream servers get new computers hitting the WSUS, and the
> > computers get placed in the "Unassigned Computers" group.
>
> > The downstream servers then update and replicate that information to
> > the upstream server.
>
> > On the upstream server, I can see the computer in the "Unassigned
> > Computers" group with no issue because of the roll up reporting.
>
> > Here's where the problem starts:
>
> > On the downstream server, I move the computer into a different group
> > that I assign it to. I refresh that groups view to verify the computer
> > is placed there. Then I syncronize the downstream server to the
> > upstream server.
>
> > On the upstream server, the computer that was moved on the downstream
> > server nevers gets placed into the new group, nor does it ever leave
> > the "Unassigned Computers" group.
>
> > I can replicate this situation all the time. To get the computers to
> > properly show up in the proper group on the upstream server, I have to
> > always follow these steps.
>
> > 1) Delete the computer from the upstream server
> > 2) On the downstream server, force an update
> > 3) On the PC, issue a: wuauclt /detectnow
> > 4) On the downstream server, move the computer into the new group
> > 5) Force an update on the downstream server.
> > 6) The upstream server will then see the computer in the proper group
>
> > It seems to me that the downstream servers will only report the
> > computer's group once, even if its moved from a different group, and
> > will never get properly reflected on the upstream server.
>
> > Anyone else see this issue?
>
> > --
> > Jason Chambers
|
|
"Jason Chambers" <jchambers[ at ]gmail.com> wrote in message
news:1182960908.549643.262360[ at ]z28g2000prd.googlegroups.com...
[Quoted Text] > I can replicate this situation all the time. To get the computers to
> properly show up in the proper group on the upstream server, I have to
> always follow these steps.
>
> 1) Delete the computer from the upstream server
> 2) On the downstream server, force an update
> 3) On the PC, issue a: wuauclt /detectnow
> 4) On the downstream server, move the computer into the new group
> 5) Force an update on the downstream server.
> 6) The upstream server will then see the computer in the proper group
Part of the issue, Jason, is in understanding how the environment works. In
this scenario, by executing a forced detection in step 3, you've enabled the
client to become aware that it has been assigned to a new group. Then,
following the detection the client reports into that new group, the replica
server now has the report assigned to the new group, and then the replica
server executes a reporting rollup with the client system reported in the
new group.
Until the client system becomes aware of the group change, the reporting
data will remain associated with the group that the client last reported
itself a member of.
--
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
.....
|
|
Then why would the data be accurate on the downstream servers, and
inaccurate on the upstream servers. This includes the patches that
have/have not been applied. Shouldn't the downstream server be
reporting this information to the upstream server, and not the client?
On Jun 27, 7:57 pm, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Jason Chambers" <jchamb...[ at ]gmail.com> wrote in message > > news:1182960908.549643.262360[ at ]z28g2000prd.googlegroups.com... > > > I can replicate this situation all the time. To get the computers to > > properly show up in the proper group on the upstream server, I have to > > always follow these steps. > > > 1) Delete the computer from the upstream server > > 2) On the downstream server, force an update > > 3) On the PC, issue a: wuauclt /detectnow > > 4) On the downstream server, move the computer into the new group > > 5) Force an update on the downstream server. > > 6) The upstream server will then see the computer in the proper group > > Part of the issue, Jason, is in understanding how the environment works. In > this scenario, by executing a forced detection in step 3, you've enabled the > client to become aware that it has been assigned to a new group. Then, > following the detection the client reports into that new group, the replica > server now has the report assigned to the new group, and then the replica > server executes a reporting rollup with the client system reported in the > new group. > > Until the client system becomes aware of the group change, the reporting > data will remain associated with the group that the client last reported > itself a member of. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/...> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
|
|
"Jason Chambers" <jchambers[ at ]gmail.com> wrote in message
news:1183040051.915494.255870[ at ]k29g2000hsd.googlegroups.com...
[Quoted Text] > Then why would the data be accurate on the downstream servers, and
> inaccurate on the upstream servers.
Because the clients report to the *downstream* servers shortly after each
event of significance, but the downstream server only uploads reporting
rollup data at the scheduled synchronization event(s). By default, that's
only once per day.
> This includes the patches that
> have/have not been applied. Shouldn't the downstream server be
> reporting this information to the upstream server, and not the client?
The downstream server *does* report it to the upstream server, but only once
per day (by default) during scheduled server-to-server synchronization.
Thus, the downstream server could have "newer" information for as much as 24
hours, if the client last reported only minutes after the server
synchronized with the upstream server.
--
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, is this 1 time sync predetermined, or random?
On Jun 28, 11:34 pm, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Jason Chambers" <jchamb...[ at ]gmail.com> wrote in message > > news:1183040051.915494.255870[ at ]k29g2000hsd.googlegroups.com... > > > Then why would the data be accurate on the downstream servers, and > > inaccurate on the upstream servers. > > Because the clients report to the *downstream* servers shortly after each > event of significance, but the downstream server only uploads reporting > rollup data at the scheduled synchronization event(s). By default, that's > only once per day. > > > This includes the patches that > > have/have not been applied. Shouldn't the downstream server be > > reporting this information to the upstream server, and not the client? > > The downstream server *does* report it to the upstream server, but only once > per day (by default) during scheduled server-to-server synchronization. > Thus, the downstream server could have "newer" information for as much as 24 > hours, if the client last reported only minutes after the server > synchronized with the upstream server. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/...> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
|
|
As I stated previously, I have it updating 24 times a day, (or every
hour) and it still lags about 5 or 6 hours. The reporting only seems
to synchronize overnight.
I'm just interested to know when that time is.
On Jun 29, 10:29 am, Jason Cochran <Jason.Cochran.
2sy...[ at ]DoNotSpam.com> wrote:
[Quoted Text] > Jason, > > IN WSUS 3.0 you can configure a custom synchronization schedule, as > well manaully force a sync. > > To configure a custom sync schedule > > 1. Open WSUS MMC > 2. Choose Options on the left pane > 3. Choose Synchronization Schedule in the middle pane. > > To manually force a sync > > 1. Open WSUS MMC > 2. Choose Synchronization on the left pane > 3. Choose Synchronize now on the far right Actions pane. > > Lawrence, I have a question about scheduling the WSUS updates to > install in a multi time zone scenario. > > If I set the install time in the GPO to midnight in the United States, > will our client in other parts of the world install the updates at > midnight US time or local time? > > -- > Jason Cochran > ------------------------------------------------------------------------ > Jason Cochran's Profile: http://forums.techarena.in/member.php?userid=27320> View this thread: http://forums.techarena.in/showthread.php?t=773775> > http://forums.techarena.in
|
|
"Jason Chambers" <jchambers[ at ]gmail.com> wrote in message
news:1183477511.876997.60960[ at ]q75g2000hsh.googlegroups.com...
[Quoted Text] > As I stated previously, I have it updating 24 times a day, (or every
> hour) and it still lags about 5 or 6 hours. The reporting only seems
> to synchronize overnight.
It can only report upstream what it has. It only gets what it gets from the
clients when they have something to report. Clients submit reporting data to
the assigned WSUS server for the following events:
[a] Detection == which is what changes the status to "Needed"
[b] Successful download == which is what updates the status popup dialog
when you click on "Needed".
[c] Successful installation == which is what updates the status to
"Reboot Required".
[d] Successful reboot following installation == which is what updates
the status to "Installed".
>> Lawrence, I have a question about scheduling the WSUS updates to
>> install in a multi time zone scenario.
>>
>> If I set the install time in the GPO to midnight in the United States,
>> will our client in other parts of the world install the updates at
>> midnight US time or local time?
Installation is always performed at *LOCAL* time. So, your global clients
will install at midnight local time.
--
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
.....
|
|
I can understand the concept that the servers can report data only
when the client reports in, but I do not understand why the downstream/
upstream servers can be so out-of-sync, even if the servers are
configured to sync every hour.
- A client on the downstream server will have the patch installed.
- The downstream server will reflect that the patch has actually been
installed in its reporting services
- But the upstream server doesn't update it's report about the client
until some time overnight.
* The downstream server syncs every hour (24 times a day) on the hour.
* The upstream server 4 times a day (on 2 and 8 o'clocks.)
* Even if the downstream server has correct information about the
client at 11am, and the upstream server has incorrect information on
the client at that time, they will still be incorrect at 5pm.
Several hours can pass by, the upstream server will have incorrect
information it's reports about the client, but the downstream server
will have correct information. This means the reporting is out of sync
somehow. Is there a configuration setting on the upstream server that
says only update roll-up downstream reporting at separate time?
Because that's what it appears to me.
On Jul 3, 12:16 pm, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Jason Chambers" <jchamb...[ at ]gmail.com> wrote in message > > news:1183477511.876997.60960[ at ]q75g2000hsh.googlegroups.com... > > > As I stated previously, I have it updating 24 times a day, (or every > > hour) and it still lags about 5 or 6 hours. The reporting only seems > > to synchronize overnight. > > It can only report upstream what it has. It only gets what it gets from the > clients when they have something to report. Clients submit reporting data to > the assigned WSUS server for the following events: > [a] Detection == which is what changes the status to "Needed" > [b] Successful download == which is what updates the status popup dialog > when you click on "Needed". > [c] Successful installation == which is what updates the status to > "Reboot Required". > [d] Successful reboot following installation == which is what updates > the status to "Installed". > > >> Lawrence, I have a question about scheduling the WSUS updates to > >> install in a multi time zone scenario. > > >> If I set the install time in the GPO to midnight in the United States, > >> will our client in other parts of the world install the updates at > >> midnight US time or local time? > > Installation is always performed at *LOCAL* time. So, your global clients > will install at midnight local time. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/...> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
|
|
"Jason Chambers" <jchambers[ at ]gmail.com> wrote in message
news:1183552711.766096.179350[ at ]k79g2000hse.googlegroups.com...
[Quoted Text] >I can understand the concept that the servers can report data only
> when the client reports in, but I do not understand why the downstream/
> upstream servers can be so out-of-sync, even if the servers are
> configured to sync every hour.
I wrote an extensive explanation for this, just a week or so ago, in this
very newsgroup.
The short version is -- it matters not when the *servers* synchronize, if
the client is only reporting once every 22-24 hours. :-)
> - A client on the downstream server will have the patch installed.
> - The downstream server will reflect that the patch has actually been
> installed in its reporting services
But, *this* reporting event only occurs after a successful installation
event -- generally once every 24 hours.
> - But the upstream server doesn't update it's report about the client
> until some time overnight.
Specifically, at the next server-to-server synchronization *after* the
client reports to the replica server.
> * Even if the downstream server has correct information about the
> client at 11am, and the upstream server has incorrect information on
> the client at that time, they will still be incorrect at 5pm.
How much longer after that 4x per day replica synchronization is the client
data out-of-sync? Understand that while the server-to-server synchronization
*transmits* the data to the upstream server, from there it's held in a
processing queue, and is processed asynchronously on a cycles-available
basis. How much longer it would take would be dependent on the server load
at 5pm.
Since you've indicated that the master server is sychronizing to
microsoft.com every hour, it could be a really long time before there are
enough free cycles to process the downstream data -- which also depends on
how many replica servers there are, and when they each report.
I would argue that hourly synchronization is probably not needed -- maybe
even pointless -- unless you've also got the server infrastructure in place
to support hourly *detection* by each of the clients. I suspect I could
successfully argue, mathematically, that the whole server synchronization
process won't show much improvement in distribution cycle times of updates
once the server(s) are synchronizing more than 2x as frequent as the
clients.
Other variables that factor into this are:
How predictable are your client installations on the first scheduled
opportunity.
Do you have 50% clients installed? 75%? 99%?
Do you use deadlines to force short cycle-times from detection to
installation?
How many replica servers are in the environment?
How often do those replica servers synchronize.
Even with your replicas synchronizing 4x daily, if the clients are still
only using the default detection interval, at least 2, and probably 3 of
those replica synchronizations produce no usable work on behalf of the
clients.
> Is there a configuration setting on the upstream server that
> says only update roll-up downstream reporting at separate time?
Not to my knowledge.
--
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://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Thanks for your patience on my little nit pickings Lawrence. Can you
point me to that article you are referring to so I can give it a good
thorough reading?
I think I got the terms wrong when it comes to the servers. Just to
clear things up, I got my Master server syncing 4 times a day and my
Replica's 24 times a day. Also, I have policy to have the clients poll
the server every 4 hours as well (call it extreme if you will) :)
My objective at the end of the day is just to print one master report
that is correct, instead of having to compare it to the replica server
for accuracy.
Here are the answers to your questions
* How predictable are your client installations on the first scheduled
opportunity. Very, I say 80% of the computers are online and in the
office for scheduled installs (12pm at each regional office)
* Do you have 50% clients installed? 75%? 99%?. My current breakdown:
7 Errors
33 Needing (25 of these are servers, which we only update every Q due
to our business being 24/7)
88 Installed/Not Applicable
62% installed (91% if you don't count servers)
* Do you use deadlines to force short cycle-times from detection to
installation? Here's the policy:
Policy Setting
Allow Automatic Updates immediate installation Enabled
Automatic Updates detection frequency Enabled
Check for updates at the following
interval (hours): 4
Policy Setting
Configure Automatic Updates Enabled
Configure automatic updating: 4 - Auto download and schedule the
install
The following settings are only required
and applicable if 4 is selected.
Scheduled install day: 0 - Every day
Scheduled install time: 12:00
Policy Setting
No auto-restart for scheduled Automatic Updates installations Enabled
Reschedule Automatic Updates scheduled installations Enabled
Wait after system
startup (minutes): 5
Policy Setting
Specify intranet Microsoft update service location Enabled
Set the intranet update service for detecting updates: http://myserver
Set the intranet statistics server: http://myserver
There was only 1 update that we scheduled force install deadlines for
and that was for the daylight savings time change.
* How many replica servers are in the environment? 1 (Set not to
download updates, clients download from Microsoft)
* How often do those replica servers synchronize? Every hour
On Jul 5, 10:32 pm, "Lawrence Garvin \(MVP\)"
<onsit...[ at ]community.nospam> wrote:
[Quoted Text] > "Jason Chambers" <jchamb...[ at ]gmail.com> wrote in message > > news:1183552711.766096.179350[ at ]k79g2000hse.googlegroups.com... > > >I can understand the concept that the servers can report data only > > when the client reports in, but I do not understand why the downstream/ > > upstream servers can be so out-of-sync, even if the servers are > > configured to sync every hour. > > I wrote an extensive explanation for this, just a week or so ago, in this > very newsgroup. > > The short version is -- it matters not when the *servers* synchronize, if > the client is only reporting once every 22-24 hours. :-) > > > - A client on the downstream server will have the patch installed. > > - The downstream server will reflect that the patch has actually been > > installed in its reporting services > > But, *this* reporting event only occurs after a successful installation > event -- generally once every 24 hours. > > > - But the upstream server doesn't update it's report about the client > > until some time overnight. > > Specifically, at the next server-to-server synchronization *after* the > client reports to the replica server. > > > * Even if the downstream server has correct information about the > > client at 11am, and the upstream server has incorrect information on > > the client at that time, they will still be incorrect at 5pm. > > How much longer after that 4x per day replica synchronization is the client > data out-of-sync? Understand that while the server-to-server synchronization > *transmits* the data to the upstream server, from there it's held in a > processing queue, and is processed asynchronously on a cycles-available > basis. How much longer it would take would be dependent on the server load > at 5pm. > > Since you've indicated that the master server is sychronizing to > microsoft.com every hour, it could be a really long time before there are > enough free cycles to process the downstream data -- which also depends on > how many replica servers there are, and when they each report. > > I would argue that hourly synchronization is probably not needed -- maybe > even pointless -- unless you've also got the server infrastructure in place > to support hourly *detection* by each of the clients. I suspect I could > successfully argue, mathematically, that the whole server synchronization > process won't show much improvement in distribution cycle times of updates > once the server(s) are synchronizing more than 2x as frequent as the > clients. > > Other variables that factor into this are: > How predictable are your client installations on the first scheduled > opportunity. > Do you have 50% clients installed? 75%? 99%? > Do you use deadlines to force short cycle-times from detection to > installation? > How many replica servers are in the environment? > How often do those replica servers synchronize. > > Even with your replicas synchronizing 4x daily, if the clients are still > only using the default detection interval, at least 2, and probably 3 of > those replica synchronizations produce no usable work on behalf of the > clients. > > > Is there a configuration setting on the upstream server that > > says only update roll-up downstream reporting at separate time? > > Not to my knowledge. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...> > Everything you need for WSUS is at http://www.microsoft.com/wsus> > And, almost everything else is at http://wsusinfo.onsitechsolutions.com> ....
|
|
"Jason Chambers" <jchambers[ at ]gmail.com> wrote in message
news:1183736093.855350.63520[ at ]q75g2000hsh.googlegroups.com...
[Quoted Text] > Can you
> point me to that article you are referring to so I can give it a good
> thorough reading?
The thread is "Computers from downstream server", and the specific post is
dated 6/13 9:12PM (CT).
> I think I got the terms wrong when it comes to the servers. Just to
> clear things up, I got my Master server syncing 4 times a day and my
> Replica's 24 times a day. Also, I have policy to have the clients poll
> the server every 4 hours as well (call it extreme if you will) :)
Having your replicas sync 24 times a day is definitely excessive, and it's
probably causing a fair amount of overwork on the master server, and may
well account for any delays in the processing of asynchronous events.
The 'every 4 hour' detection is less extreme, but still pretty pointless
unless you're checking the master server for new content after every
synchronization.
If the master server is synchronizing four times a day, there's not much
point in having replicas do more than that.
- Your replicas should synchronize in a time frame consistent with when
you normally approve updates.
- Your replicas should synchornize in a time frame consistent with your
scheduled installation activities.
- Your replicas should synchronized at staggered times, in order to
minimize the workload on the master server.
> My objective at the end of the day is just to print one master report
> that is correct, instead of having to compare it to the replica server
> for accuracy.
Truly, I think a replica server environment is too complex to realistically
achieve this expectation. :-)
Part of the article cited above described how the natural time lag in a
replica server environment from approval to reporting rollup could be as
much as 72 hours. In such a scenario, a *daily* report would not be likely
at all. At best, you should be able to print one master report at the end of
the =week=, that would be an accurate indication of your enterprise status.
> * How many replica servers are in the environment? 1 (Set not to
> download updates, clients download from Microsoft)
> * How often do those replica servers synchronize? Every hour
Let's talk a bit more about your replica environment. Since you only have
*one* replica server, how many clients does that replica serve? How many
clients in your organization total? What kind of bandwidth service do you
have to the remote site where the replica server is housed? Does that
replica server service remote clients? If so, how much bandwidth to those
sites, and how many clients on each site?
--
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://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
|