Clients registered on two WSUS simultaneously - side effects?

WSUS v3 SP2

External (roaming but corporate AD clients) 2000
Internal (AD) 500

To save corporate internet bandwidth I'm using a two WSUS servers, one for
external clients (WSUS1) as they need to download their content from
update.microsoft.com and one for internal clients (WSUS2) emanating downloads
from its own repository. Two are required as unfortunately this WSUS setting
is per WSUS server only.

I don't really want to identify (read maintain) which clients can roam and
which do not and apply different target URLs, but would rather apply the same
GPO (target address).

If I did ident them there are pros and cons:

Pros:

1. Clients will not be registered on both WSUS server simultaneously.

2. Simplifies reporting

Cons:

1. Have to identify and maintain a list of computer accounts by either OU
or Security group such to target different URLs

2. When the roaming 2000 return (unlikely to be simultaneously I know) they
will consume significant corporate internet BW even when in the office.


So, having one target URL I can use split DNS and an external DNS name
(update.ourdomain.com).

Clients that roam will receive an internal IP pointing to WSUS1, and when
roaming an external IP pointing through various FWs to WSUS2 .

However, the same client will be registered on two WSUS server
simultaneously (for a while, or if they keep swapping between int and ext
within the 30day WSUS client clean up time).

I've tested this and whilst everything seems to function OK the only
downside I've spotted so far is reporting. It would be 'nice' to simply run
a report from both servers but of course now I need to check dates to
determine where the client connected to last.

AND, are there any further nasties waiting for me?

Many thanks
Lea

LeaUK schrieb:
[..]
> However, the same client will be registered on two WSUS server
> simultaneously (for a while, or if they keep swapping between int and ext
> within the 30day WSUS client clean up time).
>
> I've tested this and whilst everything seems to function OK the only
> downside I've spotted so far is reporting. It would be 'nice' to simply run
> a report from both servers but of course now I need to check dates to
> determine where the client connected to last.
[...]

Just make one of the servers a slave to the other. Then the master will
always have a complete list.

I have a quite similar setup (but much less clients) and this works just
fine.

Just my 2cc, Wolfgang

--
Only a fool fights in a burning house.
-- Kank the Klingon, "Day of the Dove", stardate unknown

"Lawrence Garvin [MVP]" wrote:

> "LeaUK" <> wrote in message
> news:BC2EAF1C-07A2-4B30-88EF-...
> > WSUS v3 SP2
> >
> > External (roaming but corporate AD clients) 2000
> > Internal (AD) 500
> >
> > To save corporate internet bandwidth I'm using a two WSUS servers, one for
> > external clients (WSUS1) as they need to download their content from
> > update.microsoft.com and one for internal clients (WSUS2) emanating
> > downloads
> > from its own repository. Two are required as unfortunately this WSUS
> > setting
> > is per WSUS server only.
> >
> > I don't really want to identify (read maintain) which clients can roam and
> > which do not and apply different target URLs, but would rather apply the
> > same
> > GPO (target address).
>
> Lea, I would presume that these systems are already "identified" within your
> Active Directory heirarchy by either Organizational Unit or some security
> group memberships. Consider leveraging the information you already have. If
> the roaming clients are already in an isolated OU, then you need only apply
> a GPO to that OU and successfully point the roaming clients to their
> dedicated server.
>
> If your AD heirarchy does not make this distinction -- perhaps it should.
> :-)

Agreed, but it currently doesn't Hence I could distinguish the
difference by security group, but I don't want yet another list of clients
our Help Desk have to maintain, so a solution which does not require this
would be appreciated by those potentially maintaining ;-)
>
>
>
> > However, the same client will be registered on two WSUS server
> > simultaneously (for a while, or if they keep swapping between int and ext
> > within the 30day WSUS client clean up time).
>
> Actually this is less of an issue than you might think it would be. If the
> DMZ server is a replica of the upstream server

Yes it is

> and the client is reporting
> with the same SusClientID,

Yep it will be

>and you're using Reporting Rollup to have the DMZ
> (replica) server's status information posted to the upstream server, the
> upstream server will retain the most recent data from each SusClientID.

Ooooh, what's reporting rollup - this could be absolutely key!

These servers cannot be upstream / downstream (I don't think) as one has
'store updates locally on this server' the other 'do not store updates
locally, download from Microsoft…' - but perhaps the reporting can be linked?



As you can appreciate the problem I with reporting being separated is that
clients may be last seen on either server and therefore it's thrown of a
little, meaning who ever is reviewing the reports ends up having to compare
the two.


> either way, all of your roaming clients will be listed on the upstream
> server all of the time, the only question becomes whether that status
> information came from the last connection to the replica server via the
> Internet, or came from that client's occasional connection direct to the
> upstream server.
>
>
> > I've tested this and whilst everything seems to function OK the only
> > downside I've spotted so far is reporting. It would be 'nice' to simply
> > run
> > a report from both servers but of course now I need to check dates to
> > determine where the client connected to last.
>
> Reporting Rollup should be the solution to this situation.
>
>
> > AND, are there any further nasties waiting for me?
>
> Not that I can think of.
>


Phew - that's some good news at least

Thanks Lawrence.


>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2010)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"Wolfgang Steger" wrote:

> LeaUK schrieb:
> [..]
> > However, the same client will be registered on two WSUS server
> > simultaneously (for a while, or if they keep swapping between int and ext
> > within the 30day WSUS client clean up time).
> >
> > I've tested this and whilst everything seems to function OK the only
> > downside I've spotted so far is reporting. It would be 'nice' to simply run
> > a report from both servers but of course now I need to check dates to
> > determine where the client connected to last.
> [...]
>
> Just make one of the servers a slave to the other. Then the master will
> always have a complete list.

I didn't think they could be slave/master if one was storing updates, but
the other telling clients to retrieve from MS? Is this true?


>
> I have a quite similar setup (but much less clients) and this works just
> fine.
>
> Just my 2cc, Wolfgang
>
> --
> Only a fool fights in a burning house.
> -- Kank the Klingon, "Day of the Dove", stardate unknown
> .
>

Replica mode: An upstream WSUS server shares updates, approval status, and
computer groups with its downstream server or servers. Downstream replica
servers inherit update approvals and cannot be administered apart from their
upstream WSUS server.

This is would be perfect but as I understand cant happen when updates are
local on one and microsoft on another?



"LeaUK" wrote:

> "Lawrence Garvin [MVP]" wrote:
>
> > "LeaUK" <> wrote in message
> > news:BC2EAF1C-07A2-4B30-88EF-...
> > > WSUS v3 SP2
> > >
> > > External (roaming but corporate AD clients) 2000
> > > Internal (AD) 500
> > >
> > > To save corporate internet bandwidth I'm using a two WSUS servers, one for
> > > external clients (WSUS1) as they need to download their content from
> > > update.microsoft.com and one for internal clients (WSUS2) emanating
> > > downloads
> > > from its own repository. Two are required as unfortunately this WSUS
> > > setting
> > > is per WSUS server only.
> > >
> > > I don't really want to identify (read maintain) which clients can roam and
> > > which do not and apply different target URLs, but would rather apply the
> > > same
> > > GPO (target address).
> >
> > Lea, I would presume that these systems are already "identified" within your
> > Active Directory heirarchy by either Organizational Unit or some security
> > group memberships. Consider leveraging the information you already have. If
> > the roaming clients are already in an isolated OU, then you need only apply
> > a GPO to that OU and successfully point the roaming clients to their
> > dedicated server.
> >
> > If your AD heirarchy does not make this distinction -- perhaps it should.
> > :-)
>
> Agreed, but it currently doesn't Hence I could distinguish the
> difference by security group, but I don't want yet another list of clients
> our Help Desk have to maintain, so a solution which does not require this
> would be appreciated by those potentially maintaining ;-)
> >
> >
> >
> > > However, the same client will be registered on two WSUS server
> > > simultaneously (for a while, or if they keep swapping between int and ext
> > > within the 30day WSUS client clean up time).
> >
> > Actually this is less of an issue than you might think it would be. If the
> > DMZ server is a replica of the upstream server
>
> Yes it is
>
> > and the client is reporting
> > with the same SusClientID,
>
> Yep it will be
>
> >and you're using Reporting Rollup to have the DMZ
> > (replica) server's status information posted to the upstream server, the
> > upstream server will retain the most recent data from each SusClientID.
>
> Ooooh, what's reporting rollup - this could be absolutely key!
>
> These servers cannot be upstream / downstream (I don't think) as one has
> 'store updates locally on this server' the other 'do not store updates
> locally, download from Microsoft…' - but perhaps the reporting can be linked?
>
>
>
> As you can appreciate the problem I with reporting being separated is that
> clients may be last seen on either server and therefore it's thrown of a
> little, meaning who ever is reviewing the reports ends up having to compare
> the two.
>
>
> > either way, all of your roaming clients will be listed on the upstream
> > server all of the time, the only question becomes whether that status
> > information came from the last connection to the replica server via the
> > Internet, or came from that client's occasional connection direct to the
> > upstream server.
> >
> >
> > > I've tested this and whilst everything seems to function OK the only
> > > downside I've spotted so far is reporting. It would be 'nice' to simply
> > > run
> > > a report from both servers but of course now I need to check dates to
> > > determine where the client connected to last.
> >
> > Reporting Rollup should be the solution to this situation.
> >
> >
> > > AND, are there any further nasties waiting for me?
> >
> > Not that I can think of.
> >
>
>
> Phew - that's some good news at least
>
> Thanks Lawrence.
>
>
> >
> >
> > --
> > Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
> > Principal/CTO, Onsite Technology Solutions, Houston, Texas
> > Microsoft MVP - Software Distribution (2005-2010)
> >
> > My Blog: http://onsitechsolutions.spaces.live.com
> > Microsoft WSUS Website: http://www.microsoft.com/wsus
> > My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
> >
>

LeaUK schrieb:
>
[...]
>
> I didn't think they could be slave/master if one was storing updates, but
> the other telling clients to retrieve from MS? Is this true?
>

For me both possible situations work(ed) fine. One WSUS telling the
clients to fetch from MS and two telling clients to fetch from WSUS.

Now the first one is the master and the other two are slaves, but for a
long time I had them running the other way 'round, one of the "storing"
WSUS was master and the other "storing" one and the "direct-fechting"
one as slaves.

Although I would prefer if a single WSUS server could serve both clients
fetching from MS *and* clients fetching from WSUS (client policy
deciding where to fetch from) - I could save on WSUS server then.

Just my 2cc, Wolfgang

--
"Logic and practical information do not seem to apply here."
"You admit that?"
"To deny the facts would be illogical, Doctor"
-- Spock and McCoy, "A Piece of the Action", stardate unknown

"LeaUK" <> wrote in message
news:FEE712A7-A64D-4395-A442-...

> I didn't think they could be slave/master if one was storing updates, but
> the other telling clients to retrieve from MS? Is this true?

This depends. It's one of the feature enhancements to WSUS v3.
So for those still using WSUS v2, then a replica server is somewhat
constrained in how it can be configured.

However, as of WSUS v3, the option to maintain a content store, or not, is
independent of the status of the server as master/replica.

In addition, the option to download content from the upstream server or
microsoft.com is also independent of the status of the server as
master/replica.

And all *three* options (local content store, download from Microsoft,
autonomous/replica) can be configured on demand from the Options page of the
console.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

On Tue, 23 Mar 2010 22:54:19 +0100, Wolfgang Steger
<wolfgangs-> wrote:

>LeaUK schrieb:
>>
>[...]
>>
>> I didn't think they could be slave/master if one was storing updates, but
>> the other telling clients to retrieve from MS? Is this true?
>>
>
>For me both possible situations work(ed) fine. One WSUS telling the
>clients to fetch from MS and two telling clients to fetch from WSUS.
>
>Now the first one is the master and the other two are slaves, but for a
>long time I had them running the other way 'round, one of the "storing"
>WSUS was master and the other "storing" one and the "direct-fechting"
>one as slaves.
>
>Although I would prefer if a single WSUS server could serve both clients
>fetching from MS *and* clients fetching from WSUS (client policy
>deciding where to fetch from) - I could save on WSUS server then.

On this I would also like to see a fallback configuration where if the client
cannot contact the WSUS server to complete a download it would automatically try
the MS Server after a timeout period. One day say. Thus it could download
approvals from the local server and if then removed from the network would
continue to get content from the MS server for outstanding approved updates.

Added to "Always get content from the MS Server" there would be 3 possibilities.

Get content from WSUS server
Use MS server as fallback
Use MS server as primary download source.

>
>Just my 2cc, Wolfgang
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

"Lawrence Garvin [MVP]" wrote:

> "LeaUK" <> wrote in message
> news:FEE712A7-A64D-4395-A442-...
>
> > I didn't think they could be slave/master if one was storing updates, but
> > the other telling clients to retrieve from MS? Is this true?
>
> This depends. It's one of the feature enhancements to WSUS v3.
> So for those still using WSUS v2, then a replica server is somewhat
> constrained in how it can be configured.
>
> However, as of WSUS v3, the option to maintain a content store, or not, is
> independent of the status of the server as master/replica.
>
> In addition, the option to download content from the upstream server or
> microsoft.com is also independent of the status of the server as
> master/replica.
>
> And all *three* options (local content store, download from Microsoft,
> autonomous/replica) can be configured on demand from the Options page of the
> console.

I think you have made my day The answer then is yes; when using v3 I can
use Replica mode even though master and slave deliver content from itself or
Microsoft?

>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2010)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"Wolfgang Steger" wrote:

> LeaUK schrieb:
> >
> [...]
> >
> > I didn't think they could be slave/master if one was storing updates, but
> > the other telling clients to retrieve from MS? Is this true?
> >
>
> For me both possible situations work(ed) fine. One WSUS telling the
> clients to fetch from MS and two telling clients to fetch from WSUS.
>
> Now the first one is the master and the other two are slaves, but for a
> long time I had them running the other way 'round, one of the "storing"
> WSUS was master and the other "storing" one and the "direct-fechting"
> one as slaves.

Another confirmation - you should see the smile on my face

I will elect the one storing the updates as the Master and enable Replica
mode thus allowing all admin actions to be carried out on one server. The
only reason for two is for difference in retrieval config.

>
> Although I would prefer if a single WSUS server could serve both clients
> fetching from MS *and* clients fetching from WSUS (client policy
> deciding where to fetch from) - I could save on WSUS server then.
>
> Just my 2cc, Wolfgang
>
> --
> "Logic and practical information do not seem to apply here."
> "You admit that?"
> "To deny the facts would be illogical, Doctor"
> -- Spock and McCoy, "A Piece of the Action", stardate unknown
> .
>