Microsoft Analysis: Data Requirements Guide
Detail on the minimum required data points for Microsoft analysis
What data do you need to collect — and how?
This guide is intended to help organisations understand the minimum data required to perform a comprehensive Microsoft licensing analysis.
Your tools may already have existing guides for standardized outputs, you can find all out of the box data sources here:
https://help.licenseware.io/all-supported-data-sources
This guide will explain all of the required data for a full analysis.
Data requirements differ depending on whether a device is a client endpoint or a server. Virtual relationship data is an additional requirement for servers and is often sourced separately from general discovery. SQL Server may be present on either device type and has its own considerations.
Client Endpoints
Required data points
| Field | Description |
|---|---|
device_name |
Device name or FQDN |
software_publisher |
Software developer / publisher |
software_name |
Installed software name, including edition |
software_version |
Installed software version |
os |
Operating system name and version |
Optional but recommended
| Field | Description |
|---|---|
device_type |
Physical or Virtual |
number_of_cores |
Total core count in the system |
number_of_processors |
Total number of installed processors |
Hardware data for client devices improves analysis completeness but is not required for basic Microsoft client licensing calculations.
Discovery tooling examples
| Tool | Notes |
|---|---|
| Microsoft Intune | Agent-based, natively deployed across managed Windows/macOS devices |
| Microsoft Defender for Endpoint | Security-focused agent with software inventory capability |
| Lansweeper | Agentless network scanning with software and hardware inventory |
| ManageEngine | Agent and agentless discovery suited to mid-market environments |
| NinjaOne | RMM-based discovery common in MSP-managed environments |
| ServiceNow | Enterprise CMDB-integrated discovery |
| Tanium | Real-time endpoint data collection at scale |
| CrowdStrike / SentinelOne / Sophos | Security agents that also expose installed software inventory |
| Qualys | Security scanning with software inventory output |
| PDQ Inventory | Lightweight Windows-focused software discovery |
| Spiceworks | Free inventory tool suited to smaller environments |
| HaloITSM / Jira Service Management | ITSM platforms with integrated discovery modules |
If your tool isn't listed, any export containing the required fields can be used.
Servers (Physical and Virtual)
Servers require the full set of data points above plus hardware details and virtual relationship data. This is essential for accurate calculation of server-based licensing requirements for products such as Windows Server and SQL Server, where licensing is tied to physical host topology, core counts, and virtualisation boundaries.
Required data points
| Field | Description |
|---|---|
device_name |
Device name or FQDN |
software_publisher |
Software developer / publisher |
software_name |
Installed software name, including edition |
software_version |
Installed software version |
os |
Operating system name and version |
number_of_cores |
Total core count in the system |
number_of_processors |
Total number of installed processors |
device_type |
Physical or Virtual |
virtualization_type |
Virtualisation technology in use (e.g. VMware, Hyper-V) |
host_name |
For virtual machines: the name of the host. Not applicable where the workload runs on shared IaaS infrastructure (e.g. Azure, AWS) with no dedicated host. |
cluster_name |
For clustered hosts: the name of the cluster. Not applicable where no dedicated host or cluster exists. |
Discovery tooling examples
The same tools used for client discovery will generally cover server hardware and OS data. However, virtual relationship data (host/guest mappings, cluster membership) is often not captured by standard discovery tools and requires a dedicated virtualisation data source — see the section below.
Virtual Relationship Data
Why it matters
For any virtual device in scope, the platform needs to understand which physical host it runs on, which other VMs share that host, and whether hosts are part of a cluster. Without this, it is not possible to correctly calculate licensing requirements under Microsoft's virtualisation rules.
This data often comes from a separate source
General discovery tools frequently do not capture virtual topology in sufficient detail. In many environments, this data needs to be collected specifically from the virtualisation platform. Common sources include:
| Tool | Notes |
|---|---|
| VMware PowerCLI | Exports host, cluster, and VM relationship data directly from vSphere |
| RVTools | Widely used free utility that exports VMware infrastructure topology to Excel |
| Hyper-V Manager / PowerShell | Native exports of host/guest relationships from Microsoft Hyper-V |
| Lansweeper | Captures virtualisation relationships for VMware and Hyper-V environments |
| Device42 | Discovers and maps virtual infrastructure across multiple hypervisor platforms |
| ServiceNow Discovery | Captures virtual topology as part of broader CMDB infrastructure discovery |
Where your primary discovery tool does not provide this data, it can be exported from the above sources and provided as a separate file for processing alongside the main inventory data. Refer to: Virtualisation and Hardware and How to use the IFMP Template
SQL Server Edition and Version
SQL Server may be installed on any device — client or server — and must be accounted for regardless of where it is found.
A common gap in discovery data
Many discovery tools capture that SQL Server is installed but do not reliably collect the edition (e.g. Standard, Enterprise, Developer) or the precise version. This is critical for licensing analysis as the edition directly determines licensing requirements and cost.
How to fill the gap
If your discovery tool does not collect SQL edition data, it can be obtained directly from the SQL Server instances using SQL Server Management Studio (SSMS). A Central Management Server can be used to query multiple instances simultaneously using SELECT @@version, with results exported to CSV or Excel for processing.
Refer to: Obtain SQL Edition via SQL Server Management Studio
Excluding Devices from Analysis
Certain devices may be eligible for exclusion from licensing calculations where coverage already exists through other means. Common scenarios include:
- Disaster Recovery / failover environments — passive DR devices covered by a licensed production environment
- Dev/Test environments — devices covered under the licence of the primary production device
- MSDN / Visual Studio subscribers — dev and test usage entitled through user-based subscription licensing
Exclusions can be applied in bulk once the initial data has been processed. Each device requires a documented reason for exclusion to maintain a clear audit trail.
Refer to: Bulk Exclude Devices
Summary Checklist
| Data Category | Client Endpoints | Servers |
|---|---|---|
| Device name | ✅ Required | ✅ Required |
| Software name, edition, version | ✅ Required | ✅ Required |
| Operating system | ✅ Required | ✅ Required |
| Core / processor count | ⚪ Optional | ✅ Required |
| Device type (Physical/Virtual) | ⚪ Optional | ✅ Required |
| Virtual host / cluster mapping | ➖ Not needed | ✅ Required* |
| SQL Server edition (if applicable) | ✅ Required | ✅ Required |
* Host and cluster mapping is not applicable where workloads run on shared IaaS infrastructure with no dedicated host.