SSIS Installed but not used

What this check looks for

When an SSISDB database exists and it has a catalog schema, meaning the Integration Services catalog is genuinely set up rather than a database that happens to share the name, the check counts three things:

• Packages deployed, from SSISDB.catalog.folders, projects and packages.
• Executions in the last two years, from SSISDB.catalog.executions.
• Executions ever.

It reports when the catalog is there but nothing is using it.

Why it matters

This is a housekeeping finding, which is why it is Low. Nothing is broken and nothing is at risk today. It is on the list because an unused component is a cost with no matching benefit, in four small ways:

• It is surface area. The Integration Services service runs, listens, and has to be patched on the same schedule as everything else. A component nobody uses is a component nobody watches, and it still gets CVEs.
• SSISDB is a database you are responsible for. It needs backing up, it needs a CHECKDB, it holds a database master key that needs its password recorded somewhere, and it will appear in every audit and every migration plan.
• It complicates a migration. SSISDB is one of the more awkward databases to move, because of the master key and the catalog configuration. Discovering during a migration that it was never used is a frustrating way to spend an afternoon.
• It confuses the picture. Somebody looking at this instance in two years will see SSIS installed and assume something depends on it.

The catalog also retains execution history and its own cleanup job, so it slowly grows even while doing nothing useful.

How to confirm it yourself

IF DB_ID('SSISDB') IS NOT NULL
BEGIN
    SELECT COUNT(*) AS [packages]
      FROM [SSISDB].[catalog].[folders]   AS f
     INNER JOIN [SSISDB].[catalog].[projects] AS p ON p.[folder_id]  = f.[folder_id]
     INNER JOIN [SSISDB].[catalog].[packages] AS k ON k.[project_id] = p.[project_id];

    SELECT COUNT(*) AS [executions_all_time],
           MAX([start_time]) AS [last_execution]
      FROM [SSISDB].[catalog].[executions];

    SELECT COUNT(*) AS [executions_last_2_years]
      FROM [SSISDB].[catalog].[executions]
     WHERE [start_time] > DATEADD(YEAR, -2, GETDATE());
END

Check the package store and the file system too, before concluding nothing uses SSIS. Packages can live outside the catalog:

SELECT [name], [folderid], [packagetype]
  FROM msdb.dbo.sysssispackages WITH (NOLOCK);

And check for Agent jobs that run packages from a file path rather than the catalog:

SELECT j.[name] AS [job_name], s.[step_name], s.[subsystem], s.[command]
  FROM msdb.dbo.sysjobs AS j WITH (NOLOCK)
 INNER JOIN msdb.dbo.sysjobsteps AS s WITH (NOLOCK)
         ON s.[job_id] = j.[job_id]
 WHERE s.[subsystem] = 'SSIS'
    OR s.[command] LIKE '%dtexec%';

How to fix it

Confirm before removing anything. Three questions, all of which the queries above answer:

1. Are there packages in the catalog?
2. Has anything executed, ever, and when was the last time?
3. Is anything running packages from the file system or the package store instead?

If all three come back empty, the component really is unused.

Then remove it in order:

1. Back up SSISDB first, whatever you conclude. It costs nothing and it is the only copy of anything that was in there.
2. Record the master key password. If you ever want to restore that backup, you need it.
3. Drop the SSIS catalog from SQL Server Management Studio, under Integration Services Catalogs.
4. Uninstall Integration Services through the SQL Server installer’s Remove feature, on its own rather than as part of anything else.
5. Remove the SSIS packages folder from the file system if nothing else uses it.

If you are not confident, disabling the Integration Services service and leaving SSISDB in place is a reversible middle step that removes the running surface without removing anything you might want back.

If it turns out something does use it, then the finding has done its job differently: the catalog needs the same care as the rest of the instance, which means backups, a retention policy and monitoring.

How long it takes

About an hour, most of it confirming that nothing uses it.

Related reports

Related checks

Frequently asked questions

We use SSIS but not the catalog. Then packages are in the package store or on the file system, and the queries above find them. The check only looks at the catalog, so this is a real false positive worth confirming.

Is two years the right window? It is deliberately generous. A package that has not run in two years is not part of any annual process either.

Can I drop SSISDB without uninstalling the service? Yes, and it is a reasonable first step. The service will start and do nothing.

We are planning to use it. Then this is a note rather than an action. It will stop firing as soon as something runs.