Clients registered on two WSUS simultaneously - side effects?

[LeaUK]

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

[Wolfgang Steger]

LeaUK schrieb:
[..]

Post by LeaUK
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

[LeaUK]

Post by Wolfgang Steger
[..]

Post by LeaUK
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?

Post by Wolfgang Steger
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]]

Post by LeaUK
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.

[LeaUK]

Post by Lawrence Garvin [MVP]

Post by LeaUK
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?

Post by Lawrence Garvin [MVP]
--
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/profile/Lawrence.Garvin

[Wolfgang Steger]

LeaUK schrieb:
[...]

Post by LeaUK
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

[Dave Mills]

On Tue, 23 Mar 2010 22:54:19 +0100, Wolfgang Steger

Post by Wolfgang Steger
[...]

Post by LeaUK
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.

Post by Wolfgang Steger
Just my 2cc, Wolfgang

[Lawrence Garvin [MVP]]

Post by Dave Mills
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.

So.. if you had this fallback capability, and it was working . . . however
would you know your WSUS server was *not* working?

[Dave Mills]

On Wed, 24 Mar 2010 08:13:35 -0500, "Lawrence Garvin [MVP]"

Post by Lawrence Garvin [MVP]

Post by Dave Mills
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.

So.. if you had this fallback capability, and it was working . . . however
would you know your WSUS server was *not* working?

Do I care?
If I configure use WSUS I will know if it is working and this is for Desktops.
If I configure Fallback it is for Laptops and I don't care where they get the
content from.

[Lawrence Garvin [MVP]]

Post by Dave Mills

Post by Lawrence Garvin [MVP]
So.. if you had this fallback capability, and it was working . . . however
would you know your WSUS server was *not* working?

Do I care?
If I configure use WSUS I will know if it is working and this is for Desktops.
If I configure Fallback it is for Laptops and I don't care where they get the
content from.

Okay.. so why maintain a content store at all!?

Just remove the content store and have your clients download from Microsoft
100% of the time.

But I think you do care, because you do want your WSUS server to be working,
and the only way (most) people know it's not working is when they discover
it's broken (because clients are not getting updated). Ideally they'd notice
that the most recent Last Contacted Date is longer than the shorted
configured detection interval and thus the most recent LCD is no longer
valid -- which should occur long before your suggested download failover
would kick in.

If you have failover capability (and I'm not saying it's a bad thing, I'm
just exploring the true value of the option), and it kicks in (say, oh,
after a day of not being able to get the update from the WSUS server) --
how, exactly, and when, are you going to know that the WSUS server is broken
(for at least 24 hours by that point) if you don't already know that?

[LeaUK]

Post by Lawrence Garvin [MVP]

Post by Dave Mills

Post by Lawrence Garvin [MVP]
So.. if you had this fallback capability, and it was working . . . however
would you know your WSUS server was *not* working?

Do I care?
If I configure use WSUS I will know if it is working and this is for Desktops.
If I configure Fallback it is for Laptops and I don't care where they get the
content from.

Okay.. so why maintain a content store at all!?
Just remove the content store and have your clients download from Microsoft
100% of the time.
But I think you do care, because you do want your WSUS server to be working,
and the only way (most) people know it's not working is when they discover
it's broken (because clients are not getting updated). Ideally they'd notice
that the most recent Last Contacted Date is longer than the shorted
configured detection interval and thus the most recent LCD is no longer
valid -- which should occur long before your suggested download failover
would kick in.
If you have failover capability (and I'm not saying it's a bad thing, I'm
just exploring the true value of the option), and it kicks in (say, oh,
after a day of not being able to get the update from the WSUS server) --
how, exactly, and when, are you going to know that the WSUS server is broken
(for at least 24 hours by that point) if you don't already know that?

I have configured email notifications, which are superb and fit in nicely
with our 'daily activities' / read daily grind! We will check:

1. Has the email arrived?
2. The last synchronised update time

BTW - is there a database backup option somewhere? That would be useful in
case of catastrophic failure and reinstall - although it's on VM so other
backup options are available...

Post by Lawrence Garvin [MVP]
--
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/profile/Lawrence.Garvin

[Lawrence Garvin [MVP]]

Post by LeaUK
BTW - is there a database backup option somewhere? That would be useful in
case of catastrophic failure and reinstall - although it's on VM so other
backup options are available...

Database backup recommendations are documented in the WSUS Operations Guide.

NTBACKUP (or its cousin on Win2008) is probably the best tool for a
WID-based server.

For a WSUS server with SQL Server, use the internal Database Maintenance
Wizard to schedule backups.

[Dave Mills]

On Wed, 24 Mar 2010 14:36:38 -0500, "Lawrence Garvin [MVP]"

Post by Lawrence Garvin [MVP]

Post by Dave Mills

Post by Lawrence Garvin [MVP]
So.. if you had this fallback capability, and it was working . . . however
would you know your WSUS server was *not* working?

Do I care?
If I configure use WSUS I will know if it is working and this is for Desktops.
If I configure Fallback it is for Laptops and I don't care where they get the
content from.

Okay.. so why maintain a content store at all!?

One download via the WAN link instead of 100s.

Post by Lawrence Garvin [MVP]
Just remove the content store and have your clients download from Microsoft
100% of the time.
But I think you do care, because you do want your WSUS server to be working,
and the only way (most) people know it's not working is when they discover
it's broken (because clients are not getting updated). Ideally they'd notice
that the most recent Last Contacted Date is longer than the shorted
configured detection interval and thus the most recent LCD is no longer
valid -- which should occur long before your suggested download failover
would kick in.
If you have failover capability (and I'm not saying it's a bad thing, I'm
just exploring the true value of the option), and it kicks in (say, oh,
after a day of not being able to get the update from the WSUS server) --
how, exactly, and when, are you going to know that the WSUS server is broken
(for at least 24 hours by that point) if you don't already know that?

My Desktops would tell me WSUS is broken as I would not use fallback for them.
My Laptops though they have long AWOL periods and tell me nothing about the
status of WSUS. These sometime pop into the office for 6 minutes or VPN for 5 to
10 minutes. At other time they are present 7x24 for weeks. I don't want to force
them to always use MS as it increases the Internet bandwidth use when they are
"in the office". On the other hand if the connect for just a while it is enough
time to get the update list but not enough to get the content. Hence they go
AWOL again needing update content they cannot get. A Fallback would plug that
hole.

[Lawrence Garvin [MVP]]

Post by Dave Mills

Post by Lawrence Garvin [MVP]
Okay.. so why maintain a content store at all!?

One download via the WAN link instead of 100s.

So, you *would* want to know if your WSUS server was failing and causing
numerous clients to initiate "hundreds" of downloads across the WAN/Internet
links?

[Lawrence Garvin [MVP]]

Post by Dave Mills

Post by Lawrence Garvin [MVP]
If you have failover capability (and I'm not saying it's a bad thing, I'm
just exploring the true value of the option), and it kicks in (say, oh,
after a day of not being able to get the update from the WSUS server) --
how, exactly, and when, are you going to know that the WSUS server is broken
(for at least 24 hours by that point) if you don't already know that?

My Desktops would tell me WSUS is broken as I would not use fallback for them.
My Laptops though they have long AWOL periods and tell me nothing about the
status of WSUS. These sometime pop into the office for 6 minutes or VPN for 5 to
10 minutes. At other time they are present 7x24 for weeks. I don't want to force
them to always use MS as it increases the Internet bandwidth use when they are
"in the office". On the other hand if the connect for just a while it is enough
time to get the update list but not enough to get the content. Hence they go
AWOL again needing update content they cannot get. A Fallback would plug that
hole.

A second content-free server also adequately resolves this issue, combined
with appropriate site policies and/or DNS configurations.

While I don't disagree that it would be nice to have that option
configurable from the client-side, it also needs to be recognized that doing
that is a significant architectural change in WSUS, and justifying the
vendor's investment in such changes would have to be supported by
significant evidence that the existing methodology is cumbersome,
inefficient, or non-functional. Inasmuch as hundreds, if not thousands, of
organizations have happily dropped a VM-based contentLess WSUS replica
server into their DMZ to support VPN-based (or even openInternet-based
clients), makes it highly unlikely that such a feature would be considered.

One possible exception to that scenario, however, exists within the Windows
Update Agent team. A recent scenario involving mismatched URLs in the
"Specify intranet Microsoft update service location" policy, suggests that
the WUAgent might have been re-programmed to *ignore* the "statistics
server" URL. (Something that should have been done eons ago, so it would be
great if it finally has come to pass. I've not yet been able to test/verify
this behavior.) If, in fact, this is a true statement, then that opens the
door for that parameter to be re-purposed as a "fallback" URL for the
Windows Update Agent. In fact, it might could even be implemented as a
dual-mode fallback. If the value is undefined (blank), then the WUAgent
falls back to the AU servers; if the value is defined, the WUAgent falls
back to an alternate WSUS server. The only weak link here is how the WUAgent
gets the current WU download base URL. Currently that comes from the WSUS
Server, when no content exists, in lieu of the local URL of the WSUS Server
when content does exist.

The key here would be to successfully lobby the WUAgent team to implement
that functionality. The architecture of the WSUS Server still only permits
it to send a single URL for downloading content, but the WUAgent could be
coded to strip the base URL off of what is provided by the WSUS Server, and
substitute/prepend a value provided by the agent configuration -- the
responsibility for the accuracy of that URL, however, would then be borne
by the customer, currently it's established by Microsoft when an update is
published.

[LeaUK]

Post by Wolfgang Steger
[...]

Post by LeaUK
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.

Post by Wolfgang Steger
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]

Post by LeaUK
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 ;-)

Post by LeaUK
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.

Post by LeaUK
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.

Post by LeaUK
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/profile/Lawrence.Garvin

[LeaUK]

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?

Post by LeaUK

Post by LeaUK
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 ;-)

Post by LeaUK
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.

Post by LeaUK
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.

Post by LeaUK
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/profile/Lawrence.Garvin