remote GCI recurse filter not showing items...

Hi all,

I have written a query to list certain certificates from a list of servers based on a list of criteria against filterscript as below:

The script works perfectly however some systems in the list are not having their matching objects added to a variable, I.E. the recurse and filterscript is not retrieving the matching data, I have checked against these offending systems manually and again it does not retrieve anything, the value of $Currentsystem is empty.

I have checked that PSremoting is enabled and that other security such as UAC is disabled etc.

Does anyone have any idea why some servers refuse to return any data when after checking they should?

I end up with a list of several servers with certificate information based on my filterscript search but the ones it does not retrieve any information for are obviously omitted.

Any ideas?

Many thanks!

Apologies, I failed to enter the code block correctly, please find below:

 $CurrentSystem = Invoke Command -Computername $COMP -scriptblock{cd Cert:\LocalMachine;Get-ChildItem -recurse | select -property PSParentPath, version, SerialNumber, Issuer, subject, notbefore, notafter -ExcludeProperty PSComputerName, RunspaceId | where-object -filterscript {$PSItem.issuer -like "*lbg*" -or $PSItem.issuer -like "*lloyds*" -or $PSItem.issuer -like "*lgt*" -or $PSItem.issuer -like "*verint*" -or $PSItem.issuer -like "*witness*"}} 

Hi guys,

I know my code block was incorrect ‘invoke-command’ was missing the hyphen which may have caused quite a few of you to simply ignore my post which is fair enough, however just incase anyone should want to know, I have answered my own issue.

I was using $PSitem operator within my filterscript which is native only to Powershell version 3 and above, some of my servers are stil only using PS version 2 so I needed to substitute my $PSitem for the older $_. operator.

Hey Martin,

That’s good to know re V2 and well done for figuring it out, isn’t it good when you have that Ahhh moment :slight_smile:
I personally would have left the PSComputername property as in below so you can see which ones are and are not working. I added the Geotrust thing to it too for my testing on my PC BTW.

$CurrentSystem = Invoke-Command -Computername $COMP -scriptblock{
    Set-Location Cert:\LocalMachine;Get-ChildItem -recurse -Force | 
    Select-Object -property PSParentPath, version, SerialNumber, Issuer, subject, notbefore, notafter -ExcludeProperty RunspaceId | 
    where-object -filterscript {$PSItem.issuer -like "*lbg*" -or 
                                $PSItem.issuer -like "*lloyds*" -or 
                                $PSItem.issuer -like "*lgt*" -or 
                                $PSItem.issuer -like "*verint*" -or 
                                $PSItem.issuer -like "*witness*" -or
                                $PSItem.Issuer -like "*GeoTrust*"}} 

I know in an enterprise, this may not be your call / job, but as for your servers being on PoSH v2, you really want to get those updated. You are not really gaining anything by staying v2, you are losing significant things. You are going to have to get off of it as you upgrade, as per recent guidance from MS …

Windows PowerShell 2.0 Deprecation
Windows PowerShell 2.0 Deprecation - PowerShell Team

later versions of the OS, v2 is off by default, though still supported, sure you can turn it back on, but…

… and other concerns, v2 should be disabled on any systems using it today, and move to a new version for better controls, management, auditing, etc… Though, you should test things before upgrading, IMHO, v4 at a minimum and v3 and below scripts will still work. You can easily update via GPO, DSC, System Center, etc… But a reboot is required, so planning is a thing as well.

Practical Reasons for Upgrading to PowerShell 4.0
Practical Reasons for Upgrading to PowerShell 4.0 - Scripting Blog

Defending Against PowerShell Attacks
Defending Against PowerShell Attacks - PowerShell Team

… again, just saying…