Karl
Mon Dec 15 15:52:23 CST 2003
Good news, according to a public post at www.susserver.org, SUS 2.0 fixes
the biggest limitations of 1.0 [such as reporting] and according to publicly
available news reports, might be out in first quarter 2004. Keep in mind
that SUS is free and is version 1.0 If you went to a third party
solution, you'd probably have to install the client onto all the
workstations, unlike the SUS client which is already installed by the latest
Windows service packs. The SUS clients are probably already at 2.x or will
update themselves automatically, all you would probably need to do is update
your SUS server(s) when it is released.
For the time being, you can check either the windows System event logs on
the clients and/or the IIS log file on the SUS server. There is a free tool
and web site at www.susserver.org that parses your IIS log for you. For
checking the windows event logs, you could use free log dumping tools like
the one at www.sysinternals.com If you can check either one of these or
both, then you have less of a need to run an MBSA scan to confirm SUS is
working.
I don't think the scanning limitations is necessarily a big or unique
limitation. I would choose to run network scans myself so I have one report
instead of multiple disparate reports. Running it locally is not
necessarily guaranteed to happen reliably either. It does impact you, but
MBSA is free. Other people have complained about it needing admin
permissions to run, but Microsoft must have had a reason for designining it
that way [possibly to try to prevent misuse... would you really want any
non-admin having access to that information for every computer on your
network?].
As far as getting MBSA to work locally, you could write a script to download
the XML file yourself from microsoft.com and copy it to the c:\ drive onto
every computer once a day/week/whatever. Not ideal, but should be doable on
a 250 client network. Then, use the command in MBSA to use the XML file
from the c:\ drive.
Last, even if you can't confirm whether SUS is working reliably, I still
think running it is probably better than not running it. I know SMS
environments where they can't confirm whether patches are being installed
correctly either. Patch management is ALWAYS going to fail some of the
time, no matter which solution you pick. But SUS so far seems to me as
reliable as anything else if not more.
Hope this helps.
"Mr Brownstone" <anonymous@discussions.microsoft.com> wrote in message
news:C1B32077-BFF3-49DE-A46E-9CB9308CD963@microsoft.com...
> Hi there
>
> I've deployed SUS. That bit's all fine and working well (I think).
>
> The problem is, I only think it is. As all the documentation says, I need
to verify that the patch management is happening on all my machines.
>
> I'm fully aware of tools like MBSA, MBSACLI, hfnetchk, etc. They all have
one problem. They are built as network scanners and a machine that is
turned off at the time you run the scan will not be scanned.
>
> I would like to be able to run MBSA on each machine at startup or when a
user logs in. This would ensure that machines are scanned regularly. If I
relied on regular scanning from my workstation, I would not scan any machine
that boots up only in the evening. Also, laptops that come on site for only
a few hours a month can be scanned as well. In this scenario, the very
machines that present the greatest risk to a business are the ones that
don't get scanned.
>
> Back to running MBSACLI on bootup or login -- I can't! MBSA only runs
with administrative rights! What's more, if I use a computer startup script
in group policy, the process runs under the system account and can't attach
to the network to get the mssecure.xml file or to connect to SUS.
>
> Am I the only one who thinks this is a severe shortcoming? Bigger
environments can afford SMS (both the product cost and the skills required
to administer it). In a 250-user environment this just isn't going to
happen.