Understanding Powershell and WQL in CruzOC for Windows Client and Windows Server Endpoints

Client and server Management This document describes support for the windows OS management and monitoring features introduced in 8.0.1. Windows OS Discovery Via WMI now also supports Powershell Remoting and Windows Query language (WQL)

Powershell Action scripts may executed against targets that support Powershell. This includes Windows OS and includes HyperV, Azure as well as systems that have modules that support Powershell (for example VMware PowerCLI ). Powershell remoting is a process where a powershell script is encapsulated locally and then executed on a remote target via WinRM protocol. Powershell scripts can be created in the Actions portlet similar to the way other action are created. Some Powershell action have been pre-seeded in 8.0.1. These can be found by searching for "Windows (PS)" in the action name in the action portlet. These will also be listed from the Resource manager -> right click -> Action menu for WMI discovered devices.

WQL is a query language similar to SQL. Action scripts can be created in the form of a WQL query. WQL actions are created in the Action portlet similar to other actions. Pre-seeded WQL actions can be found by searching for "WQL" in the action portlet. These will also be listed from the Resource manager -> right click -> Action menu for WMI discovered devices.

These new capabilities also mean that Compliance policies may be created and executed on the PS or WQL output so you can now keep Client and server OS’s in compliance with your unique policy requiremetns.

Pre-requisites

•  CruzOC must be installed on on a Window OS. WMI and Powershell are native to Windows
   Dot net 3.5 is also required to for WMI (Dot net 4.6 or higher is recommended)
• CruzOC must have WMI access on all target machines with firewall permitted access on the required ports. Administrator credentials are required for WMI.  In some cases WMI may need to be configured to allow access see - https://docs.microsoft.com/en-us/windows/win32/wmisdk/troubleshooting-a-remote-wmi-connection
  
  
• Disable file sharing - View network status and tasks under Network and Internet. ->  Select Change advanced sharing settings in Network and Sharing Center. -> Choose Turn off file and printer sharing, and tap Save changes.  
• Some Powershell scripts may not work on older powershell versions. 5.1 or higher Is recommended (See Appendix A)
• WMI  ports:
  • TCP port 135 and a range of dynamic ports:
  • TCP 49152-65535 (RPC dynamic ports – Windows Vista, 2008 and above)
  • TCP 1024-65535 (RPC dynamic ports – Windows NT4, Windows 2000, Windows 2003)
  • Widows Performance Counter Access: TCP port 445 (SMB, RPC/NP)
• Enable Powershell remoting
• On each target issue command
  • Enable-PSRemoting  -force  
  • Set-Item WSMan:localhost\client\trustedhosts -value *
  • Note: trusted host may be set an needed. The “–value *” Is recommended initially for validating the use and reduce troubleshooting of powershell in your environment. This can be locked down later through manual update or via group Policy. At a minimum, the NMS server must be a trusted host.
  • You may also need to set you execution poilcy as follows:
    • PS C:\Users\Administrator> set-executionpolicy remotesigned
      
      Execution Policy Change
      The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
      you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
      policy?
      [Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): 
• Verify remoting is set up correctly on clinet and host with this command    winrm quickconfig
• Requires no public networks or else will get :   Message>WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.
• https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting?view=powershell-6
• Your execution policy may need to be modified to allow Powershell execution on remote targets
• https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-6

• Powershell ports: By default, enabling PowerShell remoting enables both an http and an https listener.
  • The listeners run on default ports 5985 for http and 5986 for https. Powers shell remoting must be configured /enabled on the target machines.  
• Administrator credentials are required for each target machine

Scripts Creation and execution

WQL and Powershell scripts are created in the Actions portlet by highlighting a row -> right Click - > New.  Generally you will create a Show or Configure script depending on the script objectives. Refer to the Action section of the user guide or help set to get help with basic actions.

For Powershell or WQL you may select embedded CLI or Perl as a way to issues command to targets. For Powershell (PS) you can cut and paste a script directly into an embedded a CLI window or enter you own commands. PS script may contain any PS syntax.

WQL is not a scripting language but you can still enter WQL statements directly into the Embedded CLI screen. If you need more control over the what WQL command get issued, you may use perl to provide flow control.

PowerShell Remoting

When creating an action as a show or configure, Powershell remoting is used. This means the script is encapsulated and sent to a remote target and executed there. In the example below the user executed a powershell Action against target 192.168.186.77.  The entire Action is written to the temp directory as a .ps1 file and then the Powershell.exe is called locally with the invoke command and encrypted credentials for execution on the remote target.

Example:

powershell.exe Invoke-Command -ComputerName 192.168.186.77 -credential(New-Object System.Management.Automation.PSCredential uname,(convertto-securestring password -asplaintext -force)) "C:\Windows\Temp\WPS679260293688594025.ps1”

This same example syntax can be used to trouble shoot script execution by replacing the target IP, uname and password. This can be pasted into a CMD window (Not a Powershell window) of the source server. This allow the .ps1 script to be updated and re-run as needed.

Powershell scripting supports many different attributes as part of its normal syntax. If you add you own attributes to a script you must set the delimiter that does not conflict with normal PS tags. Additional attribute delimiters have been added to allow more flexibility when creating scripts. If you see an error message indicting an undefined attribute, you most likely have a PS script tag interfering with the default delimiter setting . You may change the delimiters the script uses but be aware that any attributes you have already set will need to be reset.

PowerShell local machine

If a powershell script need to run locally (On the NMS server), You need to create the action as an external executable. The commands in the external action script must start with “powershell.exe”. For example “powershell.exe <Commands>”. In this case the Action uses the local CMD to execute “powershell.exe <Commands>”.

WQL

• For WQL action The Word WQL must be on the first line of script to indicate that the action syntax is in the form of a WQL query statement.   Note: due to the nature of WQL output the formatting in the results screen will not have columns aligned making the output hard to read. This should be resolve in a later patch release. As a workaround you can cut and paste into a Spreadsheet where the columns should align.

Appendix A

Powershell supported versions*

Reference*

• https://4sysops.com/wiki/differences-between-powershell-versions/