Windows¶
With the Windows Discovery integration, Clarity Transform enriches Windows device records over WinRM with operating system edition, CPU topology, installed software, Windows features and .NET versions.
Where to find it¶
Go to Discover → Integrations, then select the Windows card. The card's category label is Operating System. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.
Why we do this¶
Host-level evidence originates at the endpoint rather than the network, so it reaches conversations the network may not see. Traffic between systems on the same segment, or between two virtual machines on the same host, never crosses a device capable of exporting flow data.
What we collect¶
- Operating system edition and version, and CPU topology
- Installed software and Windows features
- Installed .NET versions
What it adds¶
Installed software is the answer to a question no infrastructure source can reach: what is actually running on this machine. A hypervisor knows a virtual machine's shape; only the guest knows it has SQL Server on it.
What is deliberately not inferred¶
- No file contents and no application data. Software inventory, not data.
- No user data, documents or mailboxes.
- Nothing is installed on the host. There is no agent; collection is by remote command for the duration of the run only.
- Nothing is changed. No configuration is written, no service started or stopped.
- A listening port is not a dependency. It is evidence that a service is offered, which is a different claim from evidence that anyone uses it.
What we require¶
A local administrator account on the in-scope hosts, over WinRM, with PowerShell remoting enabled.
- Interface: WinRM
- Connectivity: the WinRM port from Clarity to each host
- Account: local administrator, or a domain account in the local Administrators group
PowerShell remoting needs to be enabled, not just the WinRM service
Installed software information comes from remote commands and registry reads that a less privileged account cannot complete, and that the WinRM service alone does not permit. A host where WinRM is listening but remoting is not enabled fails in a way that looks like a credential problem.
Verification before handover¶
Run these as the system owner before handing the credential over, so a failed discovery run is never the first time anyone finds out.
- Confirm remoting works, not just WinRM. From the Clarity virtual machine, open a remote PowerShell session to a sample host as the account. The service listening is not the same as remoting being enabled, and the difference is the most common cause of failure here.
- Confirm the software inventory reads. In that session, read the installed software registry keys. This is the operation that needs the administrator rights, so it is the one worth demonstrating.
Configuring the endpoint¶
On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:
| Field | Value |
|---|---|
| Name | A name for the endpoint |
| Credential | The stored credential for the administrator account |
| Job Schedule | A five-field cron expression, for example 0 2 * * 0 (weekly). Installed software changes on a patch cadence rather than continuously |
| Enabled | Ticked. The box is unticked when the form opens |
The help texts: Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".
The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.
No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.
The endpoint form has no End Point field, although the Endpoints grid has an End Point column. Discovery runs against the Windows devices already in the CMDB.
Removing the access¶
Remove the account from the local Administrators group on the in-scope hosts, or delete it. No agent was installed, so nothing is left behind. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.
Troubleshooting¶
| Symptom | Cause |
|---|---|
| Connection fails although WinRM is listening | PowerShell remoting is not enabled. Test with a remote session rather than a port check. |
| Connects but installed software is empty | The account is not a local administrator on that host. The registry reads need it. |
| Some hosts succeed and others fail identically | Group Policy or a local firewall differing between builds. Compare a working host with a failing one rather than treating it as a credential problem. |