Werbung: SecurityConsole.de verwaltet Ihre Computer mit Security Essentails aus der Cloud!
30 Tage kostenfrei testen und 20% Rabatt für Ihre Bestellung mit Promocode: WBF2685582
(Promocode gültig bis 31.12.2011)

Group:  English: Windows Server » microsoft.public.windows.server.update_services
Thread: Hierarchy question re: Deployment guide

HTVi
TV Discussion Newsgroups

Hierarchy question re: Deployment guide
LordFox <newsaccount2001[ at ]*spamtag*yahoo.com> 5/16/2007 10:00:58 AM
Hi,

I'm going over the deployment guide for WSUS3.0 and in the WSUS server
Hierarchies I read this:

When you set up a WSUS server hierarchy, you should point Automatic
Updates on all WSUS servers to the farthest downstream WSUS server in
the hierarchy. This shields the entire chain from server-to-server
protocol-breaking changes, because the downstream WSUS server can be
used to update the broken upstream WSUS servers via Automatic Updates.

But I don't get it. If there is a problem with an upstream server, how
can the server update itself from the downstream server, that does not
have the current information as its upstream server is broken? Maybe
someone can enlighten me.

Cheers,

Rick
Re: Hierarchy question re: Deployment guide
"Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 5/18/2007 10:12:00 PM
"LordFox" <newsaccount2001[ at ]*spamtag*yahoo.com> wrote in message
news:9bll43tlcumsnj16uici3pnub5gj4l1tc8[ at ]4ax.com...
[Quoted Text]
> Hi,
>
> I'm going over the deployment guide for WSUS3.0 and in the WSUS server
> Hierarchies I read this:
>
> When you set up a WSUS server hierarchy, you should point Automatic
> Updates on all WSUS servers to the farthest downstream WSUS server in
> the hierarchy. This shields the entire chain from server-to-server
> protocol-breaking changes, because the downstream WSUS server can be
> used to update the broken upstream WSUS servers via Automatic Updates.
>
> But I don't get it.

I don't either, and I have some very strong arguments *against* this
practice.

(And there's a better written response buried somewhere in my SentItems
folder. I'll see if I can dig it out, brush it off, and post it on the
website.)

For starters, the only way the "protocol chain" could break is if some
server installed an update. So, where did it get it from? If one server got
it from the "farthest downstream" WSUS server, and the update broke the WSUS
server, then you're about to watch every WSUS server get broken, because
everybody has the update now.

Perhaps if this is combined with judicious timing of when the update(s) are
approved, vis a vis when they're synchronized, there might be value. But the
section fails to delve into that depth of consideration.

> If there is a problem with an upstream server, how
> can the server update itself from the downstream server, that does not
> have the current information as its upstream server is broken?

Exactly! :-)

My suggestion is:

[a] Either update all WSUS servers /before/ any other systems, to ensure all
WSUS servers are functional after application of the update, but before
distribution to any other systems, or

[b] Defer updating all WSUS servers until /after/ all other systems, to
ensure the WSUS servers do not break as a result of the installation of the
update.

Which you choose may be dependent on the nature of the update.

I faciliate either of these options by defining a separate target group
exclusively for WSUS servers.

Also, either way, my thoughts are that all servers should update from the
highest server in the heirarchy, as that's the first server that will have
the update content, thus the WSUS servers would get the update /applied/
long before they're able to synchronize and download the content for
distribution to themselves.

The other suggestion I've seen is to have WSUS servers update from
themselves, which is a good 'self-test' to ensure both the server and
client-side functionality are working on each WSUS server, without having to
consider the *network* as a potential factor in the event of a non-updating
WSUS 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
.....


Re: Hierarchy question re: Deployment guide
Harry Johnston <harry[ at ]scms.waikato.ac.nz> 5/18/2007 11:42:00 PM
Lawrence Garvin (MVP) wrote:

[Quoted Text]
> For starters, the only way the "protocol chain" could break is if some
> server installed an update. So, where did it get it from? If one server got
> it from the "farthest downstream" WSUS server, and the update broke the WSUS
> server, then you're about to watch every WSUS server get broken, because
> everybody has the update now.

I believe that by "server-to-server protocol-breaking changes" the Microsoft
documentation is describing the situation where two servers cannot communicate
if (and only if) one has the update and the other doesn't. I don't know if this
has ever actually happened or not.

This scenario suggests that it would be best to have all the WSUS servers update
themselves from the same WSUS server, so that if any one gets the update all the
rest do too. Of course the chain will still be broken for the period between
the first server and the last server being updated.

I suppose that the advantage to making that single server the furthest
downstream is that it ensures that all the current round of updates have already
synchronized before the chain breaks; there's a good chance that it will be
repaired before the next important update is released.

However, that argument only takes into consideration this one particular
scenario, so I quite agree that it might not necessarily be the best arrangement
overall.

Harry.

Home | Search | Terms | Imprint Contact
Newsgroups Reader - provided by WiredBox.Net
Suche nach Orten, Städten, Postleitzahlen, Vorwahlen, Kfz-Kennzeichen