Install a Windows Patch to Remote Vista Machine?

Hi,

Sometimes we have to get "hotfixes" from Microsoft that are not part of
the usual Windows Update cycle. I'd like to programatically roll them
out (and roll them back) on specific machines.

On a local machine, you can scan the machine, then call the download and
install methods for a specific patch, but this doesn't work on a remote
machine (using COM). It can be done with PsExec, but it's messy. Can it
be done in PowerShell?

--
Gerry Hickman (London UK)

You may be able to do it WMI - need to dig into it. Otherwise have a look at
the SpecOps Command product - I think there is a free version that may do
what you want
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Gerry Hickman" wrote:

Hi Rich,

I'm asking how to do it with PowerShell!

Regarding "doing it with WMI" can you be more specific, how would I get
the return values, reboot status etc? Regarding SpecOps, I'm asking
about how to do it with Microsoft tools and technologies; the o/s and
patch are BOTH Microsoft, I should not need some 3rd party add-on.

RichS wrote:
--
Gerry Hickman (London UK)

> On a local machine, you can scan the machine, then call the download and Perhaps I've been away from sys admin too long. Are you doing all of
this from the command-line? Can you provide more details?

You seem to dislike winrm which would help with remote "COM'ing" indirectly.

Marco

Hi Marco,

Yes, you can do it from a command line. e.g. for patches that are
already on WU/MU: Using JScript you can instantiate the Windows Update
COM objects, you then scan the machine, filter the patch collection
based on the patch you want to apply, then call the Download and Install
methods, you can trap errors, check for reboot. Once you have the
JScript, you can remote it using PsExec.

My question is, how do you do this the "new way", as in PowerShell,
..NET, etc.

Marco Shaw [MVP] wrote:
--
Gerry Hickman (London UK)

Gerry Hickman wrote: Interesting...

PSH> $wu=new-object -comobject microsoft.update.autoupdate
PSH> $wu|get-member


TypeName: System.__ComObject#{4a2f5c31-cfd9-410e-b7fb-29a653973a0f}

Name MemberType Definition
---- ---------- ----------
DetectNow Method void DetectNow ()
EnableService Method void EnableService ()
Pause Method void Pause ()
Resume Method void Resume ()
ShowSettingsDialog Method void ShowSettingsDialog ()
Results Property IAutomaticUpdatesResults Results () {get}
ServiceEnabled Property bool ServiceEnabled () {get}
Settings Property IAutomaticUpdatesSettings Settings () {get}

Now, you're using COM still. Unless there's a .NET library for this,
and I'd doubt it, this is the easiest way to access WU from PowerShell
very likely.

Not a fault of PowerShell if WU doesn't have other interfaces...

Marco

It appears the WSUS *server* has a class library (written in .NET).
That class library would likely work very well if called from
PowerShell, but I can't tell you what kind of functionality it would
offer you.

Marco

Hi Marco,

OK, at last we're getting some sensible answers!
It's the fault of Microsoft for not supplying them.

--
Gerry Hickman (London UK)

Hi Marco,
Yup, good observation, but WSUS is actually not very useful in this
case. The "power" is in the client tools, plus in our case we don't run
WSUS

--
Gerry Hickman (London UK)

Hi Marco,
Yup, so much for .NET when you need to do anything useful. It's "Back to
COM" as always.

--
Gerry Hickman (London UK)