Troubleshooting — Windows (Task Worker)

Overview

On Windows, Diskover runs only the Task Worker (diskoverd). The full Diskover stack (Elasticsearch, nginx, diskover-admin, diskover-web) must be running on a separate Linux host that this Windows worker connects to.

The Task Worker is installed via the Diskover-2.6.0.exe installer for your target version and, as of 2.6.0, runs as a native Windows service named diskoverd (the NSSM service manager used by 2.4.x–2.5.x has been removed). On 2.4.x–2.5.x installs the service is NSSM-managed and named diskover, and the legacy config lives in %APPDATA%\diskoverd\.

Installation Paths

Service Management

The Task Worker runs as a native Windows service named diskoverd. Run these from an Administrator PowerShell:

# Start
Start-Service diskoverd

# Stop
Stop-Service diskoverd

# Restart
Restart-Service diskoverd

# Check status
Get-Service diskoverd

The service can also be managed from Windows Services (services.msc) — look for diskoverd. It is registered to start automatically at boot, with failure recovery set to restart 3 times at 60-second intervals.

Service account: the installer's Service Account page sets the Log On identity (LocalSystem by default). To change it later: services.msc → diskoverd → Properties → Log On tab. The account needs the "Log on as a service" right (the installer grants this automatically for the account chosen at install time; Windows grants it when you set an account via services.msc).

Log Locations

# Tail crawl subprocess log
Get-Content -Path "C:\ProgramData\diskoverd\logs\diskoverd_subproc_$env:COMPUTERNAME.log" -Tail 25 -Wait

Start with Event Viewer for service-start issues; switch to the subprocess log for task-specific failures. (There are no NSSM service-start*.log files on 2.6.0.)

Post-Install Configuration

The installer collects the Diskover Web URL, internal API key, and service account during the wizard, so a normal install needs no manual configuration — just start the service:

Start-Service diskoverd

Configure the Worker in Diskover Admin

Once the service has started and the worker appears:

1. Navigate to Diskover Admin > Configuration > DiskoverD

2. Click on the machine hostname

3. Review: Log To File enabled, Log Directory C:\ProgramData\diskoverd\logs\, Python Location C:\Program Files\Diskover\python\python.exe, Timezone

4. Save

Troubleshooting

Worker Not Appearing in Diskover Admin

Check the service is running:

Get-Service diskoverd

Check Event Viewer (Windows Logs → Application) for diskoverd service errors, and the subprocess log for connection errors:

Get-Content -Path "C:\ProgramData\diskoverd\logs\diskoverd_subproc_$env:COMPUTERNAME.log" -Tail 50

Verify the Diskover Web URL in config.yaml:

notepad "C:\ProgramData\diskoverd\config.yaml"

Ensure apiurl points to the Diskover Web host, not localhost.

Service Fails Its License Check / Admin API Returns 401

2.6.0 workers authenticate to the Diskover Admin API with the internal API key (X-Internal-Api-Key). The key is stored in the service's registry environment. To inspect it (Administrator PowerShell):

(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\diskoverd").Environment

You should see DISKOVER_INTERNAL_API_KEY=<key> alongside PYTHONPATH and DISKOVERDDIR. If it's missing or wrong, fix the Environment multi-string value (keep the other two entries!) and restart the service. The correct key is the DISKOVER_INTERNAL_API_KEY value on your Diskover server (e.g. /etc/sysconfig/.diskover-db on the web host).

Service Fails to Start (Error 1053 / "PythonClass" Errors)

The native service is hosted by pywin32's pythonservice.exe. Errors like "Could not find PythonClass entry in the registry" or a 1053 timeout mean the pywin32 components aren't registered — re-run the installer, which performs the pywin32 post-install (DLL registration + service host setup).

Scans Can't Reach Network Shares

LocalSystem (the default service account) has no credentials on network shares. Bind the service to a domain/local account that can read the scan targets: services.msc → diskoverd → Properties → Log On → This account. Restart the service afterwards.

Python Opens the Microsoft Store Instead of Running

Windows binds bare python/python3 commands to the Microsoft Store by default. The 2.6.0 installer and service are immune as they use the vendored interpreter by full path, but this still bites interactive shells. Either disable the aliases ("Manage App Execution Aliases" → python.exe/python3.exe → Off) or call the interpreter by full path:

& "C:\Program Files\Diskover\python\python.exe" --version

Task Fails Immediately

Check the subprocess log:

Get-Content -Path "C:\ProgramData\diskoverd\logs\diskoverd_subproc_$env:COMPUTERNAME.log" -Tail 100

For more detail, increase the log level to DEBUG in Diskover Admin > Configuration > DiskoverD, then retry the task.

Common causes:

• The path being scanned is not accessible by the service account (see network-shares section above)

• Elasticsearch is unreachable from this machine. Test with curl.exe http://<es-host>:9200/_cluster/health

• Python Location in Diskover Admin doesn't point at C:\Program Files\Diskover\python\python.exe

Connecting to a Single-Stack OVA

If the Diskover stack is running on a single OVA, the DiskoverD configuration for the Elasticsearch connection is likely set to localhost. This must be changed to the OVA's IPv4 address so the Windows Task Worker can fetch the ES configuration and connect properly.

Navigate to Diskover Admin > Configuration > Diskover > Elasticsearch and update the Elasticsearch host from localhost to the OVA's IP.

Running a Manual Scan

To test indexing without going through the task queue, open an Administrator PowerShell. Manual runs don't inherit the service's environment, so set the two variables first:

$env:DISKOVERDDIR = "C:\ProgramData\diskoverd"
$env:DISKOVER_INTERNAL_API_KEY = "<your-internal-api-key>"

cd "C:\Program Files\Diskover"
& "C:\Program Files\Diskover\python\python.exe" diskover.py -i diskover-<indexname> "C:\path\to\scan"

Note: All index names must start with diskover-.

Log Management and Rotation

Windows has no built-in log rotation. Left unmanaged, the crawl subprocess log can grow large on active workers.

The crawl subprocess log respects the log rotation settings configured in Diskover Admin > Configuration > DiskoverD — set a max file size and backup count to limit growth (default 100 MB with 1 backup).

For anything beyond that, a scheduled cleanup still works (adjust retention as needed):

$logDir = "C:\ProgramData\diskoverd\logs"
$maxAgeDays = 30

Get-ChildItem -Path $logDir -Filter "*.log" | Where-Object {
    $_.LastWriteTime -lt (Get-Date).AddDays(-$maxAgeDays)
} | Remove-Item -Force

Save as a .ps1 file and schedule it via Task Panel > Create Custom Task (weekly), with the action running powershell.exe -File "C:\path\to\script.ps1".

Reinstalling Python Dependencies

If the Task Worker fails to start with ModuleNotFoundError or similar import errors, reinstalling the Python dependencies can resolve the issue.

On 2.6.0 Python is vendored at C:\Program Files\Diskover\python (all users). From an Administrator PowerShell:

& "C:\Program Files\Diskover\python\python.exe" -m pip install -r "C:\Program Files\Diskover\requirements.txt"

After reinstalling, restart the service:

Restart-Service diskoverd

Note: a reinstall of the Diskover-2.6.0.exe reinstalls all bundled wheels offline, which is usually the cleaner fix for a broken environment.

Checking the Service Configuration

To view the current service configuration (executable, start type, account):

sc.exe qc diskoverd
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\diskoverd").Environment