Creative WSUS peering

Creative WSUS peering

Post by Roger Abel » Mon, 05 Sep 2005 06:48:53


Who has gone down a road like:
Two WSUS, pointing at the same database and
having their content area shared with such as DFS
Unc used in IIS for the vdir or robocopy, and with
only one of the WSUS at a time allowed to do any
sync with the MS feeds
???
The scenario I am looking at needs cheap failover peers,
not a hierarchy; it should be brain-dead (i.e. as automatic
and foolproof as possible), and if at all possible have a
shared history of configs, machines/groups, etc.
 
 
 

Creative WSUS peering

Post by Lawrence G » Mon, 05 Sep 2005 08:04:56


Not supported.. and won't work.... so nobody has "successfully" gone down
that road. :-)


Also not supported.. and won't work.


That level of redundancy and automation is not available in WSUS. Even if
you used replicas, or a distributed server as a 'clone' of the first, the
shared history will not be available. Best suggestion for 'recovery' of WSUS
is a good daily backup of the WMSDE database immediately following the
synchronization, and following every update 'approval' session. Another
option, or perhaps to be used in combination with.. is to make a Ghost image
of the system (sans the content directory) on a regular basis. The server
can be rebuilt from the Ghost image, and 'replacement' content can be
downloaded from microsoft.com using the 'wsusutil reset' command.

 
 
 

Creative WSUS peering

Post by Asher_ » Tue, 06 Sep 2005 00:20:39

"Lawrence Garvin" < XXXX@XXXXX.COM > wrote in



Keep in mind that the kind of redundancy yoou want was not built in the
design because WSUS is most definetely not a mission critical
application. If I came in after patch Tuesday to find my WSUS server
completely down, it would still take me only about half a day to recover
it. None of my clients would be affected.
 
 
 

Creative WSUS peering

Post by Roger Abel » Tue, 06 Sep 2005 01:05:34

Lawrence and Asher
Thanks you both for the replies.
I however already knew all that was stated. Yes, this is out of
scope for the delivered product, use normal recovery strategies,
etc.
All good comments, but not what I was really after.
I was looking for info from anyone that had experimented in this vein.
Consider:
Machine X1 syncs. X1 and X2 either use a common SQL database
or a DTS Task kicks in to refresh the Msde/Wmsde DB of X2.
They share content area already in one of a few ways (DFS, etc.).
Issues I see are def of the DTS task so that machine / machinegroup
records from X2 get to X1 and from X1 to X2, and care if the
config info that says "I do a sync" is reflected into the DB instead of
just machine local store.

Yes I know this is outside of scope of WSUS as released and as
we tested it in the jdp. What I ask is whether there are others that
have explored such strategies that care to share info.
--
ra
 
 
 

Creative WSUS peering

Post by Lawrence G » Tue, 06 Sep 2005 08:49:50

My point was, Roger, that you'll not likely find anybody who has
"experimented" in this vein.. because the product will not even install in
that configuration.
 
 
 

Creative WSUS peering

Post by Roger Abel » Tue, 06 Sep 2005 23:50:25


Well, I hear you Lawrence, and while you are correct that the installer
does not go down this route, it is not to terrible difficult to take a
couple
installs and get them into this configuration.
--
ra
 
 
 

Creative WSUS peering

Post by Asher_ » Wed, 07 Sep 2005 01:08:15

"Roger Abell [MVP]" < XXXX@XXXXX.COM > wrote in

Roger,

Our point is that this is so far out of design scope that you are
unlikely to find anybody who has spent the time to build that kind of
redundancy for a non-mission critical system that can be rebuilt in a
couple of hours. Heck, I don't even back mine up because of that.
 
 
 

Creative WSUS peering

Post by Lawrence G » Wed, 07 Sep 2005 01:32:28

Then.. give it a shot.... let us know how it works out.
 
 
 

Creative WSUS peering

Post by Roger Abel » Fri, 09 Sep 2005 18:20:13

Asher,
Simplicity of reinstall is not the point, but rather simplicity of
having fully redundant peers is.
Roger
 
 
 

Creative WSUS peering

Post by Asher_ » Fri, 09 Sep 2005 21:34:40


@TK2MSFTNGP12.phx.gbl:
Roger,

And this will be my last post on this subject.

Simplicity of recovery and level of mission criticality is what usually
determines need for redundancy. WSUS rates very high on the former and
very low on the latter, so that's why redundancy was never designed into
it. But, as Lawrence said, if you want to waste time trying it, knock
your socks off.






difficult
 
 
 

Creative WSUS peering

Post by UGF0cmlja » Sat, 10 Sep 2005 01:17:02

I'm with Asher and Lawrence. I've been troubleshooting other areas of
problems with WSUS and see no point in spending valuable energy and resources
"setting up redundancy" on a system that takes less then an hour to set back
up. Setting up another WSUS only involves creating the groups you have set
in the GPO for server side targetting and then approving any updates that
have been put out since the last time the WSUS was working. This is super
easy by just clicking on the link to the computers needing updates and then
approving the ones you need. No need to approve all the updates that are
already installed on the systems from the last working WSUS. Therefore, you
can see the puzzlement in working on something that is absolutely a waste of
time, especially when there are other IT projects that are a higher priorty
to work on.

Patrick
 
 
 

Creative WSUS peering

Post by Lawrence G » Sat, 10 Sep 2005 08:19:10

Asher's point, and I concur fully, is that one has to apply a certain amount
of cost-effectiveness thought to the issue of investing hardware, software,
and administration time into redundant systems -- assuming that the
application even supports redundancy. WSUS does not, nor is there really any
reason for it to do so.

When the amount of time necessary to /rebuild/ a system is less than the
amount of time necessary to /maintain/ a redundant system, one does not
choose to build and maintain the redundant system. When the amount of time
necessary to /rebuild/ a system is less than the amount of time to /restore/
a system, one does not choose to make backups.

Having said that.... A monthly backup of the System State, %PROGRAMFILES%
folder, and \WSUS\MSSQL$WSUS\Data\SUSDB* files following the approvals
process can be restored on a *** Windows Server in about 15 minutes after
a new OS is installed. The content is already backed up... it's called
microsoft.com -- except for those organizations who pay a premium for
Internet bandwidth. For them, I would suggest investing in a DVD-RAM unit
and burning the content library to DVD on a regular basis.

If you're going to go the DVD-RAM route....A monthly Ghost image can be
restored on a blank hard drive in about 30 minutes.

Since the data only changes monthly, the idea of 'redundancy' is not really
appropriate in this application.

Truth is.. I'm not backing up my WSUS server either. I can reinstall,
reconfigure, /and/ resynchronize the whole machine in a few hours. Since the
odds of losing the server when its absolutely needed is less than 1 in 30,
and even then a four to six hour delay will be insignificant in terms of
patching clients -- most clients won't even get patched for 18-36 hours
after you approve the updates for installation.
 
 
 

Creative WSUS peering

Post by Roger Abel » Sun, 11 Sep 2005 19:25:32

hatever
but you guys seem to have tunnel vision here
If I were running it I would have no problem seeing your point.
The scenario is a 2 dc forest where they have no other servers
and no skilled support - but need full continuity for potentially
lengthy periods after loss of one dc before skill can get there
to get them whole again.

"Patrick" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

Creative WSUS peering

Post by Roger Abel » Sun, 11 Sep 2005 19:28:39

have been running production environments for decades, thank you
though for the thoughts on methodology.
The single config of the pair of WSUS and unified set of records is
a feature your comments do not seem to see as part of the objective.
--
ra

"Lawrence Garvin" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

Creative WSUS peering

Post by Lawrence G » Mon, 12 Sep 2005 02:39:12

erhaps we do have tunnel vision. Perhaps our scope of vision is irrelevant.

Perhaps..... you've now shared a /unique/ circumstace that shades the story
a bit, so to fault our vision when you're arguing a very specific scenario
without sharing the details really doesn't seem fair to me.

However, even in a 2DC forest with no other servers and no skilled
support -- which... btw.... probably describes about a THIRD of the WSUS
implementations (another THIRD probably only has 1 DC!!)..... the last thing
that organization needs is the complexity and overhead of trying to cope
with NLB or failover redundancy in something that's not mission critical.

If those 2 DC are already configured as NLB pairs... I'd give consideration
to removing the NLB -- but that's just my perspective. I surely would not
introduce NLB in a 2DC scenario.

Furthemore, any organization that can function off of 2DCs, with all other
functionality residing /on/ those two DCs, probably does not /need/ any
failover redundancy in WSUS! If the DC of that pair housing WSUS fails, the
machine will have to be rebuilt anyway.

The time frame for that restoration is likely to be measured in hours due to
the criticality of the machine (as I'm sure it's running other functions
than just DC/DNS/WSUS), and not having WSUS for those few-to-several hours
will be a non-event.

Hopefully it's being rebuilt from a /full/ system backup -- when the machine
is restored, so is WSUS. In this case, the time to restore may well be less
than the time to rebuild from scratch, because I'm sure WSUS will be one of
the last applications to be reinstalled on such a server in a
rebuild-from-scratch scenario.

I stand by my point.... redundancy and failover in WSUS is an inappropriate
use of both physical and human resources.

"Roger Abell [MVP]" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...