What Is Installed? Finding Every SQL Server Component

A server can answer queries while its installation story remains unclear. Finding every SQL Server component means separating the Database Engine from shared features, Windows services, and client tools. That distinction matters when planning an upgrade, investigating a failed job, or rebuilding a machine from notes.

Start Finding Every SQL Server Component With the Discovery Report

When I inherit a host described simply as “SQL Server installed,” I expect the label to hide more than one component. Finding every SQL Server component should identify what is present, which instance owns it, and which version is running. How would you know whether a feature was installed but never started?

Open SQL Server Installation Center on the host and choose the Installed SQL Server features discovery report under Tools. Setup can also produce the report with its RunDiscovery action when the Setup executable is available. The report provides a machine-level list of detected SQL Server products and features, including shared features and instance-specific components. Save the report with the inventory date, host name, and source media or Setup version used to generate it. A discovery report is a starting point, not a substitute for checking that a service starts and accepts connections.

If a feature appears under one named instance, record that association explicitly. Another instance on the same machine can have a different set of features or a different patch level. Shared components have their own entries and can serve more than one instance. A tidy report name is surprisingly valuable six months later, when someone asks which report came from which host.

REM Command line
Setup.exe /Action=RunDiscovery

List the Windows Services When Finding Every SQL Server Component

Windows services provide a practical cross-check for components that run as services. Search for SQL Server services in Services, or use PowerShell on the host. Record the display name, internal service name, state, and start mode. A stopped service can still represent an installed component. Conversely, a client driver or management application does not always create a service. That is why the services list cannot serve as the complete installation inventory.

I have seen an inventory mistake begin with an empty-looking Services window filtered by the wrong name. The PowerShell query below makes the filter visible and lets you inspect the results. Include the SQL Server Agent, Browser, Full-Text, Analysis Services, Integration Services, and Reporting Services entries when present. Check the actual display names because packaging and versions vary.

# PowerShell
Get-CimInstance Win32_Service |
    Where-Object { $_.DisplayName -like '*SQL Server*' } |
    Select-Object Name, DisplayName, State, StartMode

Ask Each Database Engine Instance

Connect to every known Database Engine instance and ask the instance for its identity, edition, and version. SERVERPROPERTY reports the engine you reached, which is more reliable than reading an installer label and assuming all instances share a build. Record the host and instance name used for the connection as well as the returned values. If a connection fails, preserve the failed connection attempt separately; a failure does not prove the instance is absent.

The product version is a build number. Compare it with the release and update documentation when you need a named servicing level. Do not infer the exact cumulative update from a folder name, a client application version, or an old inventory spreadsheet. Those labels can survive long after the engine changes.

SELECT
    @@SERVERNAME AS ReportedServerName,
    SERVERPROPERTY('MachineName') AS MachineName,
    SERVERPROPERTY('InstanceName') AS InstanceName,
    SERVERPROPERTY('Edition') AS Edition,
    SERVERPROPERTY('ProductVersion') AS ProductVersion;

Check Service State From Inside the Instance

The dynamic management view sys.dm_server_services reports service details associated with the connected instance, such as service name, startup type, and current status. It is useful when you can connect to SQL Server but do not have an interactive view of the host. Check the permissions required in the version you run; a permission error is not evidence that services are missing. Run the query separately for each instance because one connection cannot inventory every instance on the host.

This view covers SQL Server services associated with that connection. It does not list every installed shared feature, driver, or management tool. Put its results beside the Setup discovery report rather than treating either source as a universal answer. A report that says “installed” and a service that says “stopped” can both be accurate at the same time.

SELECT
    servicename,
    startup_type_desc,
    status_desc
FROM sys.dm_server_services
ORDER BY servicename;

Separate Shared Features From Instance Features

Record each feature under the scope shown in the discovery report. The Database Engine, Analysis Services, and other instance features belong to a named installation. Shared features serve the machine more broadly. This distinction prevents an upgrade plan from assuming that updating one engine instance updates every component on the host. It also makes removal decisions safer, since a shared item can still support another instance.

If a feature was added after the original engine installation, compare its actual build with the expected servicing level. Adding a feature from older installation media can leave that feature behind a current cumulative update until servicing is applied again. Capture the evidence, then use the supported servicing path for the installed version. Avoid labeling a machine “fully patched” solely because the primary Database Engine reports a current build.

Inventory Client Tools and Drivers Separately

SQL Server Management Studio, sqlcmd, bcp, ODBC drivers, and OLE DB providers are client-side components. They have their own installers and version paths. A host can have a current Database Engine and an older client tool, or no local client tool at all. Check installed applications and the tool’s own version output where available. Keep the client inventory separate from the Database Engine build so that a support case can identify the component actually in use.

The connection path also matters. An application on another computer uses the driver installed there. That may not be the driver you see on the database host. Record the application host and driver name when the inventory is for a particular workload. The server inventory alone cannot answer a client compatibility question.

Build a Useful Inventory Record

For each host, keep the date and location of the discovery report. Record the SQL Server instances, installed features and shared features. Add the service names and their states, the engine edition and build for each instance, and any client tools and drivers installed separately. Add the source of each observation: Setup report, Windows service query, SQL query, or installed application list. That source column makes discrepancies understandable instead of forcing a guess about which line is correct.

A small table beats a paragraph that says everything looks fine. Use one row per component or instance. Fill in a version only when you actually observed it. I mark unreachable instances as unverified and schedule a connection check. Almost every inventory I inherit has at least one row somebody filled in from memory. Do not fill an empty version cell with the version of a neighboring component. That shortcut makes the inventory attractive and wrong.

Repeat Finding Every SQL Server Component After Change

Refresh the inventory after installation, feature addition, patching, upgrade, or removal. Compare the new discovery report with the prior report, then confirm the relevant services and engine builds. If the change affects a client workload, check the client machine too. Keep both dated reports so the change has a before and after record that can be inspected without relying on memory.

Asking whether SQL Server is installed gets you a yes. The useful question is which components are installed, where they run, and which versions you have actually verified. Finding every SQL Server component takes several sources because the installation has several layers. The payoff is a maintenance plan that names real components. The next person on call also gets a handoff instead of a blank screen.

Related reading on this blog: How to Get List of SQL Server Instances Installed on a Machine Via T-SQL? and Microsoft Official Support End Dates for Different Versions.

A complete inventory is not a list of names, it is a record of each component, its scope, and its verified version.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.