sp_check: SQL Server Database Checks

0 - Information Only

Remote dedicated admin connections

Issue: The Dedicated Administrator Connection (DAC) is a special diagnostic connection in SQL Server that uses a reserved scheduler and memory resources, allowing a sysadmin to connect even when the instance is unresponsive to normal connections.

By default, the DAC is enabled but is only available locally from the SQL Server host itself. The remote DAC, which allows administrators to connect to the DAC from another machine over the network, is disabled by default and must be enabled explicitly.

Problem: When SQL Server is in distress (CPU saturated, worker threads exhausted, blocking chains preventing new connections), normal connection attempts will fail or hang, leaving administrators unable to investigate or resolve the issue.

If the remote DAC is disabled, the only way to use the DAC is to log onto the SQL Server host itself via RDP or console access, which is often inconvenient or impossible during an incident, particularly outside business hours, in cloud environments, or on servers without remote console access. By the time someone can physically reach the server or establish RDP, the issue may have escalated to a full outage that requires a service restart, with all the associated impact and lost diagnostic information that a restart implies.

Learn More...

Enabled sa login

Issue: The sa login is the default system administrator account created during SQL Server installation. It is a member of the sysadmin fixed server role and has unrestricted access to the entire SQL Server instance.

Beginning with SQL Server 2005, Microsoft has supported disabling the sa login during installation when Windows Authentication mode is selected, but the account is often left enabled, particularly on instances configured for Mixed Mode authentication or those installed with default options.

Problem: The sa login is the single most well known account name in SQL Server, making it the primary target of brute force password attacks against any instance reachable on the network. A successful compromise of sa grants the attacker full control over every database on the instance, including the ability to read, modify, or destroy data, install malware, and potentially pivot to the host operating system through features such as xp_cmdshell.

Even in environments where sa is rarely used, its existence as a known target dramatically increases the attack surface.

Additionally, when sa is used by applications or scheduled tasks, audit trails become meaningless because all actions appear under the same shared account, eliminating accountability and making forensic analysis after an incident extremely difficult.

Learn More...

Security update available

Issue: Microsoft regularly releases updates for supported SQL Server versions, including Cumulative Updates (CUs) and General Distribution Releases (GDRs). GDRs contain only security fixes for the given baseline, while CUs include both security fixes and functional improvements.

This finding indicates that one or more SQL Server instances are missing a recently released update that addresses known security vulnerabilities. Microsoft publishes these updates through the Microsoft Update Catalog, the Security Update Guide, and SQL Server release notes.

Problem: Security vulnerabilities in SQL Server can allow attackers to execute arbitrary code, escalate privileges, exfiltrate data, or disrupt service availability.

Once Microsoft publishes a security update, the underlying vulnerability is publicly known, and exploit code often follows quickly. Unpatched instances become high value targets, particularly those exposed to internal application traffic from compromised endpoints or, worse, with any direct network exposure.

Beyond the direct security risk, missing patches frequently cause compliance failures during audits, since most regulatory frameworks (PCI DSS, HIPAA, SOX, ISO 27001) require timely application of vendor security updates. The longer an instance remains unpatched, the more exposure accumulates with no offsetting benefit.

Learn More...

Unsupported versions and builds

Issue: Microsoft provides each SQL Server version with a defined lifecycle, typically five years of mainstream support followed by five years of extended support, after which the product reaches end of support and no longer receives security updates or technical assistance.

As of 2026, SQL Server 2014 and earlier versions (including 2008, 2008 R2, and 2012) are fully out of support, SQL Server 2016 extended support ends in July 2026, and SQL Server 2017 extended support ends in October 2027.

This finding flags any SQL Server instance running a version that is no longer supported or is approaching end of support.

Problem: Running an unsupported SQL Server version exposes the organization to several serious risks. The most immediate is security: Microsoft no longer issues patches for newly discovered vulnerabilities, leaving the instance permanently exposed to any future exploits. Compliance frameworks such as PCI DSS, HIPAA, SOX, and many others explicitly require supported software, so an unsupported instance can cause audit failures and regulatory penalties.

Technical support from Microsoft is also unavailable, meaning any production issue must be solved without vendor assistance.

Beyond support concerns, older versions miss out on years of performance improvements, security hardening, and modern features that newer versions provide. Vendor applications increasingly require newer SQL Server versions for certification, and storage, hardware, and operating system platforms eventually drop compatibility with older releases.

Learn More...
Previous 1…121314

About sp_checks

This page contains a list of SQL Server configuration checks performed by Straight Path's suite of sp_check tools. For more details about our free tools, select one from the following list: