> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure WMI and PowerShell for Computer Discovery

> Configure and troubleshoot the WMI and PowerShell scanners Syteca uses for Computer Discovery, to maximize the Windows local privileged accounts found.

<Info>
  Not available in SaaS.
</Info>

[Computer Discovery](/docs/pam/discovery/overview) finds Windows local privileged accounts using two scanners. This page configures and troubleshoots them. By default both run concurrently, and accounts found are de-duplicated.

* The **WMI scanner** finds privileged local accounts in the default **Administrators** group.
* The **PowerShell scanner** also finds local accounts with any privileged permission granted via GPO (for example, `SeTcbPrivilege`, `SeBackupPrivilege`).

## Configuration keys

<Warning>
  **As of the version introducing [Account Discovery Settings](/docs/administration/configuration/account-discovery-settings), these keys are configured in the Management Tool instead — the config-file keys below are removed on upgrade and no longer take effect.** The table below is kept for reference on older versions.
</Warning>

Add or change these in `EkranServer.Settings.config`, found in `C:\Program Files\Ekran System\Ekran System\Server` on the Application Server host.

| Key                                  | Default | Purpose                                                       |
| ------------------------------------ | ------- | ------------------------------------------------------------- |
| `WmiScanner`                         | `1`     | Use (`1`) or skip (`0`) the WMI scanner.                      |
| `PowerShellScanner`                  | `1`     | Use (`1`) or skip (`0`) the PowerShell scanner.               |
| `WmiConnectionTimeoutSeconds`        | `20`    | Max seconds the WMI scanner spends per computer (≥ 1).        |
| `PowerShellConnectionTimeoutSeconds` | `20`    | Max seconds the PowerShell scanner spends per computer (≥ 1). |
| `PowerShellScannerUseHttps`          | `0`     | `1` = HTTPS, `0` = HTTP for the PowerShell scanner.           |
| `PowerShellScannerUseHttpPort`       | `5985`  | Port for the HTTP PowerShell connection.                      |
| `PowerShellScannerUseHttpsPort`      | `5986`  | Port for the HTTPS PowerShell connection.                     |

## WMI scanner prerequisites

<Steps>
  <Step title="Check the timeout key">
    Confirm `WmiConnectionTimeoutSeconds` is valid in the config file. The default 20s is usually enough; a high value can slow scans when target computers are unreachable.
  </Step>

  <Step title="Allow WMI through the firewall">
    On both the Application Server host and the target computers: press **Win+R**, run `firewall.cpl`, click **Allow an app or feature through Windows Defender Firewall → Change settings**, find **Windows Management Instrumentation (WMI)**, and allow it in Private, Public, and Domain as required.
  </Step>

  <Step title="Check the targets">
    Make sure target computers are online, their local accounts aren't disabled, and they have the latest Windows cumulative updates.
  </Step>
</Steps>

## PowerShell scanner prerequisites

<Steps>
  <Step title="Check the timeout key">
    Confirm `PowerShellConnectionTimeoutSeconds` is valid in the config file.
  </Step>

  <Step title="Enable WinRM">
    Ensure the **WinRM** service runs on both the Application Server host and the targets. It's on by default only on Windows Server. To check and enable on Windows 10/11:

    ```powershell theme={"system"}
    Get-Service WinRM
    Enable-PSRemoting -Force
    ```

    `Enable-PSRemoting` also sets the service to Automatic and opens the WinRM firewall rules.
  </Step>

  <Step title="Add trusted hosts (cross-domain)">
    If the Application Server host and targets aren't in the same domain, add the targets to the trusted hosts list on the Application Server host:

    ```powershell theme={"system"}
    Set-Item wsman:\localhost\Client\TrustedHosts -Value "<hostname or IP>"
    ```

    Separate multiple values with commas, or use asterisks for ranges (for example, `10.150.*`). Trusting `*` is possible but not recommended.
  </Step>

  <Step title="Allow WinRM through the firewall">
    Enable the **Windows Remote Management (HTTP-In)** inbound rule on the targets and allow port **5985**.
  </Step>

  <Step title="Synchronize time">
    The Application Server host and targets must use the same time source. A PowerShell remote session fails if a target is \~10+ seconds out of sync; adding the target to trusted hosts is an alternative workaround.
  </Step>

  <Step title="Check WMI on targets">
    Ensure the **WMI** service is running on the targets (on by default, but may have been disabled).
  </Step>
</Steps>

<Accordion title="Optional: use HTTPS for PowerShell scanning">
  To use HTTPS instead of HTTP, set up an HTTPS listener on each computer to be scanned:

  1. Generate a self-signed certificate:

  ```powershell theme={"system"}
  New-SelfSignedCertificate -DnsName "<machine>.<domain>", "<machine>", "<IP>" -CertStoreLocation Cert:\LocalMachine\My -KeyUsage KeyEncipherment, DigitalSignature -Type SSLServerAuthentication
  ```

  2. Create the listener using the certificate thumbprint (run in **cmd**, not PowerShell):

  ```text theme={"system"}
  winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<machine>.<domain>"; CertificateThumbprint="<thumbprint>"}
  ```

  3. Allow port 5986 in the firewall:

  ```powershell theme={"system"}
  New-NetFirewallRule -Name "WinRM HTTPS" -DisplayName "WinRM HTTPS" -Protocol TCP -LocalPort 5986 -Action Allow
  ```

  4. Export the certificate, then import it into Trusted Root Certification Authorities on the Application Server host:

  ```powershell theme={"system"}
  Export-Certificate -Cert Cert:\LocalMachine\My\<thumbprint> -FilePath <path>\<name>.cer
  Import-Certificate -FilePath <path>\<name>.cer -CertStoreLocation Cert:\LocalMachine\Root
  ```

  Use a GPO to set this up across many computers.
</Accordion>

## Troubleshooting

Application Server logs can be [downloaded from the Management Tool](/docs/resources/troubleshooting/logs) or found in `C:\Program Files\Ekran System\Ekran System\ServerLogs`.

<AccordionGroup>
  <Accordion title="WMI scanning errors">
    * **WMI service not running / paused** — resume the WMI service on the target.
    * **Cannot scan (offline / port 135 blocked / unreachable)** — turn the target on, allow port 135 in the firewall, or verify reachability with `ping`.
    * **Access is denied** — the secret's credentials are wrong or lack permissions; try another secret.
    * **Can't scan the Application Server's own computer** — use the PowerShell scanner for that host instead.
    * **Connection timed out** — increase `WmiConnectionTimeoutSeconds`.
  </Accordion>

  <Accordion title="PowerShell scanning errors">
    * **Cannot scan (offline / WinRM disabled / firewall / bad listener)** — turn the target on, enable WinRM, check the firewall (5985/5986), or check listeners with `winrm enumerate winrm/config/listener`.
    * **Not in same domain / IP not trusted** — add the target to TrustedHosts or use HTTPS.
    * **Name cannot be resolved** — use the IP (added to TrustedHosts) instead of the name.
    * **Access is denied** — wrong credentials or insufficient permissions; try another secret.
    * **Connection timed out** — increase `PowerShellConnectionTimeoutSeconds`.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Account Discovery" icon="radar" href="/docs/pam/discovery/overview">
    Create and run Computer Discovery rules.
  </Card>

  <Card title="SSH for Linux Discovery" icon="terminal" href="/docs/pam/discovery/ssh-linux-scanning">
    The equivalent setup for Linux scanning.
  </Card>
</CardGroup>