Start-WUScan on remote PC

[Gordon Pegue]

Thought this would work but I’m missing something:

 

PS C:\WINDOWS\system32> $ComputerName = 'PDITSLTDL01A'

 

PS C:\WINDOWS\system32> $session = New-PSSession $ComputerName -Credential $cred

 

PS C:\WINDOWS\system32> Invoke-Command -Session $session -ScriptBlock { Start-WUScan -SearchCriteria "Type='Software' AND IsInstalled=0" }

Provider load failure

    + CategoryInfo          : NotSpecified: (root/Microsoft/...FT_WUOperations:String) [Invoke-CimMethod], CimException

    + FullyQualifiedErrorId : HRESULT 0x80041013,Microsoft.Management.Infrastructure.CimCmdlets.InvokeCimMethodCommand

    + PSComputerName        : PDITSLTDL01A

Scan hit error: .ReturnValue

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Start-WUScan

    + PSComputerName        : PDITSLTDL01A

 

I know the remote session is instantiated properly because another part of the larger script that uses an Invoke-Command line to write to the remote registry works just fine.

 

It looks – based on google hits from my searches – like the Start-WUScan module was deprecated/removed starting with version 2004.

 

So my questions are:

 

Is there an alternative I can use with Invoke-Command that doesn’t require me to physically touch all the remote PC’s and install the PSWindowsUpdate module in PS?

Or is there a way to install that module via Invoke-Command?

 

What am I trying to do:

Set the TargetReleaseVersionInfo to 20H2 on machines that are on version 2004 (this part works) and then trigger a scan for updates in order to pull down the 20H2 enablement package.

 

I just found this:

https://katystech.blog/powershell/ps-remotely-updating-devices

And it looks like it might provide all my answers.

 

Someone want to concur or offer an alternative while I digest that article?

 

TIA

Gordon

[Michael B. Smith]

WU PS module was not just deprecated, but deimplemented. Pissed me off big time. Broke life cycle management promises.

 

There are replacements, but using PSWindowsUpdate is easier than the built-in replacements. Go for it.

--
You received this message because you are subscribed to the Google Groups "ntpowershell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntpowershell...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB31443E4277472AB0DE0505F1D30F9%40CY4PR07MB3144.namprd07.prod.outlook.com.

[Kurt Buff]

PSWindowsUpdate will work against remote machines..

Kurt

--

[Gordon Pegue]

Hey Michael et al –

 

Part of my learning curve with PSWindowsUpdate has included defining TrustedHosts.

 

For the command Set-Item wsman:localhost\client\trustedhosts, can I use the example string *.ou.fabrikam.com to specify the computers that are in an OU?

Can’t seem to find anything on this with google.

I do see how to add everything in the domain (that would be *.fabrikam.com), but our university domain has tens of thousands of computer objects. I only need the computers in my OU (<100).

 

 

TIA

Gordon

 

From: ntpowe...@googlegroups.com <ntpowe...@googlegroups.com> On Behalf Of Michael B. Smith
Sent: Monday, March 14, 2022 3:04 PM
To: ntpowe...@googlegroups.com

Subject: [ntpowershell] RE: Start-WUScan on remote PC

 

  [EXTERNAL]

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/1bc3c78cf85245968788c11166eed5c5%40smithcons.com.

[Michael B. Smith]

Nope. Trusted hosts are based on FQDNs and IP addresses, not OUs.

 

See

 

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting?view=powershell-5.1#how-to-add-a-computer-to-the-trusted-hosts-list

 

and

 

https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/about/about_wsman_provider?view=powershell-5.1#setting-the-value-of-items-in-the--wsman-drive

 

You can list them all individually. Or via a subnet.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB3144A207C96E90532C03A388D3109%40CY4PR07MB3144.namprd07.prod.outlook.com.

[Mike Leone]

I's that necessary for using the PSWindowsUpdate mostly, to scan a remote server? Does that need to be done on the remote server? I've never used the WSMan commands to list a Trusted Host, although I have used that PSWindowsUpdate module to query last Windows Update applied.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/42aee747472441edb390e08939fbe572%40smithcons.com.

[Michael B. Smith]

No, if everything is in a domain, you only need TrustedHosts if you are trying to identify a “special” class of computers.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CAHBr%2B%2Bhe0XdZy3Zh9yqeZbG8kfkJThKsQ2oGuOV4mc3DgGR0Lg%40mail.gmail.com.

[Gordon Pegue]

Rats. Never an easy way…

 

Read that 1^st link article. The *.fabrikam.com example is what made me wonder if it could be more granular to the OU level…

 

So now my question is this:

Is there a potential security risk in leaving the TrustedHosts list populated?

Or should any scripts I code that need it populate it on the fly, use it and then blank it out?

 

Thanks,

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/42aee747472441edb390e08939fbe572%40smithcons.com.

[Michael B. Smith]

What’s your level of paranoia?

 

(Personally, I’m not paranoid enough to blank it after each use – but I do all of this stuff in a separate VM anyway. That’s what I’d recommend.)

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB3144D65A66EDBA47ADAD1831D3119%40CY4PR07MB3144.namprd07.prod.outlook.com.

[Gordon Pegue]

Good riposte!

 

For my department (I’m a one-man IT shop), risk is acceptable given physical precautions.

 

I’ve seen both you and Kurt mention the VM-for-admin method before. Methinks it might be time to look into that a bit…

 

Thanks,

Gordon

 

 

From: ntpowe...@googlegroups.com <ntpowe...@googlegroups.com> On Behalf Of Michael B. Smith
Sent: Wednesday, March 16, 2022 9:28 AM
To: ntpowe...@googlegroups.com
Subject: [ntpowershell] RE: Start-WUScan on remote PC

 

  [EXTERNAL]

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/03547e7fc8fa403fb3f05819cea05d35%40smithcons.com.

[Kurt Buff]

If you're going to use a VM, use that as your daily driver - email, web browsing, other Office apps.

Use the physical host as your admin station.

Why? Because it's a whole lot harder to break out of a VM into a host (especially if the user on the VM isn't privileged) than it is to control a VM from the host (even if the user on the host isn't privileged).

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/securing-privileged-access-for-the-ad-admin-part-1/ba-p/259166

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/securing-privileged-access-for-the-ad-admin-part-2/ba-p/259167

Kurt

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB3144D9C3EF5B0DB99B9BAB6BD3119%40CY4PR07MB3144.namprd07.prod.outlook.com.

[Gordon Pegue]

In my efforts to construct a script using the tools in PSWindowsUpdate, I’ve come to realize something I can’t seem to puzzle out.

 

It looks like MS, in their infinite wisdom, ties all the recent Windows 10 Feature Update Enablement (FUE) packages to the same darn KB # (KB5011487).

Thus I’m having difficulties coding my script to determine if (say for example) to 20H2 FUE package is _available_ but not yet installed.

 

Right now, my script uses this: (Get-HotFix -Id KB5011487) as part of the conditional.

That doesn’t tell me _which_ FUE package is installed.

 

Tips? Hints?

 

TIA

Gordon

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB3144D9C3EF5B0DB99B9BAB6BD3119%40CY4PR07MB3144.namprd07.prod.outlook.com.

[Michael B. Smith]

PS C:\scripts> $c = & hostname.exe

 

PS C:\scripts> reg query "\\$c\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DisplayVersion

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

    DisplayVersion    REG_SZ    21H2

 

PS C:\scripts> reg query "\\$c\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

    UBR    REG_DWORD    0x22c

 

PS C:\scripts> reg query "\\$c\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

    CurrentBuild    REG_SZ    22000

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB31446E5898A9BDDA58F7D7D9D3129%40CY4PR07MB3144.namprd07.prod.outlook.com.

[Gordon Pegue]

Dang it! A registry dip!p;rovgueprvgojovk

 

Here’s what works in my script:

$r = (Invoke-Command -Session $session -ScriptBlock { Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" -Name "DisplayVersion" }).DisplayVersion

 

Then I can use the $r in my comparison check!

 

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/ca01080c274e436c96b78eccf42b3dfd%40smithcons.com.

[Gordon Pegue]

Pardon the gibberish after the first !

Not exactly sure what happened there.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntpowershell/CY4PR07MB31440429AE435D5D18CAFE42D3129%40CY4PR07MB3144.namprd07.prod.outlook.com.