Get-WMIObject & Get-CimInstance

We have a script we run through BigFix to check for product readiness. The script is zipped with a set of functions and it calls out each function, stores the data, then writes all the results to an HTML file. The zip file gets copied to the server and then we use a BigFix action script to run Powershell.exe with execution policy set to bypass.

We are having an issue with one of the functions, only when running it through BigFix. I have tried running our scripts through Powershell as me and as SYSTEM and it doesn’t matter. If I run it manually everything runs fine. If I run it through BigFix it fails, I think on get-wmiobject. I’m wondering if this is a known issue with security settings or something?

This is the function we are having issues with. I originally tried with get-wmiobject and I have tried get-ciminstance. We changed to gmwi since the other function works like that but this one still fails. It gives me an output of FUBAR. If I run the script manually after BigFix copies it to the machine and unzips it then it says VMWare Tools is installed.

function Get-VirtGuestTool {
  $scriptName         =   '150-VirtGuestTool.ps1'
  $checkName          =   'VirtGuestTool'
  $checkDescription   =   'Test if virtual guest software is installed'
  $checkState         =   ''
  $data               =   ''
  $elapsed = [System.Diagnostics.Stopwatch]::StartNew()

  try
  {

$computerProperties = gmwi win32_computersystem
        
$InstalledSoftware = Get-ChildItem "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall"
$softwareTable = @()
foreach ($obj in $InstalledSoftware) { 
    $data = New-Object PSObject
    $data | Add-Member -Type NoteProperty -Name "Name" -Value $obj.GetValue('DisplayName')
    $data | Add-Member -Type NoteProperty -Name "Version" -Value $obj.GetValue('DisplayVersion')
    $softwareTable += $data
}

# $Endpoint = ""

# $Tools2 = ""
# $Tools3 = ""

If ($computerProperties.Manufacturer -eq "Nutanix" -or $computerProperties.Manufacturer -like "*VMware, Inc.*") {
    
    if ($softwareTable.Name -like "*Nutanix*" -and $softwareTable.Name -like "*Nutanix Guest Tools*" -and $softwareTable.Name -like "*Nutanix VM Mobility*") {
        $OK = "1"
        $Reason = "Found Nutanix software required to pass PRV in the list of installed software!!"
        }
        elseif ($softwareTable.Name -like "*VMware*") {
        $OK = "1"
        $Reason = "VMWare Tools is installed"}
        
    
}

ElseIf ($computerProperties.Manufacturer -like "*Microsoft*" -and $computerProperties.Model -like "*Virtual*") { 
    $Tools = 'NA - Azure'
    $OK = "1" 
    $Reason = $Tools
}
ElseIf ($computerProperties.Manufacturer -ne "Nutanix" -and $computerProperties.Manufacturer -notlike "*VMware, Inc.*" -and $computerProperties.Manufacturer -notlike "*Microsoft*") { 
    $Tools = 'NA - Physical' 
    Write-Output "Server is physical. No tools required"
    $OK = "1"
    $Reason = $Tools
    }

Else { 
    $Tools = 'Not Installed' 
    $OK = "0"
$Reason = "Guest tools need to be installed on server"
}
 }
 Catch {
$OK = "0"
$Reason = "FUBAR"
}



  Write-Output "[$(Get-Date -UFormat %I:%M:%S)] Generating Windows Virt Guest Tools Report"
  Add-RequiredCheckListItem 'VirtGuestTool' $ok $reason
  }

This is the function that works. I put % instead of the account here but that doesn’t matter.

function Get-LocalAdmin {
  $scriptName         =   '160-.ps1'
  $checkName          =   'LocalAdmin'
  $checkDescription   =   'Verifies non-domain joined servers have the % account and it is not the default SID.'
  $checkState         =   ''
  $data               =   ''
  $elapsed = [System.Diagnostics.Stopwatch]::StartNew()



if ((gwmi win32_computersystem).partofdomain -eq $true)
    {
    $OK = "1"
    $Reason = "Server is domain joined. % is not required."
    }

    Elseif ((gwmi win32_computersystem).partofdomain -eq $false)
    {
    
    #% is default SID
    If (Get-LocalUser | Where {($_.name -eq '%%') -AND ($_.SID -like "S-1-5-21*500")})
        {
        $OK = "0"
        $Reason = "The % account is using the default SID"
        } 
       #% is default SID
        ElseIf (Get-LocalUser | Where {($_.name -eq '%%') -AND ($_.SID -notlike "S-1-5-21*500")})
        {
        $OK = "1"
        $Reason = "% account exist and is not using the default SID"
        }
        Else
        {
        $OK = "0"
        $Reason = "% account is not configured on a non-domain joined server"
        }

    }
   

  Write-Output "[$(Get-Date -UFormat %I:%M:%S)] Generating Windows Local Admin Account Report"
  #Function defined in lib\add-requiredchecklistitem.ps1
  Add-RequiredCheckListItem "LocalAdmin" $ok $reason

Is this using the PowerShell script type instead of ActionScript?

I’d have to try it out, but I wonder whether we’re using 32-bit PowerShell with that script type…if you try to run it on a command line with the 32-bit PowerShell, via C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe, does it give the same error?

Edit - found the reference, we should be using 64-bit powershell by default, if it’s present, per https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Console/Dialogs/action_script_tab.html

Just changed to the full path. Still failing

Ok, I’m not understanding the structure here - are you using the PowerShell ActionScript type, or using the ActionScript type, building a PowerShell script, and then launching PowerShell.exe via ‘waithidden’ ?

The full-path to PowerShell you have is the 32-bit version of PowerShell. To use the 64-bit, you will have to both

  • Include action uses wow64 redirection false in the ActionScript, on any line before launching the ‘wait’ command.
  • Reference the native PowerShell.exe path beneath system32

We are not using PowerShell Action Script. We are using the BigFix Action Script. The reason is we download a a main script and a bunch of functions then run the main script which kicks off all the functions. One of the functions has gmwi and it works fine. This one does not work. It seems to trip out on get-wmiobject and get-ciminstance. We have to use BigFix Action Script though because of the way everything is set up.

This is not happy either

1 Like

It’s missing the ‘action’ at the beginning of ‘action uses wow64 redirection false’

Unfortuntely that didn’t work either. I think I might have to add a lot more debugging into this script to figure out what is going on.

OK I figured out what the problem is but I’m wondering why.

It has to do with Get-ChildObject HKLM.

When I test locally using the SYSTEM account in PowerShell it can read everything just fine. When BigFix runs PowerShell it only pulls some of the software and failed to grab VMWare. I was told BigFix uses the SYSTEM account so why is it running into permissions issues? Is this a known issue.

I’m still thinking 32-bit redirection.
When you say it pulls “only some of the software”, did it actually return only the things under Wow6432Node? That’s where the 32-bit registry call would be redirected.

1 Like

You nailed it. I dont know why the command yesterday didn’t work then. THis is what I had output during my debug and the wow6432 uninstall.

The BESClient does run as LocalSystem, but spawns all processes (like PowerShell) in 32-bit mode by default.

That’s why you need

action uses wow64 redirection false

In the ActionScript before launching PowerShell. See whether you get your expected results when you include that statement.

( The filesystem is automatically redirected to 32-bit paths as well, so if you don’t disable the redirection first, even explicitly calling c:\windows\system32 gets redirected to the 32-bit path c:\windows\syswow64. Ditto for Program Files to Program Files (x86) )

That single quote is not a problem? I tried this yesterday right above the wait command that ran PS. Wondering if maybe I just should have put it at the top of the action script instead. I also did not have a single quote at the end, I used
action uses wow64 redirection false

I’m using Get-Package now and not having an issue.

That single quote is a problem…will fix above