In this short video we’ll share six ways to help protect your SQL Servers.

Protect your SQL Server

Spoiler alert! Six steps to protect help protect your SQL Server from attack:

1. If at all possible, don’t expose your SQL Server directly to the internet. Protect them behind a firewall and other multi-layered security measures.
2. Don’t allow weak passwords for sa or any other accounts. Enforce rigorous password complexity requirements.
3. Patch often. Review and apply the latest cumulative updates and applicable hotfixes from Microsoft frequently.
4. Disable the sa account. It’s a well-known login that has unfettered access to the SQL Server instance.
5. Audit failed login attempts and review all newly created logins regularly.
6. Proactively monitor and check your SQL Servers frequently.

These six steps are by no means a comprehensive list of all the security measures that should be taken to protect your SQL Servers. They are just a start, the often overlooked but basic steps to help reduce the surface area of attack on your Microsoft SQL Servers.

By following these steps, along with the others listed here, you can protect your SQL Servers from Malware.

The post Protect Your SQL Server from MrbMiner and Other Malware Attacks appeared first on The SERO Group.

Checking for the “Default” username

You can check for the presence of this login by running the query below. If found, a full network audit is recommended.

--Verify the default account doesn't exist.  No results is a good thing.
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
WHERE [name] = 'Default'

What if you already had a login named “Default”? Determine if the password was recently changed to “@fg125kjnhn987” and if there have been any recent login failures. Review for any recently created logins as well. Are all logins accounted for? Were any created that you were not aware of? If so, review each further to determine what permissions they have and identify what they’re being used for.

--Review recently created logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY create_date desc

Review recently modified logins.

--Review recently modified logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY modify_date desc

Avoid making your SQL Servers easy targets

By utilizing security best practices, most brute-force attacks can be stopped. Or, at the very least, set off alarm bells and whistles to alert you of suspicious activity. Below is a list of do’s and don’ts we typically recommend. This is not an exhaustive list.

Don’t

1. Don’t expose your SQL Servers to the internet (if at all possible). Use a VPN to access externally.
2. Don’t use weak passwords (for any account).
3. Don’t add your SQL Server service accounts to the local admin group.
4. Don’t grant your SQL Server service accounts more permissions than required.
5. Don’t grant logins more permissions than required.
6. Don’t install additional services which are not required. SQL Server licenses include not only the database engine, but integration services, analysis services, and reporting services as well (at the time of this post). It’s easy enough to go ahead and install these additional services but also increases the attack surface area. Only install what is required.
7. Don’t enable additional options, within SQL Server, if unneeded. For example, xp_cmdshell, Ole Automation Procedures, and ad hoc distributed queries.

Do

1. Patch often. Review latest cumulative update, service pack releases, and hotfixes. Start here.
2. Implement a policy in which an account will become locked out after X number of attempts.
3. Change passwords often.
4. Audit the creation of new logins (and review the audits often 😉).
5. Disable the SA account. This account is well known and has unfettered access.
6. If not required, don’t use SQL Server authentication.
7. Review failed login attempts. Especially those occurring numerous times within a short span of time. This could be an indication of a brute-force attempt.
8. Implement a process to audit using guidelines such as the US government Security Technical Implementation Guides (STIGs) or Center for Internet Security (more on these below).
9. Review the health and performance metrics of your SQL Servers regularly.
10. Proactively monitor your SQL Servers to look for unexpected deviations of resource consumption.

Audit your environment

These types of exploits can typically be avoided. Implementing good security practices can be a painful process (not only from a technical perspective but also from the staff and end user perspective). The following guides provide a large set of information and scripts to get you started with securing your environment.

CIS – Center for Internet Security

CIS Benchmarks are consensus-developed secure configuration guidelines for hardening. There are benchmarks for operating systems, server software, cloud providers, network devices etc. Take a look here for a list of what they have to offer. SQL Server specific benchmarks can be found at https://www.cisecurity.org/benchmark/microsoft_sql_server/. There are some aspects of the site which requires membership but includes additional tools. Well worth the consideration.

National Vulnerability Database

The NCP is the U.S. government repository of publicly available security checklists which provide guidance on setting the security configuration of operating systems and applications. The checklists (STIG) can be downloaded as a zip. To view, download and install the STIG Viewer from https://public.cyber.mil/stigs/srg-stig-tools/ and follow the instructions.

How we can help

Security is constantly evolving. Setting up good policies around platform hardening, password complexity and rotation, and using accounts with the least privilege required is a daunting task for any organization. Especially those without dedicated security or database administrators. I’m hopeful a few of the resources above can get you started on the right path. We’re here to help as well. If you’d like assistance in assessing your SQL Servers, schedule a call with us here.

Thanks for reading!

The post Am I affected by MrbMiner malware? appeared first on The SERO Group.

Guardicore has released a PowerShell script that examines servers to determine if they’ve been infected. We’ve safely run the scripts on SQL Servers in our lab environment and for many of our clients.

If you routinely apply regular updates to your servers, practice the Principle of Least Privilege, regularly change critical passwords, have stringent password complexity requirements, and don’t expose your SQL Servers directly to the internet, the likelihood of a brute force attack succeeding is greatly reduced.

Here are six scripts that can help determine your level of potential exposure.

Who Has sysadmin or serveradmin Privileges?

The Vollgar attack is a brute force attack that attempts to guess the password for SQL Logins with elevated privileges. To be successful it needs logins that can execute sp_configure to change server-level settings. This are implicitly held by the sysadmin and serveradmin fixed server roles.

So, the first step in determining your exposure to Vollgar is to discover the members of the sysadmin and serveradmin roles. The following script will show you the members of each role.

USE master; 
GO

EXEC sp_helpsrvrolemember
	'sysadmin';

EXEC sp_helpsrvrolemember
	'serveradmin';

In my sample database, the following is returned.

Another approach to retrieving the same information in one consolidated result set is to use the following script.

--list of logins that are members of the sysadmin or serveradmin roles
SELECT SP1.[name] AS 'Login',
	SP2.[name] AS 'ServerRole'
FROM sys.server_principals AS SP1
	JOIN sys.server_role_members AS SRM 
		ON SP1.principal_id = SRM.member_principal_id
	JOIN sys.server_principals AS SP2 
		ON SRM.role_principal_id = SP2.principal_id
WHERE SP2.[name] IN ('sysadmin', 'serveradmin')
ORDER BY SP2.[name],
	 SP1.[name];

As expected, this script produces the same results.

Of course, it’s best practice to only grant the minimum rights required by each login, a practice known as least privilege. If these queries return more logins than absolutely necessary, it’s time to review your security practices.

Who has Passwords that Do Not Expire and without Password Complexity Requirements?

Having a complex password and changing it regularly is part of the basic blocking and tackling of security. Passwords like “Password123”, “Qwerty”, and “Puddles!” can be cracked in very short order using tools freely available on the web. And if these passwords never expire, users have no reason to change them regularly, making them even more of a liability.

For Windows Integrated Authentication, password complexity and expiration is handled at the network domain level. For SQL logins, these are enforced inside of SQL Server.

To find active SQL logins (e.g. not disabled) that do not require a basic level of complexity and are set to not expired, run the following script.

--Active SQL Logins where passwords do not expire
--and do not have complexity requirements 
SELECT name, 
	type_desc, 
	create_date, 
	modify_date, 
	default_database_name
FROM sys.sql_logins
WHERE is_expiration_checked = 0
	 AND is_disabled = 0 
	 AND is_policy_checked = 0 ; 

In my sample system, the script produces the following list.

Regularly changing passwords creates a moving target for potential attackers. If you have SQL logins that do not expire and do not have minimum complexity requirements, consider turning these features on for all your logins.

Putting some of the above queries together will give us a list of all active SQL logins that are members of the sysadmin or serveradmin fixed server roles along with whether their logins adhere to password complexity and expiration policies.

--list of SQL logins that are members of the sysadmin or serveradmin roles
SELECT SP1.[name] AS 'Login',
	SP2.[name] AS 'ServerRole',
	CASE l.is_disabled WHEN 1 THEN 'No' ELSE 'Yes' END AS Is_Enabled,
	CASE l.is_expiration_checked WHEN 1 THEN 'Yes' ELSE 'No' End AS Pwd_Expires,
	CASE l.is_policy_checked WHEN 1 THEN 'Yes' ELSE 'No' END AS Pwd_Complexity_Reqs
FROM sys.server_principals AS SP1
	JOIN sys.server_role_members AS SRM
	ON SP1.principal_id = SRM.member_principal_id
	JOIN sys.server_principals AS SP2
	ON SRM.role_principal_id = SP2.principal_id
	JOIN sys.sql_logins AS l
	ON l.principal_id = SRM.member_principal_id
WHERE SP2.[name] IN ('sysadmin', 'serveradmin')
ORDER BY SP2.[name],
	 SP1.[name];

The following results are returned on my test system.

When was a SQL Login Password Changed?

From the prior two queries, we can see that Alice and Donnie are both active members of the sysadmin fixed server role. Donnie’s password doesn’t expire and doesn’t have to meet any password complexity requirements. Of course, this is a big red flag for security. Alice’s login, on the other hand, is set to adhere to complexity and expiration requirements. That’s good.

But how long has it been since Alice actually changed her password? We can use the LOGINPROPERTY() function to help us. Note: that for the function to return meaningful information, both CHECK_POLICY and CHECK_EXPIRATION must be enabled for the login.

--when was a login's password last changed?
SELECT 'Alice' AS username,
	LOGINPROPERTY('Alice', 'PasswordLastSetTime') AS PasswordLastSetTime;

In this case, we can see that Alice last set her password on March 26, 2020.

We can use other properties in the LOGINPROPERTY() function, such as BadPasswordCount and BadPasswordTime. I wouldn’t rely too heavily on the results, though. The BadPasswordCount is reset to 0 as soon as Alice successfully logs in. And, just as importantly, it’s only relevant for those SQL Logins who have CHECK_POLICY and CHECK_EXPIRATION enabled.

--bad password attempts
SELECT name, 
	LOGINPROPERTY(name, 'BadPasswordCount') AS BadPasswordCount,
	LOGINPROPERTY(name, 'BadPasswordTime') AS BadPasswordTime
FROM sys.sql_logins 
WHERE is_expiration_checked = 1
	AND is_disabled = 0 
	AND is_policy_checked = 1; 

The results from my test system are shown below.

How to See Failed Login Attempts

Assuming your SQL Server is configured to log failed login attempts, and of course it should be, you can query the error log files using the sp_readerrorlog procedure to see the failed attempts.

EXEC sp_readerrorlog 0, 1, 'Login failed' ;

The following is returned on my test system.

Better yet, use a monitoring tool to proactively monitor failed login attempts and alert when a minimum threshold is exceeded. For our DBA as a Service clients, we provide SentryOne‘s SQLSentry monitoring tool to help with this and other events that should be monitored.

Parting Thoughts

Many years ago, I set up a test system for a writing project I was involved with. As part of the test, I set the sa password to something like “Cat123Dog!” The password met most requirements of the day – upper and lower case, at least one number and one letter, and a special symbol. “Not bad,” I thought to myself.

Then I downloaded Ophcrack, a free Windows password cracker, and released it on my unsuspecting SQL Server. Expecting the utility to run for hours, if not days, I returned to work.

A few minutes later, I decided to check on it, wanting to make sure it wasn’t hung for some reason. I was stunned. Ophcrack had already found the password! That was at least 10 years ago. I’m sure the tools of the hacker trade have gotten much better since then.

Recently, I’ve read where most breaches are a result of social engineering – someone receives an e-Card from a secret admirer, finds a thumb drive in the parking lot, or clicks an email link. “The days of brute force attacks are over,” they say.

Vollgar has proven them wrong. Basic security measures are still best practice. You owe it to yourself to make sure you’re doing it well. Here are a few links that may help.

• Introduction to SQL Server Security
• Securing SQL Server
• SQL Server Security Checklist

The post Vollgar: 6 Scripts to Help Review Your SQL Servers appeared first on The SERO Group.

What version is my SQL Server currently running?

There are several ways to check the version of SQL Server you’re currently running – all of them documented in countless places on the the web. Checking the instance property page in Management Studio and executing SELECT @@VERSION are two of the more common.

My preference is to run the following script using SERVERPROPERTY. When used in combination with Central Management Server, you can check the current level for all the SQL Server instances in your environment with one click of the Execute button.

SELECT
	SERVERPROPERTY('servername') AS Server_Name,
	SERVERPROPERTY('edition') AS Edition,
	SERVERPROPERTY('productlevel') AS Product_Level, 
	SERVERPROPERTY('productversion') AS Product_Version,
	SERVERPROPERTY('productupdatelevel') AS Product_Update_Level,
	SERVERPROPERTY('productupdatereference') AS Product_Update_Reference,
	SERVERPROPERTY('resourceversion') AS Resource_Version, 
	@@VERSION AS Version_Information 

Running the query on my Docker container instance returns the following.

Keep in mind that SERVERPROPERTY can behave slightly differently for older versions of SQL Server. ProductUpdateLevel and ProductUpdateReference, for instance, were introduced as part of SQL Server 2012. When run against an older version, such as SQL Server 2005, these will return NULL.

Running against another older SQL Server produces the following. Still, it gives you the information you need.

So, is that up to date or not for this version of SQL Server?

What is the latest update level for my version of SQL Server?

To answer that question, let’s turn to the definitive source – Microsoft. Microsoft has gotten into a fairly predictable cadence of regularly releasing updates for SQL Server. To help us keep track of the releases they’ve provided a SQL Docs page that lists all versions of SQL Server for the past 20 years. Yes, all the way back to SQL Server 2000.

The list shows the Product Version, the Latest Service Pack (if applicable), the Latest GDR (General Distribution Release), the Latest cumulative update (CU), the CU Release Date, and a link to some General Guidance for the each version. Here’s what the site looks like today, March 31, 2020.

Not sure of the difference in a SP, GDR, and CU? Here’s a blog post I wrote 12 years ago when I blogged at SQLTeam that explains the vernacular.

Additional Information

Here are a few other links that may help.

• SQL Server Release Blog – A Micosoft Tech Community blog dedicated to SQL Server Releases.
• SQL Server Builds Blog – I particularly like this blog since it shows each version along with relevant build numbers.
• SQL Server Updates – Brent Ozar also maintains a great site for keeping track of version update information.

The post Is There an Update for My SQL Server? appeared first on The SERO Group.

Free SQL Server Training Resources

Often these IT Professionals, sometimes called “Accidental DBAs,” do an admirable job, even with little formal SQL Server training. Fortunately, there are a lot of great resources available online for the “Accidental DBA.” Here are a few free SQL Server learning resources worth checking out:

1. Microsoft Resources and Labs

Microsoft has put together quite a few learning opportunities available to the public for free. These are in several different formats so you can pick the one you’re most comfortable with. Here are a few you may want to check out:

1. Microsoft SQL Server 2019 (CTP 3.2) Lab. In this self-paced lab, you’ll learn how to use SQL Server 2019 to solve business challenges.
2. Microsoft AI School. Artificial Intelligence is a hot topic in today’s business environment. In Microsoft AI School, you’ll “find the information, learning materials, and resources you need to start building intelligence into your solutions.”
3. SQL Server Tutorials. More than just Online Documentation, SQL Docs is a great place for detailed information about how to use SQL Server. It includes tutorials that will step you through learning the database technology.
4. EdX. Founded by Harvard and MIT, EdX is a place where education is freely available to everyone online. Microsoft has partnered with EdX to provide free courses online for SQL Server. Here are a few:
   • Querying Data with Transact-SQL.
   • Developing SQL Databases.
   • Analyzing and Visualizing Data with SQL Server Reporting Services.
5. Channel 9. Microsoft produces a lot of video content for SQL Server and other products. They make it available online via Channel 9.

2. YouTube Channels

YouTube can be a great resource for learning just about anything. From changing a tire to playing the ukulele, you can find it on YouTube. It should come as no surprise that there are a lot of great SQL Server training videos available as well. Of course, since just about anyone can create a video, you’ll want to be careful. Not everyone is the expert that they portend to be online. Do your own research. Here are a couple of places to start.

1. SQL Server YouTube Search. A list of SQL Server-related videos.
2. Microsoft SQL Server YouTube Channel. Microsoft SQL Server home on YouTube.

3. SQLSaturdays and Virtual Groups

For many years, I was on the board of Directors for a global user group called PASS. The organization is committed to providing learning opportunities for professionals around the globe and to helping the community to better connect with one another. There are a couple of ways PASS helps with this.

1. SQLSaturdays are a series of free one-day training events in cities around the world. These events, as the name suggests are held on Saturdays and are free to attend. They typically have some of the best and most well-known SQL Server experts around. Look for a SQLSaturday near you and plan to attend. You’ll see some great content and better yet make some incredible connections.
2. Virtual Groups. Through live webinars, PASS Virtual Groups offer top-notch training no matter where you happen to be. Check out a list of upcoming webinars.

Summary

With a new release every 18 to 24 months, keeping up with the latest changes can be a challenge. Hopefully, these free resources will help. We also have an ever growing SQL Script Library available to help get you started with some of the more common tasks.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Want to Learn SQL Server? Here Are 3 Free Sources appeared first on The SERO Group.

What does that mean?

It means that Microsoft will no longer release any updates for any version of SQL Server 2008. That includes security patches and data integrity fixes. If a hacker finds a zero-day vulnerability and publishes it to the web for all ne’er-do-wells to use, it won’t be fixed. If a new issue is discovered that could lead to data corruption or loss, no fix will be forthcoming. Discover a performance problem? Forget about it. It’s yours alone.

It’s not that Microsoft is heartless or doesn’t care. They do. But they understandably can’t support a version indefinitely. And we’ve known for a long time that this train would leave the station.

Yet many companies are still using SQL Server 2008 and SQL Server 2008 R2 for a lot of different reasons. Too many other projects, fear of a complicated upgrade path, wanting to bundle it with a larger initiative, and simply not knowing where to start are commonly cited reasons for not upgrading. Yet.

What are your options?

Now, the day has come and SQL Server 2008 has officially been mothballed. So, what can you do?

1. The “Do Nothing” Option

If SQL Server 2008 has been working well for you and you don’t see a need to upgrade, it may be that you don’t have to do anything. You could simply continue working as you currently are for a while longer and then sunset the aging applications in due course.

But before you get too excited about this, remember what you’ll forfeit, both now and in the future. Microsoft will not release any hot patches, service patches, cumulative updates, or anything else for the database platform. That’s bad, but that’s not all.

You will also be limited on your operating system upgrades. (Keep in mind that Windows Server 2008 will not be supported after January 14, 2020.)

And if you do decide to upgrade, there will be a substantial amount of technical debt to pay down. The longer you wait, the further entrenched the dated software will become and the more difficult it will be to upgrade or remove.

Although this option may be right for some organizations or instances of SQL Server, it should not be considered for any system that is connected to the internet in any way, even through a VPN. It is risky enough without the possibility of accidentally introducing malicious code.

2. The “One-for-One Upgrade” Option

Sometimes the most straightforward approach is the best approach. If you only have a handful of SQL Servers, you may be able to spin up a new virtual server for each existing database server and migrate to the new servers. This one-for-one approach makes planning and even execution relatively easy. Relatively.

To do it right, however, will take a bit of thought. Before doing anything, you’ll want to run the Data Migration Assistant to check for any potential issues with the upgrade. The DMA will help identify discontinued or deprecated features that your older systems may be using. It’ll also help you discover any potential breaking or behavioral changes that you should be aware before you upgrade.

You’ll also want to make sure you right-size the new environment and configure the new SQL Servers appropriately. Then you can migrate the databases, logins, users, jobs, linked servers, etc. to the new servers. You’ll also want to consider the service accounts used and how they access network resources such as shares used for backups.

Check out our free 5 Common Issues That May Be Putting Your SQL Server At Risk PDF for some common configuration issues we find during our SQL Assessments.

Of course, this option doesn’t consider potential gains that may be realized through server consolidation.

3. The “Consolidation Upgrade” Option

For environments with say ten to forty SQL Servers, it’s worth considering a new SQL Server landscape. The existing SQL Server environment probably grew organically over time without a lot of planning or forethought. New applications were purchased and the easiest thing to do was to spin up a new SQL Server instance for it. Over time, the number of database servers sprawled and now you may have more licenses than you actually need.

The upgrade project is a perfect time to (re)evaluate your landscape.

For this option, you’ll want to:

• Identify the scope and breadth of the project
• Run the Data Migration Assistant to look for possible upgrade issues
• Determine vendor and licensing requirements
• Collect and analyze performance data for each server to determine potential consolidation candidates
• Determine a preliminary consolidation design
• Plan and execute the project

Depending on the scope, you may also want to include a High Availability / Disaster Recovery component to the project.

4. The “Combination” Upgrade

For many environments, especially larger or more complex ones, a combination approach will likely be required, one that incorporates elements from each of the first three options.

Some applications and their associated SQL Servers will be identified as “on their way out” and the first “Do Nothing” approach will be adopted. Use them as-is until you can get rid of them.

Other servers will likely need to be upgraded using the “one-for-one” approach. This will likely apply for larger database servers where resources are a concern. It may also be the case for specific application servers whose vendors insist on sysadmin privileges to the SQL Server. You’ll likely want to separate those application databases to restrict what the vendor has access to.

The majority of the SQL Servers will hopefully be considered candidates for potential consolidation, thus saving some licensing costs and simplifying your environment.

Which option is right for you?

As with most technical questions, the answer is: it depends. There is no clear one-size-fits-all approach for an upgrade project. Consider your timeline and budget, the business requirements and the other projects you have on your plate. Then make the best decision you can.

Not sure where to start? Or don’t have the bandwidth to tackle the upgrade project? We can help. We’ve walked this path before and can help guide you as you take the journey. Give us a call and let’s talk.

The post 4 Options Now That Your SQL Server 2008 Is Out of Support appeared first on The SERO Group.

The scary part is that behind many IIS web sites sits the honeypot that the hackers are after: customer and other proprietary data in a Microsoft SQL Server database. Many websites, such as customer portals, online stores, software-as-a-service sites, and others, contain specific information about individuals that, if exposed, will cost the company dearly.

As my friend and SQL Server expert Steve Jones (@way0utwest) recently tweeted:

“The amount of shareholder value that can be lost due to a data breach is the amount of shareholder value you have.” 

Agreed. A well-targeted attack can bring down a company.

Fortunately, Microsoft SQL Server can be made extremely secure if configured properly. Encryption, Role-based security, Auditing, and other mechanisms allow administrators to define, limit, and monitor access at a very granular level.

The problem is that not all SQL Servers are configured properly. Over 96% of the SQL Server instances we’ve assessed deviate from industry best practices in security, performance, or other configurations. This is troubling.

What can you do? Spend some time with your application developers, with your system and network administrator, and with your DBA team to review the layers of security designed into your systems. Are the Windows Servers patched and up to date? Have the appropriate rules been defined in your firewalls? And, of course, are your SQL Servers configured properly?

Not sure where to start with security for your SQL Servers? Review the following:

• Overview of SQL Server Security
• Securing SQL Server
• MSDN SQL Server Security Blog
• MSSQLTips SQL Server Security Tips

Have questions? Give us a call. Our SQL Server Configuration Assessments maybe a good place for you to start.

The post Are Your SQL Servers Safe? IIS Attacks Increased 782x in One Quarter appeared first on The SERO Group.

In the SQL Server world, we have industry best practices. These are guidelines that most every knowledgeable database professional will agree is a good idea or a good baseline. Sure there are exceptions, specific tweaks to accommodate certain workloads, but the best practices are a generally a good starting point. Then you can customize for your needs.

As part of our practice, we regularly examine SQL Server instances to ensure they are configured with industry best practices in mind. We check configuration settings, maintenance jobs, and alerts, among other things, to help ensure the systems are protected and highly available.

Our findings: 9 out of 10 SQL Server instances we assess do not adhere to these industry best practices. Now, this isn’t a scientific study conducted by Forrester Research. Rather it’s our direct experiences working with hundreds of SQL Servers and clients.

Why Aren’t Most SQL Servers Configured with Best Practices?

We’ve found five predominant reasons for this.

SQL Server is so easy to set up

Many years ago, I taught a bunch of Oracle DBAs how to install, configure, and administer SQL Server. The hands-on lab allocated an hour for the installation, They were incredulous. “It can’t be done that quickly.” But it was. Find the media, double-click Setup, click Next-Next-Next, and it’s installed. Unfortunately, that’s where many people stop. They accept all of the defaults and never go back to configure the instance properly. The defaults are not best practices.

SQL Server just works

Even with the defaults, SQL Server is pretty responsive and resilient. It’s a testament to the quality of the product. You can neglect it, take it for granted, and still it keeps on keeping on. We’ve assessed (and subsequently remediated) systems that haven’t been touched in years. No patches applied. No maintenance performed. Nothing but users hitting it every day. Yet, it still works. That doesn’t mean it’s good or safe. In fact, we are frequently called into a new client because something has gone terribly wrong and the company needs help getting SQL Server out of the ditch. The better care you take of your SQL Server, the better it will be to you.

Introducing the accidental DBA

Many IT organizations don’t have the need for a full-time, dedicated Database Administrator. They only have a few SQL Server instances with 10 or 20 databases. Hiring a DBA isn’t in the cards. But someone has to care for the databases, has to think about backups and restores, disaster recovery, and high availability. Someone has to throw hardware at the problem when performance suffers. That’s when the CIO, a network admin, or an application developer steps up to do it in their “spare” time. These are smart, capable people with no spare time to give to SQL Server. “If an ain’t broke, don’t fix it” becomes the defacto approach since the accidental DBA is super busy with her day job.

Duct-taping with hardware

When a performance problem creeps into a production server, often the first recourse is to simply throw hardware at the problem. Reports taking too long? Add some CPUs! Imports not processing fast enough? Get faster disks! Application not responsive enough? Increase the RAM! Hardware can cover a multitude of SQL sins. But adding hardware gets expensive. Although the cost of hardware continues to go down, licensing costs do not. Adding an additional 8 CPUs to an Enterprise Edition of SQL Server can be expensive. And even if you have the really deep pockets to do it, hardware doesn’t address the root cause or protect your system any better.

Everyone has their own standards

Many IT organizations hire capable DBAs and let them do their jobs. That’s good. However, without a common playbook and set of standardized scripts, each DBA will handle things slightly differently, or worse, manually, and the result will be widely varying configurations. No two instances are the same. One instance may have 1 tempdb file on the C:\ and another has 8 somewhere else. One instance may have a patchwork of scheduled jobs and another may not have any. It’s like a box of chocolates. That makes troubleshooting difficult and performance unpredictable.

So, What Should You Do?

Best practices are exactly that, best practices. They are settings and techniques that should be adopted and applied to your SQL Server instances. Then you can tune based on your specific needs.

So, what should you do?

The first step is to know what you’re dealing with. Just how big is this elephant you’re about to eat? Assess your SQL Servers to see just how far from the best practices they really are. Then you can make a plan for updating them. Check out Is My SQL Server Configured Properly? for more information on assessing your SQL Server.

When we do assessments for companies, we have a standard script we run on each instance that looks for departures from best practices. That allows us to effectively collect, analyze, and report on the state of each instance. Sometimes there are good reasons for the variances and we discuss the rationale behind those decisions. Often we find that some remediation is recommended and we help to prioritize the findings so you’ll know where the biggest bang for your buck is. Learn about our SQL Server Assessments.

Whether you use our services or not, I’d recommend that you adopt a similar approach: identify what needs to change, prioritize the items, create a plan to remediate, and then work the plan.

In a coming post, I’ll share some of the things we look for when we assess an instance.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Why 9 Out of 10 SQL Servers Aren’t Configured with Best Practices appeared first on The SERO Group.