Documentation

Two ways in: an RVTools export you already know how to make, or our read-everything-first collector script.

Quick start

Create an account — trial includes 3 audit runs.
Optional but recommended: enter your EA details on the License Agreements page so reports use your real prices and true-up calendar.
Upload an inventory (RVTools export or collector output) from the dashboard.
Your report generates immediately: current-state licensing first, consolidation suggestions second.

Option A — RVTools export

New to RVTools? Follow the step-by-step guide (official download link, export settings, upload — ~15 minutes). The short version: export from RVTools as .xlsx (all tabs) and upload the file as-is. We read the vInfo tab (VMs: name, CPUs, memory, guest OS, host, cluster) and the vHost tab (hosts: sockets, cores per socket, memory, cluster). Single-tab .csv exports of either sheet also work, as does our simplified format (columns: Name, vCPU, Memory (GB), OS, Parent Host, Parent Cluster, # of Host Cores).

Good to know

Powered-off VMs and templates are excluded automatically.
RVTools does not carry SQL Server editions — SQL findings from RVTools-only uploads are inferences. Run the collector on SQL hosts for evidenced editions.
Review the file before uploading; RVTools annotation columns are not read by us, but we recommend deleting them anyway.

Option B — winsqlscan collector

A PowerShell script, published as readable source so your security team can verify every query before anything runs. It performs read-only WMI/CIM and registry reads, writes one local JSON file, and makes zero network connections — you review the output and upload it yourself.

Download winsqlscan.ps1Serve from this domain only — never run a copy from anywhere else.

# Local machine (default: hardware + SQL discovery)

powershell -ExecutionPolicy Bypass -File .\winsqlscan.ps1

# A list of servers, hardware only

powershell -ExecutionPolicy Bypass -File .\winsqlscan.ps1 -Targets servers.txt -Scope core

Rights required

Local run: standard user for hardware; SQL registry reads may need local admin.
Remote targets: WMI/DCOM access (Distributed COM Users membership or local admin on targets).
Unreachable machines are listed as errors — never silently skipped.

What's in the output

Hostname, OS, sockets/cores, RAM, virtualization flag, cluster name.
SQL instance names, editions, versions (registry reads — no SQL connections).
A collection manifest: scope, targets, exact queries run, errors.

Verify your download

SHA-256 of the current release (computed from the exact file served above):

ad027dae6b80156874c19c93f057e402964ad7affd307b39c0ee7e284423daac

Check it before running:

Get-FileHash .\winsqlscan.ps1 -Algorithm SHA256

A code-signed single-file .exe ships later in the pilot program, with published SHA-256 hashes per release. Expect a Windows SmartScreen prompt on new releases — we'll document the exact warning and how to verify the file is ours.

What we can and can't see in the cloud

Azure VMware Solution / VMware Cloud on AWS: fully visible — they're vCenter-managed, so your RVTools export includes them.
Domain-joined cloud VMs (Azure/AWS/GCP native): the collector can discover them via Active Directory, but WMI is often blocked across cloud network paths — those machines appear with partial data and are flagged, not silently missed.
Non-domain cloud instances: not visible today. Cloud-API connectors (Azure Resource Graph, AWS, GCP) are planned as an optional feature — cloud workloads also carry different licensing rules (license-included vs BYOL, Azure Hybrid Benefit), which the engine will model alongside the connector.

Stuck?

Open a ticket from the Support tab in your dashboard — during the pilot you're talking directly to the people who built the engine.