Third Party Objects

Overview

msdb is where backup tools, monitoring agents and half the maintenance scripts on the internet put their tables.

The objects are real, they hold real data, and they are invisible: nothing inventories them, they are not in anybody’s source control, and they are lost the day msdb is rebuilt or the instance is migrated, which is the day somebody finds out they existed.

The Third Party Objects page: what is in msdb that setup did not put there
The whole page. Eight objects setup did not create: one view, and seven users and roles somebody added so that something could write here.

Where to find it

Expand a server in the tree, expand the msdb database, then MSDB → Third Party Objects.

The test, and its limits

The test is is_ms_shipped, which is set on everything SQL Server setup created and on nothing else.

It is a good test and not a perfect one, and the page says so: other Microsoft components install into msdb too, and what they leave is marked the same way as a vendor’s table.

So the page ranks and describes rather than accusing, and the create date against the instance’s own build date is what usually settles it. Something created three years after setup ran was not put there by setup.

Four kinds of thing turn up here

Kind Why it matters
Tables with rows in them The ones that matter: a backup tool’s history, a monitoring agent’s samples, somebody’s index maintenance log with four years of data.
Procedures and functions Where a maintenance script lives when it was installed the convenient way rather than into its own database.
Triggers, including database level DDL triggers These run on changes inside msdb itself.
Users and roles setup did not create Principals somebody added, usually so a tool could write here.

Reading the chart

The bars: objects in msdb that setup did not create, by the space they hold
One bar, because the only object here with any substance is a view. The seven users and roles are counted in the header line rather than drawn at zero.

One bar per object, by the space it holds, which is what separates a working table from a leftover definition.

The line under the header is the honest half of the page. is_ms_shipped is the test, other Microsoft components install into msdb too, and what they leave is marked exactly the way a vendor’s table is.

Reading the grid

The grid: what each object is, what it holds and when it appeared
Rows and Space separate a working table from a leftover, and Created against the instance build date is what usually settles it. Every row here but the first is a principal rather than an object.
Column What it is
Name The object or principal, schema qualified.
What it is Table, view, procedure, function, trigger, user, or role.
Rows Row count, for the objects that have one. This is the column that separates a leftover from a working table.
Space What it holds.
Created The create date, against which the instance build date is the reference.
Last changed The modify date.
Verdict What this object appears to be, and what would happen to it in a rebuild or a migration.

The toolbar

Control What it does
Space and retention Opens msdb Space and Retention, where these tables show up in the space split.
Agent security Opens Agent Security, for the principals side.

Everything here is read only

What to do about any of it is a decision about somebody else’s product, not one this page should be making. The page inventories and describes; it changes nothing and recommends nothing about another vendor’s schema.

Where the data comes from

Source What it gives
sys.objects in msdb Every object with is_ms_shipped = 0, its type, create and modify dates.
sys.schemas The schema names.
sys.dm_db_partition_stats Rows and space for the tables.
sys.triggers, sys.server_triggers Object and database level triggers.
sys.database_principals Users and roles setup did not create.
sys.dm_os_sys_info / sys.databases The instance build reference for the create date comparison.

Messages you may see

Nothing has been added to msdb. Every object and every principal in this msdb was created by SQL Server setup. That is the state a rebuild of msdb would leave it in, and it means nothing here would be lost.

Report Why you would go there
msdb Space and Retention What these tables weigh, and that nothing in SQL Server trims them.
Agent Security The principals these tools connect as.
Job Commands The jobs that write into these tables.
Package Store Another place a third party leaves something behind.

Frequently asked questions

Is anything here dangerous? The page does not say so, because it cannot know. What it says is what is there, how much data it holds, and that setup did not create it.

We are migrating to a new server. What do I do with this list? Script the objects and move the data, or accept losing it. A migration recreates msdb from setup, so everything on this page starts empty on the new instance.

A Microsoft component shows up here. That is the known limit of the is_ms_shipped test, and the page says so rather than pretending otherwise. The create date usually identifies it.

Can I drop these? Only if you know what installed them. A backup tool that finds its history table missing usually recreates it and loses the history, which may be exactly what you wanted or exactly what you did not.