remote GCI recurse filter not showing items...

This topic contains 4 replies, has 3 voices, and was last updated by  postanote 5 days, 19 hours ago.

  • Author
    Posts
  • #84133

    Martin
    Participant

    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!

  • #84134

    Martin
    Participant

    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*"}} 
  • #84170

    Martin
    Participant

    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.

  • #84209

    Alex Aymonier
    Participant

    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 🙂
    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*"}} 
    
    
    • #84254

      postanote
      Participant

      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
      'blogs.msdn.microsoft.com/powershell/2017/08/24/windows-powershell-2-0-deprecation'

      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
      'blogs.technet.microsoft.com/heyscriptingguy/2014/10/22/practical-reasons-for-upgrading-to-powershell-4-0'

      Defending Against PowerShell Attacks
      'blogs.msdn.microsoft.com/powershell/2017/10/23/defending-against-powershell-attacks'

      ... again, just saying...

You must be logged in to reply to this topic.