"Leythos" <void@nowhere.lan> wrote in message
news:MPG.2113c25bdf4c48db98984e@adfree.Usenet.com. ..

> In article <C2303C6C-D54B-4B66-AB9F-08B4A4202F31@microsoft.com>,
> Mike.Brannigan@localhost says...

>> So in short Microsoft is unlikely to make available anything other then
>> the
>> public facing DNS name for their services.
>> Maybe you should look at alternative approaches to this.
>> Consider if you direct your clients to use an internal DNS server that is
>> configured to only forward for name resolution (conditional forwarding)
>> only
>> names that meet certain criteria such as *.microsoft.com and your other
>> white listed sites. This would allow only those sites to be then
>> resolved
>> by the DNS servers that you choose to use externally and thus accesses.
>> I realize this does not prevent a direct access if someone knows an IP
>> address to type into a URL but it is a start while you look at
>> alternative
>> strategies.
>> If you use a proxy server at the edge of your network you will be able to
>> log all access to URLs with in IP address in it and then take appropriate
>> action against that member of staff etc..

>
> Mike, Steve,
>
> And there lies the problem for security. We already see the rejected
> connections and their names and even the full file path/name, and yes,
> it's easy to add them into the approved list.
>
> This should be a problem for all users I would think. Where they block
> the downloading of code by their users, completely, but want to allow MS
> Updates to the servers and workstations. In the case of the firewalls we
> have used, most of them on the market, there is no simple means to white
> list your update sites as they keep changing. Yes, we could install a
> proxy server, but that really seems like a waste when the only place we
> have a problem with is MS.
>
> I understand your reasons, but it's a catch 22, move your stuff around
> to limit your exposure or force customers to either purchase more
> hardware or to allow code to be downloaded from unknown sites.
>
> I'll stick with watching for the Windows Update failures in the logs and
> manually adding the networks as needed - at least this way our networks
> remain secure.
>
> --
>
> Leythos

You have highlighted your own biggest problem here - "but want to allow MS
Updates to the servers and workstations." - ABSOLUTELY NOT.
NO never ever ever in a production corporate environment do you allow ANY of
your workstations and servers to directly access anyone for patches or
updates
I have never allowed this or even seen it in real large or enterprise
customers. (the only place it may crop up is in mom and pop 10 PCs and a
Server shops).
If you want to patch your systems you do so in a properly controlled manner
using the appropriate centrally managed distribution tools - such as WSUS
for small medium and System Center Configuration Manager 2007 or similar
products from other vendors.
You download the patches etc or allow your WSUS or similar product to
download them from the vendor - you then regression test them for your
environment (hardware and software etc) then you approve them for deployment
and deploy to the servers and workstations form inside your secure corporate
network. Now it is not a problem to let that one server do its downloads
from the vendors (this is just the same as you would do for anti virus
updates - you download them to an internal distribution server etc).

As you said your only problem is with Microsoft then the solution I have
outlined above is the fix - only one server needs access through your
draconian firewall policies. And you get a real secure enterprise patch
management solution that significantly lowers the risk to your environment.
With the best will in the world if you are letting servers auto update all
patches from Microsoft without any degree of regression testing you have way
bigger problems then worrying about your firewall rules.

If you stick to watching for failures and manually updating rules you are
wasting your time, providing a poor service and getting paid for doing
something that there is no need to do.
--

Mike Brannigan
"Leythos" <void@nowhere.lan> wrote in message
news:MPG.2113c25bdf4c48db98984e@adfree.Usenet.com. ..

> In article <C2303C6C-D54B-4B66-AB9F-08B4A4202F31@microsoft.com>,
> Mike.Brannigan@localhost says...

>> So in short Microsoft is unlikely to make available anything other then
>> the
>> public facing DNS name for their services.
>> Maybe you should look at alternative approaches to this.
>> Consider if you direct your clients to use an internal DNS server that is
>> configured to only forward for name resolution (conditional forwarding)
>> only
>> names that meet certain criteria such as *.microsoft.com and your other
>> white listed sites. This would allow only those sites to be then
>> resolved
>> by the DNS servers that you choose to use externally and thus accesses.
>> I realize this does not prevent a direct access if someone knows an IP
>> address to type into a URL but it is a start while you look at
>> alternative
>> strategies.
>> If you use a proxy server at the edge of your network you will be able to
>> log all access to URLs with in IP address in it and then take appropriate
>> action against that member of staff etc..

>
> Mike, Steve,
>
> And there lies the problem for security. We already see the rejected
> connections and their names and even the full file path/name, and yes,
> it's easy to add them into the approved list.
>
> This should be a problem for all users I would think. Where they block
> the downloading of code by their users, completely, but want to allow MS
> Updates to the servers and workstations. In the case of the firewalls we
> have used, most of them on the market, there is no simple means to white
> list your update sites as they keep changing. Yes, we could install a
> proxy server, but that really seems like a waste when the only place we
> have a problem with is MS.
>
> I understand your reasons, but it's a catch 22, move your stuff around
> to limit your exposure or force customers to either purchase more
> hardware or to allow code to be downloaded from unknown sites.
>
> I'll stick with watching for the Windows Update failures in the logs and
> manually adding the networks as needed - at least this way our networks
> remain secure.
>
> --
>
> Leythos
> - Igitur qui desiderat pacem, praeparet bellum.
> - Calling an illegal alien an "undocumented worker" is like calling a
> drug dealer an "unlicensed pharmacist"
> spam999free@rrohio.com (remove 999 for proper email address)

In message <MPG.2112eef792c3b8c4989844@adfree.Usenet.com> Leythos
<void@nowhere.lan> wrote:

>As for WSUS - we still need to know what the update sites are, we don't
>even allow the servers to get updates unless it's an approved
>subnet/network.

The suggestion would be to run WSUS outside your firewall, as though it
were your own personal Windows Update server on an IP you'd know and
trust for your internal clients to update.

(Obviously the WSUS server shouldn't be completely unprotected, but it
doesn't need to live within your LAN and have unrestricted internet
access at the same time)

--
If quitters never win, and winners never quit,
what fool came up with, "Quit while you're ahead"?

In article <3s1ka3demsq7roarrb5g1dglqlnob5fovn@4ax.com>,
spam_narf_spam@crazyhat.net says...

> In message <MPG.2112eef792c3b8c4989844@adfree.Usenet.com> Leythos
> <void@nowhere.lan> wrote:
>

> >As for WSUS - we still need to know what the update sites are, we don't
> >even allow the servers to get updates unless it's an approved
> >subnet/network.

>
> The suggestion would be to run WSUS outside your firewall, as though it
> were your own personal Windows Update server on an IP you'd know and
> trust for your internal clients to update.
>
> (Obviously the WSUS server shouldn't be completely unprotected, but it
> doesn't need to live within your LAN and have unrestricted internet
> access at the same time)

Yep, and we could do that, even inside the LAN and allow exceptions for
it. In the case of most of our clients, with a very few exceptions, even
locations with several hundred nodes in the lan, we've never had a
problem allowing the workstations to auto download/install the windows
updates, not since it was available. On certain machines we select to
download and then manually install, but for the masses of clients
machines we just allow them to auto-update and have never had any
problems with that method. Servers, manual only.

About half our clients are under 100 nodes on the lan, they most often
have one or two two servers and we could install WSUS on one or the
single server, but the servers are very stable and adding another
component to them might not provide the same stability - so, it's still
a catch-22, but WSUS might just be the only real way around this.

Thanks

--

Leythos
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

In article <56789F44-352D-4AD6-A2CB-F590FB624EB6@microsoft.com>,
Mike.Brannigan@localhost says...

> You have highlighted your own biggest problem here - "but want to allow MS
> Updates to the servers and workstations." - ABSOLUTELY NOT.
> NO never ever ever in a production corporate environment do you allow ANY of
> your workstations and servers to directly access anyone for patches or
> updates

I should have been clearer on the servers, sorry - we download but
manually install on all servers and on specific function workstations.

In all this time we've never had a problem with automatic install on the
workstations (and we have specific machines that we manually install on)
in the production environment.

So, the idea of not allowing automatic updates to most workstations has
never been a problem.

The real problem is that even if we set them to manual, that the could
not get the updates unless we enter exceptions in the firewall for the
MS Update sites. This is what I experienced with another install of
Vista, 29 updates and not a single one was from the same list of ranges
that we get the XP/Office/Server updates from... So, even manual install
fails in that case.

Based on another post I guess I'm going to have to install WSUS and just
allow all exe/cab/code files to be pulled in HTTP sessions to that
server.

--

Leythos
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

In message <MPG.2113d9776ab5f488989851@adfree.Usenet.com> Leythos
<void@nowhere.lan> wrote:

>About half our clients are under 100 nodes on the lan, they most often
>have one or two two servers and we could install WSUS on one or the
>single server, but the servers are very stable and adding another
>component to them might not provide the same stability - so, it's still
>a catch-22, but WSUS might just be the only real way around this.

Either that, or use hostnames rather then IPs in your firewalling...

--
If quitters never win, and winners never quit,
what fool came up with, "Quit while you're ahead"?

In article <rg4ka3h2om69d2nfhrhv5eo8hfb4s16shk@4ax.com>,
spam_narf_spam@crazyhat.net says...

> In message <MPG.2113d9776ab5f488989851@adfree.Usenet.com> Leythos
> <void@nowhere.lan> wrote:
>

> >About half our clients are under 100 nodes on the lan, they most often
> >have one or two two servers and we could install WSUS on one or the
> >single server, but the servers are very stable and adding another
> >component to them might not provide the same stability - so, it's still
> >a catch-22, but WSUS might just be the only real way around this.

>
> Either that, or use hostnames rather then IPs in your firewalling...

I wish I could, the firewalls covert names to IP for that function.

--

Leythos
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

On Fri, 27 Jul 2007 15:13:52 +0100, "Mike Brannigan"

>"Leythos" <void@nowhere.lan> wrote in message

>> Mike.Brannigan@localhost says...

This thread is about the collision between...

No automatic code base changes allowed

....and...

Vendors need to push "code of the day"

Given the only reason we allow vendors to push "code of the day" is
because their existing code fails too often for us to manage manually,
one wonders if our trust in these vendors is well-placed.

A big part of this is knowing that only the vendor is pushing the
code, and that's hard to be sure of. If malware were to hijack a
vendor's update pipe, it could blow black code into the core of
systems, right pas all those system's defenses.

With that in mind, I've switched from wishing MS would use open
standards for patch transmission to being grateful for whatever they
can do to harden the process. I'd still rather not have to leave
myself open to injections of "code of the day", though.

>NO never ever ever in a production corporate environment do you allow ANY of
>your workstations and servers to directly access anyone for patches
>I have never allowed this or even seen it in real large or enterprise
>customers. (the only place it may crop up is in mom and pop
>10 PCs and a Server shops).

And there's the problem. MS concentrates on scaling up to enterprise
needs, where the enterprise should consolodate patches in one location
and then drive these into systems under their own in-house control.

So scaling up is well catered for.

But what about scaling down?

Do "mom and pop" folks not deserve safety? How about single-PC users
which have everything they own tied up in that one vulnerable box?
What's best-practice for them - "trust me, I'm a software vendor"?

How about scaling outwards?

When every single vendor wants to be able to push "updates" into your
PC, even for things as trivial as prinyers and mouse drivers, how do
you manage these? How do you manage 50 different ad-hoc update
delivery systems, some from vendors who are not much beyond "Mom and
Pop" status themselves? Do we let Zango etc. "update" themselves?

The bottom line: "Ship now, patch later" is an unworkable model.

>As you said your only problem is with Microsoft then the solution I have
>outlined above is the fix - only one server needs access through your
>draconian firewall policies. And you get a real secure enterprise patch
>management solution that significantly lowers the risk to your environment.

That's prolly the best solution, for those with the resources to
manage it. It does create a lock-in advantage for MS, but at least it
is one that is value-based (i.e. the positive value of a
well-developed enterprise-ready management system).

However, I have to wonder how effective in-house patch evaluation
really is, especially if it is to keep up with tight time-to-exploit
cycles. It may be the closed-source equivalent of the open source
boast that "our code is validated by a thousand reviewers"; looks good
on paper, but is it really effective in practice?

>--------------- ----- ---- --- -- - - -

To one who has never seen a hammer,
nothing looks like a nail

>--------------- ----- ---- --- -- - - -

In line below

--

Mike Brannigan
"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
message newsas0b3pgjqdp3cb1vrrr6mb405jq3nen3r@4ax.com...

> On Fri, 27 Jul 2007 15:13:52 +0100, "Mike Brannigan"

>>"Leythos" <void@nowhere.lan> wrote in message

>>> Mike.Brannigan@localhost says...

>
> This thread is about the collision between...
>
> No automatic code base changes allowed
>
> ...and...
>
> Vendors need to push "code of the day"
>
> Given the only reason we allow vendors to push "code of the day" is
> because their existing code fails too often for us to manage manually,
> one wonders if our trust in these vendors is well-placed.
>
> A big part of this is knowing that only the vendor is pushing the
> code, and that's hard to be sure of. If malware were to hijack a
> vendor's update pipe, it could blow black code into the core of
> systems, right pas all those system's defenses.
>
> With that in mind, I've switched from wishing MS would use open
> standards for patch transmission to being grateful for whatever they
> can do to harden the process. I'd still rather not have to leave
> myself open to injections of "code of the day", though.
>

>>NO never ever ever in a production corporate environment do you allow ANY
>>of
>>your workstations and servers to directly access anyone for patches
>>I have never allowed this or even seen it in real large or enterprise
>>customers. (the only place it may crop up is in mom and pop
>>10 PCs and a Server shops).

>
> And there's the problem. MS concentrates on scaling up to enterprise
> needs, where the enterprise should consolodate patches in one location
> and then drive these into systems under their own in-house control.
>
> So scaling up is well catered for.
>
> But what about scaling down?
>

That is where the free WSUS 3.0 product is targeted. One server to do all
the downloads and then you approve the ones you want to deploy and then your
client PCs just get them under their normal Windows Automatic Update process
(but this time they point to your WSUS server internally instead of going
external).

> Do "mom and pop" folks not deserve safety? How about single-PC users
> which have everything they own tied up in that one vulnerable box?
> What's best-practice for them - "trust me, I'm a software vendor"?
>

As above for anyone one with more then a couple of PCs.
Other wise you subscribe to the security update, are notified when they are
released, use the Download catalog to get the updates test them as you see
fit hem deploy them as you see fit using any production approach you want.

Sorry but this is not new and has been around for the last few years - patch
management for everyone from single user to mega corp. is well understood
out there in the field, which is why I was so surprised by the OPs post and
approach.

> How about scaling outwards?
>

WSUS scales outwards too - unless you mean something else.
If you mean for integration with other vendors - if they wish to create
catalog then SCCM 2007 can handle import of third party or in-house catalog
data to id out of patch machines and patch etc. I suggest you read up on the
SCCM 2007 product.

> When every single vendor wants to be able to push "updates" into your
> PC, even for things as trivial as prinyers and mouse drivers, how do
> you manage these?

Since MSFT is taking a huge number of these patches and updated drivers then
you can continue to handle these. as regards the rest if they start using
standard catalog methods as I mentioned above then integration becomes a no
brainer. Otherwise you again have to get informed of there new updates -
most publish some form of alert etc. then download, test and deploy using
whatever tools you like in your enterprise.

> How do you manage 50 different ad-hoc update
> delivery systems, some from vendors who are not much beyond "Mom and
> Pop" status themselves? Do we let Zango etc. "update" themselves?
>
> The bottom line: "Ship now, patch later" is an unworkable model.
>

There is almost no such thing as flawless software and particularly when
you are talking about tens of millions of lines of code in an OS.
Every major OS vendor on the planet regularly ships patches and updates for
their products.

>>As you said your only problem is with Microsoft then the solution I have
>>outlined above is the fix - only one server needs access through your
>>draconian firewall policies. And you get a real secure enterprise patch
>>management solution that significantly lowers the risk to your
>>environment.

>
> That's prolly the best solution, for those with the resources to
> manage it. It does create a lock-in advantage for MS, but at least it
> is one that is value-based (i.e. the positive value of a
> well-developed enterprise-ready management system).
>
> However, I have to wonder how effective in-house patch evaluation
> really is, especially if it is to keep up with tight time-to-exploit
> cycles.

Then that is their problem and they must address it in the manner best
suited to them either by increasing their resources assigned to it or taking
a firmer approach such as only taking absolutely critical patches etc.
I have worked with enterprise across this whole spectrum from full dedicated
patch management teams that perform full and complete regression testing for
all patches they need to roll out internally to extremely poor ad hoc
solutions and minimal testing,.

> It may be the closed-source equivalent of the open source
> boast that "our code is validated by a thousand reviewers"; looks good
> on paper, but is it really effective in practice?
>
>
>

>>--------------- ----- ---- --- -- - - -

> To one who has never seen a hammer,
> nothing looks like a nail

>>--------------- ----- ---- --- -- - - -

On Wed, 1 Aug 2007 20:40:01 +0100, "Mike Brannigan"

>Mike Brannigan
>"cquirke

>> On Fri, 27 Jul 2007 15:13:52 +0100, "Mike Brannigan"

>>>"Leythos" <void@nowhere.lan> wrote in message
>>>> Mike.Brannigan@localhost says...

>> MS concentrates on scaling up to enterprise needs, where
>> the enterprise should consolodate patches in one location
>> and then drive these into systems under their own in-house control.

>> But what about scaling down?

>That is where the free WSUS 3.0 product is targeted. One server to do all
>the downloads and then you approve the ones you want to deploy and then your
>client PCs just get them under their normal Windows Automatic Update process
>(but this time they point to your WSUS server internally instead of going
>external).

Sounds good - by "one server", do you mean a server dedicated to this
task alone, or can that be the only server you have? Will it run on
SBS, or is there a different solution for that?

This is good, but it's still not scaling all the way down to a single
PC that has everything important on it. Those users have no choice
but to trsut patches not to mess up.

Windows *almost* offers a mitigation, but screws it up (or rather,
doesn't see the need to work the way I'd hoped it would).

There's an Automatic Updates option to "download now, but let me
decide when to install them". When I read that, I thought it would
put me in full control over such updates (e.g. "...when or IF to
install them") but it does not. If I click "no, don't install these",
it will stealth them in via the next shutdown.

This is a pity, because otherwise it would facilitate this policy:
- download patches as soon as available but DO NOT INSTALL
- watch for reports of problems with patches
- watch for reports of exploits
- if exploits, get offline and install already-downloaded patches
- else if no "dead bodies" reported from patch bugs, install patches
- but if reports of "dead bodies", can avoid the relevant patches

As it is, if I don't want MS ramming "code of the day" when my back is
turned, I have to disable downloading updates altogether, so...
- do NOT download patches as soon as available
- watch for reports of problems with patches
- watch for reports of exploits
- if exploits, have to stay online to download patches -> exploited
- if no "dead bodies" from patch bugs, downloads and install patches
- but if reports of "dead bodies", can avoid the relevant patches

>> How do you manage 50 different ad-hoc update
>> delivery systems, some from vendors who are not much beyond "Mom and
>> Pop" status themselves? Do we let Zango etc. "update" themselves?
>>
>> The bottom line: "Ship now, patch later" is an unworkable model.

>There is almost no such thing as flawless software and particularly when
>you are talking about tens of millions of lines of code in an OS.

Sure, and the lesson is to design and code with this in mind, reducing
automatic exposure of surfaces to arbitrary material, and ensuring
that any code can be amputated immediately, pending patch.

If all non-trivial code has bugs, and you need bug-free code, then the
solution is to keep that code trivial ;-)

I see this as akin to hi-wear surfaces within mechanical systems.
You'd nearly always design such systems so that hi-wear parts are
cheap and detatchable for field replacement, e.g. pressed steel bore
within an aluminium block, piston rings that are not built permanently
into the piston, removable crank bearings rather than ball bearings
running directly on crank and case surfaces, etc.

I don't see enough of that awareness in modern Windows. If anything,
the trend is in the other direction; more automated and complex
handling of material that the user has indicated no intention to
"open", poor or absent file type discipline, subsystems that cannot be
excluded from installation or uninstalled, etc.

>Every major OS vendor on the planet regularly ships patches and updates for
>their products.

They do indeed, yes, and many vendors are lagging behind MS in
sensible practice. For example, Sun were still allowing Java applets
to "ask" the JRE to pass them through to older versions "for backward
compatibility", and installing new JRE versions did not get rid of old
ones, allowing these to remain a threat.

But the bottom line is, it's a suspension of disbelief to trust patch
code (that may be hastily developed under present exploits) to work
when slid under installed applications that could not possibly have
been written for such code, especially when the reason to swallow such
code is because the same vendor messed up when writing the same code
under less-rushed pre-release circumstances.

What should have happened, is that the first time some unforgivable
code defect allowed widespread exploitation (say, the failure to check
MIME type against file name extension and actual material type when
processing in-line files in HTML "message text"), the vendor should
have been stomped so hard that they'd dare not make the same sort of
mistake again.

Instead, the norm is for swave vendors to fail so regularly that we
have to automate the process of "patching". Vendors can do this by
making the patch material available on a server, leaving it to the
user to cover the cost of obtaining it. Meanwhile, stocks of
defective product are not recalled, nor are replacement disks added to
these packages, so what you buy after the fact is still defective, and
still have to be patched at your expense.

Couple that with the common advice to "just" wipe and re-install, and
you will be constantly falling back to unpatched status, and having to
pull down massive wads of "repair" material - something that just is
not possible to do via pay-per-second dial-up.

I was impressed when MS shipped XP SP2 CDs to end users, as well as
the security roll-up CDs for Windows all the way back to Win98. But
we still need the ability to regenerate a fully-functional and
fully-patched OS installation and maintenance disk - something that
"royalty" OEMs don't provide their victims even at purchase time.

>> However, I have to wonder how effective in-house patch evaluation
>> really is, especially if it is to keep up with tight time-to-exploit
>> cycles.

>Then that is their problem

Not really, no. The problem arises from a bug rate within exposed
surfaces that is unsustainable for the extent of those surfaces,
forcing too many patches to manage manually. Yes, it becomes our
problem, but we didn't cause it other than by choosing to use a
platform that is so widely used that it is immediately attacked.

That equation not only favors minority platforms such as Mac OS and
Linux, it also favors an abandonment of personal computing for SaaS,
for which the risks are currently way under-estimated.


Note that I don't see the need to patch as an MS issue, given that (as
you mention) all equally-complex systems have similar needs to patch.

What puts MS on the sharp end, is the degree of exposure - like the
difference between the bearing on your boot hinge, and the bearing
that holds the crankshaft in the engine block.

It's been amusing to see how well (or rather, how poorly) Apple's
Safari browser has fared, when exposed to the same "wear".

A trend I really don't like, is where relatively trivial software
vendors jump on the "update" bandwagon, leveraging this to re-assert
thier choice of settings or "call home". It's bad enough that buggy
code quality is rewarded with tighter vendor dependency, as it is.

>I have worked with enterprise across this whole spectrum from full dedicated
>patch management teams that perform full and complete regression testing for
>all patches they need to roll out internally to extremely poor ad hoc
>solutions and minimal testing,.

I'm not talking entrerprises, here. They are well-positioned to
manage the problem; it's the "free" end-users with thier single PCs or
small peer-to-peer LANs I'm thinking about.

Collectively, all those loose systems can act as very large botnets.

>> It may be the closed-source equivalent of the open source
>> boast that "our code is validated by a thousand reviewers"; looks good
>> on paper, but is it really effective in practice?

>------------ ----- ---- --- -- - - - -

The most accurate diagnostic instrument
in medicine is the Retrospectoscope

>------------ ----- ---- --- -- - - - -

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
message news:llq4b3p39bgbsq7su9c7akjghgeq55narl@4ax.com...

> On Wed, 1 Aug 2007 20:40:01 +0100, "Mike Brannigan"

>>Mike Brannigan
>>"cquirke

>>> On Fri, 27 Jul 2007 15:13:52 +0100, "Mike Brannigan"
>>>>"Leythos" <void@nowhere.lan> wrote in message
>>>>> Mike.Brannigan@localhost says...

>

>>> MS concentrates on scaling up to enterprise needs, where
>>> the enterprise should consolodate patches in one location
>>> and then drive these into systems under their own in-house control.

>

>>> But what about scaling down?

>

>>That is where the free WSUS 3.0 product is targeted. One server to do all
>>the downloads and then you approve the ones you want to deploy and then
>>your
>>client PCs just get them under their normal Windows Automatic Update
>>process
>>(but this time they point to your WSUS server internally instead of going
>>external).

>
> Sounds good - by "one server", do you mean a server dedicated to this
> task alone, or can that be the only server you have? Will it run on
> SBS, or is there a different solution for that?
>

SBS 2003 R2 comes with WSUS out if the box.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca