RE: Patch Management - again

[Ken Schaefer]

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Subject: Re: Patch Management - again

>  And even Win32 (NT/9x) didn't have anything approaching a common installer 
> system until 2000 or so, and side-by-side DLL installs didn't show up 
> until... 
> what, Win XP?  XP SP2?
>
>  .NET was supposed to solve all these problems, but I haven't really 
> seen that materialize.  Even Microsoft publishes stuff that demands 
> a particular release of the .NET Framework.  :-(

.NET Framework is design to allow multiple versions of the Framework to run 
side-by-side. Having a .NET application that requires a particular version 
isn't what it's designed to solve. Newer applications will require the 
functionality of newer versions of the framework. And newer versions may remove 
deprecated features, thus requiring an older version for older apps.

Cheers
Ken


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Alan Davies]

Exactly my point!  Therefore it doesn't exist as it's not relevant
unless it's used ..

Having said that, no doubt MS would be clouted with some dumb legal
action over cornering the market in patching or some other such BS, were
the solution every successful and in widespread use ..



a 

-Original Message-
From: Phil Brutsche [mailto:p...@optimumdata.com] 
Sent: 15 June 2010 17:15
To: NT System Admin Issues
Subject: Re: Patch Management - again

It isn't.

The WSUS engine is more than capable of distributing and automatically
installing third-party updates - it's what's used in products like
System Center Essentials for the task - and MS created System Center
Updates Publisher (aka SCUP) so that admins can add the updates.

Third parties who refuse to publish catalogs SCUP can use (like Adobe)
are as much as fault as anyone else.

SCUP links:
http://technet.microsoft.com/en-us/library/bb531022.aspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=0446cce9-94a4-4
fb0-b335-e7516044063d&displaylang=en

On 6/15/2010 11:06 AM, Alan Davies wrote:
> And why is a solution like this missing from MS operating systems??

-- 

Phil Brutsche
p...@optimumdata.com

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


WARNING:
The information in this email and any attachments is confidential and may be 
legally privileged.

If you are not the named addressee, you must not use, copy or disclose this 
email (including any attachments) or the information in it save to the named 
addressee nor take any action in reliance on it. If you receive this email or 
any attachments in error, please notify the sender immediately and then delete 
the same and any copies.

"CLS Services Ltd × Registered in England No 4132704 × Registered Office: 
Exchange Tower × One Harbour Exchange Square × London E14 9GE"



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 7:33 PM, Steven Peck  wrote:
> So as I have said.  Pretty much every issue has not been patch
> related.  But having called MS we had help identifying the actual
> cause of the issue.

  That doesn't make Windows better at package management; it just
means if you pay for Microsoft's help, they'll help you.  I would hope
so!  :)

> I guess your support experience has not been as good as mine.  With
> only one or two exceptions in years, every issue has been the result
> of configuration or third party software, not an MS fix.

  We may have been talking about different things.  I wasn't talking
about MSFT helping with patch management issues only, but rather, in
general.  If I call about a "known issue", they just point to the
requisite MSKB article and say the "behavior is by design" and won't
be fixed.  If you mean *just* patch management issues, okay.  That's
my fault for getting off-topic.  Sorry.

  To get back on topic: "you can pay Microsoft for help investigating
possible patch issues" != "Windows has good package management
technology".

> You consistently post this viewpoint. It has become expected.

  I believe you consistently post your viewpoint, too.  :)  I don't
consider that a bad thing.  If you didn't believe what you were
saying, you wouldn't be worth listening to.  :)

>>  (Plus, if you really want the company-to-blame thing, that's
>> available for Linux, too.  Novell or Red Hat or Canonical will happily
>> take your money and let you blame them all you want.)
>
> You keep saying blame.  If you pay Redhat you get the same time of
> service you get from MS.  A person will help you diagnose and
> troubleshoot the issue.  But you have to be using their stuff and they
> will help you see if it was their fix / update or something specific
> to your system / install.  This is the exact same advantage of having
> quality paid vendor support.

  Um.  Isn't that what I was saying?  That if you pay X for support,
they'll help you with their stuff, regardless of whether X = Microsoft
or X = Canonical?  :)

>>  When I compare Linux and Windows, I often say that it's not that one
>> *can't* do this or that on Windows, but that it costs more.  Same
>> thing here.  More stuff in this area is built-in, and what's there is
>> more sophisticated in functionality and is easier to maintain.  All
>> that adds up to lower costs.
>>
> No it doesn't.  It only costs 'less' if you fail to value your time
> and the time it has taken to acquire your expertise.

  And all the time I've spent acquiring knowledge on Microsoft
products?  Courses I've taken, manuals I've read, books I've bought
and studied, support calls, paid consultants, lab environments?  That
did not have a cost?

  I have yet to find anything in the IT world that didn't require
learning, planning, and integration effort.  This is the same
everywhere, Linux or Microsoft, payware or freeware or Open Source.

  Yah, any monkey can sit down with an install CD and click GUI
buttons and get something that boots.  That's true of Linux these
days, too (for better or worse).  That doesn't translate into a stable
IT infrastructure on any platform.

> The 'you can fix it yourself' part is a myth.

  Interesting.  You say "you can fix it yourself" is a myth, while I
say the commercial support angle is a myth.  Perhaps we are both
figments of our own imaginations?  ;-)

  Understand that you don't need to be a software developer to fix
simple issues.  Anecdote: Roughly eight years ago, I was tasked with
getting an ISDN link working with Linux.  It turns out the provider
was using a ridiculously long SPID, and the Linux ISDN stack was
truncating it, causing things to fail.  I understood almost nothing in
the source code, but I understood enough to know what "#define
MAX_SPID_LENGTH = 8" meant in the header, and to bump that number up.
Compare that to, say, MAX_PATH on Windows.  For whatever reason, it
appears that will be 255 forever, and we're just stuck with it.

> Cost comes from somewhere, paying a dev, learning it
> yourself, the kindness of random strangers

  Absolutely.  I just maintain that those costs are higher for Windows.

>>  To the best of my knowledge, with MSI, I can't do half of what I can
>> do with RPM (see my other posts in this thread for examples).
>
> Our desktop guys have been packaging the adobe updates, the java
> updates, the whatever weird in house custom app updates we have for
> years now.  I shall ask them what they use.  For straight MS updates,
> MS SCCM, select what you want and fire away.

  For distributing Microsoft updates, we have WSUS now.  It sucks up a
ton of RAM for even 100 PCs, it needs a SQL database server and a web
application, it's full of cryptic stuff that isn't documented
anywhere.  On Linux, all you need is a file share.  Again, costs.

  We also do things like custom MSI deployments for Java updates.  But
wasn't your argument that most people can't do that stuff, and those
that ca

Re: Patch Management - again

[Steven Peck]

...

On Tue, Jun 15, 2010 at 4:16 PM, Ben Scott  wrote:
> On Tue, Jun 15, 2010 at 6:56 PM, Steven Peck  wrote:
>> Debian had the Drupal CMS in their distributions for
>> years and despite many attempts we could not get that thing out of
>> their despite it being old/unsecure/not-desired all because some guy
>> refused to remove it from the repo.
>>
>> At least with MS OS and Applications we have a central point.
>
>  I've heard that before.  Never, *ever* have I encountered or seen or
> heard of the "central point of blame" actually helping a situation.
> Not for mere mortals like me and my colleagues, anyway.
>
>   Say Microsoft screws up.  *What then*?  I call PSS and pay $250 and
> if I'm lucky, the call center monkey I got has a half a brain and
> acknowledges the issue.

So as I have said.  Pretty much every issue has not been patch
related.  But having called MS we had help identifying the actual
cause of the issue.

>  From then on, I'm helpless.  I don't know what group in Microsoft
> has responsibility for fixing it; I don't know when or *if* it will be
> fixed.  It's all a faceless corporation.  At least you knew which guy
> in Debian to blame.  Maybe someday Microsoft publishes a hotfix, or
> maybe they just say "This behavior is by design" and tell me, politely
> and professionally, to pound sand.  Or maybe they even say, yah,
> that's a problem, but we won't be fixing this any time soon, sorry.
> Maybe in the next release of Windows.  Or the one after that for sure.

I guess your support experience has not been as good as mine.  With
only one or two exceptions in years, every issue has been the result
of configuration or third party software, not an MS fix.

>  Please tell me how "having a big company to blame" makes this better
> for me or my employer.  I've heard that line so many times, and yet it
> never happens.

You consistently post this viewpoint. It has become expected.

>  (Plus, if you really want the company-to-blame thing, that's
> available for Linux, too.  Novell or Red Hat or Canonical will happily
> take your money and let you blame them all you want.)

You keep saying blame.  If you pay Redhat you get the same time of
service you get from MS.  A person will help you diagnose and
troubleshoot the issue.  But you have to be using their stuff and they
will help you see if it was their fix / update or something specific
to your system / install.  This is the exact same advantage of having
quality paid vendor support.

>> We have had very few actual patch related issues.
>> We have had many claims that the issue were patch
>> related but when drilled down on turned out
>> to generally be not a patch issue.
>
>  When I compare Linux and Windows, I often say that it's not that one
> *can't* do this or that on Windows, but that it costs more.  Same
> thing here.  More stuff in this area is built-in, and what's there is
> more sophisticated in functionality and is easier to maintain.  All
> that adds up to lower costs.
>
No it doesn't.  It only costs 'less' if you fail to value your time
and the time it has taken to acquire your expertise.  The 'you can fix
it yourself' part is a myth.  Very few people can actually do this and
those that can are generally not cheap.  I say this having been the
Drupal Documentation Team lead and ran and built their forums for
several years.   Cost comes from somewhere, paying a dev, learning it
yourself, the kindness of random strangers

>> Vendors need to get on the band wagon and begin to leverage the tools
>> Microsoft has supplied them ...
>
>  To the best of my knowledge, with MSI, I can't do half of what I can
> do with RPM (see my other posts in this thread for examples).  If I
> can, please point me at an FM that I can R; I will shower you with
> thanks and buy you the frosty beverage of your choice.  This applies
> to Windows components and Microsoft applications as much as it does to
> third-party stuff, so this isn't a "third party vendors all suck"
> issue, as far as I can see.

> -- Ben

Our desktop guys have been packaging the adobe updates, the java
updates, the whatever weird in house custom app updates we have for
years now.  I shall ask them what they use.  For straight MS updates,
MS SCCM, select what you want and fire away.

Steven

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 6:56 PM, Steven Peck  wrote:
> Debian had the Drupal CMS in their distributions for
> years and despite many attempts we could not get that thing out of
> their despite it being old/unsecure/not-desired all because some guy
> refused to remove it from the repo.
>
> At least with MS OS and Applications we have a central point.

  I've heard that before.  Never, *ever* have I encountered or seen or
heard of the "central point of blame" actually helping a situation.
Not for mere mortals like me and my colleagues, anyway.

   Say Microsoft screws up.  *What then*?  I call PSS and pay $250 and
if I'm lucky, the call center monkey I got has a half a brain and
acknowledges the issue.

  From then on, I'm helpless.  I don't know what group in Microsoft
has responsibility for fixing it; I don't know when or *if* it will be
fixed.  It's all a faceless corporation.  At least you knew which guy
in Debian to blame.  Maybe someday Microsoft publishes a hotfix, or
maybe they just say "This behavior is by design" and tell me, politely
and professionally, to pound sand.  Or maybe they even say, yah,
that's a problem, but we won't be fixing this any time soon, sorry.
Maybe in the next release of Windows.  Or the one after that for sure.

  Please tell me how "having a big company to blame" makes this better
for me or my employer.  I've heard that line so many times, and yet it
never happens.

  (Plus, if you really want the company-to-blame thing, that's
available for Linux, too.  Novell or Red Hat or Canonical will happily
take your money and let you blame them all you want.)

> We have had very few actual patch related issues.
> We have had many claims that the issue were patch
> related but when drilled down on turned out
> to generally be not a patch issue.

  When I compare Linux and Windows, I often say that it's not that one
*can't* do this or that on Windows, but that it costs more.  Same
thing here.  More stuff in this area is built-in, and what's there is
more sophisticated in functionality and is easier to maintain.  All
that adds up to lower costs.

> Vendors need to get on the band wagon and begin to leverage the tools
> Microsoft has supplied them ...

  To the best of my knowledge, with MSI, I can't do half of what I can
do with RPM (see my other posts in this thread for examples).  If I
can, please point me at an FM that I can R; I will shower you with
thanks and buy you the frosty beverage of your choice.  This applies
to Windows components and Microsoft applications as much as it does to
third-party stuff, so this isn't a "third party vendors all suck"
issue, as far as I can see.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Steven Peck]

Yes but with the Linux tree updates identifying the actual issue and
who has the authority to change / update / do it right can be
challenging.  Debian had the Drupal CMS in their distributions for
years and despite many attempts we could not get that thing out of
their despite it being old/unsecure/not-desired all because some guy
refused to remove it from the repo.

At least with MS OS and Applications we have a central point.  We have
had very few actual patch related issues.  We have had many claims
that the issue were patch related but when drilled down on turned out
to generally be not a patch issue.

Vendors need to get on the band wagon and begin to leverage the tools
Microsoft has supplied them but I don't really agree that the Linux
world has done this better.  It really all gets down to which *nix
distro you are using and which repositories you pick as to if they
work or not.

Steven Peck
http://www.blkmtn.org


On Tue, Jun 15, 2010 at 3:38 PM, Ben Scott  wrote:
> On Tue, Jun 15, 2010 at 5:48 PM, Steven Peck  wrote:
>> You are essentially relying on 'some' 
>> to be doing something 'right' or at least agreed on and that their
>> choices will not nuke your existing configuration.
>
>  Well, unless you write all software you use yourself, you're always
> relying on someone else to do it right.  :)
>
>  It's certainly true that package maintainers can make mistakes.  (As
> you may have noticed, proprietary software companies aren't perfect
> either.  )  However, one nice thing about strong package
> management is that it's very easy to automate things like integrity
> checking to detect mistakes -- often even preventing them from causing
> damage.
>
>  For example, on our Linux boxes, every program file is "owned" by a
> particular package.  If another package tries to install another copy
> of some library, RPM will detect that during pre-install and abort,
> saying the new package has a file which conflicts with an
> already-installed package.
>
>  The tools used to build RPM packages include things which
> automatically detect the libraries needed by an executable and note
> them as dependencies.
>
>  And assuming the packages contain correct information (the same way
> we assume Microsoft builds their MSIs correctly), there's all sorts of
> good things you get.
>
>  Say I want to uninstall foo, but something else depends on it.  RPM
> will refuse the uninstall, telling my exactly what "foo" depends on.
>
>  Or say I'm looking at a strange file, and I'm wondering what it's
> for.  For example:
>
>        /usr/lib/libpanel_g.a
>
>  I have no idea what that library is for.  But I can do this:
>
>        $ rpm --query --file /usr/lib/libpanel_g.a
>        ncurses-devel-5.5-24.20060715
>
> So now I know it's from the "ncurses" development package.  If I
> didn't know what ncurses was, I can do:
>
>        $ rpm --query --info ncurses
>
> and read a description.
>
>  Take a look at C:\WINDOWS\SYSTEM32\ on a Windows box near you.  Can
> you tell me what every file is for?  Can you easily find out?
>
>  Or let's say you want to make sure Exchange has all the right
> versions of all the right libraries installed.  At *best*, you're
> running a purpose-built tool which checks that.  It's quite possible
> you're going to end up searching the hard disk for particular .DLL
> files and manually checking version numbers.
>
>  With RPM, I can do "rpm --verify --all".  That will check every file
> in every package, and tell me if it has been changed improperly (and
> if so, what changed); it will also report any broken dependencies.
>
>  Certainly, MSI has made things better, and Microsoft keeps improving
> it, so I have hope that we'll be able to do things like this on
> Windows some day.  But it's still years off, at best, I think, before
> the Windows ecosystem will really catch up on this front.  First
> Microsoft has to build the tools, and then the rest of the industry
> has to adopt them.
>
>  I'm not saying this is a sufficient condition to abandon Windows for
> Linux.  I'm just saying this is something Linux does better today, and
> that it's a model I hope the Microsoft world learns from and adopts.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 6:40 PM, Andrew S. Baker  wrote:
>>>shaky foundation?
>
> The DOS, Win16 underpinnings...

  And even Win32 (NT/9x) didn't have anything approaching a common
installer system until 2000 or so, and side-by-side DLL installs
didn't show up until... what, Win XP?  XP SP2?

  .NET was supposed to solve all these problems, but I haven't really
seen that materialize.  Even Microsoft publishes stuff that demands a
particular release of the .NET Framework.  :-(

> Installed base is great when everything has been well laid out. Not so
> great, when you're bound to earlier suboptimal decisions...

  As a wise man once said: Indeed.  ;-)

  The Windows platform's greatest advantage (the huge base of software
available for it) is also one of it's biggest problems.  There's so
much stuff out there, and Windows has changed so much over time, that
Microsoft can't change *anything* without breaking *something*.

  While I think some of this can be blamed on Microsoft, since they
really should have seen some of it coming and were in a position to do
something about it, some of it's just bad luck.  And regardless of
fault, it's what we have now, and fixing it isn't going to be easy,
even for Microsoft.  :-(

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Andrew S. Baker]

*>>shaky foundation?*

The DOS, Win16 underpinnings...

Installed base is great when everything has been well laid out. Not so
great, when you're bound to earlier suboptimal decisions...


-ASB: http://XeeSM.com/AndrewBaker


On Tue, Jun 15, 2010 at 5:47 PM, Joseph Heaton  wrote:

> shaky foundation?
>
> >>> "Andrew S. Baker"  6/15/2010 2:42 PM >>>
> I don't know that I would say that Linux *always* had package management
> going well -- certainly not all distros.
>
> There was a time when Debian was highly regarded *because* of its excellent
> package management system.
>
> Redhat was next, and then RPM became a major standard because of their
> popularity and subsequent clout.
>
> SuSE was probably the next one in line.
>
> I'm not disagreeing with you as far as where things stand today, but at
> best, we can say that Linux started off on a "better" footing, and had less
> legacy and installed base to overcome.  Such is both the power and drawback
> of a large installed base over a shaky foundation.
>
> -ASB: http://XeeSM.com/AndrewBaker
>
>
> On Tue, Jun 15, 2010 at 1:47 PM, Ben Scott  wrote:
>
> > On Tue, Jun 15, 2010 at 12:15 PM, Phil Brutsche 
> > wrote:
> > >> And why is a solution like this missing from MS operating systems??
> > >
> > > It isn't.
> >
> >  Comparing MSI/WSUS to RPM/YUM (or dpkg/APT or...) is really missing
> > a lot.  MSI is a beast to develop for, it's a compatibility nightmare
> > across releases, MSI packages frequently require an interactive
> > presence, MSIs vary radically in design, they're a bear to customize,
> > the post-install management functions are non-existent, WSUS is a
> > completely different framework vs MSI, I could go on and on and on.
> >
> > > Third parties who refuse to publish catalogs SCUP can use (like Adobe)
> > > are as much as fault as anyone else.
> >
> >   So, basically, practically the entire software industry.
> >
> >  Microsoft has been working on Windows software installation for a
> > decade plus, and it's still very hairy, especially if you want to also
> > support not-the-latest-release-of-Windows.  I can't really blame
> > third-party developers for (1) resorting to doing their own thing and
> > (2) not wanting to jump aboard Microsoft's bandwagon when Microsoft
> > themselves weren't done building it yet (and still may not be).
> >
> >  Now, a lot of this is due to the "legacy" Microsoft built with
> > classic Windows, which was completely ad hoc.  The entire Windows
> > software industry ecosystem is built up around that.  It's way too
> > late to get it right the first time, so now Microsoft has to come up
> > with a way to migrate the world's largest installed base to something
> > more manageable.  That's not going to be quick.  Microsoft is still
> > responsible, since they built it like that way-back-when, but even
> > Microsoft can't change the past.  They work in the world they built,
> > and it's not realistic to expect them to fix it overnight.
> >
> >  But for those same reasons, expecting the rest of the software
> > industry to adopt what Microsoft's latest idea quickly is also
> > unrealistic.
> >
> >  In contrast, all the current Linux distributions were designed
> > "right" the right time, with strong package management from day one.
> > So everything has been and continues to be much smoother on the
> > package/update management front.
> >
> > -- Ben
> >
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 5:48 PM, Steven Peck  wrote:
> You are essentially relying on 'some' 
> to be doing something 'right' or at least agreed on and that their
> choices will not nuke your existing configuration.

  Well, unless you write all software you use yourself, you're always
relying on someone else to do it right.  :)

  It's certainly true that package maintainers can make mistakes.  (As
you may have noticed, proprietary software companies aren't perfect
either.  )  However, one nice thing about strong package
management is that it's very easy to automate things like integrity
checking to detect mistakes -- often even preventing them from causing
damage.

  For example, on our Linux boxes, every program file is "owned" by a
particular package.  If another package tries to install another copy
of some library, RPM will detect that during pre-install and abort,
saying the new package has a file which conflicts with an
already-installed package.

  The tools used to build RPM packages include things which
automatically detect the libraries needed by an executable and note
them as dependencies.

  And assuming the packages contain correct information (the same way
we assume Microsoft builds their MSIs correctly), there's all sorts of
good things you get.

  Say I want to uninstall foo, but something else depends on it.  RPM
will refuse the uninstall, telling my exactly what "foo" depends on.

  Or say I'm looking at a strange file, and I'm wondering what it's
for.  For example:

/usr/lib/libpanel_g.a

  I have no idea what that library is for.  But I can do this:

$ rpm --query --file /usr/lib/libpanel_g.a
ncurses-devel-5.5-24.20060715

So now I know it's from the "ncurses" development package.  If I
didn't know what ncurses was, I can do:

$ rpm --query --info ncurses

and read a description.

  Take a look at C:\WINDOWS\SYSTEM32\ on a Windows box near you.  Can
you tell me what every file is for?  Can you easily find out?

  Or let's say you want to make sure Exchange has all the right
versions of all the right libraries installed.  At *best*, you're
running a purpose-built tool which checks that.  It's quite possible
you're going to end up searching the hard disk for particular .DLL
files and manually checking version numbers.

  With RPM, I can do "rpm --verify --all".  That will check every file
in every package, and tell me if it has been changed improperly (and
if so, what changed); it will also report any broken dependencies.

  Certainly, MSI has made things better, and Microsoft keeps improving
it, so I have hope that we'll be able to do things like this on
Windows some day.  But it's still years off, at best, I think, before
the Windows ecosystem will really catch up on this front.  First
Microsoft has to build the tools, and then the rest of the industry
has to adopt them.

  I'm not saying this is a sufficient condition to abandon Windows for
Linux.  I'm just saying this is something Linux does better today, and
that it's a model I hope the Microsoft world learns from and adopts.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Kurt Buff]

Unlike say, some random software company that says their service pack,
hotfix or other update won't trash your machine.

MSFT/Adobe/others come to mind...

On Tue, Jun 15, 2010 at 14:48, Steven Peck  wrote:
> Nor do they do the applications on a given distribution 'right' all
> the time.  You are essentially relying on 'some' 
> to be doing something 'right' or at least agreed on and that their
> choices will not nuke your existing configuration.
>
> Steven Peck
>
> On Tue, Jun 15, 2010 at 2:42 PM, Andrew S. Baker  wrote:
>> I don't know that I would say that Linux *always* had package management
>> going well -- certainly not all distros.
>> There was a time when Debian was highly regarded *because* of its excellent
>> package management system.
>> Redhat was next, and then RPM became a major standard because of their
>> popularity and subsequent clout.
>> SuSE was probably the next one in line.
>> I'm not disagreeing with you as far as where things stand today, but at
>> best, we can say that Linux started off on a "better" footing, and had less
>> legacy and installed base to overcome.  Such is both the power and drawback
>> of a large installed base over a shaky foundation.
>> -ASB: http://XeeSM.com/AndrewBaker
>>
>>
>> On Tue, Jun 15, 2010 at 1:47 PM, Ben Scott  wrote:
>>>
>>> On Tue, Jun 15, 2010 at 12:15 PM, Phil Brutsche 
>>> wrote:
>>> >> And why is a solution like this missing from MS operating systems??
>>> >
>>> > It isn't.
>>>
>>>  Comparing MSI/WSUS to RPM/YUM (or dpkg/APT or...) is really missing
>>> a lot.  MSI is a beast to develop for, it's a compatibility nightmare
>>> across releases, MSI packages frequently require an interactive
>>> presence, MSIs vary radically in design, they're a bear to customize,
>>> the post-install management functions are non-existent, WSUS is a
>>> completely different framework vs MSI, I could go on and on and on.
>>>
>>> > Third parties who refuse to publish catalogs SCUP can use (like Adobe)
>>> > are as much as fault as anyone else.
>>>
>>>  So, basically, practically the entire software industry.
>>>
>>>  Microsoft has been working on Windows software installation for a
>>> decade plus, and it's still very hairy, especially if you want to also
>>> support not-the-latest-release-of-Windows.  I can't really blame
>>> third-party developers for (1) resorting to doing their own thing and
>>> (2) not wanting to jump aboard Microsoft's bandwagon when Microsoft
>>> themselves weren't done building it yet (and still may not be).
>>>
>>>  Now, a lot of this is due to the "legacy" Microsoft built with
>>> classic Windows, which was completely ad hoc.  The entire Windows
>>> software industry ecosystem is built up around that.  It's way too
>>> late to get it right the first time, so now Microsoft has to come up
>>> with a way to migrate the world's largest installed base to something
>>> more manageable.  That's not going to be quick.  Microsoft is still
>>> responsible, since they built it like that way-back-when, but even
>>> Microsoft can't change the past.  They work in the world they built,
>>> and it's not realistic to expect them to fix it overnight.
>>>
>>>  But for those same reasons, expecting the rest of the software
>>> industry to adopt what Microsoft's latest idea quickly is also
>>> unrealistic.
>>>
>>>  In contrast, all the current Linux distributions were designed
>>> "right" the right time, with strong package management from day one.
>>> So everything has been and continues to be much smoother on the
>>> package/update management front.
>>>
>>> -- Ben
>>>
>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>>> ~   ~
>>
>>
>>
>>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 5:42 PM, Andrew S. Baker  wrote:
>>  In contrast, all the current Linux distributions were designed
>> "right" the [first] time, with strong package management from day one.
>
> I don't know that I would say that Linux *always* had package management
> going well -- certainly not all distros.

  Well, there was a bit of weasel-wording on my part there, with "all
current distros".  :)

  If you go back > 10 years or so, yes, there were significant distros
without strong package management.  But well before 2000, anything
without good package management either got upgraded to add it, or
became obsolete or extremely marginalized.  (One could argue about
Slackware, but they consciously made the decision to be package
management luddites.  It takes all kinds.)

  Even Red Hat 2.0, circa 1995, had RPM, which knew enough to check
dependencies and handle upgrades if you had all the local packages.

  As you note, Debian had the early advantage with a comprehensive
solution for solving dependencies and automatically downloading
packages.  Red Hat didn't do that until 6.something (c. 1999).  But
other tools were available to do it; I used to use one called (IIRC)
"autorpm".  They used all the same dependency info already included in
RPM packages.  There was no separate update infrastructure to create,
just an index of package info that could be rebuilt from the original
package files at any time.

  Certainly, things have become better over time, but the foundation
for solid package management was there 15 years ago.  That gave Linux
a real leg up.  I certainly don't envy Microsoft the task of trying to
retrofit a solution on to Windows, and then convince everybody to use
it.  But that's not my problem; keeping our software as up-to-date as
I can *is*.  :-)

  (On that note, back to our Win 2000 migration.)

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Steven Peck]

Nor do they do the applications on a given distribution 'right' all
the time.  You are essentially relying on 'some' 
to be doing something 'right' or at least agreed on and that their
choices will not nuke your existing configuration.

Steven Peck

On Tue, Jun 15, 2010 at 2:42 PM, Andrew S. Baker  wrote:
> I don't know that I would say that Linux *always* had package management
> going well -- certainly not all distros.
> There was a time when Debian was highly regarded *because* of its excellent
> package management system.
> Redhat was next, and then RPM became a major standard because of their
> popularity and subsequent clout.
> SuSE was probably the next one in line.
> I'm not disagreeing with you as far as where things stand today, but at
> best, we can say that Linux started off on a "better" footing, and had less
> legacy and installed base to overcome.  Such is both the power and drawback
> of a large installed base over a shaky foundation.
> -ASB: http://XeeSM.com/AndrewBaker
>
>
> On Tue, Jun 15, 2010 at 1:47 PM, Ben Scott  wrote:
>>
>> On Tue, Jun 15, 2010 at 12:15 PM, Phil Brutsche 
>> wrote:
>> >> And why is a solution like this missing from MS operating systems??
>> >
>> > It isn't.
>>
>>  Comparing MSI/WSUS to RPM/YUM (or dpkg/APT or...) is really missing
>> a lot.  MSI is a beast to develop for, it's a compatibility nightmare
>> across releases, MSI packages frequently require an interactive
>> presence, MSIs vary radically in design, they're a bear to customize,
>> the post-install management functions are non-existent, WSUS is a
>> completely different framework vs MSI, I could go on and on and on.
>>
>> > Third parties who refuse to publish catalogs SCUP can use (like Adobe)
>> > are as much as fault as anyone else.
>>
>>  So, basically, practically the entire software industry.
>>
>>  Microsoft has been working on Windows software installation for a
>> decade plus, and it's still very hairy, especially if you want to also
>> support not-the-latest-release-of-Windows.  I can't really blame
>> third-party developers for (1) resorting to doing their own thing and
>> (2) not wanting to jump aboard Microsoft's bandwagon when Microsoft
>> themselves weren't done building it yet (and still may not be).
>>
>>  Now, a lot of this is due to the "legacy" Microsoft built with
>> classic Windows, which was completely ad hoc.  The entire Windows
>> software industry ecosystem is built up around that.  It's way too
>> late to get it right the first time, so now Microsoft has to come up
>> with a way to migrate the world's largest installed base to something
>> more manageable.  That's not going to be quick.  Microsoft is still
>> responsible, since they built it like that way-back-when, but even
>> Microsoft can't change the past.  They work in the world they built,
>> and it's not realistic to expect them to fix it overnight.
>>
>>  But for those same reasons, expecting the rest of the software
>> industry to adopt what Microsoft's latest idea quickly is also
>> unrealistic.
>>
>>  In contrast, all the current Linux distributions were designed
>> "right" the right time, with strong package management from day one.
>> So everything has been and continues to be much smoother on the
>> package/update management front.
>>
>> -- Ben
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>> ~   ~
>
>
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Joseph Heaton]

shaky foundation?

>>> "Andrew S. Baker"  6/15/2010 2:42 PM >>>
I don't know that I would say that Linux *always* had package management
going well -- certainly not all distros.

There was a time when Debian was highly regarded *because* of its excellent
package management system.

Redhat was next, and then RPM became a major standard because of their
popularity and subsequent clout.

SuSE was probably the next one in line.

I'm not disagreeing with you as far as where things stand today, but at
best, we can say that Linux started off on a "better" footing, and had less
legacy and installed base to overcome.  Such is both the power and drawback
of a large installed base over a shaky foundation.

-ASB: http://XeeSM.com/AndrewBaker 


On Tue, Jun 15, 2010 at 1:47 PM, Ben Scott  wrote:

> On Tue, Jun 15, 2010 at 12:15 PM, Phil Brutsche 
> wrote:
> >> And why is a solution like this missing from MS operating systems??
> >
> > It isn't.
>
>  Comparing MSI/WSUS to RPM/YUM (or dpkg/APT or...) is really missing
> a lot.  MSI is a beast to develop for, it's a compatibility nightmare
> across releases, MSI packages frequently require an interactive
> presence, MSIs vary radically in design, they're a bear to customize,
> the post-install management functions are non-existent, WSUS is a
> completely different framework vs MSI, I could go on and on and on.
>
> > Third parties who refuse to publish catalogs SCUP can use (like Adobe)
> > are as much as fault as anyone else.
>
>   So, basically, practically the entire software industry.
>
>  Microsoft has been working on Windows software installation for a
> decade plus, and it's still very hairy, especially if you want to also
> support not-the-latest-release-of-Windows.  I can't really blame
> third-party developers for (1) resorting to doing their own thing and
> (2) not wanting to jump aboard Microsoft's bandwagon when Microsoft
> themselves weren't done building it yet (and still may not be).
>
>  Now, a lot of this is due to the "legacy" Microsoft built with
> classic Windows, which was completely ad hoc.  The entire Windows
> software industry ecosystem is built up around that.  It's way too
> late to get it right the first time, so now Microsoft has to come up
> with a way to migrate the world's largest installed base to something
> more manageable.  That's not going to be quick.  Microsoft is still
> responsible, since they built it like that way-back-when, but even
> Microsoft can't change the past.  They work in the world they built,
> and it's not realistic to expect them to fix it overnight.
>
>  But for those same reasons, expecting the rest of the software
> industry to adopt what Microsoft's latest idea quickly is also
> unrealistic.
>
>  In contrast, all the current Linux distributions were designed
> "right" the right time, with strong package management from day one.
> So everything has been and continues to be much smoother on the
> package/update management front.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Andrew S. Baker]

I don't know that I would say that Linux *always* had package management
going well -- certainly not all distros.

There was a time when Debian was highly regarded *because* of its excellent
package management system.

Redhat was next, and then RPM became a major standard because of their
popularity and subsequent clout.

SuSE was probably the next one in line.

I'm not disagreeing with you as far as where things stand today, but at
best, we can say that Linux started off on a "better" footing, and had less
legacy and installed base to overcome.  Such is both the power and drawback
of a large installed base over a shaky foundation.

-ASB: http://XeeSM.com/AndrewBaker


On Tue, Jun 15, 2010 at 1:47 PM, Ben Scott  wrote:

> On Tue, Jun 15, 2010 at 12:15 PM, Phil Brutsche 
> wrote:
> >> And why is a solution like this missing from MS operating systems??
> >
> > It isn't.
>
>  Comparing MSI/WSUS to RPM/YUM (or dpkg/APT or...) is really missing
> a lot.  MSI is a beast to develop for, it's a compatibility nightmare
> across releases, MSI packages frequently require an interactive
> presence, MSIs vary radically in design, they're a bear to customize,
> the post-install management functions are non-existent, WSUS is a
> completely different framework vs MSI, I could go on and on and on.
>
> > Third parties who refuse to publish catalogs SCUP can use (like Adobe)
> > are as much as fault as anyone else.
>
>   So, basically, practically the entire software industry.
>
>  Microsoft has been working on Windows software installation for a
> decade plus, and it's still very hairy, especially if you want to also
> support not-the-latest-release-of-Windows.  I can't really blame
> third-party developers for (1) resorting to doing their own thing and
> (2) not wanting to jump aboard Microsoft's bandwagon when Microsoft
> themselves weren't done building it yet (and still may not be).
>
>  Now, a lot of this is due to the "legacy" Microsoft built with
> classic Windows, which was completely ad hoc.  The entire Windows
> software industry ecosystem is built up around that.  It's way too
> late to get it right the first time, so now Microsoft has to come up
> with a way to migrate the world's largest installed base to something
> more manageable.  That's not going to be quick.  Microsoft is still
> responsible, since they built it like that way-back-when, but even
> Microsoft can't change the past.  They work in the world they built,
> and it's not realistic to expect them to fix it overnight.
>
>  But for those same reasons, expecting the rest of the software
> industry to adopt what Microsoft's latest idea quickly is also
> unrealistic.
>
>  In contrast, all the current Linux distributions were designed
> "right" the right time, with strong package management from day one.
> So everything has been and continues to be much smoother on the
> package/update management front.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 1:28 PM, David Lum  wrote:
> +1 for Johnny Dangerously

 "Do you know your last name is an adverb?"

> +1 for Shavlik

  Yah, I haven't used Shavlik NetChk much, but what I did try was
impressive.  I tried the free NetChk Limited package, and it found an
issue that WSUS/WU does not.  I'm still investigating that (in my
copious free time).

  To Microsoft's credit, someone on the patch-management list from
MSFT emailed offering to help on that issue.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Tue, Jun 15, 2010 at 12:15 PM, Phil Brutsche  wrote:
>> And why is a solution like this missing from MS operating systems??
>
> It isn't.

  Comparing MSI/WSUS to RPM/YUM (or dpkg/APT or...) is really missing
a lot.  MSI is a beast to develop for, it's a compatibility nightmare
across releases, MSI packages frequently require an interactive
presence, MSIs vary radically in design, they're a bear to customize,
the post-install management functions are non-existent, WSUS is a
completely different framework vs MSI, I could go on and on and on.

> Third parties who refuse to publish catalogs SCUP can use (like Adobe)
> are as much as fault as anyone else.

  So, basically, practically the entire software industry.

  Microsoft has been working on Windows software installation for a
decade plus, and it's still very hairy, especially if you want to also
support not-the-latest-release-of-Windows.  I can't really blame
third-party developers for (1) resorting to doing their own thing and
(2) not wanting to jump aboard Microsoft's bandwagon when Microsoft
themselves weren't done building it yet (and still may not be).

  Now, a lot of this is due to the "legacy" Microsoft built with
classic Windows, which was completely ad hoc.  The entire Windows
software industry ecosystem is built up around that.  It's way too
late to get it right the first time, so now Microsoft has to come up
with a way to migrate the world's largest installed base to something
more manageable.  That's not going to be quick.  Microsoft is still
responsible, since they built it like that way-back-when, but even
Microsoft can't change the past.  They work in the world they built,
and it's not realistic to expect them to fix it overnight.

  But for those same reasons, expecting the rest of the software
industry to adopt what Microsoft's latest idea quickly is also
unrealistic.

  In contrast, all the current Linux distributions were designed
"right" the right time, with strong package management from day one.
So everything has been and continues to be much smoother on the
package/update management front.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[David Lum]

+1 for Johnny Dangerously

+1 for Shavlik
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 971.222.1025 // (Cell) 503.267.9764



From: Jonathan Link [mailto:jonathan.l...@gmail.com]
Sent: Monday, June 14, 2010 7:42 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

To paraphrase Danny Vermin: "I automated a kernel upgrade once...ONCE!"



On Mon, Jun 14, 2010 at 10:10 AM, Jeff Cain 
mailto:je...@sunbelt-software.com>> wrote:
Jason,

   For what it's worth, I would not ever automate a kernel upgrade.

Thanks,
Jeff Cain
Technical Support Analyst
Sunbelt Software
Email: supp...@sunbeltsoftware.com<mailto:supp...@sunbeltsoftware.com>
Voice: 1-877-757-4094
Fax:   1-727-562-5199
Web: <http://www.sunbeltsoftware.com<http://www.sunbeltsoftware.com/>>
Physical Address:
33 N Garden Ave
Suite 1200
Clearwater, FL  33755
United States

If you do not want further email from us, please forward
this message to 
listmana...@sunbelt-software.com<mailto:listmana...@sunbelt-software.com> with
the word 'unsubscribe' in the subject of your email.

Helpful Sunbelt Software Links:

Knowledge Base
Open a New Support Ticket
Sunbelt Software Product Support Communities


-Original Message-
From: Jason Gauthier [mailto:jgauth...@lastar.com<mailto:jgauth...@lastar.com>]
Sent: Monday, June 14, 2010 9:49 AM
To: NT System Admin Issues
Subject: RE: Patch Management - again

Except that doesn't upgrade the kernel or any other OS libraries.  It's not 
full patch management.


-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com<mailto:kurt.b...@gmail.com>]
Sent: Saturday, June 12, 2010 8:58 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

'portupgrade -a'

FreeBSD is ridiculously easy to maintain.

And, for monitoring programs installed from ports, there's portaudit, which 
sends a daily email.

Kurt

On Fri, Jun 11, 2010 at 12:59, Alex Eckelberry 
mailto:al...@sunbelt-software.com>> wrote:
>>  WSUS.
>
> What do you do about non-Windows patching?
>
> Alex
>
>
> -Original Message-
> From: Ben Scott [mailto:mailvor...@gmail.com<mailto:mailvor...@gmail.com>]
> Sent: Thursday, June 10, 2010 11:30 AM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
> mailto:jhea...@dfg.ca.gov>> wrote:
>> What are you guys using for automating patch management for your servers?
>
>  WSUS.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
..
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~






~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Phil Brutsche]

It isn't.

The WSUS engine is more than capable of distributing and automatically
installing third-party updates - it's what's used in products like
System Center Essentials for the task - and MS created System Center
Updates Publisher (aka SCUP) so that admins can add the updates.

Third parties who refuse to publish catalogs SCUP can use (like Adobe)
are as much as fault as anyone else.

SCUP links:
http://technet.microsoft.com/en-us/library/bb531022.aspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=0446cce9-94a4-4fb0-b335-e7516044063d&displaylang=en

On 6/15/2010 11:06 AM, Alan Davies wrote:
> And why is a solution like this missing from MS operating systems??

-- 

Phil Brutsche
p...@optimumdata.com

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[Rod Trent]

Speaking of Secunia...webinar on now...

http://secunia.com/vulnerability_scanning/corporate/webinars/ 

-Original Message-
From: Alan Davies [mailto:adav...@cls-services.com] 
Sent: Tuesday, June 15, 2010 12:07 PM
To: NT System Admin Issues
Subject: RE: Patch Management - again

And why is a solution like this missing from MS operating systems??
Well, because vendors with their own commercial interests (ie. spend as
little as possible and agree on nothing with competitors) don't play well.
If there were an open platform for "plugging" into a patch-updating type
API, and all vendors were forced/coerced into using it, the world would be a
better place.  Well .. a bit anyway ;)

Secunia PSI does a great job at telling you what you need, we just need
something that translates that with vendor supported methods of actually
scheduling and installing the damn updates! :(

With Open Source .. people *usually* want to do the right thing.
Different world.



a

P.S.  Shavlik, Altiris, and a hundred other 3rd party solutions do non-MS
patch release on the Windows platform in the enterprise.  You just have to
invest in hosting it, learning how to use it, deploying it, testing with it
and integrating it into your change control procedures ...

-Original Message-
From: Crawford, Scott [mailto:crawfo...@evangel.edu]
Sent: 11 June 2010 23:51
To: NT System Admin Issues
Subject: RE: Patch Management - again

Thanks very much for this. It's exactly the kind of info I was looking for.

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com]
Sent: Friday, June 11, 2010 5:26 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Fri, Jun 11, 2010 at 5:37 PM, Crawford, Scott 
wrote:
>>  Our only non-Windows computers are running Linux, and Linux makes 
>> patch management ridiculously easy.
>
> I'm sure there's countless places I could find this information, but 
> could you elaborate on that statement a bit?



WARNING:
The information in this email and any attachments is confidential and may be
legally privileged.

If you are not the named addressee, you must not use, copy or disclose this
email (including any attachments) or the information in it save to the named
addressee nor take any action in reliance on it. If you receive this email
or any attachments in error, please notify the sender immediately and then
delete the same and any copies.

"CLS Services Ltd × Registered in England No 4132704 × Registered Office:
Exchange Tower × One Harbour Exchange Square × London E14 9GE"



~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~




~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Alan Davies]

And why is a solution like this missing from MS operating systems??
Well, because vendors with their own commercial interests (ie. spend as
little as possible and agree on nothing with competitors) don't play
well.  If there were an open platform for "plugging" into a
patch-updating type API, and all vendors were forced/coerced into using
it, the world would be a better place.  Well .. a bit anyway ;)

Secunia PSI does a great job at telling you what you need, we just need
something that translates that with vendor supported methods of actually
scheduling and installing the damn updates! :(

With Open Source .. people *usually* want to do the right thing.
Different world.



a

P.S.  Shavlik, Altiris, and a hundred other 3rd party solutions do
non-MS patch release on the Windows platform in the enterprise.  You
just have to invest in hosting it, learning how to use it, deploying it,
testing with it and integrating it into your change control procedures
...

-Original Message-
From: Crawford, Scott [mailto:crawfo...@evangel.edu] 
Sent: 11 June 2010 23:51
To: NT System Admin Issues
Subject: RE: Patch Management - again

Thanks very much for this. It's exactly the kind of info I was looking
for.

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Friday, June 11, 2010 5:26 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Fri, Jun 11, 2010 at 5:37 PM, Crawford, Scott 
wrote:
>>  Our only non-Windows computers are running Linux, and Linux makes
>> patch management ridiculously easy.
>
> I'm sure there's countless places I could find this information, but
> could you elaborate on that statement a bit?


WARNING:
The information in this email and any attachments is confidential and may be 
legally privileged.

If you are not the named addressee, you must not use, copy or disclose this 
email (including any attachments) or the information in it save to the named 
addressee nor take any action in reliance on it. If you receive this email or 
any attachments in error, please notify the sender immediately and then delete 
the same and any copies.

"CLS Services Ltd × Registered in England No 4132704 × Registered Office: 
Exchange Tower × One Harbour Exchange Square × London E14 9GE"



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Kurt Buff]

Oh, well, for that, I use freebsd-update. Just as easy.

On Mon, Jun 14, 2010 at 06:49, Jason Gauthier  wrote:
> Except that doesn't upgrade the kernel or any other OS libraries.  It's not 
> full patch management.
>
>
> -Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, June 12, 2010 8:58 PM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> 'portupgrade -a'
>
> FreeBSD is ridiculously easy to maintain.
>
> And, for monitoring programs installed from ports, there's portaudit, which 
> sends a daily email.
>
> Kurt
>
> On Fri, Jun 11, 2010 at 12:59, Alex Eckelberry  
> wrote:
>>>  WSUS.
>>
>> What do you do about non-Windows patching?
>>
>> Alex
>>
>>
>> -Original Message-----
>> From: Ben Scott [mailto:mailvor...@gmail.com]
>> Sent: Thursday, June 10, 2010 11:30 AM
>> To: NT System Admin Issues
>> Subject: Re: Patch Management - again
>>
>> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>>> What are you guys using for automating patch management for your servers?
>>
>>  WSUS.
>>
>> -- Ben
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>>
>>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Ben Scott]

On Mon, Jun 14, 2010 at 10:10 AM, Jeff Cain  wrote:
> For what it's worth, I would not ever automate a kernel upgrade.

  Really, everything on a computer is "automated".  It's just a
question of how much human supervision you give it.

  It's not like if I type "yum update kernel\*" or "rpm --install
kernel*rpm" or "cp bzimage /boot/vmlinuz.new" that I'm actually doing
the work.

  How much human supervision one gives a kernel upgrade probabbly
depends most on how many boxes you're dealing with.  A single host in
a one-off config?  Yah, run commands manually, and check everything at
each stage.  A farm of 100s of identical servers?  That wants more
automation, with testing and staggered deployment to keep problems
from taking out everything at once.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Jonathan Link]

To paraphrase Danny Vermin: "I automated a kernel upgrade once...ONCE!"



On Mon, Jun 14, 2010 at 10:10 AM, Jeff Cain wrote:

> Jason,
>
>For what it's worth, I would not ever automate a kernel upgrade.
>
> Thanks,
> Jeff Cain
> Technical Support Analyst
> Sunbelt Software
> Email: supp...@sunbeltsoftware.com
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: <http://www.sunbeltsoftware.com>
> Physical Address:
> 33 N Garden Ave
> Suite 1200
> Clearwater, FL  33755
> United States
> 
> If you do not want further email from us, please forward
> this message to listmana...@sunbelt-software.com with
> the word 'unsubscribe' in the subject of your email.
> 
> Helpful Sunbelt Software Links:
>
> Knowledge Base
> Open a New Support Ticket
> Sunbelt Software Product Support Communities
>
>
> -Original Message-
> From: Jason Gauthier [mailto:jgauth...@lastar.com]
> Sent: Monday, June 14, 2010 9:49 AM
> To: NT System Admin Issues
>  Subject: RE: Patch Management - again
>
> Except that doesn't upgrade the kernel or any other OS libraries.  It's not
> full patch management.
>
>
> -----Original Message-
> From: Kurt Buff [mailto:kurt.b...@gmail.com]
> Sent: Saturday, June 12, 2010 8:58 PM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> 'portupgrade -a'
>
> FreeBSD is ridiculously easy to maintain.
>
> And, for monitoring programs installed from ports, there's portaudit, which
> sends a daily email.
>
> Kurt
>
> On Fri, Jun 11, 2010 at 12:59, Alex Eckelberry 
> wrote:
> >>  WSUS.
> >
> > What do you do about non-Windows patching?
> >
> > Alex
> >
> >
> > -Original Message-
> > From: Ben Scott [mailto:mailvor...@gmail.com]
> > Sent: Thursday, June 10, 2010 11:30 AM
> > To: NT System Admin Issues
> > Subject: Re: Patch Management - again
> >
> > On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
> wrote:
> >> What are you guys using for automating patch management for your
> servers?
> >
> >  WSUS.
> >
> > -- Ben
> >
> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
> >
> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
> >
> >
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <
> http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <
> http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ..
>  ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Jeff Cain]

Jason,

For what it's worth, I would not ever automate a kernel upgrade.

Thanks,
Jeff Cain
Technical Support Analyst
Sunbelt Software
Email: supp...@sunbeltsoftware.com
Voice: 1-877-757-4094
Fax:   1-727-562-5199
Web: <http://www.sunbeltsoftware.com>
Physical Address:
33 N Garden Ave
Suite 1200
Clearwater, FL  33755
United States

If you do not want further email from us, please forward
this message to listmana...@sunbelt-software.com with
the word 'unsubscribe' in the subject of your email.

Helpful Sunbelt Software Links:

Knowledge Base
Open a New Support Ticket
Sunbelt Software Product Support Communities


-Original Message-
From: Jason Gauthier [mailto:jgauth...@lastar.com] 
Sent: Monday, June 14, 2010 9:49 AM
To: NT System Admin Issues
Subject: RE: Patch Management - again

Except that doesn't upgrade the kernel or any other OS libraries.  It's not 
full patch management.


-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com]
Sent: Saturday, June 12, 2010 8:58 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

'portupgrade -a'

FreeBSD is ridiculously easy to maintain.

And, for monitoring programs installed from ports, there's portaudit, which 
sends a daily email.

Kurt

On Fri, Jun 11, 2010 at 12:59, Alex Eckelberry  
wrote:
>>  WSUS.
>
> What do you do about non-Windows patching?
>
> Alex
>
>
> -Original Message-
> From: Ben Scott [mailto:mailvor...@gmail.com]
> Sent: Thursday, June 10, 2010 11:30 AM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>> What are you guys using for automating patch management for your servers?
>
>  WSUS.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

..
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Jason Gauthier]

Except that doesn't upgrade the kernel or any other OS libraries.  It's not 
full patch management.


-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Saturday, June 12, 2010 8:58 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

'portupgrade -a'

FreeBSD is ridiculously easy to maintain.

And, for monitoring programs installed from ports, there's portaudit, which 
sends a daily email.

Kurt

On Fri, Jun 11, 2010 at 12:59, Alex Eckelberry  
wrote:
>>  WSUS.
>
> What do you do about non-Windows patching?
>
> Alex
>
>
> -Original Message-
> From: Ben Scott [mailto:mailvor...@gmail.com]
> Sent: Thursday, June 10, 2010 11:30 AM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>> What are you guys using for automating patch management for your servers?
>
>  WSUS.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Kurt Buff]

'portupgrade -a'

FreeBSD is ridiculously easy to maintain.

And, for monitoring programs installed from ports, there's portaudit,
which sends a daily email.

Kurt

On Fri, Jun 11, 2010 at 12:59, Alex Eckelberry
 wrote:
>>  WSUS.
>
> What do you do about non-Windows patching?
>
> Alex
>
>
> -Original Message-
> From: Ben Scott [mailto:mailvor...@gmail.com]
> Sent: Thursday, June 10, 2010 11:30 AM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>> What are you guys using for automating patch management for your servers?
>
>  WSUS.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Ben Scott]

On Fri, Jun 11, 2010 at 6:36 PM, Joseph L. Casale
 wrote:
>>       rpm --freshen /pub/mirror/centos/5/updates/i386/RPMS/*
>
> That do depsolving if a package updates requires another packed to be
> updated as well?

  It will properly order installation so that dependencies are updated
first.  However, it won't install newly required packages, which does
very occasionally happen."yum update" will install newly required
packages; that's obviously a better solution.  If I had a lot of Linux
boxes, I would definitely do that.  For the past five years or so I've
been dealing with mostly 'dows with only one-off 'nix boxes, so I
haven't had need.

  I had the "update requires a new package" thing hit me once or twice
before yum came out.  I did one-off commands to handle it when it
showed up in the reports in the morning.  For example:

for server in $( < servers.txt ) ; do ssh r...@${server} rpm
--install /pub/mirror/centos/5/updates/i386/RPMS/foo-1.2.3.i386.rpm ;
done

  That uses SSH (secure shell) to run the package install command on a
list of servers.

  SSH is kind of like PSEXEC but faster, works with any program, and
is safe over the public 'net.  Putting it in a for loop is an
extremely common idiom in the 'nix world.  If you have a lot of 'nix
boxes, look for pssh, which can run the commands in parallel.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[Crawford, Scott]

Thanks very much for this. It's exactly the kind of info I was looking
for.

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Friday, June 11, 2010 5:26 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Fri, Jun 11, 2010 at 5:37 PM, Crawford, Scott 
wrote:
>>  Our only non-Windows computers are running Linux, and Linux makes
>> patch management ridiculously easy.
>
> I'm sure there's countless places I could find this information, but
> could you elaborate on that statement a bit?

  Well, this is really off-topic for this list, but then, so is the
World Cup.  I'll mention a few things.  More in-depth discussion
belongs elsewhere, like the patch-management list.

  We use CentOS, so the examples I give are for that distribution.
Most other distros have similar methods.

  Most Linux distributions use a tool called a "package manager" to
install and update software.  Every software component is part of a
package.  Every program file installed on the system is owned by a
package.  The same tools are used to install, uninstall, and update
every software package on the system.  To install the Wireshark packet
sniffer:

yum install wireshark

  To update it:

yum update wireshark

  So if you don't care about bandwidth, you can just do:

yum update

and all the software gets updated.

  Now, if you have a fleet of machines and don't want to suck up your
Internet bandwidth downloading updates, you'll need some kind of local
repository of updates.  Your "patch server", so to speak.  But unlike
Microsoft, all the updates are posted to public FTP/HTTP servers, in a
plain directory structure.  So to maintain a mirror, all you need to
do is use a standard download tool.  Thus:

cd /pub/mirror/centos
wget --mirror --no-host-dir --cut-dirs=1
http://mirror.centos.org/centos/5/updates/i386/RPMS/

  Now you've got a local repository with all the updates.  You can
share that out using NFS or SMB or whatever you use to share files.

  To tell a computer to update against that:

rpm --freshen /pub/mirror/centos/5/updates/i386/RPMS/*

  The "freshen" command tells the package manage to install newer
packages, but only for packages which are already installed.

  I've been using this technique in various environments off-and-on
since roughly 1996 or so.  It still works, so I haven't had need to
research other methods.

  However, if you want, the tools to build the index yum needs from a
repository of files are included in the distribution.  I'm told it
would be as easy as:

yum-arch  /pub/mirror/centos/5/updates/i386/RPMS/

and then editing /etc/yum.conf to look at your own server rather than
the default mirror network.

  If you want to test the integrity of the software on the system, you
can do:

rpm --verify --all

  That will check every file of every installed package.  It will
report differences in date, time, permissions, checksum, etc.  It will
also report broken dependencies.  Like most *nix commands, it's
normally silent, so silence is golden.

  Any of these commands can be put in a scheduled job to run every
night.  No special background services or poorly-documented software
is required to maintain the repository.  It's all standard commands
you use anyway.  The repository is just a directory with a bunch of
package files in it.  There's no need to run a special web server, or
to have a database backend; there's no special download protocol.  The
update packages are just like regular packages; there's no cryptic
format or special installers.

  There's a package called "yum-cron"; if you install it, it will
email you a report every night if there are pending updates to
install.  I use a mail filter to route those messages to a mail
folder.  If it's empty, all is well.  Things needing attention show up
as new mail.  That's all I've ever needed or wanted for reporting.

  I've had people ask about things like pie charts.  I honestly don't
see how pie charts help patch management, but if you want that sort of
thing, Red Hat sells a fancy GUI thing called "Red Hat Network".  You
get a year if you buy their commercial packaged distro.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Joseph L. Casale]

>  To tell a computer to update against that:
>
>   rpm --freshen /pub/mirror/centos/5/updates/i386/RPMS/*

That do depsolving if a package updates requires another packed to be
updated as well?

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Fri, Jun 11, 2010 at 5:37 PM, Crawford, Scott  wrote:
>>  Our only non-Windows computers are running Linux, and Linux makes
>> patch management ridiculously easy.
>
> I'm sure there's countless places I could find this information, but
> could you elaborate on that statement a bit?

  Well, this is really off-topic for this list, but then, so is the
World Cup.  I'll mention a few things.  More in-depth discussion
belongs elsewhere, like the patch-management list.

  We use CentOS, so the examples I give are for that distribution.
Most other distros have similar methods.

  Most Linux distributions use a tool called a "package manager" to
install and update software.  Every software component is part of a
package.  Every program file installed on the system is owned by a
package.  The same tools are used to install, uninstall, and update
every software package on the system.  To install the Wireshark packet
sniffer:

yum install wireshark

  To update it:

yum update wireshark

  So if you don't care about bandwidth, you can just do:

yum update

and all the software gets updated.

  Now, if you have a fleet of machines and don't want to suck up your
Internet bandwidth downloading updates, you'll need some kind of local
repository of updates.  Your "patch server", so to speak.  But unlike
Microsoft, all the updates are posted to public FTP/HTTP servers, in a
plain directory structure.  So to maintain a mirror, all you need to
do is use a standard download tool.  Thus:

cd /pub/mirror/centos
wget --mirror --no-host-dir --cut-dirs=1
http://mirror.centos.org/centos/5/updates/i386/RPMS/

  Now you've got a local repository with all the updates.  You can
share that out using NFS or SMB or whatever you use to share files.

  To tell a computer to update against that:

rpm --freshen /pub/mirror/centos/5/updates/i386/RPMS/*

  The "freshen" command tells the package manage to install newer
packages, but only for packages which are already installed.

  I've been using this technique in various environments off-and-on
since roughly 1996 or so.  It still works, so I haven't had need to
research other methods.

  However, if you want, the tools to build the index yum needs from a
repository of files are included in the distribution.  I'm told it
would be as easy as:

yum-arch  /pub/mirror/centos/5/updates/i386/RPMS/

and then editing /etc/yum.conf to look at your own server rather than
the default mirror network.

  If you want to test the integrity of the software on the system, you can do:

rpm --verify --all

  That will check every file of every installed package.  It will
report differences in date, time, permissions, checksum, etc.  It will
also report broken dependencies.  Like most *nix commands, it's
normally silent, so silence is golden.

  Any of these commands can be put in a scheduled job to run every
night.  No special background services or poorly-documented software
is required to maintain the repository.  It's all standard commands
you use anyway.  The repository is just a directory with a bunch of
package files in it.  There's no need to run a special web server, or
to have a database backend; there's no special download protocol.  The
update packages are just like regular packages; there's no cryptic
format or special installers.

  There's a package called "yum-cron"; if you install it, it will
email you a report every night if there are pending updates to
install.  I use a mail filter to route those messages to a mail
folder.  If it's empty, all is well.  Things needing attention show up
as new mail.  That's all I've ever needed or wanted for reporting.

  I've had people ask about things like pie charts.  I honestly don't
see how pie charts help patch management, but if you want that sort of
thing, Red Hat sells a fancy GUI thing called "Red Hat Network".  You
get a year if you buy their commercial packaged distro.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[Crawford, Scott]

I'm sure there's countless places I could find this information, but
could you elaborate on that statement a bit?

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Friday, June 11, 2010 4:30 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Fri, Jun 11, 2010 at 3:59 PM, Alex Eckelberry
 wrote:
> What do you do about non-Windows patching?

  Our only non-Windows computers are running Linux, and Linux makes
patch management ridiculously easy.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Ben Scott]

On Fri, Jun 11, 2010 at 3:59 PM, Alex Eckelberry
 wrote:
> What do you do about non-Windows patching?

  Our only non-Windows computers are running Linux, and Linux makes
patch management ridiculously easy.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[James Kerr]

suffer

- Original Message - 
From: "Alex Eckelberry" 

To: "NT System Admin Issues" 
Sent: Friday, June 11, 2010 3:59 PM
Subject: RE: Patch Management - again



 WSUS.


What do you do about non-Windows patching?

Alex


-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com]
Sent: Thursday, June 10, 2010 11:30 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:

What are you guys using for automating patch management for your servers?


 WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Alex Eckelberry]

>  WSUS.

What do you do about non-Windows patching? 

Alex


-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Thursday, June 10, 2010 11:30 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
> What are you guys using for automating patch management for your servers?

  WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Alan Davies]

That's a reason to stage and test before deployment, not a reason to not
auto download/install/reboot thereafter.  Depends on how flexible your
patching product is I guess .. ;)


a 

-Original Message-
From: Angus Scott-Fleming [mailto:angu...@geoapps.com] 
Sent: 11 June 2010 15:11
To: NT System Admin Issues
Subject: Re: Patch Management - again

On 10 Jun 2010 at 15:05, paul d  wrote:

> I pretty much do the same here. Auto download, manual reboot.

I disabled "automatic download" after the failed Excel patch a few
months ago.  
Those machines with "auto download" had downloaded the bad patch. Even
though I 
waited to apply the updates until Microsoft had fixed the Excel patch,
those 
machines didn't check to see if there was a new patch, they just applied
the 
bad patch they had already grabbed.  I had to uninstall the patches and
update 
the machines manually.

I'll probably move to WSUS for my larger clients here soon based on
comments in 
this list.

--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038
Security Blog: http://geoapps.com/





~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


WARNING:
The information in this email and any attachments is confidential and may be 
legally privileged.

If you are not the named addressee, you must not use, copy or disclose this 
email (including any attachments) or the information in it save to the named 
addressee nor take any action in reliance on it. If you receive this email or 
any attachments in error, please notify the sender immediately and then delete 
the same and any copies.

"CLS Services Ltd × Registered in England No 4132704 × Registered Office: 
Exchange Tower × One Harbour Exchange Square × London E14 9GE"



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Alan Davies]

WSUS is great .. as long as you don't have too many cooks sticking their
proverbials in the broth!!  I've used in in tight (>1000 user)
environments and I've participated in it in 320,000 plus user
environments.  It really needs someone to tightly control it, understand
it and maintain it consistently with a single strategy.
 
I've used Shavlik for servers in the past (a bit expensive for
workstations too) with reasonable success.  Auto-rebooting is perfectly
fine for more servers, contrary to popular belief.  Control it via your
schedule agreed in Change Control, don't just willy nilly do the whole
lot at 3am some night!  Leave Exchange, ISA, DBs, etc. that are a bit
more fragile to be rebooted manually (usually better to stop app
services first, then reboot).
 
 
a



From: Joe Tinney [mailto:jtin...@lastar.com] 
Sent: 11 June 2010 13:56
To: NT System Admin Issues
Subject: RE: Patch Management - again



+1

Prior to that we used WSUS for the workstations. On the servers, we use
WSUS to auto-download and do a manual install.

WSUS is really rock solid.

From: Tom Miller [mailto:tmil...@hnncsb.org] 
Sent: Thursday, June 10, 2010 11:32 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

 

We use the Dell Kace KBOX here.  It gets its patching stream from
Patchlink (not that it really matters).  I have no issues with it, and
it's very easy to use.  KBOX is a full management product, so that might
be overkill if you looking for patching exclusively.  

 



>>> "Joseph Heaton"  6/10/2010 11:17 AM >>>
I've been asked to research this arena again.

What are you guys using for automating patch management for your
servers?

Our environment:

A lot of VmWare
Mostly Server 2k8, some 2k8R2, some 2K3.

Not worried about 3rd party application patching within this project.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

 

Confidentiality Notice: This e-mail message, including attachments, is
for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message. 

 

 

 

 



WARNING:
The information in this email and any attachments is confidential and may be 
legally privileged.

If you are not the named addressee, you must not use, copy or disclose this 
email (including any attachments) or the information in it save to the named 
addressee nor take any action in reliance on it. If you receive this email or 
any attachments in error, please notify the sender immediately and then delete 
the same and any copies.

"CLS Services Ltd × Registered in England No 4132704 × Registered Office: 
Exchange Tower × One Harbour Exchange Square × London E14 9GE"


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Angus Scott-Fleming]

On 10 Jun 2010 at 15:05, paul d  wrote:

> I pretty much do the same here. Auto download, manual reboot.

I disabled "automatic download" after the failed Excel patch a few months ago.  
Those machines with "auto download" had downloaded the bad patch. Even though I 
waited to apply the updates until Microsoft had fixed the Excel patch, those 
machines didn't check to see if there was a new patch, they just applied the 
bad patch they had already grabbed.  I had to uninstall the patches and update 
the machines manually.

I'll probably move to WSUS for my larger clients here soon based on comments in 
this list.

--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038
Security Blog: http://geoapps.com/





~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[Joe Tinney]

+1

Prior to that we used WSUS for the workstations. On the servers, we use
WSUS to auto-download and do a manual install.

WSUS is really rock solid.

From: Tom Miller [mailto:tmil...@hnncsb.org] 
Sent: Thursday, June 10, 2010 11:32 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

 

We use the Dell Kace KBOX here.  It gets its patching stream from
Patchlink (not that it really matters).  I have no issues with it, and
it's very easy to use.  KBOX is a full management product, so that might
be overkill if you looking for patching exclusively.  

 



>>> "Joseph Heaton"  6/10/2010 11:17 AM >>>
I've been asked to research this arena again.

What are you guys using for automating patch management for your
servers?

Our environment:

A lot of VmWare
Mostly Server 2k8, some 2k8R2, some 2K3.

Not worried about 3rd party application patching within this project.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

 

Confidentiality Notice: This e-mail message, including attachments, is
for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message. 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[James Rankin]

WSUS for Windows
VMWare Update Manager for ESX
GPOs for all the other crap (Adobe, Java, etc.)
Dell IT Assistant for hardware

On 10 June 2010 16:17, Joseph Heaton  wrote:

> I've been asked to research this arena again.
>
> What are you guys using for automating patch management for your servers?
>
> Our environment:
>
> A lot of VmWare
> Mostly Server 2k8, some 2k8R2, some 2K3.
>
> Not worried about 3rd party application patching within this project.
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>
>


-- 
"On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into
the machine wrong figures, will the right answers come out?' I am not able
rightly to apprehend the kind of confusion of ideas that could provoke such
a question."

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[Rod Trent]

The original intent was to use the SCUP catalog to provide 3rd party
updates, but Microsoft left it up to the vendors to provide the catalog.
The vendors never stepped up.  Of course, you can still deploy 3rd party
updates using Software Distribution, but there's still the pain of
developing the patch distribution with options (i.e., silent, etc.) and
vendors like Adobe are notorious for being clueless about how Enterprises
function.

Microsoft and Shavlik worked together to create SCUPdates.  Shavlik
basically eases the burden of the admin when they have to spend a lot of
time trying to figure out the vendor patch installation options.  Shavlik
does the heavy lifting and gives the admin a tool to deploy updates as
easily and quickly as they can with the regular WSUS catalog downloads.

-Original Message-
From: Andrew Levicki [mailto:and...@levicki.me.uk] 
Sent: Thursday, June 10, 2010 11:40 PM
To: NT System Admin Issues
Cc: NT System Admin Issues
Subject: Re: Patch Management - again

Hi Rod,

Doesn't SCCM already handle third party updates?

I may be wrong.

Andrew.

On 2010/06/11, at 9:13, "Rod Trent"  wrote:

> And, by the way, Shavlik has an awesome add-in for SCCM for 3rd party 
> patching.
>
> -Original Message-
> From: Ziots, Edward [mailto:ezi...@lifespan.org]
> Sent: Thursday, June 10, 2010 7:18 PM
> To: NT System Admin Issues
> Subject: RE: Patch Management - again
>
> Shavlik...
> Z
>
> Edward Ziots
> CISSP,MCSA,MCP+I,Security +,Network +,CCA Network Engineer Lifespan 
> Organization
> 401-639-3505
> ezi...@lifespan.org
>
>
> -Original Message-
> From: Ben Scott [mailto:mailvor...@gmail.com]
> Sent: Thursday, June 10, 2010 11:30 AM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
>
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
> wrote:
>> What are you guys using for automating patch management for your
> servers?
>
>  WSUS.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Andrew Levicki]

Hi Rod,

Doesn't SCCM already handle third party updates?

I may be wrong.

Andrew.

On 2010/06/11, at 9:13, "Rod Trent"  wrote:


And, by the way, Shavlik has an awesome add-in for SCCM for 3rd party
patching.

-Original Message-
From: Ziots, Edward [mailto:ezi...@lifespan.org]
Sent: Thursday, June 10, 2010 7:18 PM
To: NT System Admin Issues
Subject: RE: Patch Management - again

Shavlik...
Z

Edward Ziots
CISSP,MCSA,MCP+I,Security +,Network +,CCA Network Engineer Lifespan
Organization
401-639-3505
ezi...@lifespan.org


-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com]
Sent: Thursday, June 10, 2010 11:30 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
wrote:

What are you guys using for automating patch management for your

servers?

 WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Rod Trent]

And, by the way, Shavlik has an awesome add-in for SCCM for 3rd party
patching.

-Original Message-
From: Ziots, Edward [mailto:ezi...@lifespan.org] 
Sent: Thursday, June 10, 2010 7:18 PM
To: NT System Admin Issues
Subject: RE: Patch Management - again

Shavlik...
Z

Edward Ziots
CISSP,MCSA,MCP+I,Security +,Network +,CCA Network Engineer Lifespan
Organization
401-639-3505
ezi...@lifespan.org


-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com]
Sent: Thursday, June 10, 2010 11:30 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
wrote:
> What are you guys using for automating patch management for your
servers?

  WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Ziots, Edward]

Shavlik...
Z

Edward Ziots
CISSP,MCSA,MCP+I,Security +,Network +,CCA
Network Engineer
Lifespan Organization
401-639-3505
ezi...@lifespan.org


-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Thursday, June 10, 2010 11:30 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
wrote:
> What are you guys using for automating patch management for your
servers?

  WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Steven Peck]

We use SCCM for our servers.

Patches released on Tuesday. - Meeting evaluate
Deploy to development environment on Wednesday
Deploy to Test environment on Thursday
Deploy to production on Saturday

At any time screaming people can throw a wrench if a real problem is
discovered.  Some servers or groupings are on a slightly different
schedule for somethings (telecom) but for the most part we deploy on
over a thousands servers with this schedule.  Generally 'problems'
turn out to be isolated to 'NOT the patch'.

Steven

On Thu, Jun 10, 2010 at 12:05 PM, paul d  wrote:
> I pretty much do the same here.  Auto download, manual reboot.
> However, it's a hospital so I arrange downtime with all the departments
> (since the clinical software will be off-line during the downtime).
> For desktops, I use Shavlik which allows me to patch non-MS products.
>
>> From: kennedy...@elyriaschools.org
>> To: ntsysadmin@lyris.sunbelt-software.com
>> Date: Thu, 10 Jun 2010 12:47:03 -0400
>> Subject: RE: Patch Management - again
>>
>> On the server side that won't change muchI don't think you want
>> download and install automatically as a server option. I have my servers set
>> to download but not install. Then I hit each one and tell it to install, so
>> you skip the step of downloading on each server that is already done.
>>
>>
>>
>>
>> -Original Message-
>> From: Joseph Heaton [mailto:jhea...@dfg.ca.gov]
>> Sent: Thursday, June 10, 2010 12:18 PM
>> To: NT System Admin Issues
>> Subject: Re: Patch Management - again
>>
>> I currently have 67 boxes that I patch manually each month, ranging from
>> XP to 2k8R2. It's actually kind of nice, at the moment, as I do it at night
>> from home, through a VPN back to the office.
>>
>> >>> Phil Brutsche  6/10/2010 9:15 AM >>>
>> +1
>>
>> I get nightmares thinking about what it was like before.
>>
>> On 6/10/2010 10:29 AM, Ben Scott wrote:
>> > On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
>> > wrote:
>> >> What are you guys using for automating patch management for your
>> >> servers?
>> >
>> > WSUS.
>>
>> --
>>
>> Phil Brutsche
>> p...@optimumdata.com
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>>
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>>
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>>
>
> 
> Hotmail is redefining busy with tools for the New Busy. Get more from your
> inbox. See how.
>
>
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[paul d]

I pretty much do the same here.  Auto download, manual reboot.
However, it's a hospital so I arrange downtime with all the departments (since 
the clinical software will be off-line during the downtime).
For desktops, I use Shavlik which allows me to patch non-MS products.

> From: kennedy...@elyriaschools.org
> To: ntsysadmin@lyris.sunbelt-software.com
> Date: Thu, 10 Jun 2010 12:47:03 -0400
> Subject: RE: Patch Management - again
> 
> On the server side that won't change muchI don't think you want download 
> and install automatically as a server option. I have my servers set to 
> download but not install. Then I hit each one and tell it to install, so you 
> skip the step of downloading on each server that is already done.
> 
> 
> 
> 
> -Original Message-
> From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] 
> Sent: Thursday, June 10, 2010 12:18 PM
> To: NT System Admin Issues
> Subject: Re: Patch Management - again
> 
> I currently have 67 boxes that I patch manually each month, ranging from XP 
> to 2k8R2.  It's actually kind of nice, at the moment, as I do it at night 
> from home, through a VPN back to the office.
> 
> >>> Phil Brutsche  6/10/2010 9:15 AM >>>
> +1
> 
> I get nightmares thinking about what it was like before.
> 
> On 6/10/2010 10:29 AM, Ben Scott wrote:
> > On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
> >> What are you guys using for automating patch management for your servers?
> > 
> >   WSUS.
> 
> -- 
> 
> Phil Brutsche
> p...@optimumdata.com 
> 
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
> 
> 
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
> 
> 
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
> 
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Kennedy, Jim]

On the server side that won't change muchI don't think you want download 
and install automatically as a server option. I have my servers set to download 
but not install. Then I hit each one and tell it to install, so you skip the 
step of downloading on each server that is already done.




-Original Message-
From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] 
Sent: Thursday, June 10, 2010 12:18 PM
To: NT System Admin Issues
Subject: Re: Patch Management - again

I currently have 67 boxes that I patch manually each month, ranging from XP to 
2k8R2.  It's actually kind of nice, at the moment, as I do it at night from 
home, through a VPN back to the office.

>>> Phil Brutsche  6/10/2010 9:15 AM >>>
+1

I get nightmares thinking about what it was like before.

On 6/10/2010 10:29 AM, Ben Scott wrote:
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>> What are you guys using for automating patch management for your servers?
> 
>   WSUS.

-- 

Phil Brutsche
p...@optimumdata.com 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Re: Patch Management - again

[Joseph Heaton]

I currently have 67 boxes that I patch manually each month, ranging from XP to 
2k8R2.  It's actually kind of nice, at the moment, as I do it at night from 
home, through a VPN back to the office.

>>> Phil Brutsche  6/10/2010 9:15 AM >>>
+1

I get nightmares thinking about what it was like before.

On 6/10/2010 10:29 AM, Ben Scott wrote:
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>> What are you guys using for automating patch management for your servers?
> 
>   WSUS.

-- 

Phil Brutsche
p...@optimumdata.com 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Phil Brutsche]

+1

I get nightmares thinking about what it was like before.

On 6/10/2010 10:29 AM, Ben Scott wrote:
> On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
>> What are you guys using for automating patch management for your servers?
> 
>   WSUS.

-- 

Phil Brutsche
p...@optimumdata.com

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[James Kerr]

Yeah I just use WSUS for our desktops and servers as well.

James


- Original Message - 
From: "Ben Scott" 

To: "NT System Admin Issues" 
Sent: Thursday, June 10, 2010 11:29 AM
Subject: Re: Patch Management - again


On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  
wrote:

What are you guys using for automating patch management for your servers?


 WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~ 



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Kennedy, Jim]

If this is just OS patching you just need WSUS, and I would talk to the other 
group about switching the desktops to that also.  Single point of download so 
all those clients are not hitting your internet connectionyou decide what 
(and when) updates to deploy...not some set of rules by MS.

Free and very reliable. I am thrilled with it.

-Original Message-
From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] 
Sent: Thursday, June 10, 2010 11:36 AM
To: NT System Admin Issues
Subject: RE: Patch Management - again

Desktops is done by a different group.  We currently are a Novell environment, 
with a Windows application domain.  I personally have both of my machines in 
the Windows domain, and doing updates myself.  I think the desktop group has 
the clients automatically downloading and installing updates directly from 
Microsoft.  Most of our desktops are not in the Windows domain.

>>> "Rod Trent"  6/10/2010 8:28 AM >>>
You're wanting this just for servers?  What are you currently using for 
desktops?

-Original Message-
From: Joseph Heaton [mailto:jhea...@dfg.ca.gov]
Sent: Thursday, June 10, 2010 11:17 AM
To: NT System Admin Issues
Subject: Patch Management - again

I've been asked to research this arena again.

What are you guys using for automating patch management for your servers?

Our environment:

A lot of VmWare
Mostly Server 2k8, some 2k8R2, some 2K3.

Not worried about 3rd party application patching within this project.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ 
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Sean Rector]

+1

Sean Rector, MCSE


-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Thursday, June 10, 2010 11:30 AM
To: NT System Admin Issues
Subject: Re: Patch Management - again

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton 
wrote:
> What are you guys using for automating patch management for your
servers?

  WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~
2010-2011 subscriptions are on sale now!   Featuring: 
Rigoletto   |   Cos? Fan Tutte   |   The Valkyrie   |   Madama Butterfly

Visit us online at www.VaOpera.org or call 1-866-OPERA-VA

The vision of Virginia Opera is to enrich lives through the powerful 
integration of music, voice and human drama.




This e-mail and any attached files are confidential and intended solely for the 
intended recipient(s). Unless otherwise specified, persons unnamed as 
recipients may not read, distribute, copy or alter this e-mail. Any views or 
opinions expressed in this e-mail belong to the author and may not necessarily 
represent those of Virginia Opera. Although precautions have been taken to 
ensure no viruses are present, Virginia Opera cannot accept responsibility for 
any loss or damage that may arise from the use of this e-mail or attachments.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: Patch Management - again

[Joseph Heaton]

Desktops is done by a different group.  We currently are a Novell environment, 
with a Windows application domain.  I personally have both of my machines in 
the Windows domain, and doing updates myself.  I think the desktop group has 
the clients automatically downloading and installing updates directly from 
Microsoft.  Most of our desktops are not in the Windows domain.

>>> "Rod Trent"  6/10/2010 8:28 AM >>>
You're wanting this just for servers?  What are you currently using for
desktops?

-Original Message-
From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] 
Sent: Thursday, June 10, 2010 11:17 AM
To: NT System Admin Issues
Subject: Patch Management - again

I've been asked to research this arena again.

What are you guys using for automating patch management for your servers?

Our environment:

A lot of VmWare
Mostly Server 2k8, some 2k8R2, some 2K3.

Not worried about 3rd party application patching within this project.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Tom Miller]

We use the Dell Kace KBOX here.  It gets its patching stream from Patchlink 
(not that it really matters).  I have no issues with it, and it's very easy to 
use.  KBOX is a full management product, so that might be overkill if you 
looking for patching exclusively.  
 


>>> "Joseph Heaton"  6/10/2010 11:17 AM >>>
I've been asked to research this arena again.

What are you guys using for automating patch management for your servers?

Our environment:

A lot of VmWare
Mostly Server 2k8, some 2k8R2, some 2K3.

Not worried about 3rd party application patching within this project.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~


Confidentiality Notice:  This e-mail message, including attachments, is for the 
sole use of the intended recipient(s) and may contain confidential and 
privileged information.  Any unauthorized review, use, disclosure, or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: Patch Management - again

[Ben Scott]

On Thu, Jun 10, 2010 at 11:17 AM, Joseph Heaton  wrote:
> What are you guys using for automating patch management for your servers?

  WSUS.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: Patch Management - again

[Rod Trent]

You're wanting this just for servers?  What are you currently using for
desktops?

-Original Message-
From: Joseph Heaton [mailto:jhea...@dfg.ca.gov] 
Sent: Thursday, June 10, 2010 11:17 AM
To: NT System Admin Issues
Subject: Patch Management - again

I've been asked to research this arena again.

What are you guys using for automating patch management for your servers?

Our environment:

A lot of VmWare
Mostly Server 2k8, some 2k8R2, some 2K3.

Not worried about 3rd party application patching within this project.


~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
  ~


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~