What’s the issue?
The default trace is a lightweight server-side trace that SQL Server runs automatically, capturing a curated set of events including configuration changes, object creation and deletion, permission and login changes, log file growth, and error conditions. It is enabled by default and controlled by the default trace enabled server configuration option.
Output is written to rollover trace files in the SQL Server LOG directory, retaining five files of 20 MB each. The data is readable through fn_trace_gettable and is the source behind several of the built-in management reports in SQL Server Management Studio.
This check identifies instances where default trace enabled is set to 0, detected by querying sys.configurations.
Why is this a problem?
Disabling the trace removes the built-in record of configuration and security changes. For most instances this is the only historical record of who changed a sp_configure option, created a login, granted a permission, or dropped an object, since SQL Server Audit is often not configured and the error log does not capture these events.
Questions such as when a setting changed, when a login appeared, or when a database grew unexpectedly are usually answered from the default trace, and without it the answer is unavailable.
The trace also has very little cost. It captures a narrow set of low-frequency events and imposes minimal overhead, so the usual justification for disabling a trace does not apply here. An instance with it turned off has typically had the change made without a clear reason, or as part of a hardening template that treated all tracing as equivalent.
What should you do about this?
Check the current value with EXEC sp_configure 'default trace enabled'; and confirm whether the configured and running values match, since a mismatch means a change is pending.
Enable the trace with EXEC sp_configure 'default trace enabled', 1; RECONFIGURE;. The change takes effect immediately and does not require a service restart. Confirm the trace is running by querying sys.traces for the trace with an ID of 1.
Recognize that the default trace is deprecated and retains only a limited window of history, so it complements rather than replaces a proper audit strategy. Where the recorded events matter for compliance or investigation, configure SQL Server Audit with the relevant action groups and a destination that retains data longer than the five rolling default trace files allow.