SQL Best Practice Checks Test

Compliance in databases involves adhering to defined security, configuration, and operational standards that help safeguard data and ensure regulatory conformity. Compliance checks verify whether a database aligns with these standards, thereby reducing risks such as security breaches, misconfigurations, and performance issues. Without proper monitoring, administrators may encounter undetected failed checks, configuration drift, or difficulties in tracking compliance trends across multiple servers. The SQL Best Practice Checks test addresses these challenges by automatically executing compliance checks on SQL Server databases and reporting the number of successful and failed checks.

This test ensures that SQL Server databases remain compliant with established policies and standards. In enterprise environments, such checks are vital to avoid downtime, data integrity issues, and potential security loopholes. By also calculating the percentage of failed checks, the test provides a clear view of compliance health. This enables administrators to detect deviations quickly, prioritize remediation, and maintain adherence to both organizational and regulatory requirements. Ultimately, the test reduces risks, improves governance, and strengthens the overall security posture of SQL Server database environments.

Target of the test : A Microsoft SQL server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every Microsoft SQL server monitored.

Configurable parameters for the test
Parameters	Description
Test period	How often should the test be executed. By default, this is set to 60 minutes.
Host	The IP address of the Microsoft SQL server.
Port	The port number through which the Microsoft SQL server communicates. The default port is 1433.
User	If a Microsoft SQL Server 7.0/2000 is monitored, then provide the name of a SQL user with the Sysadmin role in this text box. While monitoring a Microsoft SQL Server 2005 or above, provide the name of a SQL user with all of the privileges outlined in User Privileges Required for Monitoring Microsoft SQL server.
Password	Specify the password corresponding to the mentioned user.
Confirm Password	Confirm the password by retyping it.
Instance	Enter the name of a specific Microsoft SQL instance that is to be monitored against this parameter. The default value of this parameter is “default”. To monitor a Microsoft SQL instance named “CFS”, enter this as the value of the Instance parameter.
Domain	By default, none is displayed in the Domain text box. If the ‘SQL server and Windows’ authentication has been enabled for the server being monitored, then the Domain can continue to be none. On the other hand, if ‘Windows only’ authentication has been enabled, then, in the Domain text box, specify the Windows domain in which the managed Microsoft SQL server exists. Also, in such a case, the User name and Password that you provide should be that of a user authorized to access the monitored SQL server.
ISNTLMV2	In some Windows networks, NTLM (NT LAN Manager) may be enabled. NTLM is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM version 2 (“NTLMv2”) was concocted to address the security issues present in NTLM. By default, the ISNTLMV2 flag is set to No, indicating that NTLMv2 is not enabled by default on the target Microsoft SQL host. Set this flag to Yes if NTLMv2 is enabled on the target host.
IsPassive	If the value chosen is Yes, then the Microsoft SQL server under consideration is a passive server in a SQL cluster. No alerts will be generated if the server is not running. Measures will be reported as “Not applicable" by the agent if the server is not up.
SSL	By default, the SSL flag is set to No, indicating that the target Microsoft SQL server is not SSL-enabled by default. To enable the test to connect to an SSL-enabled Microsoft SQL server, set the SSL flag to Yes.
Force Strict Encryption	This parameter specifies whether SQL Server connections must always use certificate-based encryption. By default, this parameter is set to No, which means connections can proceed even if encryption is not strictly enforced. When set to Yes, the SQL Server JDBC driver requires all connections to be encrypted using valid certificates.
Hostname in Certificate	Specify the host name that will be validated against the SQL Server TLS/SSL certificate when encrypted communication is enabled using TLS.
Truststore Filename	This parameter is applicable only if SSL-enabled channel is used for communication to the target SQL server, if not, set this parameter to none. Truststore is used to store certificates from Certified Authorities (CA) that verify and authenticate the certificate presented by the server in an SSL connection. Therefore, the eG agent should have access to the truststore where the certificates are stored to authenticate and connect with the target server and collect metrics. For this, first extract the certificates from the server into the following default location /opt/egurkha/jre/lib/security/egmqsslstore.jks.
Truststore Password and Confirm Password	If a Truststore File name or file path is provided, then, in this text box, provide the password that is used to obtain the associated certificate details from the Truststore File. Confirm the password by retyping it in this text box.
DD Frequency	Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Total checks	Indicates the total number of compliance checks executed on the server.	Number	A higher value shows that multiple checks are being validated. Used as the baseline to compare successful and failed checks.
Successful checks	Indicates the number of compliance checks that passed successfully.	Number	A low value for this measure indicates many compliance gaps. Use the detailed diagnosis of this measure to find out the Category, Parameter, Current Value, Expected Value, Result and Description.
Failed checks	Indicates the number of compliance checks that failed.	Number	A high number of failed checks suggests significant compliance risks or misconfigurations. Admins should investigate these failed checks promptly. Use the detailed diagnosis of this measure to find out the Category, Parameter, Current Value, Expected Value, Result and Description.
Percentage of failed checks	Indicates the percentage of compliance checks that failed.	Percent	A low value is desired for this measure. A high value indicates that a large proportion of compliance checks have failed, highlighting serious configuration gaps or security vulnerabilities. This means the server is at significant compliance risk and may not meet organizational or regulatory standards. Administrators should immediately review the failed checks, identify root causes, and take corrective actions to restore compliance.