Re: WSUS for more than 30000 clients

"Tommy" <> wrote in message
news:65904f8d-e7b7-4bd4-bffe-...
> What would be a good configuration to support more than 30000 (or even
> 60000) clients under the following limitations

> 1.) All Clients point to the same hostname (i.e., http://wsus)
> and
> 2.) There is no Active Directory
> and
> 3.) Don't have Windows CAL or SQL CAL for each windows client.

Well.. the same hostname is really a non issue. DNS (although it begs the
question of how you're going to implement DNS) can help with this.

The lack of Active Directory is a slightly more concerning issue... and I
really must ask how you're managing an environment of 30,000 systems in
=2009= without using Active Directory. More importantly, it's probably
useful to know =Why?= you're not using Active Directory, as those reasons
(and I'm sure they're valid) will affect how you design a WSUS deployment
for an organization that large. The primary limitation with not having
Active Directory is that you cannot use a back-end database server; you're
limited to running the database server on the WSUS server(s) -- but this may
not be a major issue, as we'll soon see.

Not having Windows CALs is a show-stopper. You *must* have a Windows CAL to
use WSUS. It's a licensing requirement.

Not having SQL CALs is not a show-stopper, but it also prevent the use of a
back-end SQL Server (of course, without Active Directory, this is really a
non-issue) -- which subsequently restricts the number of clients you can
support per WSUS server -- which is directly related to the hardware
resources available on the server.


> I read somewhere that a school was able to support 65000 clients with
> only a couple of 2 frontend to 1 backend servers using the NLB/SQL
> cluster deployment guide as documented by MS.

This is absolutely possible.

> If that's possible, is there a way to avoid the SQL clusters?

The SQL clusters are an optional configuration that faciliate managing that
number of clients from one WSUS "server" (actually a 2-node NLB front-end).
However, NLB requires a back-end SQL Server (which will require SQL CALs).

> I'm wondering what others are doing with large deployments of WSUS
> clients.

Writing checks for the appropriate licensing of the required server
software. :-)


Okay, let's talk about the Hardware Requirements for WSUS. From the WSUS v3
Deployment Guide (which was originally authored in 2005, and updated in 2007
to reflect the estimated/extrapolated/expected improvements in performance
by using a SQL2005-based engine (Windows Internal Database) instead of the
SQL2000-based WMSDE engine.

In 2007, the WSUS team estimated that a single-core, hyperthreaded 3GHz
64-bit CPU with 2GB RAM was capable of supporting up to 20,000 clients; and
a dual-socket, single-core, hyperthreaded 3GHz 64-bit CPU with 4GB RAM was
capable of supporting up to 10,000 clients. These configurations are not
apples-to-apples, though (as I've recently become aware), and another
footnoted factor is included in these calculations, based on the detection
interval of the assigned clients.

Of course, there was no empirical data to support any of this at the time
the Deployment Guide was written; it was, in some part (as previously
noted), extrapolated from the expected increase in performance by using the
Windows Internal Database in place of WMSDE.

Note also that unlike WSUS v2, the Deployment Guide makes no distinction
between what environments can use the native internal database engine and
what environments require an actual SQL Server installation. The WSUS
instance of the Windows Internal Database has no throttling (unlike SQL
Server 2005 Express Edition); however, the WID is only available in 32-bit
distributions. On a 64-bit server it runs in WoW -- which is *not* an
optimal deployment for a server designed to support 30,000 clients.

Another *possible* option is using SQL Server 2008 Expres Edition 64-bit,
which is a native 64-bit database engine -- but it has throttling
limitations you need to be aware of, which will also limit the number of
clients that can be supported in such a scenario. Also, SQL Server 2008 is
not a supported database engine at this time.

There's another factor to be considered here also, which I mentioned
earlier. The single-core 20,000 client solution was written with the
assumption that clients were detecting every eight hours. That's 20,000/8 =
2500 clients per hour. Rolling that detection interval back to the default
of 22 hours, means that the same configuration should be able to easily
support 2500 x 22 = 55,000 clients, and quite possibly to your suggested
objective of 60,000 -- maybe even by merely throwing some more RAM at the
machine and using a dual-core CPU. (Can you even by a single-core server
anymore???)

The dual-CPU 10,000 client solution was written with the assumption that
clients are synchronizing every TWO hours (an absolutely *pointless*
configuration IMNSHO), but that's the equivalent of 5,000 clients per
hour -- so consider increasing that to detections every 8 hours, and you can
easily add 4x the number of clients to that dual-CPU 4GB machine --
potentially as many as 20,000 clients, just by using the documented hardware
configuration and modifying the detection frequency to maintain the same
relative client load. Drop that to every 12 hours, and you've easily hit
60,000 clients at the same relative load; go all the way to the default 22
hour detection and you've hit 110,000 clients.

Now, the other "unwritten" consideration is the comparison of hardware
resources available today, compared to hardware resources considered in the
2007 writing of the Deployment Guide. Consider the difference between a
dual-socket, single-core, hyperthreaded 3GHz machine with 4GB RAM (about the
top end that was available a few years ago), to a quad-socket, dual-core,
3GHz machine with 16GB RAM -- easily available today (if you write a big
enough check).

You can use your own imagination of what kind of load differentials you
might find between those two machines. The former, mathematically
extrapolated to support 60k clients with some reasonable modifications in
the WUAgent configuration; and the latter with 4x the available RAM and 4x
the number of CPU cores.

So -- to the question: Can a single WSUS server support 60,000 clients? My
answer would be almost certainly using today's available server
configurations, a properly configured multi-spindle drive array, and a
64-bit installation of SQL Server 2005 Standard Edition -- you might even be
able to do double that!

However.. do you *want* to put that many clients in the hands of a single
server? When we start talking about maintaining updates for tens of
thousands of clients, never mind 100,000+, we really need to be thinking
about fault tolerance. Using a two-node NLB cluster with a two-node
Active/Passive SQL cluster brings a level of reliability and security to the
continued deployment of updates in the environment.

Also, something beyond the scope of this little essay, is the *time*
required to actually *deploy* updates to that many clients. If you're
rotating deployments to 100,000 clients around a three-week cycle, you
really cannot afford your only WSUS server to be offline for two or three
days while you restore from a catastrophic failure.


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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

"Tommy" <> wrote in message
news:73cb8d6c-4b8f-456a-923e-...

> Not having Windows CALs is a show-stopper. You *must* have a Windows CAL
> to
> use WSUS. It's a licensing requirement.

As far as licensing goes for Windows, the Web Server edition doesn't
require it.

Correct, but be aware of the system limitations of using Web Server edition.
Because of those limitations, the actual number of clients you can support
on a Web Edition server are significantly lower than those discussed in the
Deployment Guide (which assumes a Standard Edition server - or Ent Edition
for > 4GB scenarios).


> However, I couldn't find a clear answer if the Upstream server (which
> would be a Standard edition) that has the sql database would require
> it.
>
> And as for the SQL license, the per processor license would be the way
> to go.

Correct, on the per-CPU SQL Server licensing; however, you'll want to double
check the possible requirement for Windows CALs. While Windows CALs may not
be required for your Web Edition replica servers, they likely are required
for access (even though it's indirect) to the Upstream Standard Edition
server or the installed SQL Server database service (under the same logic
that would require SQL CALs if you weren't using a per-CPU licensing model).


> The only CAL it needs are the number of front end (or downstream
> servers it supports).

This is an incorrect assumption, and gets many organizations "in trouble"
when planning for the use of SQL Server in a WSUS environment. =ALL= clients
of a WSUS environment are required to have a Windows CAL. The exception, as
you note, is when a Web Edition server is being used -- however, that
exception only applies when the Web Edition is configured as a
single-server/stand-alone installation. The implementation of a back-end
database server, or an upstream Standard Edition server, ramps that Windows
CAL requirement back on the table, as ANY client accessing any Windows
Server (other than Web Edition) is required to have a Windows CAL.


> Thanks you for this information, I believe this is the best way to
> leverage the number of server versus the number of clients to support.
> I think 22 hours should be good enough for laptops and desktops.

It's a *rare* environment, indeed, that can actually justify client
detections more frequent than once per day. The fact that they *can* do them
more frequently should not be confused with the question of whether they
*need* them more frequently.


> Getting a kick ass hardware is not a major issue for me, its when when
> we write checks for MS (for possibly more than $1M) that bothers me.

<sigh>... a reality that continues to mislead organizations the world over.
HARDWARE costs are rarely more than 20% of the Total Implementation Costs of
any technology solution -- and organizations that base their budgeting or
decision making based on hardware costs are setting themselves up for big
surprises down the road -- including, if you'll forgive me, the misguided
attitude that it's okay to write big checks for hardware, and not write big
checks for software licensing and/or training on how to use that software!

You have a unique scenario in that you don't already have Windows CALs in
place (as do most Windows-based environments) -- and avoiding writing a
check to Microsoft may require that you deploy multiple WSUS Servers
exclusively on Web Edition systems -- which for 60k clients would take a
couple dozen servers.

Compare *that* cost to the cost of the *best* solution for your
organization -- which we've not really discussed. Whether replica servers
are right for your organization or not, I cannot yet say. It may well be
that the *best* solution for your organization is *one* central server with
no reporting rollup at all.


> Also, something beyond the scope of this little essay, is the *time*
> required to actually *deploy* updates to that many clients. If you're
> rotating deployments to 100,000 clients around a three-week cycle, you
> really cannot afford your only WSUS server to be offline for two or three
> days while you restore from a catastrophic failure.

This is a valid recomendation that I really need to consider, although
I'm debating if given the licensing issues that you brought up, I
might just use 4 replica 64-bit Windows 2008 Web server edition (w/
4GB RAM) using its own SUSDB WID and have one upstream WIndows server
that will download all updates from MS and roll-up all clients reports.

Well.. here's something you also need to consider with 64-bit servers --
which I've already mentioned:

The WID on 64-bit servers is 32-bit only and runs in WoW64 mode -- so you'll
take a big performance hit trying to put 15k clients on a WID installation
on a 64-bit replica server with a 32-bit database engine.

Those high-end specifications were probably designed with a back-end
database server in mind (even though the Deployment Guide does not
explicitly state so).

Also, something you'll need to check with a licensing specialist about, as
noted previously -- unless the *upstream* server is also Web Edition (which
does not make it suitable for rollup of 60,000 clients under any conditions,
as rolling up 60k clients requires a 4GB RAM minimum server)... using
Standard or Enterprise Edition on the upstream server may also kick in the
Windows CAL requirement -- even though the clients are not connecting
directly to that server (for the same rationale that requires a SQL CAL with
the use of a back-end database server) -- as well may the mere presence of
SQL Server (even with per-CPU licensing).

Once you're forced into the investment in Windows CALs -- which is where
most of your licensing cost is going to accrue -- then it becomes trivial to
use Windows Server Standard Edition (which allows for more RAM) on your
replica servers (which really will be able to support 15k clients each) --
or even a single Windows Server Enterprise Edition central server,
configured to support all 60k clients.


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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

"Tommy" <> wrote in message
news:8a71d517-260d-4311-82f9-...

> This is the reason why currently I'm still on WIndows Web server
> edition to avoid Microsoft's notoriously complex licensing model

And this is exactly my point. Using Web Edition may avoid the licensing
issues for Windows CALs, when using NATIVE features of the Operating System
(e.g. IIS), but it does not guarantee avoidance of licensing issues when
installing non-OS-native applications (like SQL Server or WSUS) on that
machine.

> As I mentioned above, this is already my scenario where I run a couple
> of dozen Web Edition servers.

I'll leave it between you and your Microsoft sales rep(s) as to whether your
uses of those servers are all licensed. I'm kinda challenged to grasp that a
single organization with no other Windows Servers has a need for a dozen or
more WEB servers. :-)

My only interest here is to make sure I don't mislead you into any
assumptions about the use of Web Edition as an absolute methodology for
avoiding additional licensing costs.


What If I use the 64-bit SQL Server 2008 Express Edition?

Well, using SQL 2008 64-bit is certainly an option. But let's consider some
things here:

1. WSUS 3 is not supported on SQL Server 2008 -- any edition -- so you'd be
immediately working in a non-supported configuration.

2. SQL Server 2008 Express Edition does have physical limitations on RAM and
Database size, so even though it's 64-bit, you still have a de facto ceiling
of the number of clients that can be supported on a Windows Server 2008 Web
Edition x64 system running SQL Server 2008 Express Edition x64.

> With WSUS 3.0 SP2 just around the corner, this might be another solution.

Not really. WSUS3SP2 does not add any support for running on SQL Server
2008.
It only adds support for running on Windows Server 2008 =R2=.


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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin